暗夜星空: Introduction to RSVP

IntServ and RSVP

When it comes to QoS we have three models that we can use:

Best Effort (don’t use QoS for traffic that doesn’t need any special treatment.)
DiffServ (Differentiated Services)
IntServ (Integrated Services)

In short, when using DiffServ we implement QoS on a “hop by hop” basis where we use the ToS byte of IP packets for classification. IntServ is completely different, it’s a signaling process where network flows can request a certain bandwidth and delay that is required for the flow. IntServ is described in RFC 1633 and there are two components:

Resource reservation
Admission control

Resource reservation signals the network and requests a certain bandwidth and delay that is required for a flow. When the reservation is successful each network component (mostly routers) will reserve the bandwidth and delay that is required. Admission control is used to permit or deny a certain reservation. If we would allow all flows to make a reservation, we can’t guarantee any service anymore…

When a host wants to make a reservation it will send a RSVP reservation request using a RSVP path message. This message is passed along the route towards the destination. When a router can guarantee the required bandwidth/delay it will forward the message. Once it reaches the destination it will reply with a RSVP resv message. The same process will occur for the opposite direction. Each router will check if they have enough bandwidth/delay for the flow and if so, they will forward the message towards the source of the reservation. Once the host receives the reservation message we are done.

Now this might sound nice but the problem with IntServ is that it’s difficult to scale…each router has to keep track of each reservation for each flow. What if a certain router doesn’t support Intserv or loses it’s reservation information? Currently RSVP is mostly used for MPLS traffic engineering, we use DiffServ for QoS implementations.

RSVP Configuration Example

Anyway let’s take a look at the configuration of RSVP, I will be using the following topology:

Configurations
R1
R2
R3
R4

Want to take a look for yourself? Here you will find the startup configuration of each device.

First we need to enable RSVP on all interfaces:

R1(config)#interface fa0/0
R1(config-if)#ip rsvp bandwidth 128 64

R2(config)#interface fa0/0
R2(config-if)#ip rsvp bandwidth 128 64

R2(config)#interface fa0/1
R2(config-if)#ip rsvp bandwidth 128 64

R3(config)#interface fa0/0
R3(config-if)#ip rsvp bandwidth 128 64

R3(config)#interface fa0/1
R3(config-if)#ip rsvp bandwidth 128 64

R4(config)#interface fa0/0
R4(config-if)#ip rsvp bandwidth 128 64

If you don’t specify the bandwidth then by default RSVP will use up to 75% of the interface bandwidth for reservations. I’m telling RSVP that it can only use up to 128 kbps for reservations and that the largest reservable flow can be 64 kbps.

Now we’ll configure R1 to act like a RSVP host so it will send a RSVP send path message:

R1(config)#ip rsvp sender-host 192.168.34.4 192.168.12.1 tcp 23 0 64 32

I will make a reservation between destination 192.168.34.4 and source 192.168.12.1 using TCP destination port 23 (telnet). The source port is 0 which means it can be anything. The average bitrate is 64 kbps with a maximum burst of 32 kbps.


R1#show ip rsvp sender 
To              From            Pro DPort Sport Prev Hop        I/F    BPS
192.168.34.4  192.168.12.1   TCP 23    0     192.168.12.1          64K

Above you see the reservation that we configured on R1. Now let’s configure R4 to respond to this reservation:

R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 23 0 ff ?
  load  Controlled Load Service
  rate  Guaranteed Bit Rate Service

I can choose between controlled load or guaranteed bit rate. Guaranteed means the flow will have a bandwidth and delay guarantee. Controlled load will guarantee the bandwidth but not the delay.

R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 23 0 ff rate 64 32

Let’s verify our configuration on R4:

R4#show ip rsvp reservation 
To               From          Pro DPort Sport Next Hop      I/F Fi Serv BPS
192.168.34.4   192.168.12.1  TCP 23    0   192.168.34.4      FF RATE 64K

You can see that it has received the reservation from R1. What about R2 and R3?

R2#show ip rsvp reservation 
To            From          Pro DPort Sport Next Hop      I/F    Fi Serv BPS
192.168.34.4  192.168.12.1  TCP 23    0     192.168.23.3  Fa0/1  FF RATE 64K

R3#show ip rsvp reservation 
To            From          Pro DPort Sport Next Hop      I/F    Fi Serv BPS
192.168.34.4  192.168.12.1  TCP 23    0     192.168.34.4  Fa0/1  FF RATE 64K

Above you can see that R2 and R3 also made the reservation. We can also check RSVP information on the interface level:

R2#show ip rsvp interface detail | begin Fa0/1
 Fa0/1:
   Interface State: Up
   Bandwidth:
     Curr allocated: 64K bits/sec
     Max. allowed (total): 128K bits/sec
     Max. allowed (per flow): 64K bits/sec
     Max. allowed for LSP tunnels using sub-pools: 0 bits/sec
     Set aside by policy (total): 0 bits/sec
   Admission Control:
     Header Compression methods supported:
       rtp (36 bytes-saved), udp (20 bytes-saved)
   Traffic Control:
     RSVP Data Packet Classification is ON via CEF callbacks
   Signalling:
     DSCP value used in RSVP msgs: 0x3F
     Number of refresh intervals to enforce blockade state: 4
     Number of missed refresh messages: 4
     Refresh interval: 30
   Authentication: disabled

