netdev - Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1331129500.2237.72.camel@mojatatu>
Date:	Wed, 07 Mar 2012 09:11:40 -0500
From:	Jamal Hadi Salim <jhs@...atatu.com>
To:	Lennert Buytenhek <buytenh@...tstofly.org>
Cc:	John Fastabend <john.r.fastabend@...el.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	bhutchings@...arflare.com, roprabhu@...co.com,
	netdev@...r.kernel.org, mst@...hat.com, chrisw@...hat.com,
	davem@...emloft.net, gregory.v.rose@...el.com, kvm@...r.kernel.org,
	sri@...ibm.com, Chris Healy <chealy@...co-us.com>
Subject: Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into
 hardware

On Tue, 2012-03-06 at 15:09 +0100, Lennert Buytenhek wrote:

> Why so?  (I think the switch chips should just never do learning at
> all..)

I agree that learning in software gives you more flexibility; however,
I am for providing interface flexibility as well - switches have
learning features. I think i should be able to use them when it makes
sense to. 

> > I think it should also be upto the admin to decide whether the learning
> > happens in the kernel or user space.
> 
> I can't see any point in doing it in userspace.  What would be the
> advantage of that?  And based on what would the admin make the decision?
> 

If i wanted to do some funky access control based on some new MAC
address showing up - best place to do it is user space.

> It does, there is an STP state field per port in the switch chip,
> which controls whether learning takes place on this port (in
> Learning and Forwarding states) and whether packets are forwarded
> (in the Forwarding state).

ok, makes sense.

> But e.g. it doesn't automatically flush this port's FDB entries if
> you move a port from Forwarding to Listening -- the STP state field
> only controls direct learning and forwarding for received packets.
>
> And when you receive a BPDU with the topology change notification
> bit set, the switch won't automatically shorten the FDB entry
> timeout for you until the topology change is over, either.

I have to go back and look at some manuals i have - but iirc, the
ones ive played with behaved similarly.  As long as we provide knobs
to set/unset those different attributes, I think the handling of all
that should be from software (likely some daemon in user space);
then it shouldnt matter whether we are working with STP BPDUs or TRILL
or thenewprotocolTM etc. 

> Keep in mind that these chips also do VLAN tagging in hardware, and
> so a scenario like:
> 
> 	# brctl addbr br123
> 	# brctl addif br123 lan1.123
> 	# brctl addif br123 lan2.123
> 
> is also one that can be handled in hardware (which the current
> patchwork patch doesn't handle yet).
> 

We would need to work with offloading VLANs, no? Do the current
VLAN offloads used for NICs suffice for switching chips as well?
i.e typically most chips have a table associated with some port in
which the Vlan is partof or is the lookup key. 

> You can let the switch rate limit the number of packets passed up to
> the CPU.  500 kp/s broadcast traffic seems somewhat excessive in any
> case, and I'm not sure if this deserves handling apart from QoSing
> those streams to manageable levels.

Yes, that would provide a solution.
I havent seen anything where you can rate limit the learning(SA lookup
failure). 

cheers,
jamal

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html