High level description
1. Obtain an accurate problem description:
• Display flickering, snowy
• Pinkish,greenish,blueish
• Black Display during loopback as well as during the call
• Half image, zoom in
• Other....
Obtain pictures or video when problem is happening
• New install, upgrade?
• Reproducible, random
• Start of the call, end of the call, after display is idle?
• Point to point calls?, Multi-point calls?
• Do we have a video or a picture when problem occurs.
• Problem only with one type of unit? Interop ?
• Problem appears after firmware upgrade? Any network changes?
• Any message during the failure (i.e Network congestion etc.)
• Verify type of Display and generation (CTS 500 GEN2 37", CTS 1000 GEN2 65", etc)
• Obtain app code and boot code:
- App code, boot code and firmware must be the same on all three displays
Isolating the problem
- We can try first a loopback with encoder enabled, this will confirm codec itself is not dropping packets
From SSH CLI:
diag display loopback full enable
diag display loopback full enable
- If ICMP is enabled across the path we can use mtr to see which device may be introducing delay, packet loss, etc.
Replace 160 for your current QoS marking:
- Verify Packets sent/receive show proper QoS value and proper policy maps are matched
- Network devices:
Verify SRND guide to make sure we meet network requirements:
1) ‘show run’ output
In addition, I would suggest collecting the following information to further isolate network traffic:
1) Interf type x/y <- WAN interface
2) ‘load-interval 30’
3) Reproduce problem and keep call up for perhaps 5 mins and then collect
the following information while the call is still up and while packet loss is being seen:
a) ‘show interf intftype x/y’
b) ‘show policy-map interf intftype x/y ’
c) ‘show queue intftype x/y’
The above should allow us to (a) determine what our guaranteed bandwidth really is (b) determine where we are seeing drops (ex: interface drops vs software queuing drops).
In addition, I would suggest collecting the following information to further isolate network traffic:
1) Interf type x/y <- WAN interface
2) ‘load-interval 30’
3) Reproduce problem and keep call up for perhaps 5 mins and then collect
the following information while the call is still up and while packet loss is being seen:
a) ‘show interf intftype x/y’
b) ‘show policy-map interf intftype x/y ’
c) ‘show queue intftype x/y’
The above should allow us to (a) determine what our guaranteed bandwidth really is (b) determine where we are seeing drops (ex: interface drops vs software queuing drops).
No comments:
Post a Comment