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 14:48:46 +0000	[thread overview]
Message-ID: <470A434E.9000103@riverviewtech.net> (raw)
In-Reply-To: <4705538C.7070403@riverviewtech.net>

On 10/06/07 06:16, John Default wrote:
> So, now i get it (after your first mail, it wasn't possible :)).  I 
> think the idea is great, but.
> 
> What everything would you we actually avoid ? For correct operation we 
> will have to look at destination IP anyway, skipping only ip header 
> check (iphdr checksum, version, maybe length check), which consists of 
> functions that are implemented in very quick way (sum through 20B 
> written in assembly..) (probably few tens of nanoseconds on 1GHz processor)

True...

> With the probability of damaged packet header we probably can skip 
> checking.  But there are some security problems that can arise from that.

Agreed.

> Then we avoid lookup in routing table. But routing already does have 
> cache (i don't know how effective) for routes to avoid doing the lookup 
> for each packet. Will this be much faster than route cache ?

> Bringing it down to lower, dumber layer we risk that we will somehow 
> mess up policy routing,  multipath routing and probably some other 
> advanced things.

> Another thing is that turning the l3 switching on, router will start to 
> behave little bit different as usually, what could confuse the 
> administrator ...

I'm not thinking about making this an all or nothing type of 
application.  I would rather turn on L3 switching as desired and use the 
existing kernel as is for any thing else.  The intent is to not mess 
things up, but optimize when basic routing will be the predominant task.

> What about NAT and other packet-changing things in iptables (and QoS 
> marking and the like)?  Stealing packet before layer3 processing we 
> avoid these things as well i think.  Hm this could really become a problem.
> There could be mechanism for detecting if packet is changed anyhow and 
> then we would not touch it, but if box is meant for changing packets, 
> then we would have to implement it too or process no packets at all 
> ...(you are right, who would use l3 switch for NAT : ) )

This, again, is not a scenario for L3 switching, at least not in its 
first incarnation.  However basic NATing would not be difficult to 
implement, just alter the source IP like the source MAC is altered.

> ... and you should probably decrement and check the ttl too : )

Agreed.

> I just mentioned few things that came to my mind that might need to be 
> considered. But otherwise i think the idea is very nice. I will try to 
> find out more, just need to find time to read the source ; )

These are all very good points and deserve to be addressed.  Thank you 
for discussing things, that's exactly what I was wanting.

> (disclaimer: I am just beginner, with my stupid questions i am just 
> trying to help your thinking process)

(See my last statement.)



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

  parent reply	other threads:[~2007-10-08 14:48 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 [this message]
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=470A434E.9000103@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.