From: Mohan Sundaram <mohan.tux@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Layer 3 switching...
Date: Sat, 06 Oct 2007 12:39:18 +0000 [thread overview]
Message-ID: <47077F26.8030306@vsnl.com> (raw)
In-Reply-To: <4705538C.7070403@riverviewtech.net>
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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-10-06 12:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 20:56 [LARTC] Layer 3 switching Grant Taylor
2007-10-05 10:05 ` John Default
2007-10-05 14:48 ` Grant Taylor
2007-10-06 11:16 ` John Default
2007-10-06 12:39 ` Mohan Sundaram [this message]
2007-10-08 14:48 ` Grant Taylor
2007-10-08 15:00 ` Grant Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47077F26.8030306@vsnl.com \
--to=mohan.tux@gmail.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.