ebtables mac update

ebtables mac update

[Покотиленко Костик]

Hi,

We have two building with local networks connected by Zyxel Prestige 841
and 841C VDSL-modems. They work in transparent bridge mode.

On one end 841 is connected directly to a switch. On other 841C
connected to a linux router wich is also connected to a switch, and
those interfaces bridged.

There is a problem, when a computer is being moved from one building to
another it stops seeing other end of the bridge until modems are
rebooted.

I was thinking the problem is in modems' part, but in Zyxel support I've
been told they are just dumn transparent bridges and doesn't behave like
that.

So, the only device left that may cause such problem is linux
router/bridge.

Is there any kind of behaviour of linux bridge (ebtables) that may cause
such problem?

P.S. there is no ebtables rules at all, no iptables related rules.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Pascal Hambourg]

Pokotilenko Kostik (approximate romanization) wrote :
> 
> We have two building with local networks connected by Zyxel Prestige 841
> and 841C VDSL-modems. They work in transparent bridge mode.
> 
> On one end 841 is connected directly to a switch. On other 841C
> connected to a linux router wich is also connected to a switch, and
> those interfaces bridged.

So is it a bridge or a router ?

> There is a problem, when a computer is being moved from one building to
> another it stops seeing other end of the bridge until modems are
> rebooted.

Can you elaborate "stops seeing" ?
Packet captures of ARP and IP traffic on both ends might provide more
information.

> I was thinking the problem is in modems' part, but in Zyxel support I've
> been told they are just dumn transparent bridges and doesn't behave like
> that.

A bridge (or a switch) is never completely as dumb as a hub. It uses a
MAC-port table in order to forward frames only through the relevant ports.

> So, the only device left that may cause such problem is linux
> router/bridge.
> 
> Is there any kind of behaviour of linux bridge (ebtables) that may cause
> such problem?

The Linux bridge maintains a MAC-port table based on the source MAC
address in received frames. As expected, if a MAC address was associated
to a given port and a frame from that MAC address is received on a
different port, then the table is updated accordingly. Besides,
rebooting the modems and not the Linux box fixes the problem. So I doubt
that the Linux bridge causes the problem.

Of course the update process requires that the moved box sends traffic
first. If it just sits there waiting then MAC-port tables won't be
updated, until the entry eventually expires.

> P.S. there is no ebtables rules at all, no iptables related rules.

Then may I ask what is the purpose of this box ?

Re: ebtables mac update

[Покотиленко Костик]

В Вто, 29/06/2010 в 14:36 +0200, Pascal Hambourg пишет:
> Pokotilenko Kostik (approximate romanization) wrote :
> > 
> > We have two building with local networks connected by Zyxel Prestige 841
> > and 841C VDSL-modems. They work in transparent bridge mode.
> > 
> > On one end 841 is connected directly to a switch. On other 841C
> > connected to a linux router wich is also connected to a switch, and
> > those interfaces bridged.
> 
> So is it a bridge or a router ?

Modems 841C and 841 are configured in bridge mode.

Linux box runs some services and have 3 interfaces, 2 of them are
bridged to br0 and one is left for separate local segment. So it is a
router between br0 and eth2 and a bridge between eth0, eth1.

> > There is a problem, when a computer is being moved from one building to
> > another it stops seeing other end of the bridge until modems are
> > rebooted.
> 
> Can you elaborate "stops seeing" ?
> Packet captures of ARP and IP traffic on both ends might provide more
> information.

Can't repeat tests right now, but I'm remembering that if I move the box
across the bridge and trying to ping box at other side: either
ARP-who-has can't cross the bridge or ARP-is-at (response) can't cross
the bridge.

I'll play more with this soon.

> > I was thinking the problem is in modems' part, but in Zyxel support I've
> > been told they are just dumn transparent bridges and doesn't behave like
> > that.
> 
> A bridge (or a switch) is never completely as dumb as a hub. It uses a
> MAC-port table in order to forward frames only through the relevant ports.

