[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