[LARTC] Layer 3 switching...

[Mohan Sundaram]

John Default wrote:
> Grant Taylor wrote:
>> On 10/05/07 05:05, John Default wrote:
>>> I was told that layer 3 switches are faster because "routing" there 
>>> is done by some ASIC hardware. Is there any advantage in having 
>>> another routing code in bridging when everything is done in software 
>>> which is same slow as normal routing? The only speed gain would be in 
>>> keeping the routing code very simple with limited functionality, but 
>>> i think that the trend is to put there more and more functionality 
>>> which would end up in having two same slow, same function code in two 
>>> places.
CISCO CEF works somewhat in this fashion for routing only. I've been 
building network gear for a while now.

I had this idea but no buyers. Route cache is for destination IPs 
normally. If the router does stateful filtering, then it has 
connections/ flows. Once a look up is done for a flow based on 
destination or policy routing, the exit interface with new packet header 
values and frame header value is also made part of the route cache. Thus 
the resultant of all L3/L2 actions are attached to a flow and used. This 
would include NAT translations.

The above idea gives good speed but fails for encapsulations, packet 
based load balancing and effecting inline change in configurations for 
existing flows. Being a commercial product, unless it is fully baked, it 
does not fly. User is responsible is also an arguement that is not 
accepted in such scenarios. Further this is IP specific and cannot do 
well in multi-protocol routers unless IP encapsulations like GRE are 
used as a standard.

An extension was to tie flows to MPLS labels but this was getting into 
core routing/switching space while focus was on CPE side.

Mohan