This is how I was thinking. It *should* be like the logic in a switch.

> > So, the only device left that may cause such problem is linux
> > router/bridge.
> > 
> > Is there any kind of behaviour of linux bridge (ebtables) that may cause
> > such problem?
> 
> The Linux bridge maintains a MAC-port table based on the source MAC
> address in received frames.

This is brctl showmacs, right?

>  As expected, if a MAC address was associated
> to a given port and a frame from that MAC address is received on a
> different port, then the table is updated accordingly.

So, this is exactly the same logic that switches use, right?

Can you confirm that if MAC (frame with source MAC) pops up on port
different from the one it was seen previous time then the port for that
MAC get updated?

What then "brctl setageing" for?

>  Besides,
> rebooting the modems and not the Linux box fixes the problem. So I doubt
> that the Linux bridge causes the problem.

It may happen that rebooting the modems brings port link down and the
bridge may clear the MAC-port table on that port. This is similar to
what Zyxel support told me.

> Of course the update process requires that the moved box sends traffic
> first. If it just sits there waiting then MAC-port tables won't be
> updated, until the entry eventually expires.

In my case on moved box I'm unable to make connections or even ping.

> > P.S. there is no ebtables rules at all, no iptables related rules.
> 
> Then may I ask what is the purpose of this box ?

Besides that it is a server, iptables is used to restrict access for
separate local segment at eth2 (allow access to Internet and not to
local net). Ebtables is empty now, but I wanted to be able to filter
bridge traffic if that matters someday.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Grant Taylor]

On 06/29/10 09:29, Покотиленко Костик wrote:
> Linux box runs some services and have 3 interfaces, 2 of them are 
> bridged to br0 and one is left for separate local segment. So it is a 
> router between br0 and eth2 and a bridge between eth0, eth1.

Will you please clarify what interface the Zyxel bridge is connected to? 
   (I'm guessing that it's connected to either eth0 or eth1, but I'd 
like some clarification.)

What is connected to the other two interfaces?

> This is brctl showmacs, right?

I don't know the command off the top of my head, but I know there is a 
command to have the bridge show what MAC addresses are associated with 
what bridge ports.

> So, this is exactly the same logic that switches use, right?

Should be, yes.

> Can you confirm that if MAC (frame with source MAC) pops up on port 
> different from the one it was seen previous time then the port for 
> that MAC get updated?

Should be, yes.

> What then "brctl setageing" for?

That should set the aging / expire timer for MAC addresses that have not 
been seen in a while.  (How long the MAC has to be quite before it is 
flooded again.)

> It may happen that rebooting the modems brings port link down and the 
> bridge may clear the MAC-port table on that port. This is similar to 
> what Zyxel support told me.

Agreed.  See my previous reply about a way to test this.

> In my case on moved box I'm unable to make connections or even ping.

This is contrary to how every Linux bridge that I have used ever 
behaved.  I'm thinking that the Zyxel is at least part of the problem. 
That being said, it is very unlikely but there could be some sort of 
weird interaction between the Zyxel and Linux bridging that combined is 
causing a problem.

> Besides that it is a server, iptables is used to restrict access for 
> separate local segment at eth2 (allow access to Internet and not to 
> local net). Ebtables is empty now, but I wanted to be able to filter 
> bridge traffic if that matters someday.

Remember that it is possible for IPTables to filter bridged traffic. 
(It depends if an option is enabled in the kernel.)  So IPTables could 
be interfering with out you knowing it.

Will you please provide the output of "iptables-save" (sanitized if needed).



Grant. . . .

Re: ebtables mac update

[Покотиленко Костик]

В Вто, 29/06/2010 в 09:57 -0500, Grant Taylor пишет:
> On 06/29/10 09:29, ðÏËÏÔÉÌÅÎËÏ ëÏÓÔÉË wrote:
> > Linux box runs some services and have 3 interfaces, 2 of them are 
> > bridged to br0 and one is left for separate local segment. So it is a 
> > router between br0 and eth2 and a bridge between eth0, eth1.
> 
> Will you please clarify what interface the Zyxel bridge is connected to? 
>    (I'm guessing that it's connected to either eth0 or eth1, but I'd 
> like some clarification.)
> 
> What is connected to the other two interfaces?

      +-- eth0: modem
