Introduction to RSVP

Could you provide the full device configs at the end please?


Hi Chris,

Just added the startup and final configs.



Can i do a reservation let’s say for a server behind a particular router? On your example you have R1 thru R4 and a reservation from 1 to 4 on telnet. Instead of include the IP assign to an interface can i use the IPs behind a particular router?

Hello Diego

In this lesson, Rene is using the sender-host and reservation-host commands which are used to simulate a host generating RSVP PATH messages and a host generating RSVP RESV messages respectively. These are used to simulate such hosts particularly for debugging purposes.

If you were to include a server (the RSVP sender) and a client (the RSVP receiver) then you would have to enter both the sender and the receiver into the RSVP database with the required parameters (IP address, ports, bandwidth etc…). More about how this is achieved can be found at the following Cisco documentation:

I hope this has been helpful!


Hi im a little bit confused about the RSVP RESV.
Im reading about it in the “offical cert guide” (encor 350-401 from cisco press).

On page

Dont feel that I get enough explained in the book. dont fully understand why the “previous hop” and "from "adresses are used in that case…

can someone please care to explain a little better then in the book

Hello Sam

Yes, the way it is explained is a little bit confusing. Let me try to clarify.

Let’s assume we’re looking at video server sending video data to a host, and the video server wants to reserve bandwidth along the path to the host. It is assumed that all routers in between the server and the host are enabled with RSVP.

The server sends a PATH message to the host. This message includes both the source and destination IP (server and host) of the traffic that requires the reservation, as well as the amount of bandwidth to be reserved. This information is stored in each RSVP node that receives and forwards the PATH message.

Once the PATH message reaches the host, it responds with a RESV message. This RESV message will trace the path backwards to the sender. The message must go hop-by-hop in order to ensure that the reverse path being taken is the same as the initial path This is necessary, because only those nodes in that particular path have stored the relevant data in their RSVP databases. For this reason, the RESV message is sent from router to router, with source and IP destination addresses those of the routers themselves. The ultimate destination of the RESV packet is known, since this information is found within the RSVP database that was originally created using the PATH message, so RSVP has the necessary information to ensure that the RESV packet will reach the server.

When it says “…the IP destination address of a RESV message is the IP address of the previous-hop node, obtained from the RSVP path state of each node” what it is saying is that as the RESV message goes from node to node, the destination address of that RESV is the next router in the return path. The text refers to this next router as the “previous hop node” from the point of view of the direction of the initial PATH message.

The wording in the book is ambiguous, as the terms “source” “destination” and “previous hop node” are not being used clearly, and introduce confusion.

I hope this has been helpful!


