netdev - Re: [PATCH 2/2] bridge: allow forwarding some link local frames

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] [day] [month] [year] [list]

Message-ID: <4E9CC195.8020404@intel.com>
Date:	Mon, 17 Oct 2011 17:00:21 -0700
From:	John Fastabend <john.r.fastabend@...el.com>
To:	Ed Swierk <eswierk@...switch.com>
CC:	"Brattain, Ross B" <ross.b.brattain@...el.com>,
	Stephen Hemminger <shemminger@...tta.com>,
	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] bridge: allow forwarding some link local frames

On 10/17/2011 4:36 PM, Ed Swierk wrote:
> On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
> <ross.b.brattain@...el.com> wrote:
>> 802.1AB-2009  Section 7.1 Destination address:
>>
>> NOTE 8—The destination MAC address used by a given LLDP agent defines only the scope of transmission and the
>> intended recipient(s) of the LLDPDUs; it plays no part in protocol identification. In particular, the group MAC addresses
>> identified in Table 7-1 are not used exclusively by LLDP; other protocols that require to use a similar transmission scope
>> are free to use the same addresses.
>> ...
>> If you control both end stations you could use the optional group MAC address support, or unicast LLDP.
>>
>> 802.1AB-2009  Section 7.1 Destination address:
>>
>> In addition to the prescribed support for standard group MAC addresses shown in Table 7-1,
>> implementations of LLDP may support the following destination addresses for LLDPDUs:
>> d) Any group MAC address.
>> e) Any individual MAC address.
>> Support for the use of each of these destination addresses, for both transmission and reception of LLDPDUs,
>> is either mandatory, recommended, permitted, or not permitted, according to the type of system in which
>> LLDP is implemented, as shown in Table 7-2.
> 
> Thanks for the references. I need to read the updated standards specs
> before jumping to conclusions...
> 
>> I have no idea if any LLDP agents support the optional group MAC addresses.
> 
> In our application we're both generating and consuming the LLDP
> frames. We're worried about standards conformance to the extent that
> we don't break other tools that might receive the LLDP frames we
> generate. As long as they don't care about the destination MAC address
> of the frames they receive (and they shouldn't), it's definitely
> feasible for us to use the "nearest customer bridge" address
> (01-80-C2-00-00-00) to ensure our LLDP frames traverse Linux bridges.
> 
> --Ed

Ed,

Its unclear what you mean by "and they shouldn't". If the other tool
is an LLDP daemon then it will receive the frame and process it as
a nearest customer bridge LLDPDU.

However it looks like your on the right track here. If your adding
a standard TLV you might consider adding support to an existing
agent. For example 'lldpad'.

Thanks,
John.

--
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