br0 --+
      +-- eth1: local network

eth2: network of public access points

> > This is brctl showmacs, right?
> 
> I don't know the command off the top of my head, but I know there is a 
> command to have the bridge show what MAC addresses are associated with 
> what bridge ports.
> 
> > So, this is exactly the same logic that switches use, right?
> 
> Should be, yes.
> 
> > Can you confirm that if MAC (frame with source MAC) pops up on port 
> > different from the one it was seen previous time then the port for 
> > that MAC get updated?
> 
> Should be, yes.

If so, the linux bridge should not be the point of problem.

> > What then "brctl setageing" for?
> 
> That should set the aging / expire timer for MAC addresses that have not 
> been seen in a while.  (How long the MAC has to be quite before it is 
> flooded again.)

So this is to remove MACs that were not poped up for long to just not
waste momory.

> > It may happen that rebooting the modems brings port link down and the 
> > bridge may clear the MAC-port table on that port. This is similar to 
> > what Zyxel support told me.
> 
> Agreed.  See my previous reply about a way to test this.

I'll consider.

> > In my case on moved box I'm unable to make connections or even ping.
> 
> This is contrary to how every Linux bridge that I have used ever 
> behaved.  I'm thinking that the Zyxel is at least part of the problem. 
> That being said, it is very unlikely but there could be some sort of 
> weird interaction between the Zyxel and Linux bridging that combined is 
> causing a problem.

This is quite low probability.

> > Besides that it is a server, iptables is used to restrict access for 
> > separate local segment at eth2 (allow access to Internet and not to 
> > local net). Ebtables is empty now, but I wanted to be able to filter 
> > bridge traffic if that matters someday.
> 
> Remember that it is possible for IPTables to filter bridged traffic. 
> (It depends if an option is enabled in the kernel.)  So IPTables could 
> be interfering with out you knowing it.

I know that. But some kind of matches in newer kernels are available
only in ebtables, like --phys-dev-[in|out]

> Will you please provide the output of "iptables-save" (sanitized if needed).

All rules have either "-i eth2" or "-o eth2". eth2 is public access
points network that should be restricted. br0(eth0: modem, eth1: local
network for this building): local network. Default policy is accept, so
there is no rules to restrict bridged traffic.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Pascal Hambourg]

Pokotilenko Kostik (approximate romanization) wrote :
>>> We have two building with local networks connected by Zyxel Prestige 841
>>> and 841C VDSL-modems. They work in transparent bridge mode.
>>>
>>> On one end 841 is connected directly to a switch. On other 841C
>>> connected to a linux router wich is also connected to a switch, and
>>> those interfaces bridged.
>> So is it a bridge or a router ?
> 
> Modems 841C and 841 are configured in bridge mode.

You already made that clear. I was asking about the Linux box.

> Linux box runs some services and have 3 interfaces, 2 of them are
> bridged to br0 and one is left for separate local segment. So it is a
> router between br0 and eth2 and a bridge between eth0, eth1.

Ok.

>>> There is a problem, when a computer is being moved from one building to
>>> another it stops seeing other end of the bridge until modems are
>>> rebooted.
>> Can you elaborate "stops seeing" ?
>> Packet captures of ARP and IP traffic on both ends might provide more
>> information.
> 
> Can't repeat tests right now, but I'm remembering that if I move the box
> across the bridge and trying to ping box at other side: either
> ARP-who-has can't cross the bridge or ARP-is-at (response) can't cross
> the bridge.
> 
> I'll play more with this soon.

Please do so. And make sure you capture and compare traffic at each port
of the Linux bridge (eth0 and eth1).

> Can you confirm that if MAC (frame with source MAC) pops up on port
> different from the one it was seen previous time then the port for that
> MAC get updated?

