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-boun...@puck.nether.net
[mailto:cisco-nsp-boun...@puck.nether.net] On Behalf Of Jeff Fitzwater
Sent: Monday, February 23, 2009 10:56 AM
To: cisco-nsp@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@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@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@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
