[cisco-voip] CM4.1 Network congestion reroute troubleshooting ?

Wes Sisk wsisk at cisco.com
Wed Apr 30 16:00:22 EDT 2008


Hi Kevin,

Good catch on the phones, that is a frequent trigger. Other info inline 
[ws]:


> 1. Anyway to see the number of inter location calls active and there DN's ?
>   
ws: perfmon counter (RTMT counters in 5.x and later) will show active 
calls per region/location and available b/w.  Unfortunately it does not 
correlate to device/dn.
> 2. Anyway to see which calls are currently making up the
> inter-location calculation ?
>   
ws: CM SDI traces.  For traces turn up detailed CM SDI traces and set 
the CM service parameter "Locations Trace Details Flag". For CDR effort see:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cdr_defs/4_x/cdr413.html

> 3. Any other possible reasons to get the "Congestion" messages ?
>   
ws: this is strictly determined by CM's internal bandwidth accounting 
(well, until 6.x and RSVP agents). So this very likely has nothing to do 
with actual interface or link usage, it's just what CM believes is 
happening based on configuration.
> 4. Any other hints most welcome ?
>   
ws: wait until after hours or low period of utilization and check 
perfmon counters for avail/used bandwidth per location.  If CM 
encoutnered a Cdcc or bandwith leak you will see bandwith used even at 
times when no calls are active.  If perfmon counters shows calls active, 
does it make sense?  A Cdcc leak could leave a 'call' active and 
bandwidth reserved.  Recovery is either restart CM service or click 
"resync bandwidth" on the locations bandwidth page.  With the location 
trace details flag enabled the locations bw table is printed in SDI 
traces every time locations b/w is reallocated.  In the table you see 
the Cdcc value for every 'active' call. Example: cdccPID=(2.22.83776).  
If you look in the table and see two entries cdccPID=(2.22.83776) and 
cdccPID=(2.22.83) This would imply 2 active calls.  The last number is a 
monotonically increasing sequence number for every call.  This would 
imply that the '83rd' call is up and consuming bandwidth and the 
'83776th' call is up and consuming bandwidth.  Logically this does not 
make sense.  It is extremely unlikely that both the 83rd call and the 
83776th call should be active at the same time.  Think of it in terms of 
hours, if both of these were active and your call volume were 83,000 
calls per day, then that 83rd call would have been up and connected for 
 >24 hours.  That is extremely unlikely.  If it is true, you're going to 
have a nice phone bill ;)

/Wes


More information about the cisco-voip mailing list