John Neiberger wrote: > > 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.
Thanks for that info, John. I wasn't sure if output errors counted collisions or not. I'm thinking hardware problem on the router maybe? Hardware problem on the wireless bridge's Ethernet interface? Bad cable, as you mentioned? Time to swap 'til you drop. I found this at Cisco's site: Output errors Number of times that 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. URL is: ww.cisco.com/univercd/cc/td/doc/product/voice/ics/ics25/icstg25/tsether2.htm A hardware problem could cause that, though I still wonder if it might just be too much load. High load could explain output errors (assuming that explanation is right, which is a lot to assume :-) and collisions. Of coures, a hardware problem could explain it too. One thing that is suspicious, though, is that deferrals are zero, while collisions aren't. If the network is really just busy with a high load in a healthy way, then there would probably be some deferrals too. I didn't want to mention this before because I hadn't found a good explanation for them, but I found one. Cisco says this: The deferred counter counts the number of times the interface has tried to send a frame, but found the carrier busy at the first attempt (Carrier Sense). This does not constitute a problem, and is part of normal Ethernet operation. URL for that is: http://www.cisco.com/warp/public/63/eth_collisions.html Why would a network have lots of collisions but no cases where a packet had to be deferred? This may be more evidence of a hardware problem, rather than a loading problem. It could also be evidence of the other side actually using full duplex despite its manual configuration. It sends whenever it wants, including while the other side is sending. Are you sure you can't just use full duplex? It would sure be cleaner! Even a healthy shared Ethernet is not a good medium for voice due to its inherent variable delay. Priscilla > > 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? > > John > > >>>> neil K 6/24/03 2:13:42 PM >>> > >The problem is that we are doing VoIP over the link using > Cisco FXO and > FXS > >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 > the > >Configuration side on the Routers, and have done QoS as well > on Routers, > but > >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. > > > >Thanks, > > > >neil > > > > > >""Priscilla Oppenheimer"" wrote in message > >news:[EMAIL PROTECTED] > >> 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 > Cisco > >> says that the threshold is 0.1%, but they just made that > number up. > >There's > >> no exact number where you have to be concerned, and most > experts have > said > >> 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. > >They > >> 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 > last > >> 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 > total > >> 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 > count > >> 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 > that > >> output errors are a cumulation of the other errors and that > they may not > >add > >> 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 > >the > >> 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 > statistics? > >> 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 > troubleshooting > >> action. > >> > >> If users are complaining, then use the troubleshooting > method called > "swap > >> 'til you drop." Change the cable, the interfaces, etc. But > my guess is > >that > >> nothing is wrong. Your interface looks extremely healthy. > >> > >> Priscilla > >> > >> > >> > 0 lost carrier, 0 no carrier > >> > 0 output buffer failures, 0 output buffers swapped out > >> > > >> > Thanks, > >> > > >> > neil > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71307&t=71176 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