I can only confirm that a Linux bridge does this, because I tested it. I
cannot confirm about other bridging devices, although this is what they
should do.

>> rebooting the modems and not the Linux box fixes the problem. So I doubt
>> that the Linux bridge causes the problem.
> 
> It may happen that rebooting the modems brings port link down and the
> bridge may clear the MAC-port table on that port. This is similar to
> what Zyxel support told me.

Note that you can achieve the same result by deactivating and
reactivating br0 or its ports, without touching the modems.

Re: ebtables mac update

[Покотиленко Костик]

Thanks for your answers.

It is mess a bit, because modems I was talking about (841,841C) has
broken and are now in service.

We have another pair of Zyxel Prestige 782M SHDSL modems that are being
used as temporary replacement.

Funny thing is that the problem persist. Tonight I've made some tests
with 782M. I've connected two computers in my office (win7 and linux)
through this pair directly. I seccessfully tested ping both directions,
then switched them so that each crossed the bridge and was unable to
ping.

tcpdump from linux showed:

1. while pinging from linux to win7:

- Linux sends broadcast ARP-WHO-HAS win7-ip and no one replays
- I was able to see win7's ARP-WHO-HAS some-other-ip after that linux
probably learned it's MAC and started to send unicast ping requests,
still no replay
- I also saw some unicast packets from win7 crossed the bridge

2. while pinging from win7 to linux:

- linux gets broadcast ARP-WHO-HAS linux-ip
- linux replays unicast ARP-IS-AT
- those two repeat, so win7 doesn't get replay

Regarding this I can surely tell (this is all about 782M pair) that
after box crossing the bridge MAC-port table is not updating (how it
should be if it were switch's logic). Packets with srcMAC of crossed box
CAN cross the bridge, but with dstMAC of crossed box CANNOT cross the
bridge.

В Срд, 30/06/2010 в 17:39 +0200, Pascal Hambourg пишет:
> Pokotilenko Kostik (approximate romanization) wrote :
> >>> We have two building with local networks connected by Zyxel Prestige 841
> >>> and 841C VDSL-modems. They work in transparent bridge mode.
> >>>
> >>> On one end 841 is connected directly to a switch. On other 841C
> >>> connected to a linux router wich is also connected to a switch, and
> >>> those interfaces bridged.
> >> So is it a bridge or a router ?
> > 
> > Modems 841C and 841 are configured in bridge mode.
> 
> You already made that clear. I was asking about the Linux box.
> 
> > Linux box runs some services and have 3 interfaces, 2 of them are
> > bridged to br0 and one is left for separate local segment. So it is a
> > router between br0 and eth2 and a bridge between eth0, eth1.
> 
> Ok.
> 
> >>> There is a problem, when a computer is being moved from one building to
> >>> another it stops seeing other end of the bridge until modems are
> >>> rebooted.
> >> Can you elaborate "stops seeing" ?
> >> Packet captures of ARP and IP traffic on both ends might provide more
> >> information.
> > 
> > Can't repeat tests right now, but I'm remembering that if I move the box
> > across the bridge and trying to ping box at other side: either
> > ARP-who-has can't cross the bridge or ARP-is-at (response) can't cross
> > the bridge.
> > 
> > I'll play more with this soon.
> 
> Please do so. And make sure you capture and compare traffic at each port
> of the Linux bridge (eth0 and eth1).
> 
> > Can you confirm that if MAC (frame with source MAC) pops up on port
> > different from the one it was seen previous time then the port for that
> > MAC get updated?
> 
> I can only confirm that a Linux bridge does this, because I tested it. I
> cannot confirm about other bridging devices, although this is what they
> should do.
> 
> >> rebooting the modems and not the Linux box fixes the problem. So I doubt
> >> that the Linux bridge causes the problem.
> > 
> > It may happen that rebooting the modems brings port link down and the
> > bridge may clear the MAC-port table on that port. This is similar to
> > what Zyxel support told me.
> 
> Note that you can achieve the same result by deactivating and
> reactivating br0 or its ports, without touching the modems.
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Grant Taylor]

