A kernel in the range 2.0.25-36
bridging compiled in but not enabled,
a NIC that has been put in promiscuous mode for some time
and which then gets into a state in which it won't respond to ARP (or
ping, etc.).
Look - here:
1 itserv2:/> ping lm013
PING lm013.lab.it.uc3m.es (163.117.144.142): 56 data bytes
(nothing)
2 itserv2:/> grep 142 /proc/net/arp
163.117.144.142 0x1 0x2 00:60:97:BA:BF:D5 * eth0
3 itserv2:/> sudo tcpdump -e multicast and ether src 00:60:97:BA:BF:D5
tcpdump: listening on eth0
17:56:34.987257 0:60:97:ba:bf:d5 1:80:c2:0:0:0 0000 60: null I (s=0,r=0,C) len=42
0000 0000 0100 0060 97ba bfd5 0000 0000
0100 0060 97ba bfd5 0100 0000 1400 0200
0f00 0000 0000 0000 0000 0000 0000 0000
0000
Hurrrrrrrrr.
That machine has bridging configured on a modified 2.0.25 kernel and is
running a 3c905 on a 100BT switched net.
3c59x.c:v0.99 4/7/98 Donald Becker
http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
eth0: 3Com 3c905 Boomerang 100baseTx at 0x6100, 00:60:97:ba:bf:de, IRQ 10
My machine is doing the same, and is running a pure 2.0.36 kernel (!)
and an intel card.
eepro100.c:v0.99B 4/7/98 Donald Becker linux-eepro100@cesdis.gsfc.nasa.gov
eth0: Intel EtherExpress Pro 10/100 at 0xe400, 00:90:27:12:1A:C0, IRQ 12.
The problem is most pronounced on a subnet of 100MHz pentia with 3c509b
cards and 2.0.25 kernels. They were working happily for 2 years
and just moved over to join the bigger net on a powerhub fibre-driven
substrate. I moved the driver up to 1.13b from 1.07 last sunday. It
helped - probably because it resets the 3c509b's when they collapse
completely.
These packets are an appreciable fraction of the net traffic. They're
labelled as spanning tree in the lists, according to the multicast
address. The slow net is switched through the powerhub, where it joins
a fast switched 100BT net on 3c3000 switches.
I don't think they're taking down the net, but _something_ is. It seems
that all affected cards get into a mode where they won't do ARP, even
though they're correctly configured as MULTICAST, etc. From inside
one of these machines, one can see packets, and one can see that we're not
responding to arp.
Taking the interface down and up again fixes the problem. No need to
reload the drivers.
Any ideas? What should be looked at next.
Peter
-
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/