[Bridge] Why should static MAC address match one of the port MAC addresses - bug?

Rolf Fokkens rolf.fokkens at wanadoo.nl
Sun Dec 26 09:21:58 PST 2010


In this particular situation it's not possible to do so as all 
interfaces are tap interfaces, with random generated MAC addresses. 
Changing the tap interface's MAC address results in this:

    [root at home01 ~]# ifconfig tap0 hw ether BA:B7:73:58:E6:E2
    SIOCSIFHWADDR: Device or resource busy
    [root at home01 ~]#

So that doen't work. I found a trick however: I added a dummy ethernet 
interface to the bridge, of which i can specify the MAC address, It 
works fine, but in syslog there's the following message:

    Dec 26 17:45:21 home01 kernel: [   29.316480] br0: new device dummy0
    does not support netpoll (disabling)

This means that the bridge won't use/support netpoll at all, which may 
mean there's an impact on performance. I'm not sure. I can imagine that 
a netpoll interface for a dummy interface shouldn't be hard to implement.

Attempting to summarize:

    * specifying the MAC address of a bridge interface can result in
      confusing results
    * Allowing the changing of tap interfaces' MAC addresses could be
      sensible
    * A netpoll interface for dummy ethernet might be usefull for bridge
      users


On Mon, 20 Dec 2010 Stephen Hemminger wrote:

>  Yes, that is a problem.
>  If address does not match any of the interfaces assigned to bridge,
>  then it won't be in the forwarding table.

>  But, fixing it would introduce more issues because the forwarding
>  table entry would match any port in bridge..  Therefore for sanity,
>  don't assign mac address to something not in the bridge.


On 12/20/2010 09:03 PM, Rolf Fokkens wrote:
> Hi,
>
> I think that the bridge interface no longer sees unicast messages 
> addressed to it, after changing the MAC address. I'll explain:
>
> I chose a different MAC address, 02:77:00:00:01:02. This MAC address 
> is absolutely not present on another interface. The MAC address of the 
> Windows XP client is 02:00:00:00:00:01. The bridge interface br2 now 
> only has one interface tap0 which links to the Windows XP client.
>
> [root at home01 ~]# brctl show
> bridge name    bridge id        STP enabled    interfaces
> br0        8000.002215b81084    no        eth0.3
> br1        8000.002215b81084    no        eth0.4
> br2        8000.027700000102    no        tap0
> br3        8000.002215b81084    no        eth0.1253
>
> The IP address of the Windows XP guest is 192.168.252.1, the IP 
> address of the bridge interface is 192.168.252.254, which is the 
> default gateway address of the Windows XP guest.
>
> Now let's look at the ARP entries. First the Windows XP guest:
>
> C:\>arp -a
>
> Interface 192.168.252.1 --- 0x2
>   Internet Address   Physical Address      Type
>   192.168.252.254   02-77-00-00-01-02   dynamic
>
> Next on the Linux host:
>
> [root at home01 ~]# arp -n
> Address                  HWtype  HWaddress           Flags 
> Mask            Iface
> 192.168.254.7            ether   00:18:f3:fd:09:7a   
> C                     br1
> 192.168.254.18           ether   00:16:e8:29:bc:e3   
> C                     br1
> 192.168.1.1              ether   00:0e:50:64:7f:74   
> C                     br0
> 192.168.254.16           ether   90:84:0d:6f:26:1c   
> C                     br1
> 192.168.1.128            ether   00:21:85:98:45:84   
> C                     br0
> 192.168.252.1                    
> (incomplete)                              br2
> 192.168.254.9            ether   18:a9:05:39:14:95   
> C                     br1
> [root at home01 ~]#
>
> So now we see that the Windows XP guest is aware of the new MAC 
> address of the bridge. However the Linux host is not aware of the 
> guest's MAC address! Time to see what's happening when we use tcpdump:
>
> [root at home01 ~]# tcpdump -n -e -i tap0 arp
> tcpdump: WARNING: tap0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol 
> decode
> listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
>
> 20:42:23.606319 02:00:00:00:00:01 > Broadcast, ethertype ARP (0x0806), 
> length 42: Request who-has 192.168.252.254 tell 192.168.252.1, length 28
> 20:42:23.606359 02:77:00:00:01:02 > 02:00:00:00:00:01, ethertype ARP 
> (0x0806), length 42: Reply 192.168.252.254 is-at 02:77:00:00:01:02, 
> length 28
>
> 20:47:42.503536 02:77:00:00:01:02 > Broadcast, ethertype ARP (0x0806), 
> length 42: Request who-has 192.168.252.1 tell 192.168.252.254, length 28
> 20:47:42.504039 02:00:00:00:00:01 > 02:77:00:00:01:02, ethertype ARP 
> (0x0806), length 42: Reply 192.168.252.1 is-at 02:00:00:00:00:01, 
> length 28
> 20:47:43.505541 02:77:00:00:01:02 > Broadcast, ethertype ARP (0x0806), 
> length 42: Request who-has 192.168.252.1 tell 192.168.252.254, length 28
> 20:47:43.506316 02:00:00:00:00:01 > 02:77:00:00:01:02, ethertype ARP 
> (0x0806), length 42: Reply 192.168.252.1 is-at 02:00:00:00:00:01, 
> length 28
> 20:47:44.507539 02:77:00:00:01:02 > Broadcast, ethertype ARP (0x0806), 
> length 42: Request who-has 192.168.252.1 tell 192.168.252.254, length 28
> 20:47:44.508319 02:00:00:00:00:01 > 02:77:00:00:01:02, ethertype ARP 
> (0x0806), length 42: Reply 192.168.252.1 is-at 02:00:00:00:00:01, 
> length 28
>
> First we see an ARP request from the Windows XP guest to find the 
> host's 192.168.252.254. There is a fast ARP response, so this is 
> consistent with the ARP table on the Windows XP guest.
>
> Next we see an ARP request from the Linux host to find the guest's 
> 192.168.252.1. This is followed by a fast ARP response. Despite the 
> response both the request and the response are repeated 3 times. This 
> is consistent with the fact that the ARP table on the Linux host is 
> missing the guest's MAC address.
>
> So, apparently both interfaces (br2 and tap0) see the ethernet 
> broadcast, but only the guest's interface (tap0) sees the unicast. 
> This is confirmed by brctl's output:
>
> [root at home01 ~]# brctl showmacs br2
> port no mac addr           is local? ageing timer
>   1     02:00:00:00:00:01  no        5.38
>   1     82:7a:bf:ee:e8:5e  yes       0.00
> [root at home01 ~]#
>
> We see two interresting MAC addresses. the first one is the MAC 
> address of the Windows XP guest, which indeed is not local. The second 
> one is the MAC address of the tap0 interface on the host side, which 
> apparently is local. But where's the mac address of br0 itself? It's 
> missing.
>
> This seems unintentional to me.
>
> Rolf
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20101226/d319f373/attachment.htm 


More information about the Bridge mailing list