Service-Policy on Multilink Interface

[v_michael_]

I configured a 3072 kbps multilink interface with a service-policy where LLQ was allocated 2000 kbps. Now everytime the router reboots and one of the T1's in the multilink bundle is unavailable, the router removes the service policy from the multilink because the LLQ class requires more bandwidth (2000 kbps) than what is actually available on the multilik (1536 kbps).

So, I have been searching for a soluion. We can't use priority percentages in the LLQ class because we use CAC between CallManager and the phones.

One solution seems to be to hardcode the bandwidth of the multilink interface. This way the bandwidth value will not fluctuate on the multilink when the actual T1's fluctuate.

I was wondering whether hardcoding the bandwidth command on the multilink interface would create any issues when one of the T1's is down and the actual bandwidth is lower than the hardcoded bandwidth value on the multilink?

[Joseph W. Doherty · Accepted solution]

I'm unfamilar with CAC and CallManager, but when you lose half your physical bandwidth, how do you see keeping 2 Mbps for LLQ when the link only provides 1.5 Mbps? In other words, the correct solution might be to use a percentaged based LLQ config (if supported by your IOS), but if CAC and CallManager are unable to detect there's less bandwidth, it would seem the problem rests with them.(?)

You might post this issue on one of the VoIP forums to determine if there is a way for CAC and CallMangager to be notified when there's a change in available bandwidth.

[v_michael_]

I agree that the best solution for a multilink service-policy is to assign LLQ bandwidth by percentages. So, I will implement this solution. Thanks for the suggestions.

[Giuseppe Larosa]

Hello Michael,

just to add to good notes on Joseph's post.

You should use RSVP based CAC with two parallel L3 links (without multilink PPP).

RSVP making its usual reservations has the capability to handle multiple links between locations Call manager CAC cannot do this.

In addition RSVP can detect a link is failed dynamically.

This requires configuring RSVP on voice gateways on both sides of links.

see

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/cac.html#wp1043949

some changes can happen in different CUCM versions.

Hope to help

Giuseppe