Red Hat 7.2 Slow Ethernet Outgoing Traffic

Hi,

I am running RH 7.2 and it's on a 10mb/sec ethernet connection
at a co-location center.

The eth0 interface card is an Intel Pro/1000 running at half-duplex.

I can receive data at 400-600 KB/sec but my outgoing IP traffic
is usually between 50-100 KB/sec. Another computer on the same
network switch sends outgoing traffic at 300-400 KB/Sec. So I
don't think it's a network congestion problem. I have ran iptraf
and although I am not sure what I am looking at, nothing seems
to unusual. There are times when the outgoing traffic is around 100KB/sec
when there is nothing I know of sending data. Is there a better way to
monitor if some type of virus is spewing data out? I downloaded and
installed Bitdefender anti-virus, but it detected nothing.

I don't know if the data sending is a software or hardware problem. I disabled
iptables, just to make sure that wasn't slowing it down. But that had no
affect. I ran up2date -u to update the latest code, but that didn't help
either. My ISP doesn't know what to do. I guess I could swap IP's with another
box in the rack, but that probably won't help.

Does anyone have any idea? This is a fairly new machine, dual 2.8GHZ Xeon with
SCSI, so the data throughput shouldn't be that slow. Any help would be appreciated?

Thanks,

Mike

Mike Dross wrote:
> Hi,
>
> I am running RH 7.2 and it's on a 10mb/sec ethernet connection
> at a co-location center.
>
> The eth0 interface card is an Intel Pro/1000 running at half-duplex.
>
> I can receive data at 400-600 KB/sec but my outgoing IP traffic
> is usually between 50-100 KB/sec. Another computer on the same
> network switch sends outgoing traffic at 300-400 KB/Sec. So I
> don't think it's a network congestion problem. I have ran iptraf
> and although I am not sure what I am looking at, nothing seems
> to unusual. There are times when the outgoing traffic is around 100KB/sec
> when there is nothing I know of sending data. Is there a better way to
> monitor if some type of virus is spewing data out? I downloaded and
> installed Bitdefender anti-virus, but it detected nothing.
>
> I don't know if the data sending is a software or hardware problem. I disabled
> iptables, just to make sure that wasn't slowing it down. But that had no
> affect. I ran up2date -u to update the latest code, but that didn't help
> either. My ISP doesn't know what to do. I guess I could swap IP's with another
> box in the rack, but that probably won't help.
>
> Does anyone have any idea? This is a fairly new machine, dual 2.8GHZ Xeon with
> SCSI, so the data throughput shouldn't be that slow. Any help would be appreciated?
>
> Thanks,
>
> Mike
Could be lots of things. Usually I start fixing these kinds of problems
by taking a trace of the network when the problem is presenting. Take a
look at that in ethereal or tcpdump, and you'll probably get a clue as
to whats going on. There may be an ip conflict on the network, a
serveron the other end might be shrinking your tcp window, there may be
lots of retransmits for a certain application, etc. Start with the
trace and you'll likely find a lead.
HTH
Neil

--
Neil Horman
Red Hat, Inc., http://people.redhat.com/nhorman
gpg keyid: 1024D / 0x92A74FA1, http://www.keyserver.net

Neil Horman <(E-Mail Removed)> wrote in message news:<bs9ei7$4q7$(E-Mail Removed)>...
> Mike Dross wrote:
> > Hi,
> >
> > I am running RH 7.2 and it's on a 10mb/sec ethernet connection
> > at a co-location center.
> >
> > The eth0 interface card is an Intel Pro/1000 running at half-duplex.
> >
> > I can receive data at 400-600 KB/sec but my outgoing IP traffic
> > is usually between 50-100 KB/sec. Another computer on the same
> > network switch sends outgoing traffic at 300-400 KB/Sec. So I
> > don't think it's a network congestion problem. I have ran iptraf
> > and although I am not sure what I am looking at, nothing seems
> > to unusual. There are times when the outgoing traffic is around 100KB/sec
> > when there is nothing I know of sending data. Is there a better way to
> > monitor if some type of virus is spewing data out? I downloaded and
> > installed Bitdefender anti-virus, but it detected nothing.
> >
> > I don't know if the data sending is a software or hardware problem. I disabled
> > iptables, just to make sure that wasn't slowing it down. But that had no
> > affect. I ran up2date -u to update the latest code, but that didn't help
> > either. My ISP doesn't know what to do. I guess I could swap IP's with another
> > box in the rack, but that probably won't help.
> >
> > Does anyone have any idea? This is a fairly new machine, dual 2.8GHZ Xeon with
> > SCSI, so the data throughput shouldn't be that slow. Any help would be appreciated?
> >
> > Thanks,
> >
> > Mike
> Could be lots of things. Usually I start fixing these kinds of problems
> by taking a trace of the network when the problem is presenting. Take a
> look at that in ethereal or tcpdump, and you'll probably get a clue as
> to whats going on. There may be an ip conflict on the network, a
> serveron the other end might be shrinking your tcp window, there may be
> lots of retransmits for a certain application, etc. Start with the
> trace and you'll likely find a lead.
> HTH
> Neil


I just did a ifconfig and look at all the TX errors and collisons:
This computer is using the Intel Pro 1000 (e1000) drivers. It is autonegoting
a 10MB/half duplex. Could this be the problem. The other computer on the same
network, one IP up reports a clean ifconfig.

