I'm concerned about the output errors. Collisions are not considered output
errors; they're to be expected with half duplex ethernet. So, you do really
have a problem of some variety that needs to be investigated.
I'm not familiar with the bridge you're referring to. Are you positive that
it is running half duplex? Are you positive you have a good cable?
>>>> neil K 6/24/03 2:13:42 PM >>>
>The problem is that we are doing VoIP over the link using Cisco FXO and
>ports and People are complaining about Voice breaking up, like a bad cell
>phone call. I heard it myself, it sounds good but sometimes breaks up.The
>routers are running g.729 and use the Wireless link. I have looked into
>Configuration side on the Routers, and have done QoS as well on Routers,
>still these issues. I did a MOS score calculation and it was 4.03 which is
>Acceptable" which means that the call quality should be good, but, it is
>not. Then I checked the Ethernet Interface counters, and saw collisions
>increasing rapidly, and hence the question.
>""Priscilla Oppenheimer"" wrote in message
>> neil K wrote:
>> > The Cisco bridge operates in Half-duplex and that is why
>> > half-duplex. The
>> > Router is a Cisco 1751 with WIC-1ENET, which is connected to
>> > the Wireless
>> > Bridge.
>> > I checked with the "output Interpreter" on CCO and it said the
>> > collisions
>> > are more than 0.53 much higher than 0.1 normal rate.
>> That doesn't sound like a serious problem.
>> > Here's the output of sh interfaces e 0/0
>> > Ethernet0/0 is up, line protocol is up
>> > Hardware is PQUICC Ethernet, address is 0004.dd0d.5502 (bia
>> > 0004.dd0d.5502)
>> > Internet address is 172.20.1.2/24
>> > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
>> > reliability 255/255, txload 1/255, rxload 1/255
>> > Encapsulation ARPA, loopback not set
>> > Keepalive set (10 sec)
>> > Half-duplex, 10BaseT
>> > ARP type: ARPA, ARP Timeout 04:00:00
>> > Last input 00:00:00, output 00:00:00, output hang never
>> > Last clearing of "show interface" counters 3d20h
>> > Input queue: 0/75/0/0 (size/max/drops/flushes); Total output
>> > drops: 0
>> > Queueing strategy: weighted fair
>> > Output queue: 0/1000/64/0 (size/max total/threshold/drops)
>> > Conversations 0/5/256 (active/max active/max total)
>> > Reserved Conversations 0/0 (allocated/max allocated)
>> > Available Bandwidth 7200 kilobits/sec
>> > 5 minute input rate 53000 bits/sec, 13 packets/sec
>> > 5 minute output rate 8000 bits/sec, 13 packets/sec
>> > 4528216 packets input, 642790340 bytes, 0 no buffer
>> > Received 176451 broadcasts, 0 runts, 0 giants, 0 throttles
>> > 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
>> > 0 input packets with dribble condition detected
>> > 6314935 packets output, 279254727 bytes, 0 underruns
>> > 59281 output errors, 86548 collisions, 0 interface resets
>> 86548 divided by 6314935 is about 1%. That's not a big deal. I know
>> says that the threshold is 0.1%, but they just made that number up.
>> no exact number where you have to be concerned, and most experts have
>> for years that Cisco's 0.1% is extremely low. They just want to sell you
>> switches! :-)
>> Collisions are a normal part of Ethernet's media access control method.
>> go up with load as 2 or more stations try to send simultaneously.
>> You aren't seeing a high load now, but the load statistic is for the
>> five minutes. If you want to try to correlate load with collisions, you
>> should clear the counters and keep an eye on the statistics.
>> The nefarious 59281 output errors are curious. It's supposed to be a
>> of all the other output errors and I would think it would count the
>> collisions, but Cisco isn't very clear about this. Why wouldn't they
>> all the collisions? Or maybe the output errors are different from the
>> collisions, but I don't know what else they would be. Cisco just says
>> output errors are a cumulation of the other errors and that they may not
>> up to the others because a frame could have more than one error, which
>> doesn't apply to your situation.
>> > 0 babbles, 0 late collision, 0 deferred
>> 0 deferred is a good sign, as are all those other 0 error counts.
>> I don't think you really have a problem. What gave you concern? I guess
>> collisions went up. But that would be normal if they went up at the same
>> time as both ends of the interface were trying to send a lot of traffic.
>> By the way, what does the other end say about errors? (i.e. the wireless
>> bridge interface, can it show you some statistics?)
>> What else did Cisco's Output Interpreter have to say about the
>> Can you copy and paste its report? It could help us help you.
>> Are users complaining? If not, I would say just to use the data you have
>> gathered as baseline data, but not as data that causes any
>> If users are complaining, then use the troubleshooting method called
>> 'til you drop." Change the cable, the interfaces, etc. But my guess is
>> nothing is wrong. Your interface looks extremely healthy.
>> > 0 lost carrier, 0 no carrier
>> > 0 output buffer failures, 0 output buffers swapped out
>> > Thanks,
>> > neil
Message Posted at:
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx