On Sat September 1 2007 04:30, Eugen Leitl wrote: > On Sat, Sep 01, 2007 at 02:31:47AM +0200, Herbert Poetzl wrote: > > > well, most likely, spanning tree is the magic word here :) > > > > (http://en.wikipedia.org/wiki/Spanning_tree_protocol) > > I use spanning tree since my firewalls are redundant (STP > disables one firewall, which gives you a poor man's > failover capacity -- sure no carp+pfsync). > > However, in this case the outages are intermittant, and what > happens is every couple hours or so the switch suddenly notices > a packet with a MAC which used to be on port 6 suddenly comes > in at port 49, at which point it ignores anything with that > MAC on port 6 until the period of MAC aging expires, and it > decides it's been port 6 after all. > > So why would > > switch-1 (level 3) > | | > NIC1 | > system | > NIC2 | > | | > switch-2 (level 2) > > do that? Notice that the system doesn't route. It all > happens at Ethernet frame level. > When brtables was an add-on, it also added on spanning tree routing - Now that brtables is built-in, I would suppose that the spanning tree algorithm is also built in now. I.E: The kernel is also a level 2 bridge with S.T. and the vserver isolation is at level 3 (ip). I think your mention of pulling the loop cable clearing the problem was a key clue in what is happening. Why the kernel-bridge would randomly send a traffic packet on a redundant link ???? no idea, unless it had a vlan to establish routing for. Can you snoop the bridge configuration packets on that cable loop? Or maybe put a brtable rule in that logs what the kernel bridge is doing? The kernel bridge code has been working problem free for many generations of Linux - but bit rot happens. Mike