* [Bridge] rstp solutions
From: Andrew Woods @ 2011-01-08 17:34 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 146 bytes --]
Hi Stephen,
I would also really be interested in an RSTP update - please let me know
when you have sometime to work on it again.
Thanks,
Andrew
[-- Attachment #2: Type: text/html, Size: 205 bytes --]
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2011-01-06 19:33 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev, bridge
In-Reply-To: <AANLkTikb+o2tXg0uU92Q9foVqX2P49dhJX+umLX=Nhfn@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Wed, 5 Jan 2011 21:37:28 +0800
> On Tue, Jan 4, 2011 at 4:13 AM, David Miller <davem@davemloft.net> wrote:
>> From: Stephen Hemminger <shemminger@linux-foundation.org>
>>>
>>> Because PPPOE happens afterwards and is not part the calculation.
>>> The check should be moved until after skb has reached final form.
>>
>> That works for me.
>>
>
> So, is my patch acceptable?
Yes, I've applied it, thank you.
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Changli Gao @ 2011-01-05 13:37 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bridge
In-Reply-To: <20110103.121336.212692696.davem@davemloft.net>
On Tue, Jan 4, 2011 at 4:13 AM, David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@linux-foundation.org>
>>
>> Because PPPOE happens afterwards and is not part the calculation.
>> The check should be moved until after skb has reached final form.
>
> That works for me.
>
So, is my patch acceptable?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [Bridge] rstp solutions
From: Ryan Whelan @ 2011-01-03 20:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge
In-Reply-To: <20110103124838.0d4e558a@nehalam>
[-- Attachment #1: Type: text/plain, Size: 593 bytes --]
We just implemented MSTP in our datacenter, I could see it coming in handy
to help interoperate. Not being a programmer, there is likely little I
could offer to help- but if so, let me know.
Is it currently usable/stable?
On Mon, Jan 3, 2011 at 3:48 PM, Stephen Hemminger <
shemminger@linux-foundation.org> wrote:
> On Mon, 3 Jan 2011 15:43:53 -0500
> Ryan Whelan <rcwhelan@gmail.com> wrote:
>
> > there haven't been any updates to it in years, is it still being
> maintained?
> >
>
> It never got packaged or widely used.
> I want to do something better but never seem to get the time.
>
[-- Attachment #2: Type: text/html, Size: 971 bytes --]
^ permalink raw reply
* Re: [Bridge] rstp solutions
From: Stephen Hemminger @ 2011-01-03 20:48 UTC (permalink / raw)
To: Ryan Whelan; +Cc: bridge
In-Reply-To: <AANLkTimawR9j85MSVwSeq7vAozkYBLVhbR_fn1MA7X=o@mail.gmail.com>
On Mon, 3 Jan 2011 15:43:53 -0500
Ryan Whelan <rcwhelan@gmail.com> wrote:
> there haven't been any updates to it in years, is it still being maintained?
>
It never got packaged or widely used.
I want to do something better but never seem to get the time.
^ permalink raw reply
* Re: [Bridge] rstp solutions
From: Ryan Whelan @ 2011-01-03 20:43 UTC (permalink / raw)
To: bridge
In-Reply-To: <20110103081618.2dd26e7a@nehalam>
[-- Attachment #1: Type: text/plain, Size: 672 bytes --]
there haven't been any updates to it in years, is it still being maintained?
On Mon, Jan 3, 2011 at 11:16 AM, Stephen Hemminger <
shemminger@linux-foundation.org> wrote:
> On Sun, 2 Jan 2011 09:38:50 +0200
> tamar zeiri <tamarzeiri.ml@gmail.com> wrote:
>
> > Hi all
> > Can anyone recommend the best solution for rstp (2.6 kernel)?
> > Did anyone work with rstplib on real bridges?
> >
> > Thanks
>
> Did you look at rstp daemon?
> git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
>
[-- Attachment #2: Type: text/html, Size: 1396 bytes --]
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2011-01-03 20:13 UTC (permalink / raw)
To: shemminger; +Cc: netdev, bridge, xiaosuo
In-Reply-To: <20110103101533.3f98b311@nehalam>
From: Stephen Hemminger <shemminger@linux-foundation.org>
Date: Mon, 3 Jan 2011 10:15:33 -0800
> On Mon, 03 Jan 2011 09:22:14 -0800 (PST)
> David Miller <davem@davemloft.net> wrote:
>
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Mon, 3 Jan 2011 18:44:59 +0800
>>
>> > On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
>> >> From: Changli Gao <xiaosuo@gmail.com>
>> >> Date: Sat, 25 Dec 2010 21:41:30 +0800
>> >>
>> >>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>> >>> we should check the length of skb after it to handle the ppoe skbs.
>> >>>
>> >>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>> >>
>> >> This is really strange.
>> >>
>> >> packet_length() subtracts VLAN_HLEN from the value it returns, so the
>> >> correct fix seems to be to make this function handle the PPPOE case
>> >> too.
>> >>
>> >
>> > It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
>> > example, the MTU of ethernet is normally 1500, however the actual MTU
>> > of the 802.1Q is 1504.
>>
>> Yes, I understand this, but I don't see why packet_length() cannot
>> simply account for PPPOE's encapsulation overhead just as it does for
>> VLAN's special MTU considerations.
>
> Because PPPOE happens afterwards and is not part the calculation.
> The check should be moved until after skb has reached final form.
That works for me.
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Stephen Hemminger @ 2011-01-03 18:15 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bridge, xiaosuo
In-Reply-To: <20110103.092214.193706896.davem@davemloft.net>
On Mon, 03 Jan 2011 09:22:14 -0800 (PST)
David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Mon, 3 Jan 2011 18:44:59 +0800
>
> > On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
> >> From: Changli Gao <xiaosuo@gmail.com>
> >> Date: Sat, 25 Dec 2010 21:41:30 +0800
> >>
> >>> Since nf_bridge_maybe_copy_header() may change the length of skb,
> >>> we should check the length of skb after it to handle the ppoe skbs.
> >>>
> >>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> >>
> >> This is really strange.
> >>
> >> packet_length() subtracts VLAN_HLEN from the value it returns, so the
> >> correct fix seems to be to make this function handle the PPPOE case
> >> too.
> >>
> >
> > It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
> > example, the MTU of ethernet is normally 1500, however the actual MTU
> > of the 802.1Q is 1504.
>
> Yes, I understand this, but I don't see why packet_length() cannot
> simply account for PPPOE's encapsulation overhead just as it does for
> VLAN's special MTU considerations.
Because PPPOE happens afterwards and is not part the calculation.
The check should be moved until after skb has reached final form.
--
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2011-01-03 17:22 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev, bridge
In-Reply-To: <AANLkTingFk8qJ8tBwSRCxD=9k-0O3GnTv9V9TbF4N=bg@mail.gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Mon, 3 Jan 2011 18:44:59 +0800
> On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
>> From: Changli Gao <xiaosuo@gmail.com>
>> Date: Sat, 25 Dec 2010 21:41:30 +0800
>>
>>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>>> we should check the length of skb after it to handle the ppoe skbs.
>>>
>>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>>
>> This is really strange.
>>
>> packet_length() subtracts VLAN_HLEN from the value it returns, so the
>> correct fix seems to be to make this function handle the PPPOE case
>> too.
>>
>
> It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
> example, the MTU of ethernet is normally 1500, however the actual MTU
> of the 802.1Q is 1504.
Yes, I understand this, but I don't see why packet_length() cannot
simply account for PPPOE's encapsulation overhead just as it does for
VLAN's special MTU considerations.
^ permalink raw reply
* Re: [Bridge] rstp solutions
From: Stephen Hemminger @ 2011-01-03 16:16 UTC (permalink / raw)
To: tamar zeiri; +Cc: bridge
In-Reply-To: <AANLkTik3wm3GRA067N+oj9PFSwf_3gcqnkZEYUShNHrd@mail.gmail.com>
On Sun, 2 Jan 2011 09:38:50 +0200
tamar zeiri <tamarzeiri.ml@gmail.com> wrote:
> Hi all
> Can anyone recommend the best solution for rstp (2.6 kernel)?
> Did anyone work with rstplib on real bridges?
>
> Thanks
Did you look at rstp daemon?
git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Changli Gao @ 2011-01-03 10:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bridge
In-Reply-To: <20101231.111003.48499853.davem@davemloft.net>
On Sat, Jan 1, 2011 at 3:10 AM, David Miller <davem@davemloft.net> wrote:
> From: Changli Gao <xiaosuo@gmail.com>
> Date: Sat, 25 Dec 2010 21:41:30 +0800
>
>> Since nf_bridge_maybe_copy_header() may change the length of skb,
>> we should check the length of skb after it to handle the ppoe skbs.
>>
>> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
>
> This is really strange.
>
> packet_length() subtracts VLAN_HLEN from the value it returns, so the
> correct fix seems to be to make this function handle the PPPOE case
> too.
>
It is correct. The actual MTU of 802.1q frame is 4 bytes larger. For
example, the MTU of ethernet is normally 1500, however the actual MTU
of the 802.1Q is 1504.
Please see this patch:
http://git.kernel.org/?p=linux/kernel/git/davem/net-next-2.6.git;a=commitdiff;h=c893b8066c7bf6156e4d760e5acaf4c148e37190;hp=3c0fef0b7d36e5f8d3ea3731a8228102274e3c23
> Otherwise I suspect you have many other functions to fix as well.
>
> I'm not applying this patch.
>
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [Bridge] rstp solutions
From: tamar zeiri @ 2011-01-02 7:38 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 123 bytes --]
Hi all
Can anyone recommend the best solution for rstp (2.6 kernel)?
Did anyone work with rstplib on real bridges?
Thanks
[-- Attachment #2: Type: text/html, Size: 139 bytes --]
^ permalink raw reply
* [Bridge] DHCP problem on bridge
From: yu.sheng @ 2010-12-31 21:13 UTC (permalink / raw)
To: bridge
Hi,
Have you solved this problem? I have a similar one. I bind three eth interfaces to a bridge. I connect eth0 to the dhcp server, and two subnets to eth1 and eth2. The clients in the two subnets try to get IP from the dhcp server.
My problem is that sometimes the dhcp offer or dhcp pack packets will be delayed in the bridge for such a long time, that the dhcpcd on the client will timeout and thus fail to configure the IP.
Yu
^ permalink raw reply
* Re: [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: David Miller @ 2010-12-31 19:10 UTC (permalink / raw)
To: xiaosuo; +Cc: netdev, bridge
In-Reply-To: <1293284490-17114-1-git-send-email-xiaosuo@gmail.com>
From: Changli Gao <xiaosuo@gmail.com>
Date: Sat, 25 Dec 2010 21:41:30 +0800
> Since nf_bridge_maybe_copy_header() may change the length of skb,
> we should check the length of skb after it to handle the ppoe skbs.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
This is really strange.
packet_length() subtracts VLAN_HLEN from the value it returns, so the
correct fix seems to be to make this function handle the PPPOE case
too.
Otherwise I suspect you have many other functions to fix as well.
I'm not applying this patch.
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Stephen Hemminger @ 2010-12-26 18:31 UTC (permalink / raw)
To: Rolf Fokkens; +Cc: bridge
In-Reply-To: <4D1779B6.9050305@wanadoo.nl>
On Sun, 26 Dec 2010 18:21:58 +0100
Rolf Fokkens <rolf.fokkens@wanadoo.nl> wrote:
> 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.
>
The message means you can't use kdump/netconsole/kgdb over
that bridge device.
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Rolf Fokkens @ 2010-12-26 17:21 UTC (permalink / raw)
To: bridge; +Cc: Stephen Hemminger
In-Reply-To: <4D0FB6AC.2020901@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 --]
^ permalink raw reply
* [Bridge] [PATCH] net: bridge: check the length of skb after nf_bridge_maybe_copy_header()
From: Changli Gao @ 2010-12-25 13:41 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, bridge, David S. Miller, Changli Gao
Since nf_bridge_maybe_copy_header() may change the length of skb,
we should check the length of skb after it to handle the ppoe skbs.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/bridge/br_forward.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index 2bd11ec..ee64287 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -41,17 +41,13 @@ static inline unsigned packet_length(const struct sk_buff *skb)
int br_dev_queue_push_xmit(struct sk_buff *skb)
{
- /* drop mtu oversized packets except gso */
- if (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))
+ /* ip_fragment doesn't copy the MAC header */
+ if (nf_bridge_maybe_copy_header(skb) ||
+ (packet_length(skb) > skb->dev->mtu && !skb_is_gso(skb))) {
kfree_skb(skb);
- else {
- /* ip_fragment doesn't copy the MAC header */
- if (nf_bridge_maybe_copy_header(skb))
- kfree_skb(skb);
- else {
- skb_push(skb, ETH_HLEN);
- dev_queue_xmit(skb);
- }
+ } else {
+ skb_push(skb, ETH_HLEN);
+ dev_queue_xmit(skb);
}
return 0;
^ permalink raw reply related
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Stephen Hemminger @ 2010-12-20 23:15 UTC (permalink / raw)
To: Rolf Fokkens; +Cc: bridge
In-Reply-To: <4D0FB6AC.2020901@wanadoo.nl>
On Mon, 20 Dec 2010 21:03:56 +0100
Rolf Fokkens <rolf.fokkens@wanadoo.nl> 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
>
> On 12/20/2010 07:37 PM, Stephen Hemminger wrote:
> > The address you change the address, it is like you changed the MAC address
> > of a card on the network. Windows ARP cache is no longer valid and has
> > to time out.
> >
> >
>
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.
--
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Rolf Fokkens @ 2010-12-20 20:03 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: bridge
In-Reply-To: <20101220103754.7d18de50@s6510>
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
On 12/20/2010 07:37 PM, Stephen Hemminger wrote:
> The address you change the address, it is like you changed the MAC address
> of a card on the network. Windows ARP cache is no longer valid and has
> to time out.
>
>
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Stephen Hemminger @ 2010-12-20 18:37 UTC (permalink / raw)
To: Rolf Fokkens; +Cc: bridge
In-Reply-To: <4D0E868E.4010309@wanadoo.nl>
On Sun, 19 Dec 2010 23:26:22 +0100
Rolf Fokkens <rolf.fokkens@wanadoo.nl> wrote:
> Hi All,
>
> Despite of what Stephen explains, I'm having the problem Michiel
> describes as well. I have a bridge br2 containing 1 (but potentially
> more) tap interface for kvm. Windows 7 VM doesn't like the bridge mac
> address to change, so I try to make it fixed.
>
> ifconfig br2 hw ether 02:00:00:00:01:02
>
> Interface br2 becomes instantly unreachable from the VM (via the tap
> interface). No arp response or anything else.
>
> So, Michiel's claim seems to be true: the bridge mac address should
> apparently be one of the bridge interfaces. But I don't see the logic,
> this seems like a bug to me.
>
> kernel is Fedora kernel-2.6.35.9-64.fc14.x86_64.
>
> Cheers,
>
> Rolf
The address you change the address, it is like you changed the MAC address
of a card on the network. Windows ARP cache is no longer valid and has
to time out.
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses - bug?
From: Rolf Fokkens @ 2010-12-19 22:26 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 2887 bytes --]
Hi All,
Despite of what Stephen explains, I'm having the problem Michiel
describes as well. I have a bridge br2 containing 1 (but potentially
more) tap interface for kvm. Windows 7 VM doesn't like the bridge mac
address to change, so I try to make it fixed.
ifconfig br2 hw ether 02:00:00:00:01:02
Interface br2 becomes instantly unreachable from the VM (via the tap
interface). No arp response or anything else.
So, Michiel's claim seems to be true: the bridge mac address should
apparently be one of the bridge interfaces. But I don't see the logic,
this seems like a bug to me.
kernel is Fedora kernel-2.6.35.9-64.fc14.x86_64.
Cheers,
Rolf
>
> ------------------------------------------------------------------------
>
> * /To/: Michel Lammertink <mlammertink@xxxxxxxxx
> <mailto:mlammertink@DOMAIN.HIDDEN>>
> * /Subject/: Re: Why should static MAC address match one of the
> port MAC addresses.
> * /From/: Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx
> <mailto:shemminger@DOMAIN.HIDDEN>>
> * /Date/: Tue, 12 Oct 2010 09:44:08 -0700
> * /Cc/: bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:bridge@DOMAIN.HIDDEN>
> * /In-reply-to/: <4CB46549.2070901@xxxxxxxxx
> <mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
> * /Organization/: Linux Foundation
> * /References/: <4CB46549.2070901@xxxxxxxxx
> <mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
>
> ------------------------------------------------------------------------
> On Tue, 12 Oct 2010 15:40:25 +0200 Michel Lammertink<mlammertink@xxxxxxxxx> wrote:
>
> >/ Hi all,/
> >/ /
> >/ I've read many messages on this mailing list with the question about/
> >/ setting a static MAC address on the bridge interface, but two questions/
> >/ remain:/
> >/ /
> >/ 1. Why should the MAC address of the bridge match the address of one of/
> >/ its interfaces? Setting the MAC address to a different value does not/
> >/ generate an error, but the bridge is not working properly (Local data/
> >/ does not arrive)./
>
> No longer a requirement. It was just a good way to ensure a good
> address that was unique, and not being used by other systems.
>
> >/ 2. Why does the bridge by default choose the "lowest" MAC address,/
> >/ instead of the MAC address of the first port added, as is proposed by/
> >/ the standard [1]?/
>
> It was a convenience in original design to choose a consistent value.
> Since ports can be added in any order, using the lowest seemed like
> a good idea for the original author. This has been maintained for
> backwards compatibility.
>
> >/ [1] IEEE802.1D, Par. 7.12.5./
> >/ Quote: "The Bridge Address may be the individual MAC Address of a/
> >/ Bridge Port, in which case, use of the address of the lowest numbered/
> >/ Bridge Port (Port 1) is recommended."/
> >/ /
> >/ Thanks in advance,/
> >/ /
> >/ Michel./
[-- Attachment #2: Type: text/html, Size: 3723 bytes --]
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses.
From: Rolf Fokkens @ 2010-12-19 22:19 UTC (permalink / raw)
To: bridge
In-Reply-To: <4D0E845B.60203@online.nl>
[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]
Forgot some specifics:
kernel is Fedora kernel-2.6.35.9-64.fc14.x86_64.
On 12/19/2010 11:16 PM, Rolf Fokkens wrote:
> Hi all,
>
> I'm having the problem Michiel describes as well. I have a bridge br2
> containing 1 (but potentially more) tap interface for kvm. Windows 7
> VM doesn't like the bridge mac address to change, so I try to make it
> fixed.
>
> ifconfig br2 hw ether 02:00:00:00:01:02
>
> Interface br2 becomes instantly unreachable from the VM (via the tap
> interface).
>
> So, Michiel's claim still seems to be true: the bridge mac address
> should apparently be one of the bridge interfaces.
>
> I don't see the logic, this seems like a bug to me.
>
> Cheers,
>
> Rolf
>
> ------------------------------------------------------------------------
>
> * /To/: Michel Lammertink <mlammertink@xxxxxxxxx
> <mailto:mlammertink@DOMAIN.HIDDEN>>
> * /Subject/: Re: Why should static MAC address match one of the
> port MAC addresses.
> * /From/: Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx
> <mailto:shemminger@DOMAIN.HIDDEN>>
> * /Date/: Tue, 12 Oct 2010 09:44:08 -0700
> * /Cc/: bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx
> <mailto:bridge@DOMAIN.HIDDEN>
> * /In-reply-to/: <4CB46549.2070901@xxxxxxxxx
> <mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
> * /Organization/: Linux Foundation
> * /References/: <4CB46549.2070901@xxxxxxxxx
> <mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
>
> ------------------------------------------------------------------------
> On Tue, 12 Oct 2010 15:40:25 +0200 Michel Lammertink<mlammertink@xxxxxxxxx> wrote:
>
> >/ Hi all,/
> >/ /
> >/ I've read many messages on this mailing list with the question about/
> >/ setting a static MAC address on the bridge interface, but two questions/
> >/ remain:/
> >/ /
> >/ 1. Why should the MAC address of the bridge match the address of one of/
> >/ its interfaces? Setting the MAC address to a different value does not/
> >/ generate an error, but the bridge is not working properly (Local data/
> >/ does not arrive)./
>
> No longer a requirement. It was just a good way to ensure a good
> address that was unique, and not being used by other systems.
>
> >/ 2. Why does the bridge by default choose the "lowest" MAC address,/
> >/ instead of the MAC address of the first port added, as is proposed by/
> >/ the standard [1]?/
>
> It was a convenience in original design to choose a consistent value.
> Since ports can be added in any order, using the lowest seemed like
> a good idea for the original author. This has been maintained for
> backwards compatibility.
>
> >/ [1] IEEE802.1D, Par. 7.12.5./
> >/ Quote: "The Bridge Address may be the individual MAC Address of a/
> >/ Bridge Port, in which case, use of the address of the lowest numbered/
> >/ Bridge Port (Port 1) is recommended."/
> >/ /
> >/ Thanks in advance,/
> >/ /
> >/ Michel./
[-- Attachment #2: Type: text/html, Size: 3891 bytes --]
^ permalink raw reply
* Re: [Bridge] Why should static MAC address match one of the port MAC addresses.
From: Rolf Fokkens @ 2010-12-19 22:16 UTC (permalink / raw)
To: bridge
[-- Attachment #1: Type: text/plain, Size: 2669 bytes --]
Hi all,
I'm having the problem Michiel describes as well. I have a bridge br2
containing 1 (but potentially more) tap interface for kvm. Windows 7 VM
doesn't like the bridge mac address to change, so I try to make it fixed.
ifconfig br2 hw ether 02:00:00:00:01:02
Interface br2 becomes instantly unreachable from the VM (via the tap
interface).
So, Michiel's claim still seems to be true: the bridge mac address
should apparently be one of the bridge interfaces.
I don't see the logic, this seems like a bug to me.
Cheers,
Rolf
------------------------------------------------------------------------
* /To/: Michel Lammertink <mlammertink@xxxxxxxxx
<mailto:mlammertink@DOMAIN.HIDDEN>>
* /Subject/: Re: Why should static MAC address match one of the port
MAC addresses.
* /From/: Stephen Hemminger <shemminger@xxxxxxxxxxxxxxxxxxxx
<mailto:shemminger@DOMAIN.HIDDEN>>
* /Date/: Tue, 12 Oct 2010 09:44:08 -0700
* /Cc/: bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx <mailto:bridge@DOMAIN.HIDDEN>
* /In-reply-to/: <4CB46549.2070901@xxxxxxxxx
<mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
* /Organization/: Linux Foundation
* /References/: <4CB46549.2070901@xxxxxxxxx
<mailto:4CB46549.2070901@DOMAIN.HIDDEN>>
------------------------------------------------------------------------
On Tue, 12 Oct 2010 15:40:25 +0200 Michel Lammertink<mlammertink@xxxxxxxxx> wrote:
>/ Hi all,/
>/ /
>/ I've read many messages on this mailing list with the question about/
>/ setting a static MAC address on the bridge interface, but two questions/
>/ remain:/
>/ /
>/ 1. Why should the MAC address of the bridge match the address of one of/
>/ its interfaces? Setting the MAC address to a different value does not/
>/ generate an error, but the bridge is not working properly (Local data/
>/ does not arrive)./
No longer a requirement. It was just a good way to ensure a good
address that was unique, and not being used by other systems.
>/ 2. Why does the bridge by default choose the "lowest" MAC address,/
>/ instead of the MAC address of the first port added, as is proposed by/
>/ the standard [1]?/
It was a convenience in original design to choose a consistent value.
Since ports can be added in any order, using the lowest seemed like
a good idea for the original author. This has been maintained for
backwards compatibility.
>/ [1] IEEE802.1D, Par. 7.12.5./
>/ Quote: "The Bridge Address may be the individual MAC Address of a/
>/ Bridge Port, in which case, use of the address of the lowest numbered/
>/ Bridge Port (Port 1) is recommended."/
>/ /
>/ Thanks in advance,/
>/ /
>/ Michel./
[-- Attachment #2: Type: text/html, Size: 3336 bytes --]
^ permalink raw reply
* Re: [Bridge] [PATCH v2] bridge: Fix return values of br_multicast_add_group/br_multicast_new_group
From: Tobias Klauser @ 2010-12-10 22:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, bridge
In-Reply-To: <20101210.130125.233714141.davem@davemloft.net>
On 2010-12-10 at 22:01:25 +0100, David Miller <davem@davemloft.net> wrote:
> From: Tobias Klauser <tklauser@distanz.ch>
> Date: Fri, 10 Dec 2010 14:18:04 +0100
>
> > If br_multicast_new_group returns NULL, we would return 0 (no error) to
> > the caller of br_multicast_add_group, which is not what we want. Instead
> > br_multicast_new_group should return ERR_PTR(-ENOMEM) in this case.
> > Also propagate the error number returned by br_mdb_rehash properly.
> >
> > Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
>
> Looks good, applied to net-next-2.6
>
> Please in the future make is clear, in your subject line, which
> tree this patch is meant for.
>
> I had to figure it out by trial and error, because this patch
> does not apply properly to net-2.6
Sorry about that. I'll do so in the future.
Thanks
^ permalink raw reply
* Re: [Bridge] [PATCH v2] bridge: Fix return values of br_multicast_add_group/br_multicast_new_group
From: David Miller @ 2010-12-10 21:01 UTC (permalink / raw)
To: tklauser; +Cc: netdev, bridge
In-Reply-To: <1291987084-27302-1-git-send-email-tklauser@distanz.ch>
From: Tobias Klauser <tklauser@distanz.ch>
Date: Fri, 10 Dec 2010 14:18:04 +0100
> If br_multicast_new_group returns NULL, we would return 0 (no error) to
> the caller of br_multicast_add_group, which is not what we want. Instead
> br_multicast_new_group should return ERR_PTR(-ENOMEM) in this case.
> Also propagate the error number returned by br_mdb_rehash properly.
>
> Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
Looks good, applied to net-next-2.6
Please in the future make is clear, in your subject line, which
tree this patch is meant for.
I had to figure it out by trial and error, because this patch
does not apply properly to net-2.6
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox