Overruns on Ethernet interface

[ccotech00]

Can anyone please tell me what it means if i get overruns on a ethernet interface. It is a Cisco 1721 router and it plugs into a 3Com superstack 2 switch.

212 input errors, 0 CRC, 0 frame, 212 overrun, 0 ignored

[lgijssel]

The definition is as follows:

Overrun Packets; Packets that were discarded because the node has a temporary overload of packets to handle.

If I were you, I would check duplex settings and make sure that ip fast switching is enabled.

The latter is activated through:

int fa0

ip route-cache

Regards,

Leo

[ccotech00]

Thanks ,could this be due to excessive broadcasts ?

[lgijssel]

This might be very well possible. All Broadcasts must be examined by all network nodes, putting their cpu's under stress which in turn limits througput.

Regards,

Leo

[peterledwidge]

Hi,

If the errors your seeing are on the router you might try apply a hold-queue to the interface.

For more details, refer:

http://www.cisco.com/univercd/cc/td/doc/product/software/ssr90/tsc_r90/54021.htm

[ccotech00]

I enabled fast switching on the interface but the problem still persists ,the interface is forced to run 100mb full duplex ,i also checked the amount of broadcast traffic and it only amounts to about 3.5 percent of total packets received ,which seems reasonable.I can apply a hold-queue to the interface ,but would like to establish the source of the problem as their is only about 15 users on site and there should not be alot of traffic generated on network

[Kevin Dorrell]

Is your router running CEF? Try posting the configs here and see if anyone can spot anything.

Have you done a show cpu proc? That might show you if something is hogging the CPU.

Kevin Dorrell

Luxembourg

[ccotech00]

Yes router is running CEF ,CPU util is running at about 2% so no problems there. I changed the iput queue to a 100 and haven`t had any overruns since ,but i`ll monitor it today.What does CEF do ?

[Kevin Dorrell]

Very briefly, what CEF does is to pre-prepare a fast lookup table from the routing table so that packets can be switched in interrupt code, or even in hardware, rather than jumping through the hoops of process switching or constructing a fast-cache. In higher-end routers, the CEF is handled in hardware ASIC so that the CPU does not need to get involved in packet switching at all.

There are things that can stop CEF doing its job - like log on an access list for example, or some other CPU-based activity. I think we would need to see the configuration to know if that is the case. You can get information about CEF from show ip cef interface. There is lots of other interesting information here, like how to verify that CEF is doing its job:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_tech_note09186a00801e1e46.shtml

It sounds like that your traffic pattern is very bursty, and the CPU couldn't get the packets off the input queue fast enough. But short bursts, so the average CPU is still low.

Anyway, glad you found a solution.

Kevin Dorrell

Luxembourg

[ccotech00]

Unfortunately it hasn`t solved the problem yet ,although there are less overruns now ,it still receives some overruns ,what will be the negative side to maybe changing the input queue to 150 or more, in other words what will this effect on the router ? appreciate your feedback.

[DouglasScott99]

Thing is that as has been discussed the overruns may be caused by quite short bursts. The 1700 is clearly no a high performance unit and it may be susceptible to bursts of broadcasts or even regular traffic.

0.

As already recommended make sure that you are fast switching.

1.

[I am pretty convinced that this is good advice.]

Check the buffers. sh buf

If you are getting failures then there are you lost packets. If you have enough memory gradually increase the number of buffers until you stop getting misses and failures.

2.

[I just made this up but it does seem reasonable]

Consider inbound Access lists on the interfaces (especially the ethernet) to protect the router from unwanted broadcasts.

e.g.

access-list 101 deny ip any host 255.255.255.255

access-list 101 permit ip any any

This will still allow ARP to operate. Clearly if you need soem of the broadcasts e.g. for DHCP, then this will not work.

3.

I don't think that nicreasing the queues will help but try it. To downside is that it will affect the behaviour of TCP and may (will) increase network latency when the network is saturated.

You could use a sniffer or try "deb ip pac" to see what traffic is coming in.

OBSERVE correct debug precautions. This suggested debug could well cause the router to hang completely.

Don't do it unless you can recover, and when the network is available for this work.

Finally, (belatedly)

Is this significant? What proportion of packets are actually being lost?