Yes i guess it is a typo in the book
since the first “last” RSVP RESV messages (on the far left on the picture says:
FROM: TO: TCP DPORT 23 SPORT 12345 Previous HOP
(The client to the far left is
because the client cant be the last hop node (before it returns to the client :smiley: )
I never experied so much error in a OFFICAL Cert Guide before…
its very time consuming for a person that trying to learn from scratch.
Im very thankful to this community.

Is the traffic flowing from right to left on the picture (RSVP Path State) or is the boxes with the source adresses just a ilustration that where the traffic origininated ?
think im still litte confused by this book :slight_smile:

I think i understand

The boxes with the source ip is the traffic flowing from left to right (like the initial RSVP Path messages)
but I got confused since the arrows was pointing in the oposit direction (right to left)
I thought the boxes on the images was for the RESV message… since they where linked in to the picture with the (reversed trafic flow).

Best regards.

Hello Sam

This does happen from time to time in various certification guides. I’m happy however that you find the NetworkLessons community helpful.

Yes, you’ve got it. It’s a little difficult to keep the directions straight in your head. Just remember that the initiator and sender of the data sends the PATH message, and the receiver sends the RESV message. The PATH message travels in the same direction as the data from the initiator.

I hope this has been helpful!


How is the average bit rate 64 kbps but the max burst is 32 kbps?

Hello Justin

When using the ip rsvp sender-host command, the last two entries specify the average bit-rate in kbps that is to be reserved, and the maximum burst size, again in kbps. The burst size indicates the kbps beyond the average bit rate that is allowed.

So with a bit rate of 64 kbps and a maximum burst size of 32 kbps, such a configuration can support 64 kbps continually, and occasionally (64 + 32) 96 kbps bursts.

Note that this command is used to simulate a host generating an RSVP path message, essentially reserving the path with the specific parameters indicated. You can find more information bout this command here:

I hope this has been helpful!



Can you please explain RSVP-TE with configuration example?


Hello Nihar

RSVP for MPLS-TE is an extensive subject that may require several lessons! You can always go to the Member Ideas page and suggest that Rene create a lesson on this topic. You may find that others have suggested it as well, and if so, you can add your voice to theirs.

In the meantime, you can take a look at the following Cisco documentation that details the use of RSVP for MPLS-TE and includes examples:

I hope this has been helpful!


Hi all,
I am doing the same topology in the lesson in GNS3. In R1 instead of tcp and port 23 i configured below:

ip rsvp sender-host 1 0 0 1 1

My flow matches ICMP (protocol number with value 1) and reservation is for 1kbps. In all links i have mtu 9216. A ping from R1 specifying the size to 9000 shouldn’t be dropped because the flow is only 1kbps? I still have replies on that ping. Am i missing something? :disappointed:

Hello Mario

Just to confirm, with your setup, you expect that a ping of 9000 bytes should be dropped due to the fact that even a single frame of 9000 bytes will surpass the 1 kbps limit you have placed, correct?

Remember that RSVP will reserve bandwidth on an end to end path. With the command you have above, you are reserving 1kbps. That doesn’t mean that anything above that will be dropped. If the link is capable of supporting more than that, it will transmit data at higher rates. That’s why your pings are succeeding.

RSVP mechanisms, like all QoS mechanisms, will only be enabled when there is network congestion. In such cases, priority will be given to those packets conforming to the RSVP commands. Other traffic will be dropped only if congestion on the links doesn’t allow them to pass through. In your case I’m assuming there is no other traffic, so your pings go through successfully.

I hope this has been helpful!


1 Like

HI Rene, Could you please explain the below?

start requesting 64 kbps FF reservation for TCP-> on FastEthernet0/0 neighbor
RSVP>[]: Refresh RESV, req=674BDE94, refresh interval=0mSec [cleanup timer is not awake]
RSVP>[]: Sending Resv message to
RSVP>[]: RESV CONFIRM Message for (FastEthernet0/0) from
RSVP>[]: Sending RESV CONFIRM message to

Why does the R3 wait to send the RESV CONFIRM to R4 until it get the RESV CNFRM message from Is this the normal behavior?

Hello Malith

RSVP requires that each and every router in the intended path participate in reserving the appropriate resources. In order to achieve this, the ultimate receiver, which in this lab is R4, will send a RESV message upstream, all the way back to the original sender, which is R1. R1 will then send an RESV CONFIRM message back downstream all the way to R4.

For this reason, when you look at the debugs of R3 for example, you will indeed see that the RESV is received from R4 first, it is then forwarded to R1 ( Once R1 receives it, it sends back an RESV CONFIRM message, which reaches R3, and is then forwarde3d to R4. So the order of the events is correct.

R3 can only forward whatever it has received. So it receives the RESV and then sends it. It then receives an RESV CONFIRM and then sends it.

You can find out more details about this mechanism in the Reservation Model section of RFC 2205 which describes RSVP in detail.

I hope this has been helpful!


I’m trying to replicate this lab on GNS3, but I have problems to establish the rsvp path between routers.

On R1 I can see this debug message.

May 30 10:24:23.877: RSVP:>[]: Path refresh, Event: none, State: stay in normal
*May 30 10:24:23.878: RSVP:>[]: Path refresh (msec), config: 30000 curr: 30000 xmit: 30000

But I am not able to capture any traffic with WireShark that is related with RSVP.

Can you attach a RSVP capture?

Hello Giovanni

Hmm, I’m not sure why you’re not able to get it working. However, you will find that it’s not possible to directly filter RSVP protocols while capturing. You will have to use the IP protocol type of 0x2e. Take a look at this link from Wireshark (although I see that it is incomplete, it does have some info).

Let us know how you get along!

I hope this has been helpful!


I’d like to consolidate this knowledge.

1st cmd issued at interface level (config-if)#ip rsvp bandwidth 128 64 tells the router it must do a 128Kbps BW Reservation ? But what happen if nobody request a RSV PATH MSG ? For example for 10Mbps interface has been configured with this cmd , it means if someone want to forward 10Mbps towards this interface couldn’t do that because there are 128Kbps allocated ?

2 cmd at global config : R1(config)#ip rsvp sender-host tcp 23 0 64 32 this cmd emulate a host or in other words R1 behaves as a host requesting a BW reservation for a certain flow ?

3rd cmd at R4 : R4(config)#ip rsvp reservation-host tcp 23 0 ff rate 64 32 also R4 behaves as a host but the purpose of this cmd is a kind of confirmation or acknowledgment to R1 request ?

Hello Juan

This command configures the following on the interface:

  • 128 Kbps have been allocated for use with RSVP. This is the largest total bandwidth that can be set aside for RSVP purposes.
  • 64 Kbps is the largest bandwidth that can be reserved for a single flow.

So on this setup, you can have a maximum of two flows each of 64 Kbps. Any requests for anything larger or any request after two flows have already been allocated will fail. If nobody requests to reserve bandwidth, nothing will be allocated. These values are the limits set for this path.

Yes, this command is used to make the router act as a host and request bandwidth to be allocated. Note here that typically routers will not do this. This is a specialized command that is used under lab conditions. RSVP hosts are typically workstations, servers, IP phones or other end devices.

Yes, this command simulates another host device, but this time, the one that receives and responds to the RSVP PATH message. Again this is used for simulation and testing purposes and has no functionality in production networks.

To summarize:

  • The sender-host command is used to simulate a host generating an RSVP PATH message
  • The reservation-host command is used to simulate a host generating RSP RESV messages

More about these commands can be found here:

I hope this has been helpful!


1 Like