| Message ID | 20110926153630.3959b0ea@nehalam.linuxnetplumber.net |
|---|---|
| State | RFC, archived |
| Delegated to: | David Miller |
| Headers | show |
On Mon, 2011-09-26 at 15:36 -0700, Stephen Hemminger wrote: > The Linux bridge code would process all packets addressed to > the multicast address 01:80:C2:00:00:0X as local and > and never forward. This may have been correct in the ancient past, but > reading the relevant standards, the correct behavior is to handle only > the bridge group address as a special case and leave all other link > local multicast packets alone. I disagree. According to my reading, we must filter at least the addresses ending in 4-D or F, while forwarding of the others should be configurable. > Recently there has been some complaints about forwarding (or not) of > 802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the > 802.1 Bridging Working Group for point me in the correct direction. > The 802.1X-2010 standard Table 11-1 details how different > addresses are assigned based on connectivity associations. > > Bridge group address: 01-80-C2-00-00-00 > PAE group address: 01-80-C2-00-00-03 > Link Layer Discovery 01-80-C2-00-00-0E [...] This table is informative, non normative. The text below refers to 802.1D table 7-9 (apparently should be 7-10) and 802.1Q table 8-1 as the sources. 802.1D-2004 section 7.12.6, Reserved addresses, says: Frames containing any of the group MAC Addresses specified in Table 7-10 in their destination address field shall not be relayed by the Bridge. They are configured in the Permanent Database. Management shall not provide the capability to modify or remove these entries from the Permanent or the Filtering Databases. In table 7-10 the reserved addresses are those with last digit in the range 4-F. 802.1Q-2005 section 8.6.3, Frame filtering, says: Each of the Reserved MAC Addresses specified in Table 8-1 shall be permanently configured in the Filtering Database in VLAN-aware Bridges. The Filtering Database Entries for Reserved MAC Addresses shall specify filtering for all Bridge Ports and all VLANs. Management shall not provide the capability to modify or remove entries for Reserved MAC Addresses. In table 8-1 the reserved addresses are those with last digit in the range 4-D or F. Ben.
On Tue, 27 Sep 2011 19:23:05 +0100 Ben Hutchings <bhutchings@solarflare.com> wrote: > On Mon, 2011-09-26 at 15:36 -0700, Stephen Hemminger wrote: > > The Linux bridge code would process all packets addressed to > > the multicast address 01:80:C2:00:00:0X as local and > > and never forward. This may have been correct in the ancient past, but > > reading the relevant standards, the correct behavior is to handle only > > the bridge group address as a special case and leave all other link > > local multicast packets alone. > > I disagree. > > According to my reading, we must filter at least the addresses ending in > 4-D or F, while forwarding of the others should be configurable. > > > Recently there has been some complaints about forwarding (or not) of > > 802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the > > 802.1 Bridging Working Group for point me in the correct direction. > > The 802.1X-2010 standard Table 11-1 details how different > > addresses are assigned based on connectivity associations. > > > > Bridge group address: 01-80-C2-00-00-00 > > PAE group address: 01-80-C2-00-00-03 > > Link Layer Discovery 01-80-C2-00-00-0E > [...] > > This table is informative, non normative. The text below refers to > 802.1D table 7-9 (apparently should be 7-10) and 802.1Q table 8-1 as the > sources. > > 802.1D-2004 section 7.12.6, Reserved addresses, says: > > Frames containing any of the group MAC Addresses specified in > Table 7-10 in their destination address field shall not be > relayed by the Bridge. They are configured in the Permanent > Database. Management shall not provide the capability to modify > or remove these entries from the Permanent or the Filtering > Databases. > > In table 7-10 the reserved addresses are those with last digit in the > range 4-F. > > 802.1Q-2005 section 8.6.3, Frame filtering, says: > > Each of the Reserved MAC Addresses specified in Table 8-1 shall > be permanently configured in the Filtering Database in > VLAN-aware Bridges. The Filtering Database Entries for Reserved > MAC Addresses shall specify filtering for all Bridge Ports and > all VLANs. Management shall not provide the capability to modify > or remove entries for Reserved MAC Addresses. > > In table 8-1 the reserved addresses are those with last digit in the > range 4-D or F. There is also a more recent 2011 edition of 802.1Q but it isn't available for free. Let me see if about getting it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
--- a/net/bridge/br_input.c 2011-09-16 13:12:58.061369744 -0700 +++ b/net/bridge/br_input.c 2011-09-26 11:57:41.724554692 -0700 @@ -126,18 +126,6 @@ static int br_handle_local_finish(struct return 0; /* process further */ } -/* Does address match the link local multicast address. - * 01:80:c2:00:00:0X - */ -static inline int is_link_local(const unsigned char *dest) -{ - __be16 *a = (__be16 *)dest; - static const __be16 *b = (const __be16 *)br_group_address; - static const __be16 m = cpu_to_be16(0xfff0); - - return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | ((a[2] ^ b[2]) & m)) == 0; -} - /* * Return NULL if skb is handled * note: already called with rcu_read_lock @@ -161,13 +149,10 @@ 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)) - goto drop; - - /* If STP is turned off, then forward */ - if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0) + /* Special handling for bridge group address */ + if (unlikely(compare_ether_addr(dest, br_group_address) == 0)) { + /* If STP is turned off, then act like a hub. */ + if (p->br->stp_enabled == BR_NO_STP) goto forward; if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
The Linux bridge code would process all packets addressed to the multicast address 01:80:C2:00:00:0X as local and and never forward. This may have been correct in the ancient past, but reading the relevant standards, the correct behavior is to handle only the bridge group address as a special case and leave all other link local multicast packets alone. Recently there has been some complaints about forwarding (or not) of 802.1X EAPOL frames by the bridge. Thanks to Tony Jeffree of the 802.1 Bridging Working Group for point me in the correct direction. The 802.1X-2010 standard Table 11-1 details how different addresses are assigned based on connectivity associations. Bridge group address: 01-80-C2-00-00-00 PAE group address: 01-80-C2-00-00-03 Link Layer Discovery 01-80-C2-00-00-0E Warning: this may mean that some people using bridge who expect link local packets to be isolated, now need to add firewall rules. But in my opinion, following the standard is the correct thing to do regardless. This means when using 802.1x with libvirt, there are several options: 1. Use macvtap not bridge 2. Turn off STP in libvirt 3. Use PAE group address for 802.1x 4. Provide a user level application using AF_LLC to forward the 802.2 frames Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html