Cisco VRF – Leak Default Route to Multiple VRFs While Keeping VRFs Isolated

bgpcisco-nx-osnat;vrf-lite

I'm working on a configuring stuff on a Cisco Nexus 3k based platform and trying to isolate different things into different VRFs which should not be able to talk to each other.

Some of these VRFs have RFC1918 addressing but need to be able to reach the internet so we have set up a VRF aptly called nat in which a default route is advertised by NAT gateways. We need these gateways because this particular model of Nexus does not support NAT itself.

It set up BGP to leak the default route from vrf nat to vrf blue. And the other way around, of course, because the return packets need to be able to get to the hosts in vrf blue. This is working great.

Now I want to do the same thing for vrf red but if I leak 0.0.0.0/0 from vrf nat to vrf red, hosts in vrf red will be able to reach hosts in vrf blue by being routed through vrf nat by the default route. And vice-versa.

All the examples I've seen of multiple vrfs with a common shared vrf maintain isolation between red and blue by filtering what prefixes are being redistributed/announced. That doesn't help me because I want to announce 0.0.0.0/0 in its entirety to both vrf red and vrf blue.

Is there a good way to do this or do I need to let go of the concept of a shared NAT vrf and give the NAT gateways interfaces in all the natted VRFs?

Best Answer

Turns out, it is possible :)

At first we had some difficulty getting redistribution of the default route from OSPF to the BGP instance used for route leaking working. So I ended up 'just' doing a network 0.0.0.0/0 in (router bgp 65000 > vrf nat > address-family ipv4 unicast).

But when I managed to redistribute the default route from OSPF into the vrf, the result in terms of the routing tables of vrf blue and vrf red looked identical as with the static approach but behaviour was different. In this case the switches are smart enough to not actually forward packets from vrf red to vrf blue and vice versa even though the route table suggests it would.

Related Solutions

Integrating Router into LAN – Best Practices

1.) Yes, the gateways should reside on the L3 switch. If you were running Routing on a Stick, you would instead house their gateways on the Router. Your current configuration is inline with what is called a "collapsed core" design. Where the L3 core performs both switching and VLAN routing and acts as a distribution layer.

2.) No, your L3 routing should be occuring on your 3750.

3.)If the cable modem is in bridge mode, there should be no double NAT. Bridge mode should disable all the routing features and leave the cable modem as just a cable modem.

4.) I would, just so you can hit devices on the seperate VLANs.

5.) The address of the inside interface of the Cable modem may be .1. Leave it as it is. Like Ron said, it doesn't need to be changed.

Can we see the NAT configuration of your router? It will be helpful in identifying your NAT issue.

****EDIT****

This link may be helpful: Configuring NAT I failed to take note of the NAT statement you had originally. This brings into question the claims made by your ISP. You're both able to hit the internet and your being PAT'd with the correct commands. Are you experiencing any problems?

Junos VRF – Equal-Cost Multi-Next-Hop Static Routes Not Balancing

It appears that you're applying the load balancing policy to the routing-instance. It needs to be applied to the forwarding-table in order for it to perform ECMP on the forwarding plane.

routing-options {
     forwarding-table {
          export load-balancing-policy;
     }
}

To confirm it's working, you should see something similar to this. Note the additional entry on the forwarding table for entry 10.0.0.0/24.

# run show route forwarding-table table {client}
Routing table: {client}.inet
Internet:
Destination        Type RtRef Next hop           Type Index NhRef Netif
default            user     0 8:5b:e:84:4c:b0    ucst   561     3 ge-1/1/2.3017
default            perm     0                    rjct   961     1
0.0.0.0/32         perm     0                    dscd   959     1
10.0.0.0/24        user     0 196.33.144.3       ucst   589     5 ge-1/1/5.2100 *
10.0.0.0/24        user     0 196.33.144.11      ucst   645     6 gr-1/1/10.1   *
10.0.0.55/32       user     0                    ucst   645     6 gr-1/1/10.1
10.0.0.210/32      user     0                    ucst   645     6 gr-1/1/10.1
10.0.6.0/24        user     0                    ucst   921     3 gr-1/1/10.16
.
.

Best Answer

Related Solutions

Integrating Router into LAN – Best Practices

Junos VRF – Equal-Cost Multi-Next-Hop Static Routes Not Balancing

Related Topic