Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Dropping Packets on 10baseT EIP on RSP7000

We have an older RSP7000 with an EIP board. We use an AUI to RJ45 Transceiver to connect to a CISCO 5505 switch. The switch port is auto detected at 10bt half duplex. The router also has an ESCON Channel Interface (CIP) Approx. 144mb/sec .

During an outgoing FTP (out the 10bt ethernet) we are experiencing packet loss and high retransmissions.

A "sh int eth 0/0" indicates dropped packets and a high number of collisions.

Is the "dropped packets" a normal behavior for this situation. I would think the outgoing ethernet interface would try to ensure the packets got delivered. I tried increasing the out hold-queue, but had no affect. I tried traffic shaping but had a negative affect, it made the FTP transfer slower and there were still packet drops.

Is this packet drop to be expected or is there something else configuration wise that can be done?

New Member

Re: Dropping Packets on 10baseT EIP on RSP7000


on a half duplex device collisons are normal.

You sould configure the speed and duplex fixed on you C5K. Configuring Speed and duplex to auto on one side of the link, and fix on the outher side of the link is not recommended. However, I think this is not your problem.

Don't mess up Mbit/s and MByte/s.

An Escon Channel Interface has an troughput of approx 17 MByte/sec, this is 136Mbit/s. It is full duplex.

Your Ethernet Interface only has 1.25MByte/s, this is 10Mbit/s. It is hlaf duplex.

You can find troughput tests under

So your ethernet Interface is much slower than the Escon Channel. Try to replace the interface with a FastEthernet Interface.



New Member

Re: Dropping Packets on 10baseT EIP on RSP7000

Thank you for your response. Yes, I understand there is bottleneck here and that a FE would be the best solution. I was curious why increasing the out hold-queue did not reduce the number of packets dropped. I thought when Ethernet encountered a collision, it backed off and tried again. Why is that not working here?