Покотиленко Костик wrote:
> Funny thing is that the problem persist. Tonight I've made some tests 
> with 782M. I've connected two computers in my office (win7 and linux) 
> through this pair directly. I seccessfully tested ping both 
> directions, then switched them so that each crossed the bridge and 
> was unable to ping.

When you switch then, do the Linux and Windows systems know that their 
network cable has been unplugged?

If they do, they will very likely flush their caches.

If the problem persists after the Linux and Windows systems flush their 
cache, I'm strongly thinking that the problem is with the DSL bridges.

> Regarding this I can surely tell (this is all about 782M pair) that 
> after box crossing the bridge MAC-port table is not updating (how it 
> should be if it were switch's logic). Packets with srcMAC of crossed 
> box CAN cross the bridge, but with dstMAC of crossed box CANNOT cross 
> the bridge.

That really sounds like the something is not forwarding traffic b/c it 
still thinks that the destination MAC is on the local side.

Please clarify, when you ran your test, did you try trading sides of the 
Linux bridge individually or the Linux bridge in combination with the 
DSL bridge?

Can you try repeating your test on either side of the Linux bridge?



Grant. . . .

Re: ebtables mac update

[Покотиленко Костик]

В Срд, 30/06/2010 в 18:54 -0500, Grant Taylor пишет:
> Покотиленко Костик wrote:
> > Funny thing is that the problem persist. Tonight I've made some tests 
> > with 782M. I've connected two computers in my office (win7 and linux) 
> > through this pair directly. I seccessfully tested ping both 
> > directions, then switched them so that each crossed the bridge and 
> > was unable to ping.
> 
> When you switch then, do the Linux and Windows systems know that their 
> network cable has been unplugged?

Yes, because I just switched ethernet cables.

> If they do, they will very likely flush their caches.
> 
> If the problem persists after the Linux and Windows systems flush their 
> cache, I'm strongly thinking that the problem is with the DSL bridges.

In this case, from the Windows and Linux boxes point of view nothing
should change, either they still remembering other's MAC (this case it
will just send unicast direct packet) or not (broadcast ARP is send).

> > Regarding this I can surely tell (this is all about 782M pair) that 
> > after box crossing the bridge MAC-port table is not updating (how it 
> > should be if it were switch's logic). Packets with srcMAC of crossed 
> > box CAN cross the bridge, but with dstMAC of crossed box CANNOT cross 
> > the bridge.
> 
> That really sounds like the something is not forwarding traffic b/c it 
> still thinks that the destination MAC is on the local side.
> 
> Please clarify, when you ran your test, did you try trading sides of the 
> Linux bridge individually or the Linux bridge in combination with the 
> DSL bridge?
> 
> Can you try repeating your test on either side of the Linux bridge?

I repeat, that in this test case with 782M modems I brought them both to
office, connected with 2 meters phone cable, and connected Windows box
to one modem, Linux to other, then switched.

So the scheme was this:

Win --- 782M Server ----- 782M Client --- Linux

and after switch:

Linux --- 782M Server ----- 782M Client --- Win

The fact that problem persisted tells me that the problem is in modems
and not in linux bridge.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Grant Taylor]

On 07/01/10 04:08, Покотиленко Костик wrote:
> Yes, because I just switched ethernet cables.

Ok.

> In this case, from the Windows and Linux boxes point of view nothing 
> should change, either they still remembering other's MAC (this case it 
> will just send unicast direct packet) or not (broadcast ARP is send).

Agreed.

> The fact that problem persisted tells me that the problem is in modems 
> and not in linux bridge.

Agreed.

Will you try one more step after you re-run the test?  Namely, when the 
boxen can't ping each other, try rebooting one or both of the modems and 
see if the problem continues after doing so.

I have a feeling you have just about all the evidence you need to go 
back to your modem vendor's support and say "Listen up... what you told 
me was wrong and here's my proof.".



