From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Layer 3 switching...
Date: Mon, 08 Oct 2007 15:00:17 +0000 [thread overview]
Message-ID: <470A4601.4000106@riverviewtech.net> (raw)
In-Reply-To: <4705538C.7070403@riverviewtech.net>
On 10/06/07 07:27, Mohan Sundaram wrote:
> CISCO CEF works somewhat in this fashion for routing only. I've been
> building network gear for a while now.
*nod*
> 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.
Sounds like the route cache has been well thought out in the Cisco gear.
> 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.
I don't think that L3 switching that I'm referring to is meant to be
used in all locations, especially some of the ones that you reference.
However L3 switching would be good in a core network between edge and
core networks (presuming that there is no firewalling / filtering going
on between the two). I would never use a L3 switch as the interface to
WANs and / or the ISPs, at least not today in this day and age.
> An extension was to tie flows to MPLS labels but this was getting into
> core routing / switching space while focus was on CPE side.
I think MPLS in and of its own right is a very promising technology, all
be it somewhat isolated to larger networks with their own complex core.
Rather it is my understanding that MPLS is primarily intra company,
not inter company which is where I think it could have more benefit.
However I could be wrong about this. (If a discussion is going to
ensue, let's start a new thread.)
Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
prev parent reply other threads:[~2007-10-08 15:00 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
2007-10-08 14:48 ` Grant Taylor
2007-10-08 15:00 ` Grant Taylor [this message]
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=470A4601.4000106@riverviewtech.net \
--to=gtaylor@riverviewtech.net \
--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.