ifconfig output

Hello,

I have some problems with a server here: The server has two NICs where
one is working perfectly and the other is causing trouble. The NICs
(and thus the drivers) are identically, the only difference is the
connection:

eth0 (working) is connected with the usual patch cable / switch to the
rest of the network.
eth1 (trouble) is connected like this: NIC <-> patch cable <-> media
converter to optic fibre <-> optic fibre <-> media converter <-> patch
cable <-> switch ...

The result is this:

> ifconfig eth1

eth1 Link encap:Ethernet HWaddr 00:12:791:07:14
inet addr:10.1.1.45 Bcast:10.1.255.255 Mask:255.255.0.0
inet6 addr: fe80::212:79ff:fed1:714/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:25141063 errors:1279796 dropped:0 overruns:0
frame:5301
TX packets:21916162 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2083921694 (1.9 GiB) TX bytes:3060894452 (2.8 GiB)
Interrupt:19

-> Many errors and some entries in the "frame" field... There are no
errors /"frame" entries on eth0.

Now my questions are:

* How do I read this ifconfig output ? What are those errors ? What
does the "frame" field tell me ?
* Do you have an idea what can be wrong there ?

Some additional data:

gru@PT-AGCMLX1 >grep tg3 dmesg
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
tg3: eth1: Link is up at 100 Mbps, full duplex.
tg3: eth1: Flow control is off for TX and off for RX.

$ ethtool eth1
Settings for eth1:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes

( Exactly the same for eth0)

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.com

> Now my questions are:
> * How do I read this ifconfig output ? What are those errors ? What
> does the "frame" field tell me ?
> * Do you have an idea what can be wrong there ?

The output of "route -n" would place the ifconfig output in context.

On 15 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>,
(E-Mail Removed) wrote:

>eth0 (working) is connected with the usual patch cable / switch to the
>rest of the network.
>eth1 (trouble) is connected like this: NIC <-> patch cable <-> media
>converter to optic fibre <-> optic fibre <-> media converter <-> patch
>cable <-> switch ...

Couple of possibilities - can you interchange the NICs (eth0 vs eth1),
patch cords, and the port on the switch? Is it possible to (temporarily)
replace the fiber link with copper?

>eth1 Link encap:Ethernet HWaddr 00:12:791:07:14

[compton ~]$ etherwhois 00:12:79
00-12-79 (hex) Hewlett Packard
001279 (base 16) Hewlett Packard
20555 State Highway 249 South
MS070405
Houston TX 77070
UNITED STATES
[compton ~]$

> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:25141063 errors:1279796 dropped:0 overruns:0
frame:5301
> TX packets:21916162 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000

Oh, that's pretty sick. 5 percent of the packets have errors, and 0.02%
have frame errors. This generally indicates a hardware error. The 'frame'
errors indicate packets received that were not an exact number of bytes -
that is "bits % 8 != 0". The "errors" term indicates packets that fail
checksums - depending on the driver, this could be the 4 byte CRC at the
end of the Ethernet frame, or that and/or the 2 byte IP header checksum.
That's probably the main symptom. In simple terms, the packets are
getting corrupted because of noise.

> RX bytes:2083921694 (1.9 GiB) TX bytes:3060894452 (2.8 GiB)

Talkative link you have there. What does the ifconfig stats look like
for computers this link is talking to? Do they show Ethernet errors?

>* Do you have an idea what can be wrong there ?

1. Hardware problem - bad nic/cabling/media converters
2. Interference - in your case, the patch cables or media converters
located close to electrical equipment that in adding noise to the signal
on the cable

I'm assuming that the media converters are spec'ed to support 100 Megabit
speeds.

>tg3: eth0: Flow control is on for TX and on for RX.

>tg3: eth1: Flow control is off for TX and off for RX.

I don't _know_ that this is a problem, but it is something that is different.

Old guy

Hello Moe,

> Couple of possibilities - can you interchange the NICs (eth0 vs eth1),
> patch cords, and the port on the switch?

This is possible, but I have to wait until I have physical access and
none of our users is logged in - this could take a while...

> Is it possible to (temporarily) replace the fiber link with copper?

I don't think so.

> > RX bytes:2083921694 (1.9 GiB) TX bytes:3060894452 (2.8 GiB)
>
> Talkative link you have there. What does the ifconfig stats look like
> for computers this link is talking to? Do they show Ethernet errors?

No, all of the other connected machines show zero errors

> I'm assuming that the media converters are spec'ed to support 100 Megabit
> speeds.

I surely hope so ( I didn't set up the line, I just have the server ) !

> >tg3: eth0: Flow control is on for TX and on for RX.
> >tg3: eth1: Flow control is off for TX and off for RX.
>
> I don't _know_ that this is a problem, but it is something that is different.

Yes, I saw that, too. I tried ethtool to change these settings but had
no success. Could this be a hint that the media converter doesn't
interact smoothly with our NIC ?


Many thanks for your explanations !

Markus Grunwald

On 16 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, The Grue wrote:

>> Couple of possibilities - can you interchange the NICs (eth0 vs eth1),
>> patch cords, and the port on the switch?
>
>This is possible, but I have to wait until I have physical access and
>none of our users is logged in - this could take a while...

Obviously, getting access is required. Swapping the patch cords and port
shouldn't bother most users - only take a few seconds. The NIC - that's
another matter entirely.

>> Is it possible to (temporarily) replace the fiber link with copper?
>
>I don't think so.

How about the media converters? That's really what I'd be looking at rather
than the fiber.

>No, all of the other connected machines show zero errors

On a scale of 1 to 10, this raises the NIC and media converters from a '3'
to a '4' and lowers the probability of the patch cords slightly.

>Yes, I saw that, too. I tried ethtool to change these settings but had
>no success. Could this be a hint that the media converter doesn't
>interact smoothly with our NIC ?

I don't _think_ so - I'd expect this (flow control) to be a driver to NIC
issue more than a NIC to media, or media alone issue. Remember, unlike a
modem, there are only 'data' wires outside the NIC - nothing like DTR/CTS
issues.

Old guy

Hello Moe,

> On a scale of 1 to 10, this raises the NIC and media converters from a '3'
> to a '4' and lowers the probability of the patch cords slightly.

Our hardware supplied swears that the NIC has been amply tested and it
is quite new. They don't think it's the NIC.

It's in the hands of our EDP department now. We'll see, what they can
do (and when...). They want to take a look at the media converters, and
one of the switches will be changed soon.

Many thanks for your help. I'll write again if we should find the
error..

Markus

On 27 Mar 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, The Grue wrote:

>Our hardware supplied swears that the NIC has been amply tested and it
>is quite new. They don't think it's the NIC.

Im the 1930s (no, I'm not that old), the radio repair people in the
Royal Air Force used to test the electron tubes (valves) in the radios
by taking them out, gently bouncing them on the table. If they didn't
break, they were deemed good, and returned to service. I'm not saying
that's the case here, but I guess we'll have to wait to find out. ;-)

>Many thanks for your help. I'll write again if we should find the
>error..

Hopefully, they will find and fix it soon

Old guy