Here is the problem computer:

eth0 Link encap:Ethernet HWaddr 00:30:48:20:13:FD
inet addr:207.106.235.71 Bcast:207.106.235.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:50077822 errors:0 dropped:0 overruns:0 frame:0
TX packets:32169550 errors:2218909 dropped:0 overruns:0 carrier:2218909
collisions:18561082 txqueuelen:100
RX bytes:1537668928 (1466.4 Mb) TX bytes:264992038 (252.7 Mb)
Interrupt:26 Base address:0xe400 Memory:feba0000-febc0000

Here is another linux computer on the same network using a different
network adapter:

eth0 Link encap:Ethernet HWaddr 00:30:48:22:B3B
inet addr:207.106.235.73 Bcast:207.106.235.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:57029132 errors:0 dropped:0 overruns:0 frame:1763815
TX packets:53446775 errors:0 dropped:0 overruns:0 carrier:0
collisions:1 txqueuelen:100
RX bytes:1050387987 (1001.7 Mb) TX bytes:745039743 (710.5 Mb)
Interrupt:31


What should I do??

Thanks,

Mike

Mike Dross wrote:
> Neil Horman <(E-Mail Removed)> wrote in message news:<bs9ei7$4q7$(E-Mail Removed)>...
>
>>Mike Dross wrote:
>>
>>>Hi,
>>>
>>>I am running RH 7.2 and it's on a 10mb/sec ethernet connection
>>>at a co-location center.
>>>
>>>The eth0 interface card is an Intel Pro/1000 running at half-duplex.
>>>
>>>I can receive data at 400-600 KB/sec but my outgoing IP traffic
>>>is usually between 50-100 KB/sec. Another computer on the same
>>>network switch sends outgoing traffic at 300-400 KB/Sec. So I
>>>don't think it's a network congestion problem. I have ran iptraf
>>>and although I am not sure what I am looking at, nothing seems
>>>to unusual. There are times when the outgoing traffic is around 100KB/sec
>>>when there is nothing I know of sending data. Is there a better way to
>>>monitor if some type of virus is spewing data out? I downloaded and
>>>installed Bitdefender anti-virus, but it detected nothing.
>>>
>>>I don't know if the data sending is a software or hardware problem. I disabled
>>>iptables, just to make sure that wasn't slowing it down. But that had no
>>>affect. I ran up2date -u to update the latest code, but that didn't help
>>>either. My ISP doesn't know what to do. I guess I could swap IP's with another
>>>box in the rack, but that probably won't help.
>>>
>>>Does anyone have any idea? This is a fairly new machine, dual 2.8GHZ Xeon with
>>>SCSI, so the data throughput shouldn't be that slow. Any help would be appreciated?
>>>
>>>Thanks,
>>>
>>>Mike
>>
>>Could be lots of things. Usually I start fixing these kinds of problems
>>by taking a trace of the network when the problem is presenting. Take a
>>look at that in ethereal or tcpdump, and you'll probably get a clue as
>>to whats going on. There may be an ip conflict on the network, a
>>serveron the other end might be shrinking your tcp window, there may be
>>lots of retransmits for a certain application, etc. Start with the
>>trace and you'll likely find a lead.
>>HTH
>>Neil
>
>
>
> I just did a ifconfig and look at all the TX errors and collisons:
> This computer is using the Intel Pro 1000 (e1000) drivers. It is autonegoting
> a 10MB/half duplex. Could this be the problem. The other computer on the same
> network, one IP up reports a clean ifconfig.
>
> Here is the problem computer:
>
> eth0 Link encap:Ethernet HWaddr 00:30:48:20:13:FD
> inet addr:207.106.235.71 Bcast:207.106.235.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:50077822 errors:0 dropped:0 overruns:0 frame:0
> TX packets:32169550 errors:2218909 dropped:0 overruns:0 carrier:2218909
> collisions:18561082 txqueuelen:100
> RX bytes:1537668928 (1466.4 Mb) TX bytes:264992038 (252.7 Mb)
> Interrupt:26 Base address:0xe400 Memory:feba0000-febc0000
>
> Here is another linux computer on the same network using a different
> network adapter:
>
> eth0 Link encap:Ethernet HWaddr 00:30:48:22:B3B
> inet addr:207.106.235.73 Bcast:207.106.235.255 Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:57029132 errors:0 dropped:0 overruns:0 frame:1763815
> TX packets:53446775 errors:0 dropped:0 overruns:0 carrier:0
> collisions:1 txqueuelen:100
> RX bytes:1050387987 (1001.7 Mb) TX bytes:745039743 (710.5 Mb)
> Interrupt:31
>
>
> What should I do??
>
> Thanks,
>
> Mike
Could be, if the other side of the connection isn't negotiating to the
same setting. Don't know what would cause that, but I have seen some
products simply not be able to autonegotiate with one another. You
might try forcing other settings on your NIC (using ethtool or
mii-tool), and optionally disabling autonegotitate.

HTH
Neil

--
Neil Horman
Red Hat, Inc., http://people.redhat.com/nhorman
gpg keyid: 1024D / 0x92A74FA1, http://www.keyserver.net