--- On Tue, 24/2/09, Joe Maimon <[email protected]> wrote:
> From: Joe Maimon <[email protected]>
> Subject: Re: [c-nsp] VRF and STATIC ROUTE to GLOBAL
> To: "Luan Nguyen" <[email protected]>
> Cc: [email protected]
> 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.
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
