[cisco-voip] CUCM Traces | LBM Question

Daniel Pagan dpagan at fidelus.com
Tue Mar 18 15:59:18 EDT 2014


Folks:

I have a quick questions with regards to LBM traces and operations.

LBM traces print the location-to-location relationship in a bi-directional format. For example, when the requested reservation is added in LBM for a call using a single location link:

On one line I'll see...
"RES_REC add Edge PH-Phones_Location->DC-Phones_Location. Left=<avail_BW>, Calls=<#ActiveCalls>"

While the next line prints...
"REC_REC add Edge DC-Phones_Location-> PH-Phones_Location. Left=<avail_BW>, Calls=<#ActiveCalls>".


The "Left=" and "Calls=" are the same. I understand CUCM has moved to a relationship model with location based CAC, but assigning bandwidth between locations is mirrored in both ways. Changing the location bandwidth from location-A to location-B is mirrored to match location-B to location-A. So my question is why does LBM traces print the available bandwidth and number of active calls for each direction of the loc-to-loc relationship? I ask because I'm wondering if there's a specific scenario where one should expect different values for the bi-directional entries.

Even in a scenario with enhanced CAC and using a location path instead of a direct location link (ie. locA --> locC [NYC-1] -->locB), the same LBM trace entries are found.

The reservation is added in LBM:
|LBM: RES_REC add Edge DC-Phones_Location->NYC-1_Location. Left=80, Calls=1
|LBM: RES_REC add Edge NYC-1_Location->DC-Phones_Location. Left=80, Calls=1
|LBM: RES_REC add Edge NYC-1_Location->PH-Phones_Location. Left=40, Calls=1
|LBM: RES_REC add Edge PH-Phones_Location-> NYC-1_Location. Left=40, Calls=1

I also see the same trace entries during a reservation adjustment.
Any insight to this would be great. This isn't an issue, only curiosity.

Thanks ahead of time.

- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140318/8aaca169/attachment.html>


More information about the cisco-voip mailing list