[c-nsp] VRF and STATIC ROUTE to GLOBAL

[Tony]

--- On Tue, 24/2/09, Joe Maimon <jmaimon at ttec.com> wrote:
> From: Joe Maimon <jmaimon at ttec.com>
> Subject: Re: [c-nsp] VRF and STATIC ROUTE to GLOBAL
> To: "Luan Nguyen" <luan at netcraftsmen.net>
> Cc: cisco-nsp at puck.nether.net
> Date: Tuesday, 24 February, 2009, 11:45 PM
> 
> 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.
>

--snip--
 
> 
> 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)
> 

I tried routing from global to VRF on a 3550-EMI switch a few months ago and did indeed run into performance issues.

With no VRF I was able to get line-speed (ie. near 100Mbps) routing performance, even using PBR. This is what we expect out of a 3550 switch.

I then set it up with a static route so that the next hop from the global route table was into a VRF via a CAT5 crossover cable connecting two physical ports in the same switch (one in the VRF, one not in VRF).  When I did this I found that traffic was being process switched. I could only get about 75Mbps throughput with 100% CPU (or near enough to 100%). I tried a couple of different IOS and found one would actually get up to 90Mbps but still max CPU (must be some optimisations in that IOS code).

I then changed the config so I was using PBR to route into the VRF and the performance dropped substantially. This time I was getting about 35Mbps with 100% CPU. Different code with this config was less variance, always somewhere 33-35Mbps.

I don't know how other platforms go, but that was my experience on a 3550 and shows that your assumption about VRF & PBR routing being the same feature/code path is quite likely (at least in 3550).

I was testing this for something we're trying to do in production, but had to give it up and do it differently due to the performance problems I ran into.


regards,
Tony.