PING DROPS OBSERVED DURING VIDEO COFERENCING

A video conferencing partner of ours asked for help with a high-profile technology customer recently. The vendor’s gear was being blamed for frequent video conferencing session drops. This was causing friction between vendor and the customer’s network team, and pressure on the IT manager was mounting to fix the issue at all costs.

The symptom: Otherwise healthy video conference sessions end without warning, often during executive meetings.

The video conferencing vendor deployed PathView microappliances near the video endpoints at each of three high-profile locations, and PathView’s advanced path monitoring was configured between sites using the best practice of both single- and dual-ended path monitoring. This ensured a multi-protocol active performance analysis that would exclude the vendor’s equipment from possible root cause.

With per-minute performance monitoring enabled against strict thresholds for latency, loss, jitter, QoS changes, route changes and available capacity bottlenecks, we saw only low-level, intermittent loss. The WAN circuits were 100Mbps Internet services with IPSEC tunnels between sites to corporate and video conferencing traffic.

Although low levels of packet loss were noted in the customer’s service provider network (WAN), it was intermittent and not observed during the time the session drops were occurring. Here’s PathView showing a totally clean end-to-end network during the time of video conferencing session drops. Ruling out the network, we move on to the application.

Hi yogijain,
We cann't determine the cause of the accident from your description. Describe the configuration and network topology in detail. Thank you!

Hi , @yogijain

I'd came accross so many of these issues while working for an ISP, Packet drops can occur in delay sensitive traffic such as VC (Video Conferencing) and 90% of the times issue lies within IP network, so here are some common causes i encounter for similar VC problem,   (we always follow below sequence and almost everytime caught the problematic part)

-Having congetion in uplink of VC terminal, (you can check the port stats on your AR)

-Check routers MEMORY and CPU during active VC session

-Having congetion on UPLink of your router during VC session

-Take traces from VC terminal to destination and from destination to your VC terminal, both the traces should be symetric  (Asymetric Uplink and downlink     was the most common cause)

-if all those parts are fine then, check how much latency your Traces are showing, if its not in range contact your upstream provider for route optimization, 

if everything is fine till here then its not an IP-network issue. 

Hello friend,
Is the packet loss detected when the router pings the peer end?
Please check the following:
Whether error packets exist on the interfaces;
Whether the traffic exceeds the threshold;
Whether the CPU usage and memory usage are normal;
Whether packet loss is caused by CPU defense;
Whether exception logs are generated when packet loss occurs.

I hope this helps.

Thnaks to all for your valuable suggestion ..its not necesarry that problem is at router end ,..my concern was only to filter the issue

Please find some answers of question raised above

MPU 0(Master) : uptime is 15 weeks, 3 days, 6 hours, 2 minutes
SDRAM Memory Size : 512 M bytes
Flash 0 Memory Size : 512 M bytes
Flash 1 Memory Size : 2 M bytes
MPU version information :
1. PCB Version : AR01SRU0B VER.B
2. MAB Version : 0
3. Board Type : AR201
4. CPLD0 Version : 102
5. BootROM Version : 733

<MUKA-MNR107-RTR1037>dis heal
<MUKA-MNR107-RTR1037>dis health
---------------------------------------------------------------------------
Slot Card Sensor No. SensorName Status Upper Lower Temp(C)
---------------------------------------------------------------------------
0 - 1 AR201 TEMP NORMAL 74 0 32
Info:The device does not support power display!
System CPU Usage Information:
System cpu usage at 2020-02-15 07:32 397 ms
-------------------------------------------------------------------------------
SlotID CPU Usage Upper Limit
-------------------------------------------------------------------------------
0 16% 80%
System Memory Usage Information:
System memory usage at 2020-02-15 07:32 407 ms
-------------------------------------------------------------------------------
SlotID Total Memory(MB) Used Memory(MB) Used Percentage Upper Limit
-------------------------------------------------------------------------------
0 333 153 46% 90%
System Disk Usage Information:
System disk usage at 2020-02-15 07:32 427 ms
-------------------------------------------------------------------------------
SlotID Device Total Available Used Memory(MB) Used Percentage
Memory(MB)
-------------------------------------------------------------------------------
0 flash: 457.58 148.44 32.44%
<MUKA-MNR107-RTR1037>dis esn
<MUKA-MNR107-RTR1037>dis esn
ESN of device: =======================
<MUKA-MNR107-RTR1037>dis ip int brief
*down: administratively down
^down: standby
(l): loopback
(s): spoofing
(E): E-Trunk down
The number of interface that is UP in Physical is 6
The number of interface that is DOWN in Physical is 2
The number of interface that is UP in Protocol is 5
The number of interface that is DOWN in Protocol is 3

Interface IP Address/Mask Physical Protocol
Cellular0/0/0 unassigned down down
Ethernet0/0/6 unassigned down down
Ethernet0/0/7 =============/29 up up
Ethernet0/0/8 ==============/30 up up
GigabitEthernet0/0/0 unassigned up down
LoopBack100 ============/32 up up(s)
NULL0 unassigned up up(s)
Vlanif1 =============/29 up up

<MUKA-MNR107-RTR1037>dis cu int Ethernet0/0/8
[V200R007C00SPC900]
#
interface Ethernet0/0/8
ip address X.X.X.X
mirror to observe-port both
traffic-policy WAN outbound
#
return
<MUKA-MNR107-RTR1037>dis traffi
<MUKA-MNR107-RTR1037>dis traffic-pol
<MUKA-MNR107-RTR1037>dis traffic-policy appl
<MUKA-MNR107-RTR1037>dis traffic-policy applied-record WAN
-------------------------------------------------
Policy Name: WAN
Policy Index: 0
Classifier:PREMIUM_RT Behavior:PREMIUM_RT
Classifier:BUSINESS Behavior:BUSINESS
-------------------------------------------------
*interface Ethernet0/0/8
traffic-policy WAN outbound
slot 0 : success
Classifier: PREMIUM_RT
Operator: AND
Rule(s) :
if-match acl 3006
Behavior: PREMIUM_RT
Committed Access Rate:
CIR 6656 (Kbps), PIR 0 (Kbps), CBS 1248000 (byte), PBS 2496000 (byte)
Color Mode: color Blind
Conform Action: pass
Yellow Action: pass
Exceed Action: pass
Marking:
Remark DSCP ef
statistic: enable
Classifier: BUSINESS
Operator: AND
Rule(s) :
if-match acl 3007
Behavior: BUSINESS
Marking:
Remark DSCP af11
statistic: enable
Committed Access Rate:
CIR 26624 (Kbps), PIR 0 (Kbps), CBS 4992000 (byte), PBS 9984000 (byte)
Color Mode: color Blind
Conform Action: pass
Yellow Action: pass
Exceed Action: pass
-------------------------------------------------
Policy total applied times: 1.
<MUKA-MNR107-RTR1037>dis clock
2020-02-15 07:32
Saturday
Time Zone(IST) : UTC+05:30

Hi @yogijain
If you mean that you want to exclude the error possibility of the router, and since the service is video conference, you are suggested to check the QoS configuration and type of dropped packets.
Also, you should confirm sum of the traffic if it has exceeded the forwarding capacity already.

Hi @yogijain,
Kindly help to answer the issue below.
Ping drops, did the user ping the router drops, or ping packets dropped when crossing the router.