All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.