> 01 80 C2 00 00 01 00 A4 00 80 D2 9C 88 08 00 01
> 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00
The killer packet has a strange destination MAC address
IMHO. IEEE 802.1d explicitly marks 01:80:C2:00:00:01 as
"Reserved for future standardization".
Maybe the cisco interprets this as a spanning tree frame. If
it is, it would be easy to explain the cisco spewing out all
kinds of strange packets. If you interpret this as a spanning
tree frame, it has the 'root bridge' field set to
00 00:00 00 00 00 00 00. The cisco would then think: Hey, a
bridge with a bridge ID lower than mine! This is the new
root bridge for this lan! (root bridges are like designated
routers in OSPF). It would then go out and spew 'Topology
changed' messages, telling the other bridges about the
new designated root.
This would settle in a minute or so after disconnecting the linux
box, when the ciscos time out the information.
Linux STP (i.e. "bridging") is not originating this frame.
The STP frames linux originates:
1. have a mac dest addr of 01:80:c2:00:00:00
2. have a packet length in bytes 12 and 13 (frame[12] = 0, frame[13]=0x26)
3. have frame[14]=0x42, frame[15]=0x42, frame[16]=0x03 (dont ask)
4. have frame[17]=0x00, frame[18]=0x00 (protocol identifier)
5. have frame[19]=0x00 (protocol version identifier)
2.2.5 has Jean-Rene Peulve's patches in, so they will never send out
a ethernet packet which is too small.
I don't think your ethernet card can generate STP frames. (There are
quad port cards which can do STP themselves). I never heard of a
kernel which generates 01:80:c2:00:00:01 frames. None of your
processes generates 01:80:c2:00:00:01 frames. So? I'm puzzled.
Can you run tcpdump on that machine, verifying that the packets are
really locally generated? Do you trust everyone on your ethernet? No
script kiddies? (It's so easy to poison the 802.1d I wouldn't be
surprised if there were at least 10 zillion n3th3kk3rz 'toolz' out there.)
Maybe 01:80:c2:00:00:01 is some kind of vlan stp? I know nothing
about this stuff.
IMHO you shouldn't be blaming cisco for this. It's very easy to kill _any_
STP'ed ethernet. The bridge with the lowest bridge ID has preference
when selecting a root bridge, so if you just say your priority field is 0
you
are the root bridge. From that point on it's very easy to poison your
spanning tree with faulty information. This is a misfeature of the spanning
tree protocol, but the STP designers wanted plug-and-play configuration.
You _can_ tell the cisco's not to let a specific MAC addr participate in
the stp I believe. I have a catalyst 1600 or so over here. I believe it lets
me do this.
Disabling multicast doesn't help you here, as this is not an IP multicast
datagram.
What patches do RH apply to their stock 2.2.5?
Can you tell me what packets the ciscos spit out (only if it's not too much
trouble) in response?
Just some thoughts,
Lennert Buytenhek
<buytenh@dsv.nl>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/