Cisco IOS Voice Troubleshooting and Monitoring -- VoIP over Frame Relay with Multipoint PVCs and Prioritization Troubleshooting

From DocWiki

Revision as of 23:56, 17 December 2009 by Pzimmerm (Talk | contribs)
Jump to: navigation, search

Guide Contents
Troubleshooting Cisco IOS Voice Overview
Debug Command Output on Cisco IOS Voice Gateways
Filtering Troubleshooting Output
Cisco VoIP Internal Error Codes
Troubleshooting Cisco IOS Voice Telephony
Troubleshooting Cisco IOS Voice Protocols
Troubleshooting Cisco IOS Telephony Applications
Monitoring the Cisco IOS Voice Network
Cause Codes and Debug Values

When you are troubleshooting the traffic-shaping and prioritization for a VoIP over Frame Relay network with hub and spoke topology, the configuration of the hub is such that there are two permanent virtual circuits (PVCs) for each remote spoke, and both data and voice are sent over both PVCs.

Note Note: The prioritization and fragmentation discussed in this document applies not only to this scenario but also to a scenario where you may have one PVC with voice and data and another with only data. The data PVCs need to be traffic-shaped just as the voice and data PVCs are. This is because when a single physical pipe is shared, in this case at the hub, the serialization delay affects all data items, regardless of the PVC they are destined for.

The following debug commands can help you troubleshoot traffic-shaping and prioritization for VoIP over Frame Relay.

  • debug priority-Displays PQ events and indicates whether dropping occurs in this queue. Frame Relay is a special case with respect to policing the priority queue. The PQ is policed to ensure that the fair queues are not starved of bandwidth. When you configure the PQ, you specify in kbps the maximum amount of bandwidth available to that queue. Packets that exceed that maximum are dropped. Originally, the priority queue of a service-policy configured in a Frame Relay map class was policed during periods of congestion and noncongestion. Cisco IOS Release 12.2 removes this exception. PQ is still policed with FRF.12, but other nonconforming packets are only dropped if there is congestion.
  • debug frame-relay fragment-Displays event or error messages related to Frame Relay fragmentation. The command is only enabled at the PVC level on the selected interface.
 newyork# debug priority
 Priority output queueing debugging is on  
 newyork# ping 172.16.120.1 
 Type escape sequence to abort.   
 Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds:   
 !!!!!   
 Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms   
 newyork#   
 00:42:40: PQ: Serial2/0: ip -> normal   
 00:42:40: PQ: Serial2/0 output (Pk size/Q 104/2)   
 00:42:40: PQ: Serial2/0: ip -> normal   
 00:42:40: PQ: Serial2/0 output (Pk size/Q 104/2)   
 00:42:40: PQ: Serial2/0: ip -> normal   
 00:42:40: PQ: Serial2/0 output (Pk size/Q 104/2)   
 00:42:40: PQ: Serial2/0: ip -> normal   
 00:42:40: PQ: Serial2/0 output (Pk size/Q 104/2)   
 00:42:40: PQ: Serial2/0: ip -> normal   
 00:42:40: PQ: Serial2/0 output (Pk size/Q 104/2)   
 00:42:41: PQ: Serial2/0 output (Pk size/Q 13/0)   
 newyork# debug frame-relay fragment interface serial 2/0 100  
 This may severely impact network performance.  
 You are advised to enable no logging console debug. Continue?[confirm]  
 Frame Relay fragment/packet debugging is on  
 Displaying fragments/packets on interface Serial2/0 dlci 100 only  
 Serial2/0(i): dlci 100, rx-seq-num 126, exp_seq-num 126, BE bits set, frag_hdr 04 C0 7E   
 Serial2/0(o): dlci 100, tx-seq-num 82, BE bits set, frag_hdr 04 C0 52  

For more information about VoIP over Frame Relay with Multipoint PVCs and Prioritization, refer to VoIP over Frame Relay with Multipoint PVCs and Prioritization, document 12162.

Rating: 0.0/5 (0 votes cast)

Personal tools