[c-nsp] VRF and STATIC ROUTE to GLOBAL
Joe Maimon
jmaimon at ttec.com
Tue Feb 24 07:45:52 EST 2009
There are apparently three approaches to trafficking between VRF's.
- configuration route leakage, static routes, route-maps and whatnot
All hacks in my opinion.
- physical crossover between two devices, vrf A in device A becomes vrf
B in device B
Which is actually a degenerate or optimized instance of the following:
- crossover in the same device
This can be done as per your tunnel example.
You can also do this with physical ports, with a l2/l3 switch
architecture its not as conveniently done however, since you would need
to cross connect one access port in one vlan to another access port in
another vlan.
For router ports, you can use dot1q and have many different crossovers.
I have been doing this for quite some time, as some may note, there are
issues you may run across that require static arp entries to workaround.
In my opinion, there is significant design benefits in using an
interface to traffic between vrf's, such as using routing protocols,
nat, firewall, security features and everything else designed to work at
interface level.
However, the downside is processing the packet twice.
(if you use tunnels, you should try to ensure that the tunnel MTU allows
1500 unfragmented)
I think it would be worthwhile to lab the two approaches, tunnel and
physical crossover and compare it with configuration leaking to come up
with some performance numbers.
<wishlisting>
In my opinion, this would be best served by a dedicated tunnel type,
allowing the device to optimize the path but still providing the same
benefits.
Something like:
ip vrf RED
ip vrf BLUE
int t0
ip vrf forwarding RED
ip address 10.1.1.1 255.255.255.252
tunnel source vrf RED
tunnel destination vrf BLUE
tunnel mode vrf-connect
int t1
ip vrf forwarding BLUE
ip address 10.1.1.2 255.255.255.252
tunnel source vrf BLUE
tunnel destination vrf RED
tunnel mode vrf-connect
Or Maybe:
ip vrf RED
rd 1:1
ip vrf BLUE
rf 1:2
int VRF1.1
ip address 10.1.1.1 255.255.255.252
xconnect vrf rd 1:1 rd 1:2
int VRF1.2
ip address 10.1.1.2 255.255.255.252
xconnect vrf rd 1:2 rd 1:1
Also, while in wishlisting mode, it would be nice if you could policy
route in a vrf (the most likely reason why the software doesnt allow you
to is that vrf processing is the same code/feature path as policy routing)
</wishlisting>
Joe
Luan Nguyen wrote:
> Instead of an external link with 2 physical ports, you could try to create a
> GRE tunnel with 2 loopback interfaces.
>
> interface Loopback0
> ip address 10.10.10.1 255.255.255.0
> !
> interface Loopback10
> ip address 10.10.100.1 255.255.255.0
> !
> interface Tunnel1
> ip vrf forwarding NSP
> ip address 172.16.1.1 255.255.255.0
> tunnel source Loopback0
> tunnel destination 10.10.100.1
> !
> interface Tunnel2
> ip address 172.16.1.2 255.255.255.0
> tunnel source Loopback10
> tunnel destination 10.10.10.1
>
>
> Then run OSPF...etc. I haven't try static route, but pretty sure it would
> work.
>
> router ospf 100 vrf NSP
> router-id 10.10.10.1
> log-adjacency-changes
> redistribute bgp 65535 subnets
> network 10.10.10.1 0.0.0.0 area 0
> network 172.16.1.1 0.0.0.0 area 0
> !
> router ospf 1
> router-id 10.10.100.1
> log-adjacency-changes
> network 10.10.100.1 0.0.0.0 area 0
> network 172.16.1.2 0.0.0.0 area 0
>
> Regards,
>
> ++++++++++++++++++++++++++++++++++++++++++++++++
> Luan Nguyen
> Chesapeake NetCraftsmen, LLC.
> [Web] http://www.netcraftsmen.net
> [Blog] http://cnc-networksecurity.blogspot.com/
> [Mobile] 703-953-9116
> +++++++++++++++++++++++++++++++++++++++++++++++++
>
> -----Original Message-----
> From: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Jeff Fitzwater
> Sent: Monday, February 23, 2009 10:56 AM
> To: cisco-nsp at puck.nether.net
> Subject: [c-nsp] VRF and STATIC ROUTE to GLOBAL
>
> This question was posted earlier, before I opened ticket with CISCO.
>
> Router is 6500 with 720-CXL running SXI code.
>
>
> 1. I have router "A" which is used to connect to our three ISPs ( two
> I1s and one I2 connection with full BGP), and also receives all our
> internal campus traffic via RIP default path. Router "A" announces
> default to campus.
>
> 2. I now need to add a new special ESNET.GOV ISP which cannot be used
> by the majority of our campus except for two subnets. These two
> subnets will still have access to the other three ISPs for normal path
> selection but have the option of choosing an ESNET route if needed.
>
> 3. So the original thinking was to create the VRF for ESNET which
> would have its own ESNET route table and tell the two special subnets
> (using route-map match subs, set vrf ) to check the ESNET table first
> and if route is not in table then fall thru to global.
>
> 4. I can't just have one route table that includes the ESNET routes,
> because ESNET announces some more specific routes and there may be
> hosts that normally use the I1 path to these DSTs, but now see a more
> specific path and try to use it and fail because it is not allowed by
> ESNET outbound ACL.
>
>
>
> I have BGP peering working in VRF ( can see prefixes from ESNET in VRF
> table), but cannot announce our two subnet prefixes because they do
> not show up in VRF route table. So getting static back to global
> would fix this and other issue with DEFAULT to global. When I try to
> add static routes they never show up because the next hop is not
> present in VRF table or the command fails stating that... "Invalid
> next-hop address (it's this router)".
>
>
>
> I was hoping that just adding a static DEFAULT in VRF pointing to
> global would do everything I needed, but cannot get it to work even
> after trying all permutations of the command. "ip route vrf vrf-esnet
> 0.0.0.0 0.0.0.0 0.0.0.0 global"
>
>
>
> Also tried "ip route vrf vrf-esnet 0.0.0.0 0.0.0.0 loopback3
> 10.10.10.10 global" Loopback3 was created with RFC-1918 IP and had
> "vrf forwarding" added on this loopback. This also failed.
>
>
> Creating an internal path between the VRF router and the global router
> is stopping all this from working.
>
> I have a ticket open with CISCO but they are saying I have to add an
> external link with two physical ports on vrf. This will not work for
> us.
>
>
> Does anybody know how to get statics working between VRF and global
> table, if its even possible.
>
>
> Really stuck!
>
>
>
> Jeff Fitzwater
> OIT Network Systems
> Princeton University
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
More information about the cisco-nsp
mailing list