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
Received on Sat Sep 1 12:35:33 2007