Grant. . . .

Re: ebtables mac update

[Покотиленко Костик]

В Чтв, 01/07/2010 в 11:10 -0500, Grant Taylor пишет:
> On 07/01/10 04:08, ðÏËÏÔÉÌÅÎËÏ ëÏÓÔÉË wrote:
> > Yes, because I just switched ethernet cables.
> 
> Ok.
> 
> > In this case, from the Windows and Linux boxes point of view nothing 
> > should change, either they still remembering other's MAC (this case it 
> > will just send unicast direct packet) or not (broadcast ARP is send).
> 
> Agreed.
> 
> > The fact that problem persisted tells me that the problem is in modems 
> > and not in linux bridge.
> 
> Agreed.
> 
> Will you try one more step after you re-run the test?  Namely, when the 
> boxen can't ping each other, try rebooting one or both of the modems and 
> see if the problem continues after doing so.

I've done this in production enviroment (with linux bridge involved) as
well as in test enviroment (just 2 modems and 2 computers).

Those SHDSL modems should have equal setup except that one should be a
Server and the other a Client.

In both those situations rebooting Client doesn't help, but rebooting
Server one solves the problem.

> I have a feeling you have just about all the evidence you need to go 
> back to your modem vendor's support and say "Listen up... what you told 
> me was wrong and here's my proof.".

The thing is that we have 2 pairs of modem, one VDSL and one SHDSL. They
both have this problem, and my initial post to support was about VDSL
modems were they told that problem is in something else. I can't prove
that because VDSL modems has broken and are now being repaired.

At another post about this problem regarding SHDSL modems they just
suggested unofficial firmware, which I'm afraid to update b/c if
something wrong I don't have any kind of backup there. Moreover I called
local service, they say any service will lead to transportation to
capital city and will take 1-3 months :/ This is what is being happened
with VDSL.

Thanks again.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Покотиленко Костик]

В Чтв, 01/07/2010 в 20:00 +0300, Покотиленко Костик пишет:

> At another post about this problem regarding SHDSL modems they just
> suggested unofficial firmware,

Just taked a look at release notes of suggested firmware:

Bugs fixes in 2.50(BM.1)b1

1. Bridge routing table will not update automatically.
...

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Pascal Hambourg]

