TX and RX Packet Loss

[anthony.chadwick]

I have an E20.  I'm getting transmit (TX) packet loss above 15 percent.   However, my receive (RX) packet loss is 0 percent.  The distant  endpoint is the inverse - TX = 0 percent & RX = 15 percent plus.   Looking at the switch port, I've got no dropped packets or CRC errors.   So, one question I have is how is the packet loss being calculated?   More importantly, what can I look at?  I've checked my cables and they  are good.  One E20 is in campus bldg. A and the other is across the city  if that helps.

[Paulo Souza]

Hi Anthony,

Have you check the ethernet speed of both endpoints? Have they negotiated 100/Full as expected? What about your QoS in the network, are the endpoints marking QoS correctly? Are the network devices ready to prioritize the video traffic according to the marking used by endpoints? What is the bandwidth used in the call? If you try to decrease the bandwidth, does something change?

Those are things which I think you should investigate.

Paulo Souza

Please rate replies and mark question as "answered" if applicable.

[anthony.chadwick]

Both endpoints have negotiated at 100/Full.  There is no QoS.  The bandwidth used in the call is 384k, I've increased it to 512k but with the same results. 

[Martin Koch]

Could you tell us a bit more about the deployment. (network & call control) and how the call itself is established.

Loss can also be caused by MTU problems, routers dropping or routing packts into the nirvana ,...

If a call control is involved which binds the media to itself or some other host this leg also has to be investigated.

Please remember to rate helpful responses and identify helpful or correct answers.

[anthony.chadwick]

The network itself is Cisco equipment on both ends.  I lowered the MTU settings to 1300, but that gives me the same results.  There is a SIP registrar that the calls are flowing/routing through.

[Martin Koch]

You could to a tcpdump directly on both devices (check that all involved systems have their time synced with ntp, that makes it easier to find packets in different traces) and compare both and see if you already send out some damaged packet.

You could do the same with mirror ports on the network.

If you have the chance to grep one of the systes and place both in the same network you could see if this is the problem.

Replacing the networr cables and check the network cables could also be worth a try.

Also check that the right interface on the e20 is used.

In general thats generic troubleshooting, just try to elimiate different factors and see what happens,  ....

Please remember to rate helpful responses and identify helpful or correct answers.

[Chris Swinney]

My money would be on the good old duplex mismatch somewhere along the path. This doesn't have to be between the CODEC and the local switch, but could be at ANY point in the chain - even on equipment out of your visibility.

For instance, we had a nightmare recently trying to track down packet loss issue at a remote campus site that was connected via a GRE tunnel to the main campus. The network manager looked at every port on every switch and router on both campus', but couldn't find an issue. It was only after I visited the site and noticed that the traffic LEDs on a port on a switch (belonging to the provider that connected their edge router to a fibre link) was merrily blinking slow Orange indicating a fault on the port. Turns out that this had been configured incorrectly with one side forced to 100/full (on the their) router), and the other set to Auto Negotiate. This is the classic mismatch where the Auto negotiate side will default to 100/half.

Whilst the entire remote campus was affected, no one really noticed any problem apart from with the videoconfernceing that result in a multitude of lost packets in one direction.

I take it that this call does NOT route through VCS? Are you able to make remote calls via a VCS to a separate know good remote site? The VCS is a great tool to narrow down where a problem lies as you can check the media stats on the INCOMING leg, so combined with stats from the endpoint, you can at least narrow down the network segment where the issue is occurring.

To fault find the issue further, I would suggest testing the local campus first. A simple test is to locate a CODEC as close to the egress of the network as possible, then make a call to the first CODEC and the second. This again narrow down you search. Do the same at the other end and you can then eliminate either your own network or the providers.

Good Luck

Chris