Above you can see how R2 reserved 64 kbps on its FastEthernet0/1 interface.

Debugging RSVP

If you really want to see what is going on you should enable a debug, let’s do so on all routers:

R1,R2,R3,R4#debug ip rsvp
RSVP signalling debugging is on

Now let’s create a new conversation on R1:

R1(config)#ip rsvp sender-host 192.168.34.4 192.168.12.1 tcp 80 0 32 16

This is what you will see:

R1#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.12.1 (on sender host)
RSVP: new path message passed parsing, continue...
RSVP: Triggering outgoing Path refresh
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 66C8D7CC refresh interval = 0mSec
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.12.2

You can see that R1 has received a path message from itself and that it forwards it towards 192.168.12.2.

R2#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.12.1 (on FastEthernet0/0)
RSVP: new path message passed parsing, continue...
RSVP: Triggering outgoing Path refresh
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 650988D4 refresh interval = 0mSec
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.23.3

R3#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.23.2 (on FastEthernet0/0)
RSVP: new path message passed parsing, continue...
RSVP: Triggering outgoing Path refresh
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 6508EB64 refresh interval = 0mSec
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending Path message to 192.168.34.4

R4#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Received Path message from 192.168.34.3 (on FastEthernet0/0)
R4#
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh Path psb = 6618082C refresh interval = 30000mSec
RSVP: can't forward Path out received interface

R2 receives the path message from R1 and forwards it towards R3 who will forward it to R4. Now let’s configure R4 to respond:

R4(config)#ip rsvp reservation-host 192.168.34.4 192.168.12.1 tcp 80 0 ff rate 64 32

This is what you will see:

R4#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (receiver host) from 192.168.34.4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 674BE740
RSVP-RESV: Locally created reservation. No admission/traffic control needed
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.34.3
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=674C39E8, 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.34.3
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.34.3

R3#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/1) from 192.168.34.4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 66171920
RSVP-RESV: reservation was installed: 66171920
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: start requesting 64 kbps FF reservation for 192.168.12.1(0) TCP-> 192.168.34.4(80) on FastEthernet0/0 neighbor 192.168.23.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Refresh RESV, req=661769B4, 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.23.2
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.23.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.34.4

R2#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/1) from 192.168.23.3
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 674B8E00
RSVP-RESV: reservation was installed: 674B8E00
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: 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

R1#
RSVP session 192.168.34.4_80[0.0.0.0]: Received RESV for 192.168.34.4 (FastEthernet0/0) from 192.168.12.2
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: this RESV has a confirm object
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: reservation not found--new one
RSVP-RESV: Admitting new reservation: 66C95AF4
RSVP-RESV: reservation was installed: 66C95AF4
RSVP 192.168.12.1_0->192.168.34.4_80[0.0.0.0]: Sending RESV CONFIRM message to 192.168.12.2

Above you can see that each router forwards the RESV message and makes the reservation for this particular flow. That’s all I wanted to show you for now, I hope this helps you to understand RSVP.

hostname R1
!
interface GigabitEthernet0/1
 ip address 192.168.12.1 255.255.255.0
 ip rsvp bandwidth 128 64
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
!
ip rsvp sender-host 192.168.34.4 192.168.12.1 TCP 23 0 64 32
ip rsvp sender-host 192.168.34.4 192.168.12.1 TCP 80 0 32 16
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
!
end

hostname R2
!
interface GigabitEthernet0/1
 ip address 192.168.12.2 255.255.255.0
 ip rsvp bandwidth 128 64
!
interface GigabitEthernet0/2
 ip address 192.168.23.2 255.255.255.0
 ip rsvp bandwidth 128 64
!
router ospf 1
 network 192.168.12.0 0.0.0.255 area 0
 network 192.168.23.0 0.0.0.255 area 0
!
end

hostname R3
!
interface GigabitEthernet0/1
 ip address 192.168.34.3 255.255.255.0
 ip rsvp bandwidth 128 64
!
interface GigabitEthernet0/2
 ip address 192.168.23.3 255.255.255.0
 ip rsvp bandwidth 128 64
!
router ospf 1
 network 192.168.23.0 0.0.0.255 area 0
 network 192.168.34.0 0.0.0.255 area 0
!
end

hostname R4
!
interface GigabitEthernet0/1
 ip address 192.168.34.4 255.255.255.0
 ip rsvp bandwidth 128 64
!
router ospf 1
 network 192.168.34.0 0.0.0.255 area 0
!
ip rsvp reservation-host 192.168.34.4 192.168.12.1 TCP 23 0 FF RATE 64 32
ip rsvp reservation-host 192.168.34.4 192.168.12.1 TCP 80 0 FF RATE 64 32
ip ssh server algorithm encryption aes128-ctr aes192-ctr aes256-ctr
ip ssh client algorithm encryption aes128-ctr aes192-ctr aes256-ctr
!
end

If you have any questions feel free to ask.

暗夜星空

Saturday, February 22, 2020

Introduction to RSVP

IntServ and RSVP

RSVP Configuration Example

Debugging RSVP

No comments:

Post a Comment