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
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
