Prev: upside-down-ternet <humor>
Next: nmap -sP not the same as ping
From: pduffy on 5 May 2010 07:13
Just wondering if anyone has experienced anything like this, and if
so, if they have any idea what could be causing it.

A number of our boxes are HP dx5150 running Red Hat 4.3 (kernel
2.6.9-42). The onboard NIC is Broadcom BCM5751 Gigabit.

Every now and then, these boxes lose contact with the network: we find
that the central network switch (Cisco) has shut down the port, having
apparently detected that the MAC address of the connected box has
changed. Once the security on the port is reset, everything continues
as normal. (The incorrect MAC address detected by the switch is always
08:00:45:00:FF:F8.)

Obviously, this is now a fairly old version of Red Hat, and we've
found that an upgrade to kernel 2.6.9-55 seems to solve the problem
(we have application-related constraints limiting the kernels to which
we can upgrade.) However, it would be really good to understand this
problem.

Any ideas?
From: Moe Trin on 5 May 2010 15:51
On Wed, 5 May 2010, in the Usenet newsgroup comp.os.linux.networking, in article
<f68557e2-f392-4638-821c-b547d39013cc(a)a34g2000yqn.googlegroups.com>, pduffy
wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

>A number of our boxes are HP dx5150 running Red Hat 4.3 (kernel
>2.6.9-42). The onboard NIC is Broadcom BCM5751 Gigabit.

[compton ~]$ etherwhois BROADCOM
00-10-18 (hex) BROADCOM CORPORATION
001018 (base 16) BROADCOM CORPORATION
16215 ALTON PARKWAY
P.O. BOX 57013
IRVINE CA 92619-7013
UNITED STATES
[compton ~]$

>Every now and then, these boxes lose contact with the network: we
>find that the central network switch (Cisco) has shut down the port,
>having apparently detected that the MAC address of the connected box
>has changed. Once the security on the port is reset, everything
>continues as normal. (The incorrect MAC address detected by the
>switch is always 08:00:45:00:FF:F8.)

[compton ~]$ etherwhois 08:00:45
08-00-45 (hex) CONCURRENT COMPUTER CORP.
080045 (base 16) CONCURRENT COMPUTER CORP.
2 CRESCENT PLACE
OCEANPORT NJ 07757
UNITED STATES
[compton ~]$

Interesting. It's a REALLY wild guess, but I wonder if something is
messing up the Ethernet driver. I'm guessing you are using the
standard RFC0894 Ethernet frame. That begins with 64 bit preamble
(0xAAAAAAAAAAAAAAAB) which is never seen outside of the NIC, then
a pair of 48 bit MAC addresses (destination - source) and a 16 bit
type field. For IP datagrams, the type is 0800 (the only other
likely type on the wire is an ARP packet - 0806). What follows is
an IP header - which _begins_ with a 4 bit version, 4 bit header
length, 8 bit TOS (type of service), and a 16 bit total length of
the datagram in bytes. See RFC0791. Now it's a bit of a stretch,
but the last 16 bits of the Ethernet header, plus the first 16 bits
of the IP header are highly likely to be... 08 00 45 00
The problem comes with the next 8 bits, as a length of 0xFFF8 is
illegal.

>However, it would be really good to understand this problem.

No kidding. Do post back here if you can identify the actual cause.
It would be really nice to be able to put a packet sniffer on that (or
is it "those" because it's happening on more than one port) wire to
see what the actual packets are.

As another bit of information, the OUI 08:00:45 goes back a fairly
long time - at least to March 1990, and (what amounts to be a serial)
number 00:FF:F8 would be relatively early in a production run.

Old guy
 | 
Pages: 1
Prev: upside-down-ternet <humor>
Next: nmap -sP not the same as ping