[PATCH 1/2] bridge: leave carrier on for empty bridge

[PATCH 1/2] bridge: leave carrier on for empty bridge

[Stephen Hemminger]

[-- Attachment #1: br-carrier-default.patch --]
[-- Type: text/plain, Size: 1058 bytes --]

This resolves a regression seen by some users of bridging.
Some users use the bridge like a dummy device. 
They expect to be able to put an IPv6 address on the device
with no ports attached. Although there are better ways of doing
this, there is no reason to not allow it.

Note: the bridge still will reflect the state of ports in the
bridge if there are any added.

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

---
This fix needs to go to stable as well since it has
been reported as a regression.


--- a/net/bridge/br_device.c	2011-09-01 08:52:27.596631192 -0700
+++ b/net/bridge/br_device.c	2011-09-01 09:01:03.256611801 -0700
@@ -91,7 +91,6 @@ static int br_dev_open(struct net_device
 {
 	struct net_bridge *br = netdev_priv(dev);
 
-	netif_carrier_off(dev);
 	netdev_update_features(dev);
 	netif_start_queue(dev);
 	br_stp_enable_bridge(br);
@@ -108,8 +107,6 @@ static int br_dev_stop(struct net_device
 {
 	struct net_bridge *br = netdev_priv(dev);
 
-	netif_carrier_off(dev);
-
 	br_stp_disable_bridge(br);
 	br_multicast_stop(br);
 

Re: [PATCH 1/2] bridge: leave carrier on for empty bridge

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 03 Oct 2011 21:14:45 -0700

> This resolves a regression seen by some users of bridging.
> Some users use the bridge like a dummy device. 
> They expect to be able to put an IPv6 address on the device
> with no ports attached. Although there are better ways of doing
> this, there is no reason to not allow it.
> 
> Note: the bridge still will reflect the state of ports in the
> bridge if there are any added.
> 
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied to 'net' and queued up for -stable.

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

[Stephen Hemminger]

[-- Attachment #1: bridge-multicast-filter.patch --]
[-- Type: text/plain, Size: 5475 bytes --]

This is based on an earlier patch by Nick Carter with comments
by David Lamparter but with some refinements. Thanks for their patience
this is a confusing area with overlap of standards, user requirements,
and compatibility with earlier releases.

It adds a new sysfs attribute 
   /sys/class/net/brX/bridge/group_fwd_mask
that controls forwarding of frames with address of: 01-80-C2-00-00-0X
The default setting has no forwarding to retain compatibility.

One change from earlier releases is that forwarding of group
addresses is not dependent on STP being enabled or disabled. This
choice was made based on interpretation of tie 802.1 standards.
I expect complaints will arise because of this, but better to follow
the standard than continue acting incorrectly by default.

The filtering mask is writeable, but only values that don't forward
known control frames are allowed. It intentionally blocks attempts
to filter control protocols. For example: writing a 8 allows
forwarding 802.1X PAE addresses which is the most common request.

Reported-by: David Lamparter <equinox@diac24.net>
Original-patch-by: Nick Carter <ncarter100@gmail.com>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>


---
 net/bridge/br_device.c   |    2 ++
 net/bridge/br_input.c    |   12 ++++++------
 net/bridge/br_private.h  |   11 +++++++++++
 net/bridge/br_sysfs_br.c |   34 ++++++++++++++++++++++++++++++++++
 4 files changed, 53 insertions(+), 6 deletions(-)

--- a/net/bridge/br_device.c	2011-10-03 11:08:42.648254251 -0700
+++ b/net/bridge/br_device.c	2011-10-03 11:08:43.932271613 -0700
@@ -358,6 +358,8 @@ void br_dev_setup(struct net_device *dev
 	memcpy(br->group_addr, br_group_address, ETH_ALEN);
 
 	br->stp_enabled = BR_NO_STP;
+	br->group_fwd_mask = BR_GROUPFWD_DEFAULT;
+
 	br->designated_root = br->bridge_id;
 	br->bridge_max_age = br->max_age = 20 * HZ;
 	br->bridge_hello_time = br->hello_time = 2 * HZ;
--- a/net/bridge/br_input.c	2011-10-03 11:08:32.944122866 -0700
+++ b/net/bridge/br_input.c	2011-10-03 11:18:31.063811030 -0700
@@ -162,14 +162,37 @@ rx_handler_result_t br_handle_frame(stru
 	p = br_port_get_rcu(skb->dev);
 
 	if (unlikely(is_link_local(dest))) {
-		/* Pause frames shouldn't be passed up by driver anyway */
-		if (skb->protocol == htons(ETH_P_PAUSE))
+		/*
+		 * See IEEE 802.1D Table 7-10 Reserved addresses
+		 *
+		 * Assignment		 		Value
+		 * Bridge Group Address		01-80-C2-00-00-00
+		 * (MAC Control) 802.3		01-80-C2-00-00-01
+		 * (Link Aggregation) 802.3	01-80-C2-00-00-02
+		 * 802.1X PAE address		01-80-C2-00-00-03
+		 *
+		 * 802.1AB LLDP 		01-80-C2-00-00-0E
+		 *
+		 * Others reserved for future standardization
+		 */
+		switch (dest[5]) {
+		case 0x00:	/* Bridge Group Address */
+			/* If STP is turned off,
+			   then must forward to keep loop detection */
+			if (p->br->stp_enabled == BR_NO_STP)
+				goto forward;
+			break;
+
+		case 0x01:	/* IEEE MAC (Pause) */
 			goto drop;
 
-		/* If STP is turned off, then forward */
-		if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
-			goto forward;
+		default:
+			/* Allow selective forwarding for most other protocols */
+			if (p->br->group_fwd_mask & (1u << dest[5]))
+				goto forward;
+		}
 
+		/* Deliver packet to local host only */
 		if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
 			    NULL, br_handle_local_finish)) {
 			return RX_HANDLER_CONSUMED; /* consumed by filter */
--- a/net/bridge/br_private.h	2011-10-03 11:08:32.888122106 -0700
+++ b/net/bridge/br_private.h	2011-10-03 11:18:22.967713859 -0700
@@ -29,6 +29,11 @@
 
 #define BR_VERSION	"2.3"
 
+/* Control of forwarding link local multicast */
+#define BR_GROUPFWD_DEFAULT	0
+/* Don't allow forwarding control protocols like STP and LLDP */
+#define BR_GROUPFWD_RESTRICTED	0x4007u
+
 /* Path to usermode spanning tree program */
 #define BR_STP_PROG	"/sbin/bridge-stp"
 
@@ -193,6 +198,8 @@ struct net_bridge
 	unsigned long			flags;
 #define BR_SET_MAC_ADDR		0x00000001
 
+	u16				group_fwd_mask;
+
 	/* STP */
 	bridge_id			designated_root;
 	bridge_id			bridge_id;
--- a/net/bridge/br_sysfs_br.c	2011-10-03 11:08:32.920122541 -0700
+++ b/net/bridge/br_sysfs_br.c	2011-10-03 11:08:43.932271613 -0700
@@ -149,6 +149,39 @@ static ssize_t store_stp_state(struct de
 static DEVICE_ATTR(stp_state, S_IRUGO | S_IWUSR, show_stp_state,
 		   store_stp_state);
 
+static ssize_t show_group_fwd_mask(struct device *d,
+			      struct device_attribute *attr, char *buf)
+{
+	struct net_bridge *br = to_bridge(d);
+	return sprintf(buf, "%#x\n", br->group_fwd_mask);
+}
+
+
+static ssize_t store_group_fwd_mask(struct device *d,
+			       struct device_attribute *attr, const char *buf,
+			       size_t len)
+{
+	struct net_bridge *br = to_bridge(d);
+	char *endp;
+	unsigned long val;
+
+	if (!capable(CAP_NET_ADMIN))
+		return -EPERM;
+
+	val = simple_strtoul(buf, &endp, 0);
+	if (endp == buf)
+		return -EINVAL;
+
+	if (val & BR_GROUPFWD_RESTRICTED)
+		return -EINVAL;
+
+	br->group_fwd_mask = val;
+
+	return len;
+}
+static DEVICE_ATTR(group_fwd_mask, S_IRUGO | S_IWUSR, show_group_fwd_mask,
+		   store_group_fwd_mask);
+
 static ssize_t show_priority(struct device *d, struct device_attribute *attr,
 			     char *buf)
 {
@@ -652,6 +685,7 @@ static struct attribute *bridge_attrs[]
 	&dev_attr_max_age.attr,
 	&dev_attr_ageing_time.attr,
 	&dev_attr_stp_state.attr,
+	&dev_attr_group_fwd_mask.attr,
 	&dev_attr_priority.attr,
 	&dev_attr_bridge_id.attr,
 	&dev_attr_root_id.attr,

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

[Benjamin Poirier]

On 11-10-03 21:14, Stephen Hemminger wrote:
> This is based on an earlier patch by Nick Carter with comments
> by David Lamparter but with some refinements. Thanks for their patience
> this is a confusing area with overlap of standards, user requirements,
> and compatibility with earlier releases.
> 
> It adds a new sysfs attribute 
>    /sys/class/net/brX/bridge/group_fwd_mask
> that controls forwarding of frames with address of: 01-80-C2-00-00-0X
> The default setting has no forwarding to retain compatibility.
> 
> One change from earlier releases is that forwarding of group
> addresses is not dependent on STP being enabled or disabled. This
> choice was made based on interpretation of tie 802.1 standards.
> I expect complaints will arise because of this, but better to follow
> the standard than continue acting incorrectly by default.
> 
> The filtering mask is writeable, but only values that don't forward
> known control frames are allowed. It intentionally blocks attempts
> to filter control protocols. For example: writing a 8 allows
> forwarding 802.1X PAE addresses which is the most common request.
> 

Indeed, I have tested this patch with kvm + tap + bridge to
authenticate/authorize a virtual machine connected to a 802.1X enabled
switch. It works swell.

Tested-by: Benjamin Poirier <benjamin.poirier@gmail.com>

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

[Ben Hutchings]

On Mon, 2011-10-03 at 21:14 -0700, Stephen Hemminger wrote:
> plain text document attachment (bridge-multicast-filter.patch)
> This is based on an earlier patch by Nick Carter with comments
> by David Lamparter but with some refinements. Thanks for their patience
> this is a confusing area with overlap of standards, user requirements,
> and compatibility with earlier releases.
> 
> It adds a new sysfs attribute 
>    /sys/class/net/brX/bridge/group_fwd_mask
> that controls forwarding of frames with address of: 01-80-C2-00-00-0X
> The default setting has no forwarding to retain compatibility.
> 
> One change from earlier releases is that forwarding of group
> addresses is not dependent on STP being enabled or disabled. This
> choice was made based on interpretation of tie 802.1 standards.
> I expect complaints will arise because of this, but better to follow
> the standard than continue acting incorrectly by default.
> 
> The filtering mask is writeable, but only values that don't forward
> known control frames are allowed. It intentionally blocks attempts
> to filter control protocols. For example: writing a 8 allows
> forwarding 802.1X PAE addresses which is the most common request.
[...]

I wonder why you don't forbid forwarding frames sent to reserved
destination addresses?  The standards seem pretty clear that this should
not be allowed.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

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

[Stephen Hemminger]

On Wed, 05 Oct 2011 20:40:19 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:

> On Mon, 2011-10-03 at 21:14 -0700, Stephen Hemminger wrote:
> > plain text document attachment (bridge-multicast-filter.patch)
> > This is based on an earlier patch by Nick Carter with comments
> > by David Lamparter but with some refinements. Thanks for their patience
> > this is a confusing area with overlap of standards, user requirements,
> > and compatibility with earlier releases.
> > 
> > It adds a new sysfs attribute 
> >    /sys/class/net/brX/bridge/group_fwd_mask
> > that controls forwarding of frames with address of: 01-80-C2-00-00-0X
> > The default setting has no forwarding to retain compatibility.
> > 
> > One change from earlier releases is that forwarding of group
> > addresses is not dependent on STP being enabled or disabled. This
> > choice was made based on interpretation of tie 802.1 standards.
> > I expect complaints will arise because of this, but better to follow
> > the standard than continue acting incorrectly by default.
> > 
> > The filtering mask is writeable, but only values that don't forward
> > known control frames are allowed. It intentionally blocks attempts
> > to filter control protocols. For example: writing a 8 allows
> > forwarding 802.1X PAE addresses which is the most common request.
> [...]
> 
> I wonder why you don't forbid forwarding frames sent to reserved
> destination addresses?  The standards seem pretty clear that this should
> not be allowed.

Future proofing. Since addresses are unassigned there is no certainty of the
assigned semantics when they are used.

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

[David Miller]

From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 03 Oct 2011 21:14:46 -0700

> This is based on an earlier patch by Nick Carter with comments
> by David Lamparter but with some refinements. Thanks for their patience
> this is a confusing area with overlap of standards, user requirements,
> and compatibility with earlier releases.
> 
> It adds a new sysfs attribute 
>    /sys/class/net/brX/bridge/group_fwd_mask
> that controls forwarding of frames with address of: 01-80-C2-00-00-0X
> The default setting has no forwarding to retain compatibility.
> 
> One change from earlier releases is that forwarding of group
> addresses is not dependent on STP being enabled or disabled. This
> choice was made based on interpretation of tie 802.1 standards.
> I expect complaints will arise because of this, but better to follow
> the standard than continue acting incorrectly by default.
> 
> The filtering mask is writeable, but only values that don't forward
> known control frames are allowed. It intentionally blocks attempts
> to filter control protocols. For example: writing a 8 allows
> forwarding 802.1X PAE addresses which is the most common request.
> 
> Reported-by: David Lamparter <equinox@diac24.net>
> Original-patch-by: Nick Carter <ncarter100@gmail.com>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>

Applied to net-next.

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

[Ed Swierk]

Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
testing LLDP in a virtual topology and need the bridge to forward
them.

If we're worried about standards, there is justification for allowing
forwarding of LLDP frames. 802.1d-2005 specifies two classes of
bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
just new terminology for what was previously just called an
802.1d-compliant bridge, while provider bridge is a new class that
transparently forwards certain control frames.

The only MAC addresses that are not supposed to be forwarded by either
customer or provider bridges are:

IEEE 802.3 Full Duplex PAUSE operation (01-80-C2-00-00-01)
IEEE 802.3 Slow_Protocols_Multicast address (01-80-C2-00-00-02)
IEEE 802.1X PAE address (01-80-C2-00-00-03)
Provider Bridge Group Address (01-80-C2-00-00-08)

Customer bridges are also not supposed to forward these addresses:

Bridge Group Address (01-80-C2-00-00-00)
Provider Bridge GVRP Address (01-80-C2-00-00-0D)
IEEE 802.1AB Link Layer Discovery Protocol multicast address (01-80-C2-00-00-0E)

My application requires a bridge between a pair of interfaces that
forwards (at least) LLDP frames; call this a provider bridge if you
care about standards conformance. It sounds like others require
forwarding 802.1X PAE frames, which appears non-conformant in any
case.

Standards aside, given that the default behavior is safe and that
/sys/class/net/brX/bridge/group_fwd_mask is unlikely to be modified by
accident by a casual user, can we just remove the
BR_GROUPFWD_RESTRICTED mask and allow users to forward whatever they
want?

--Ed

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

[Stephen Hemminger]

On Mon, 17 Oct 2011 07:35:53 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:

> Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
> testing LLDP in a virtual topology and need the bridge to forward
> them.
> 
> If we're worried about standards, there is justification for allowing
> forwarding of LLDP frames. 802.1d-2005 specifies two classes of
> bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
> just new terminology for what was previously just called an
> 802.1d-compliant bridge, while provider bridge is a new class that
> transparently forwards certain control frames.


Because in current 802.1Q (2005) standard there explicit language
that LLDP should not be forwarded. In Section 7.5

	Frames that carry control information to determine the active
	topology and current extent of each VLAN, i.e., spanning tree
	and GVRP BPDUs, and frames from other link constrained
	protocols, such as EAPOL and LLDP, are not forwarded.
	Permanently configured static entries in the filtering database
	(8.2, 8.3, and 8.12) ensure that such frames are discarded by
	the Forwarding Process (8.6).

> The only MAC addresses that are not supposed to be forwarded by either
> customer or provider bridges are:
> 
> IEEE 802.3 Full Duplex PAUSE operation (01-80-C2-00-00-01)
> IEEE 802.3 Slow_Protocols_Multicast address (01-80-C2-00-00-02)
> IEEE 802.1X PAE address (01-80-C2-00-00-03)
> Provider Bridge Group Address (01-80-C2-00-00-08)
>
> Customer bridges are also not supposed to forward these addresses:
> 
> Bridge Group Address (01-80-C2-00-00-00)
> Provider Bridge GVRP Address (01-80-C2-00-00-0D)
> IEEE 802.1AB Link Layer Discovery Protocol multicast address (01-80-C2-00-00-0E)
> 
> My application requires a bridge between a pair of interfaces that
> forwards (at least) LLDP frames; call this a provider bridge if you
> care about standards conformance. It sounds like others require
> forwarding 802.1X PAE frames, which appears non-conformant in any
> case.
> 
> Standards aside, given that the default behavior is safe and that
> /sys/class/net/brX/bridge/group_fwd_mask is unlikely to be modified by
> accident by a casual user, can we just remove the
> BR_GROUPFWD_RESTRICTED mask and allow users to forward whatever they

Since EAPOL is allowed, and there is a use case for LLDP, allowing
that is probably okay.

I would prefer not to let user break standards by default. You of course are
free to compile what ever you want

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

[Ross Brattain]

On Mon, 17 Oct 2011 07:35:53 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:

> Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
> testing LLDP in a virtual topology and need the bridge to forward
> them.
> 
> If we're worried about standards, there is justification for allowing
> forwarding of LLDP frames. 802.1d-2005 specifies two classes of
> bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
> just new terminology for what was previously just called an
> 802.1d-compliant bridge, while provider bridge is a new class that
> transparently forwards certain control frames.

01-80-C2-00-00-0E should not pass the physical link.  If it does it will affect PFC 802.1Qbb and ETS 802.1Qaz.

802.1AB-2009 is more specific.  See Table 7-1 Group MAC addresses used by LLDP:

Nearest bridge: 01-80-C2-00-00-0E
Propagation constrained to a single physical link; stopped by all types of bridge

Nearest non-TPMR bridge: 01-80-C2-00-00-03
Propagation constrained by all bridges other than TPMRs; intended for use within provider bridged networks

Nearest Customer Bridge: 01-80-C2-00-00-00
Propagation constrained by customer bridges; this gives the same coverage as a customer-customer MACSec connection


--
Ross

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

[Ed Swierk]

Interesting, I didn't realize LLDP could use any of those addresses.

I finally got a peek at the hot-off-the-presses IEEE 802.1Q-2011, and
notice that 01-80-C2-00-00-0E is now assigned as "Individual LAN Scope
group address, Nearest bridge group address" rather than dedicated to
LLDP specifically.

Since our application is generating the LLDP frames we could change it
to use -00 or -03 and let the Linux bridge drop the -0E frames.

--Ed

On Mon, Oct 17, 2011 at 1:53 PM, Ross Brattain
<ross.b.brattain@intel.com> wrote:
> On Mon, 17 Oct 2011 07:35:53 -0700
> Ed Swierk <eswierk@bigswitch.com> wrote:
>
>> Why is forwarding LLDP (01-80-C2-00-00-0E) frames forbidden? I'm
>> testing LLDP in a virtual topology and need the bridge to forward
>> them.
>>
>> If we're worried about standards, there is justification for allowing
>> forwarding of LLDP frames. 802.1d-2005 specifies two classes of
>> bridge, customer (C-VLAN) and provider (S-VLAN). Customer bridge is
>> just new terminology for what was previously just called an
>> 802.1d-compliant bridge, while provider bridge is a new class that
>> transparently forwards certain control frames.
>
> 01-80-C2-00-00-0E should not pass the physical link.  If it does it will affect PFC 802.1Qbb and ETS 802.1Qaz.
>
> 802.1AB-2009 is more specific.  See Table 7-1 Group MAC addresses used by LLDP:
>
> Nearest bridge: 01-80-C2-00-00-0E
> Propagation constrained to a single physical link; stopped by all types of bridge
>
> Nearest non-TPMR bridge: 01-80-C2-00-00-03
> Propagation constrained by all bridges other than TPMRs; intended for use within provider bridged networks
>
> Nearest Customer Bridge: 01-80-C2-00-00-00
> Propagation constrained by customer bridges; this gives the same coverage as a customer-customer MACSec connection
>
>
> --
> Ross
>

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

[Ross Brattain]

On Mon, 17 Oct 2011 14:09:34 -0700
Ed Swierk <eswierk@bigswitch.com> wrote:

> Interesting, I didn't realize LLDP could use any of those addresses.
> 
> I finally got a peek at the hot-off-the-presses IEEE 802.1Q-2011, and
> notice that 01-80-C2-00-00-0E is now assigned as "Individual LAN Scope
> group address, Nearest bridge group address" rather than dedicated to
> LLDP specifically.
> 

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.

> Since our application is generating the LLDP frames we could change it
> to use -00 or -03 and let the Linux bridge drop the -0E frames.
> 

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.

I have no idea if any LLDP agents support the optional group MAC addresses.

--
Ross

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

[Ed Swierk]

On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
<ross.b.brattain@intel.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

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

[John Fastabend]

On 10/17/2011 4:36 PM, Ed Swierk wrote:
> On Mon, Oct 17, 2011 at 4:07 PM, Ross Brattain
> <ross.b.brattain@intel.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.