High overrun errors after subinterface creation

[hoffa2000]

Hi folks

I've just split a gigabit interface on my 7301 into two dot1q interfaces and set the other end point interface (Cat6513) as a trunk only allowing the two VLANs.

Before this setup I had no incoming errors on the 7301 but after about half a day I see the figures below on the 7301

170912969 packets input, 85343674837 bytes,

Received 3013 broadcasts, 0 runts, 0 giants

122247 input errors, 0 CRC, 0 frame, 122247 overrun

The overrun counter is constantly incremented. Both the physical interface on the 7301 and the one on the 6513 has VLAN 1 set as the native VLAN. Is that a problem? I could hardly see that a perfectly working interface should get hardware errors just because I alter the VLAN tagging.

Regards

Fredrik

[Joseph W. Doherty]

Now using the same interface for a trunk, has the volume of physical traffic increased?

[glen.grant]

?How busy is the link now that you have 2 links running across the trunk, input errors are usually caused by overutuilization on a link .

[hoffa2000]

That was my initial theory, that the traffic had increased but it hasn't. Its the same amout of traffic sent to the interface, the only difference is that it's seperated by dot1q tags for different processing on the router.

/Fredrik

[Joseph W. Doherty]

Found this within Cisco documentation:

"overrun

Number of times the receiver hardware was unable to hand received data to a hardware buffer because the input rate exceeded the receiver's ability to handle the data."

Perhaps the extra handling of the VLAN tag is just a bit too much for the 7301 to keep up with the input data rate.

Fast path switch is documented as 1 Mpps, but process switching is only listed at 79 Kpps. Seen any difference in CPU utilization?

[hoffa2000]

Not really. Perhaps an increase from 15 to 20% CPU utilization.

So the overrun has nothing to do with any untagged packets flowing over the trunk, for example broadcasts from the native vlan?

/Fredrik

[Joseph W. Doherty]

I wouldn't think so. I wonder though about the extra 5% cpu. Doesn't sound like much of an increase, but we don't know how bursty this average increase represents.

Two things you might try, if feasible, either try 100 Mbps on this link or use a shaper on the 6513 to decrease the rate to just a little more than your average rate.

My thinking is a 100% busy 100 Mbps would spread the interface frame processing time vs. what you might see in bursts on a gig interface showing 10% utilization. With a shaper you can shape to your average rate plus a little more, again though, the frames will have additional time between them.

Beyond that, perhaps someone else has a solution or it's time to open a TAC case, if you have a support contract.