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
|
