cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1400
Views
0
Helpful
3
Replies

RSVP Issue

Hello everyone,

I have a question about the RSVP Agent, and CUCM RSVP CAC.

I have 128 kbps Frame Relay interface, with 1 DLCI connected to other peer Router. CUCM is configured with all the necessary Locations for RSVP, with MRGL as well.

interface Serial0/3/0
bandwidth 128
no ip address
encapsulation frame-relay
clock rate 128000
frame-relay traffic-shaping
ip rsvp bandwidth
!
interface Serial0/3/0.1 point-to-point
ip address X.X.X.X 255.255.255.0
snmp trap link-status
frame-relay class Shape
frame-relay interface-dlci 101
frame-relay ip rtp header-compression
ip rsvp bandwidth 40

When I configure the command "ip rsvp bandwidth 40" on the subinterface, it is also automatically configured on the Main Serial Interface as well (just without the value). Why is it so?

When I issue the "show ip rsvp interface" command, it shows me that the RSVP Bandwidth for Frame Relay subinterface (0/3/0.1) is 40 kbps, and Serial interface RSVP bandwidth is 96 kbps.

As you can see, I have configured only 40 kbps for IP RSVP Bandwidth on subinterface, so that only one G729 call should be allowed, but when I am testing it, up to 4 calls can be made, the the RSVP is somehow reserving the bandwidth for all 4 calls (I did not test more calls). Why it is doing so?

Locations are configured with "Mandatory (Video desired)" option.

Can you please help me to understand, why the RSVP is allowing up to 4 calls, when I have configured the command "ip rsvp bandwidth 40" for allowing only 1 G729 call?

3 Replies 3

Steven Griffin
Level 4
Level 4

To answer your questions:

When I configure the command "ip rsvp bandwidth 40" on the subinterface, it is also automatically configured on the Main Serial Interface as well (just without the value). Why is it so? 

All interfaces that voice may traverse need the ip rsvp bandwidth statement, since this is a sub-interface the main interface will need it too.

When I issue the "show ip rsvp interface" command, it shows me that the RSVP Bandwidth for Frame Relay subinterface (0/3/0.1) is 40 kbps, and Serial interface RSVP bandwidth is 96 kbps.

RSVP, by default, automatically will allow reservation of up-to 75% of an interfaces bandwidth unless you say otherwise.  96 kbps is 75% of your 128kbps frame relay connection.

As you can see, I have configured only 40 kbps for IP RSVP Bandwidth on subinterface, so that only one G729 call should be allowed, but when I am testing it, up to 4 calls can be made, the the RSVP is somehow reserving the bandwidth for all 4 calls (I did not test more calls). Why it is doing so? 

Locations are configured with "Mandatory (Video desired)" option.

Couple of reasons why this could be occuring.  The obvious one is that the aforementioned 96 kbps on Serial 0/3/0 is allowing four G.729 calls as each call is 24K you can fit exactly 4 calls into 96kbps  (24*4 =96). Set your ip rsvp bandwidth statement to be 40 on the main serial interface.

The other reason is that you may not have enabled rsvp policy preemption.   Add the global command "ip rsvp policy preempt" to your router so that CUCM can preempt RSVP reservations.  It is also a good idea to disable the actual 'reservation' of bandwidth on the interface and just let the RSVP sub-system only 'track' the bandwidth used by voice calls.  Add the following commands to each interface that has ip rsvp bandwidth.

 ip rsvp data-packet classification none
 ip rsvp resource-provider none

There is also a great Cisco Voice of the Engineer recording all about RSVP call agent. 
https://cisco.webex.com/ec0605lc/eventcenter/recording/recordAction.do;jsessionid=jpR7TyGJpB3nTrkD1W3YSJjchg1Kgxqht3fhzdMXgqQF23wxHkvN!-2072492621?theAction=poprecord&actname=%2Feventcenter%2Fframe%2Fg.do&actappname=ec0605lc&renewticket=0&renewticket...

-Steven



Please help us make the communities better. Rate helpful posts!

Those commands did not help.

The RSVP is still reserving more then 1 call.

michael-luo
Level 1
Level 1

It's really hard to tell without looking at CCM traces.  But I guess for some reason, the two endpoints was not mapped to the right location, thus the CAC was not enforced.

Try set the CCM trace level to detailed and test it again.  Upload trace here with detailed info (date/time, calling number, called number).

Michael