Brett Frankenberger wrote:
Cisco has no support for:
ip route vrf vrfX x.x.x.x/x next-hop next-hop vrfY
where the traffic in vrfX matching that route would be sent over into vrfY
(and then forwarded according to vryY's forwarding table). (Some other
vendors can do that.) (In your case, you want "vrfY" to be "global",
but that's not doable either.)
I cracked open my MPLS books last night and found a similar solution
with an IP next-hop in the MPLS & VPN Arch book. It set the next-hop to
be an IP in the global VRF by using the 'global' keyword.
ip default vrf VRFx 0.0.0.0 0.0.0.0 1.2.3.4 global
It has the same problems as the other solution I found for setting the
next-hop to be an exit interface. I want the Ps to make a routing
decision to determine the exit path for the packet, not hardcode it to
go one way or another (and possibly have a iBGP-meshed BR1 decide that
the better exit point would be another BR and route that back to the
core P to get to BR2. This is why I was wondering if the target
interface or IP could be a loopback on the Ps. I really need to lab
these ideas.
The only clean way is to connect via an interface. For example,
connect a cable from GIa/b to GIc/d and then configure:
int GIa/b
ip address x.x.x.1/30
int GIc/d
ip vrf forwarding vrfX
ip address x.x.x.2/30
ip route vrf vrfX 0.0.0.0/0 GIc/d x.x.x.1
(obviosuly I'm not using exact IOS commands above, but you get the
idea.)
I thought about that and I could do that. It's an added expense though.
On some platforms, this can be done with tunnels instead of physical
interfaces to avoid using two physical ports and dealing with the risk
that those ports might fail:
int lo1
ip address z.z.z.10/32
int lo2
ip address x.x.x.20/32
int tun1
ip address x.x.x.1/30
tunnel source lo1
tunnel destination x.x.x.20
int tun2
ip vrf forwarding vrfX
ip address x.x.x.2/30
tunnel source lo2
tunnel destination x.x.x.20
ip route vrf vrfX 0.0.0.0/0 tun2
How well this works depends on how tunnels are implemented on the
platform you're using. It works fine on software-based routers.
ASR1000s worked OK in my testing. Never tried 6500/7600s.
This is a thought. I haven't tried it on 7600s either but it's worth
trying to see if it would work.
Note that the suggestion to leak default from your global table into
the VRF potentially fails on two accounts. First, you might or might
not have a default in your global table. Second, if you do, leaking
that would direct all internet traffic to follow the default route,
and, assuming you have default plus a lot of more other routes in your
global table, you wouldn't want traffic covered by a more-specific in
the global table to follow the default if it originated in vrfX. That
is, with a global table of:
100.0.0.0/8 -> A
0.0.0.0/0 -> B
if you import only 0.0.0.0/0 into a vrf, then all traffic matching the
default in that VRF will be sent to B, even traffic traffic to
100.0.0.0/8.
I originate a default in my IGP on each BR currently. I'm thinking
about moving that into iBGP though. I'll originate a default on the Ps
in the VRF with MP-iBGP. This touches on the problem I outlined above
talking about the Ps making the decision on exit path. My Ps are part
of the iBGP mesh with full tables from the BRs. In theory they should
make the same routing decision for a given packet that a BR will do when
it receives that same packet milliseconds later.
I'm going to try the importing of the default in the VRF statement. I
think that will work but I'll find out for sure with my testing. If it
doesn't then I may have to try the tunneling solution. I may have to
settle for inefficient routing for a few months until the ASR comes in
and then do tunnels on it. Either way I think I'm on the right track.
Thanks for the insight
Justin
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
