You want to configure RSVP on your network.
Basic RSVP configuration is relatively simple. All you need to do is define how much bandwidth can be reserved on the interface:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#interface FastEthernet0/0 Router(config-if)#ip rsvp bandwidth 128 56 Router(config-if)#exit Router(config)#end Router#
Some network administrators have to worry about unauthorized use of bandwidth reservation. You can control this by specifying an access-list of allowed neighbor devices:
Router#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router(config)#access-list 15 permit ip 192.168.1.0 0.0.0.255 Router(config)#interface FastEthernet0/0 Router(config-if)#ip rsvp bandwidth 128 56 Router(config-if)#ip rsvp neighbor 15 Router(config-if)#exit Router(config)#end Router#
Note that before you can configure RSVP on an interface, you must first configure the interface for WFQ, CBWFQ, or WRED. This step is not included in this example, to make it easier to focus on the RSVP configuration. For examples of WFQ, CBWFQ, and WRED, please refer to Recipes 11.6, 11.7, and 11.9, respectively.
The first example tells the router to pay attention to RSVP signaling, and defines how much bandwidth can be reserved in the following command:
Router(config-if)#ip rsvp bandwidth 128 56
The first numerical argument, 128, specifies that applications can reserve a maximum aggregate bandwidth of 128 Kbps. The last argument, 56, means that the largest amount that a single application can request is 56 Kbps.
When you use the ip rsvp neighbor command, as in the second example, it is important to remember that this router receives RSVP reservation requests from neighboring devices. If this is an access router, then the neighboring device on the local LAN port could be an end device. But for other routers and other interfaces, it is likely that the RSVP request will come from another router, not from the end device making the initial request. So, for router-to-router connections, it may not be useful to specify an access list because all RSVP requests, legitimate or not, will come from a neighboring router. The best place to control which devices are allowed to reserve bandwidth is on the access router.
There are several useful show commands to look at the RSVP configuration of your router, as well as the dynamic reservation requests. The first of these is the show ip rsvp interface command, which shows information on the reservations that have been made by interface:
Router#show ip rsvp interface interfac allocate i/f max flow max per/255 UDP IP UDP_IP UDP M/C Et0 0M 1M 100K 0 /255 0 2 0 0 To0 50K 1M 100K 12 /255 0 1 0 0
This command shows that there are two interfaces that are currently supporting RSVP reservations, Ethernet0 and TokenRing0. The allocate column shows the amount of bandwidth that has been allocated to active RSVP requests on each interface. In all of these fields, the letter K stands for Kbps and M stands for Mbps. The i/f max column shows the total amount that can be allocated on each of these interfaces, while the flow max shows the maximum that can be requested by any one flow. These are the parameters from the ip rsvp bandwidth interface configuration command.
The remaining columns show information about the actual allocated streams. The per/255 column shows the fraction of the total interface bandwidth that is used by each of these allocations. This is measured as a fraction of 255, as is common for expressing loads on Cisco interfaces. The UDP column shows the number of UDP-encapsulated sessions, IP counts the TCP-encapsulated sessions, and UDP_IP shows the sessions that use both UDP and TCP. The UDP M/C column shows whether the interface is configured to allow UDP reservations.
You can look at individual reservations in detail with the following command:
Router#show ip rsvp installed RSVP: Ethernet0 has no installed reservations RSVP: TokenRing0 BPS To From Protoc DPort Sport Weight Conversation 50K 192.168.5.5 192.168.1.10 TCP 888 999 4 520 Router#
This shows that the router is currently supporting a 50Kbps TCP session between the two IP addresses that are shown, with the source and destination port numbers, 999 and 888 respectively. The Weight column shows the weighting factor, and Conversation shows the conversation (or flow) number used by WFQ for this queue. If you don't run WFQ on this interface, then both of these values appear as 0.
There is considerable overlap between the information shown in the show ip rsvp installed command and the output with the reservation and sender keywords. However, there are some important additional pieces of information here:
Router#show ip rsvp reservation To From Pro DPort Sport Next Hop I/F Fi Serv BPS Bytes 192.168.5.5 192.168.1.10 TCP 888 999 192.168.3.2 To0 FF LOAD 50K 50K Router#show ip rsvp sender To From Pro DPort Sport Prev Hop I/F BPS Bytes 192.168.5.5 192.168.1.10 TCP 888 999 192.168.1.201 Et0 50K 50K Router#
With the reservation keyword, you see details about what type of reservation has been made. In this case, FF indicates that this is a Fixed Filter reservation, which means that it contains a single conversation between two end devices. However, RSVP also allows aggregation of flows. If this column says SE, which stands for Shared Explicit Filter, then it represents a shared reservation of unlimited scope. The other option is WF, which stands for Wildcard Filter, and indicates a shared reservation that can only include certain end devices or applications.
With the sender flag, you see the actual path information for the reservation. The Prev Hop and I/F columns here show the address and interface of the previous hop router. The BPS column shows the reserved bandwidth for this session in Kbps, and the Bytes column shows the maximum burst size in Kilobytes.
The show ip rsvp neighbor command simply lists all of the IP addresses of active RSVP neighbors on all interfaces. This command is useful if you want to figure out what devices are making RSVP requests. As we mentioned earlier, since all RSVP requests are made hop-to-hop, it is quite likely that you will see a lot of routers in this list. However, on access routers, this command will help you to see whether the right end devices are making RSVP requests. If there are unauthorized devices in the list, you may want to consider using the ip rsvp neighbor interface configuration command to restrict which devices are allowed to make requests:
Router#show ip rsvp neighbor Interfac Neighbor Encapsulation Et0 192.168.1.10 RSVP Et0 192.168.1.201 RSVP To0 192.168.3.2 RSVP
Recipe 11.6; Recipe 11.7; Recipe 11.9