Introduction to RSVP

Lessons Discussion
41

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!

Laz

1 Like
42

HI Rene, Could you please explain the below?

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

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

43

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 (192.168.12.1). 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!

Laz

44

Hi
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: 192.168.12.1_0->168.168.34.4_23[0.0.0.0]: Path refresh, Event: none, State: stay in normal
*May 30 10:24:23.878: RSVP: 192.168.12.1_0->168.168.34.4_23[0.0.0.0]: 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?

45

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).

https://wiki.wireshark.org/RSVP.md

Let us know how you get along!

I hope this has been helpful!

Laz

46

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 192.168.34.4 192.168.12.1 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 192.168.34.4 192.168.12.1 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 ?

47

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!

Laz

1 Like