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.
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.
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).
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 ?
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
How often is RSVP used with QoS? From what I see, it can get quite complex to configure and doesn’t seem very scalable.
I also have a lot of questions about how RSVP works.
I have a one gig link here. This command basically says that I am enabling RSVP on the interface, but I am only allowing 100 kbps of it to be used for the purpose of RSVP, where a single flow cannot be higher than 50 kbps.
If I understand this command right, this is telling the local device to make a reservation for a flow sourced from 192.168.12.1 destined to 192.168.12.2 that is using telnet, whereas the reservation should ask for 128 kbps of BW with the option to burst up to 192 kbps?.
What exactly happens if the sender makes a reservation that doesn’t match what the destination has configured?
Sender: ip rsvp sender-host 192.168.12.2 192.168.12.1 TCP 23 0 128 64
Destination: ip rsvp reservation-host 192.168.12.2 192.168.12.1 TCP 23 0 FF RATE 64 128
I’ve switched the kbps around, and it turns out the reservation is still completed successfully, but the sender doesn’t get the full BW they asked for. They only get 64 kbps:
What exactly does the ERROR message do, and what is the sender trying to say here? It keeps going on and on like this.
I have 3 routers in the path. On each one, I’ve enabled rsvp, where I dedicated 100 kbps of the link’s bandwidth and allowed only 50 to be requested in one flow. I’ve made R1 request for a gigabit of bandwidth and configured the destination (R3) the same way (ip rsvp reservation-host 192.168.23.3 192.168.12.1 TCP 23 0 FF LOAD 1000000 128)
Despite having only 50 kbps allowed, R3 seems to be happy to make the reservation
With RSVP, the hosts will send an RSVP message to make a bandwidth reservation. On Cisco IOS, the command to make a switch/router act as an RSVP host is ip rsvp sender-host. How would this be implemented on a real computer, though? And when would it reserve the bandwidth? Each time it tries to use the flow or even if it isn’t used?
Are these bandwidth reservations valid even if we aren’t congested?
What’s up with the “delay reservation”? I understand that you can reserve bandwidth, but delay? How does that work?
Yes. This command makes the R1 router act as an RSVP host requesting the specific resources (128kbps with 64kbps burst rate) along the whole path from R1 to R4.
This is expected, because R4 has been configured to deliver up to a maximum of 64Kbps per flow. Even though 128Kbps was requested, R4 responds with a successful reservation of 64Kbps.
From the packet capture, you can see that this is a ResvErr message. ResvErr messages are sent downstream as a response to Resv messages that may be incorrect/corrupt/incomprehensible or just unexpected. From the packet capture, you can see that this is a policy control failure. This occurs when the resource reservation request fails to meet the requested policy. This is due to the fact that R4 didn’t fulfil R1’s request as expected. You can also see a value of 3 in the error code. Based on these RSVP error codes provided by IANA, the value of 3 means “Generic Policy Rejection”, which simply means that the policy was not accepted, which is indeed what happened. ResvErr messages don’t necessarily mean that the operation failed, they can also be used for diagnostics or troubleshooting even if a reservation was successful, as is this case, albeit not as requested.
The exact same thing happens in your example. You see, if the request is not met, it doesn’t mean that the RSVP request fails, it just succeeds at a slower rate, and RESVErr messages are sent for informational and troubleshooting purposes only.
Typically, RSVP would be built into the applications running on the computer itself. Although RSVP is typically associated with the Transport Layer because it is used to reserve resources for end-to-end communication between hosts, it is often triggered and managed by application-layer processes (e.g., multimedia streaming, VoIP applications). So you wouldn’t actually have to configure anything yourself on the host, the application being served by RSVP would do that. But you would have to have a network that supports RSVP so that such applications can leverage it.
RSVP works differently than other QoS mechanisms such as Diffserv. Whether there is or there isn’t congestion it is irrelevant to RSVP. RSVP will reserve bandwidth and will keep that bandwidth open only for use by the RSVP flow that reserved it. Traffic that does not belong to an RSVP reserved flow will never use the reserved bandwidth even if it is available.
RSVP reserves network bandwidth. It doesn’t guarantee delay requirements directly but works with queuing mechanisms such as LLQ which RSVP supports. More info about this can be found at this Cisco documentation:
How does that work?