Pokotilenko Kostik (approximate romanization) wrote :
> 
> Funny thing is that the problem persist. Tonight I've made some tests
> with 782M. I've connected two computers in my office (win7 and linux)
> through this pair directly. I seccessfully tested ping both directions,
> then switched them so that each crossed the bridge and was unable to
> ping.
> 
> tcpdump from linux showed:
> 
> 1. while pinging from linux to win7:
> 
> - Linux sends broadcast ARP-WHO-HAS win7-ip and no one replays
> - I was able to see win7's ARP-WHO-HAS some-other-ip after that linux
> probably learned it's MAC and started to send unicast ping requests,
> still no replay
> - I also saw some unicast packets from win7 crossed the bridge
> 
> 2. while pinging from win7 to linux:
> 
> - linux gets broadcast ARP-WHO-HAS linux-ip
> - linux replays unicast ARP-IS-AT
> - those two repeat, so win7 doesn't get replay
> 
> Regarding this I can surely tell (this is all about 782M pair) that
> after box crossing the bridge MAC-port table is not updating (how it
> should be if it were switch's logic). Packets with srcMAC of crossed box
> CAN cross the bridge, but with dstMAC of crossed box CANNOT cross the
> bridge.

An explanation may be that the MAC table in each modem is updated only
with the source address of packets received on the ethernet port and not
those received through the VDSL link, based on the assumption that the
other modem already takes care of them.

Do the modems have a management interface that shows the contents of the
MAC table ?

Re: ebtables mac update

[Покотиленко Костик]

В Чтв, 01/07/2010 в 11:59 +0200, Pascal Hambourg пишет:
> Pokotilenko Kostik (approximate romanization) wrote :
> > 
> > Funny thing is that the problem persist. Tonight I've made some tests
> > with 782M. I've connected two computers in my office (win7 and linux)
> > through this pair directly. I seccessfully tested ping both directions,
> > then switched them so that each crossed the bridge and was unable to
> > ping.
> > 
> > tcpdump from linux showed:
> > 
> > 1. while pinging from linux to win7:
> > 
> > - Linux sends broadcast ARP-WHO-HAS win7-ip and no one replays
> > - I was able to see win7's ARP-WHO-HAS some-other-ip after that linux
> > probably learned it's MAC and started to send unicast ping requests,
> > still no replay
> > - I also saw some unicast packets from win7 crossed the bridge
> > 
> > 2. while pinging from win7 to linux:
> > 
> > - linux gets broadcast ARP-WHO-HAS linux-ip
> > - linux replays unicast ARP-IS-AT
> > - those two repeat, so win7 doesn't get replay
> > 
> > Regarding this I can surely tell (this is all about 782M pair) that
> > after box crossing the bridge MAC-port table is not updating (how it
> > should be if it were switch's logic). Packets with srcMAC of crossed box
> > CAN cross the bridge, but with dstMAC of crossed box CANNOT cross the
> > bridge.
> 
> An explanation may be that the MAC table in each modem is updated only
> with the source address of packets received on the ethernet port and not
> those received through the VDSL link, based on the assumption that the
> other modem already takes care of them.
> 
> Do the modems have a management interface that shows the contents of the
> MAC table ?

They do have management interface, but I was unable to find a way to see
MAC table. I'll discuss this with Zyxel support maybe they'll clear that
out. Main thing is that tonight I got chance to pull modems off
production and make those tests in simplified enviroment.

Thanks to all. Now it doesn't seem related to linux bridge, so if there
is new input I'll continue this thread.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Pascal Hambourg]

Pokotilenko Kostik wrote :
> 
> Main thing is that tonight I got chance to pull modems off
> production and make those tests in simplified enviroment.
>
> Thanks to all. Now it doesn't seem related to linux bridge

You can repeat the same experiment with a Linux bridge instead of the
VDSL modem pair. If all works fine, it'll rule out the Linux bridge.

Re: ebtables mac update

[Покотиленко Костик]

В Чтв, 01/07/2010 в 12:49 +0200, Pascal Hambourg пишет:
> Pokotilenko Kostik wrote :
> > 
> > Main thing is that tonight I got chance to pull modems off
> > production and make those tests in simplified enviroment.
> >
> > Thanks to all. Now it doesn't seem related to linux bridge
> 
> You can repeat the same experiment with a Linux bridge instead of the
> VDSL modem pair. If all works fine, it'll rule out the Linux bridge.

Good idea, thanks.

-- 
Покотиленко Костик <casper@meteor.dp.ua>

Re: ebtables mac update

[Grant Taylor]

On 06/29/10 07:36, Pascal Hambourg wrote:
> The Linux bridge maintains a MAC-port table based on the source MAC 
> address in received frames. As expected, if a MAC address was 
> associated to a given port and a frame from that MAC address is 
> received on a different port, then the table is updated accordingly. 
> Besides, rebooting the modems and not the Linux box fixes the 
> problem. So I doubt that the Linux bridge causes the problem.

I mostly agree.

The only thing that I would wonder about is is it possible that Linux is 
seeing the link go down on the physical NIC that is connected to the 
bridge, thus taking the logical port in the bridge down there by causing 
it's learned MAC addresses associated with that port to be lost.

This could easily be tested by putting a hub (or similar) between the 
Linux box and the Zyxel bridge.  That way when the bridge is rebooted, 
the Linux box does not see the link go down.  If the problem still 
corrects its self, you have completely removed the Linux box from the 
tests, there by strongly pointing at the Zyxel bridge.

> Of course the update process requires that the moved box sends 
> traffic first. If it just sits there waiting then MAC-port tables 
> won't be updated, until the entry eventually expires.

Agreed.

Pining or broadcasting looking to see what devices are on the far end 
should accomplish the same thing.

> Then may I ask what is the purpose of this box ?

Remember that EBTables modifies how in kernel bridging behaves.  Thus 
the in kernel bridging will still behave like a normal bridge, even if 
EBTables rules are not used.  (In fact it is possible to have bridging 
support in the kernel with out EBTables.)

Bridges will still learn (and forget / expire) where MAC addresses are. 
  So even if there were not EBTables rules, the bridge its self will 
learn what hosts are on what side of the bridge there by intelligently 
forwarding (or not) frames across the link that don't need to be.

I would have been tempted to put a bridge on both sides, not just the 
one.  Because as it is, broadcasts for the end with out the network are 
still propagated across the link.



Grant. . . .

Re: ebtables mac update

[Jan Engelhardt]

On Tuesday 2010-06-29 16:45, Grant Taylor wrote:
>
>The only thing that I would wonder about is is it possible that
>Linux is seeing the link go down on the physical NIC that is
>connected to the bridge, thus taking the logical port in the bridge
>down there by causing it's learned MAC addresses associated with
>that port to be lost.

Sure it does just that, seems like a sensible thing. If one bridge
port is down, there is no point in keeping a now-stale entry for
some MAC address.

Re: ebtables mac update

[Grant Taylor]

On 06/29/10 12:03, Jan Engelhardt wrote:
> Sure it does just that, seems like a sensible thing. If one bridge 
> port is down, there is no point in keeping a now-stale entry for some 
> MAC address.

Agreed.

The point being that rebooting the external bridge is causing Linux to 
do something that could be solving the problem.  Thus you can't be sure 
that the problem is with the external bridge.



Grant. . . .

Re: ebtables mac update

[Покотиленко Костик]

В Вто, 29/06/2010 в 09:45 -0500, Grant Taylor пишет:
> On 06/29/10 07:36, Pascal Hambourg wrote:
> > The Linux bridge maintains a MAC-port table based on the source MAC 
> > address in received frames. As expected, if a MAC address was 
> > associated to a given port and a frame from that MAC address is 
> > received on a different port, then the table is updated accordingly. 
> > Besides, rebooting the modems and not the Linux box fixes the 
> > problem. So I doubt that the Linux bridge causes the problem.
> 
> I mostly agree.
> 
> The only thing that I would wonder about is is it possible that Linux is 
> seeing the link go down on the physical NIC that is connected to the 
> bridge, thus taking the logical port in the bridge down there by causing 
> it's learned MAC addresses associated with that port to be lost.
> 
> This could easily be tested by putting a hub (or similar) between the 
> Linux box and the Zyxel bridge.  That way when the bridge is rebooted, 
> the Linux box does not see the link go down.  If the problem still 
> corrects its self, you have completely removed the Linux box from the 
> tests, there by strongly pointing at the Zyxel bridge.

Worth trying.

> > Of course the update process requires that the moved box sends 
> > traffic first. If it just sits there waiting then MAC-port tables 
> > won't be updated, until the entry eventually expires.
> 
> Agreed.
> 
> Pining or broadcasting looking to see what devices are on the far end 
> should accomplish the same thing.
> 
> > Then may I ask what is the purpose of this box ?
> 
> Remember that EBTables modifies how in kernel bridging behaves.  Thus 
> the in kernel bridging will still behave like a normal bridge, even if 
> EBTables rules are not used.  (In fact it is possible to have bridging 
> support in the kernel with out EBTables.)
> 
> Bridges will still learn (and forget / expire) where MAC addresses are. 
>   So even if there were not EBTables rules, the bridge its self will 
> learn what hosts are on what side of the bridge there by intelligently 
> forwarding (or not) frames across the link that don't need to be.
> 
> I would have been tempted to put a bridge on both sides, not just the 
> one.  Because as it is, broadcasts for the end with out the network are 
> still propagated across the link.

This is to be done. But there is no issue with this until now.

-- 
Покотиленко Костик <casper@meteor.dp.ua>