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

[Rolf Fokkens <rolf.fokkens@wanadoo.nl>]

[-- Attachment #1: Type: text/plain, Size: 6380 bytes --]

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@home01 ~]# ifconfig tap0 hw ether BA:B7:73:58:E6:E2
    SIOCSIFHWADDR: Device or resource busy
    [root@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@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@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@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@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@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@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
>


[-- Attachment #2: Type: text/html, Size: 10272 bytes --]