Block website with NBAR on Cisco Router

When you create access-lists or QoS (Quality of Service) policies you normally use layer 1,2,3 and 4 information to match on certain criteria. NBAR (Network Based Application Recognition) adds application layer intelligence to our Cisco IOS router which means we can match and filter based on certain applications.

Let’s say you want to block a certain website like Youtube.com. Normally you would lookup the IP addresses that youtube uses and block those using an access-list or perhaps police / shape them in your QoS policies. Using NBAR we can match on the website addresses instead of IP addresses. This makes life a lot easier. Let’s look at an example where we use NBAR to block a website (youtube for example):

R1(config)#class-map match-any BLOCKED
R1(config-cmap)#match protocol http host "*youtube.com*"
R1(config-cmap)#exit

First I will create a class-map called “BLOCKED” and I will use match protocol to use NBAR. As you can see I match on the hostname “youtube.com”. The * means “any character”. Effectively this will block all sub-domains of youtube.com, for example “subdomain.youtube.com” will also be blocked. Now we need to create a policy-map:

R1(config)#policy-map DROP 
R1(config-pmap)#class BLOCKED
R1(config-pmap-c)#drop
R1(config-pmap-c)#exit

The policy-map above matches our class-map BLOCKED and when this matches the traffic will be dropped. Last but not least we need to apply the policy-map to the interface:

R1(config)#interface fastEthernet 0/1  
R1(config-if)#service-policy output DROP

I will apply the policy-map to the interface that is connected to the Internet. Now whenever someone tries to reach youtube.com their traffic will be dropped. You can verify this on your router using the following command:

R1#show policy-map interface fastEthernet 0/1
 FastEthernet0/1 

  Service-policy output: DROP

    Class-map: BLOCKED (match-any)
      1 packets, 500 bytes
      5 minute offered rate 0 bps, drop rate 0 bps
      Match: protocol http host "*youtube.com*"
        1 packets, 500 bytes
        5 minute rate 0 bps
      drop

    Class-map: class-default (match-any)
      6101 packets, 340841 bytes
      5 minute offered rate 10000 bps, drop rate 0 bps
      Match: any 

Above you see that we have a match for our class-map BLOCKED. Apparently someone tried to reach youtube.com. The class-map class-default matches all other traffic and it is permitted.

In case you were wondering…you can only use NBAR to match HTTP traffic, not HTTPS. The reason for this is that NBAR matches on the HTTP “get” command which is encrypted if you use HTTPS. Take a look at the following wireshark capture for HTTP:

Above you see the HTTP GET request for youtube.com in plaintext. This is what NBAR looks at and matches on. Now let me show you the HTTPS capture:

Above you see a wireshark capture of HTTPS traffic between my computer and youtube.com. It’s impossible for NBAR to look into these SSL packets and see what website you are requesting. In this case your only option is to use a proxy server for HTTP server or block the IP addresses using an access-list.

hostname R1
!
ip cef
!
class-map match-any BLOCKED
 match protocol http host "*youtube.com*"
!
policy-map DROP
 class BLOCKED
  drop
!
interface FastEthernet0/1
 ip address 192.168.1.1 255.255.255.0
 service-policy output DROP
!
end

This is how you can block websites using your normal Cisco IOS router. If you have any questions just leave a comment!

RSVP DSBM (Designated Subnetwork Bandwidth Manager)

RSVP will work fine when you need to make a reservation on the link between two routers, but what if you have a shared segment? An example could be a couple of routers that is connected to the same half-duplex Ethernet network. These routers will share the bandwidth so when multiple routers make an RSVP reservation it’s possible that we oversubscribe.

The routers should know about all RSVP reservations that are made on this shared segment and that’s exactly why we have the DSBM (Designated Subnetwork Bandwidth Manager).

One of the routers on the shared segment will be elected as the DSBM and all other RSVP routers will proxy their RSVP PATH and RESV messages through the DSBM. This way we will have centralized admission control and we won’t risk oversubscribing the shared segment.

Besides being in charge of admission control, the DSBM can also distribute other information to RSVP routers, for example the amount of non-reservable traffic that is allowed in the shared segment or the average/peak rate and burst size for non-RSVP traffic.

The election to become the RSVP DSBM uses the following rules:

• The router with the highest priority becomes the DSBM.
• In case the priority is the same, the highest IP address is the tie-breaker.

Multiple DSBMs can be configured for a shared segment but DSBM is non-preemptive. This means that once the election is over, the router that was elected will stay as the DSBM even if you configure another router later with a higher priority.

Configuration-wise it’s easy to implement DSBM, let’s use the following topology to see how it works:

Just 3 routers connected to the same switch. First we will enable RSVP on all interfaces:

R1(config)#interface FastEthernet 0/0
R1(config-if)#ip rsvp bandwidth 

R2(config)#interface FastEthernet 0/0
R2(config-if)#ip rsvp bandwidth 

R3(config)#interface FastEthernet 0/0
R3(config-if)#ip rsvp bandwidth

Now we’ll configure R3 as the DSBM for this segment:

R3(config)#interface FastEthernet 0/0
R3(config-if)#ip rsvp dsbm candidate 

If you want, you can configure the DSBM to tell other RSVP routers to limit the reservations:

R3(config-if)#ip rsvp bandwidth 2048

I’ll set the maximum bandwidth to 2048 kbit. We can also set a number of parameters for non-RSVP traffic:

R3(config-if)#ip rsvp dsbm non-resv-send-limit ?
  burst     Maximum burst (Kbytes)
  max-unit  Maximum packet size (bytes)
  min-unit  Minimum policed unit (bytes)
  peak      Peak rate (Kbytes/sec)
  rate      Average rate (Kbytes/sec)

Let’s verify if R3 has won the election:

R1#show ip rsvp sbm detail 

Interface: FastEthernet0/0
Local Configuration             Current DSBM
  IP Address: 192.168.123.1       IP Address: 192.168.123.3
  DSBM candidate: no              I Am DSBM: no
  Priority: 64                    Priority: 64
  Non Resv Send Limit             Non Resv Send Limit
    Rate: unlimited                 Rate: 2147483 Kbytes/sec
    Burst: unlimited                Burst: 536870 Kbytes
    Peak: unlimited                 Peak: unlimited
    Min Unit: unlimited             Min Unit: unlimited
    Max Unit: unlimited             Max Unit: unlimited

R2#show ip rsvp sbm detail 

Interface: FastEthernet0/0
Local Configuration             Current DSBM
  IP Address: 192.168.123.2       IP Address: 192.168.123.3
  DSBM candidate: no              I Am DSBM: no
  Priority: 64                    Priority: 64
  Non Resv Send Limit             Non Resv Send Limit
    Rate: unlimited                 Rate: 2147483 Kbytes/sec
    Burst: unlimited                Burst: 536870 Kbytes
    Peak: unlimited                 Peak: unlimited
    Min Unit: unlimited             Min Unit: unlimited
    Max Unit: unlimited             Max Unit: unlimited

R3#show ip rsvp sbm detail 

Interface: FastEthernet0/0
Local Configuration             Current DSBM
  IP Address: 192.168.123.3       IP Address: 192.168.123.3
  DSBM candidate: yes             I Am DSBM: yes
  Priority: 64                    Priority: 64
  Non Resv Send Limit             Non Resv Send Limit
    Rate: unlimited                 Rate: 2147483 Kbytes/sec
    Burst: unlimited                Burst: 536870 Kbytes
    Peak: unlimited                 Peak: unlimited
    Min Unit: unlimited             Min Unit: unlimited
    Max Unit: unlimited             Max Unit: unlimited

With R3 as the DSBM it will be in the middle of all RSVP messages. We can test this by configuring a reservation between R1 and R2:

R1(config)#ip rsvp sender-host 192.168.123.2 192.168.123.1 tcp 23 0 128 64

R2(config)#reservation-host 192.168.123.2 192.168.123.1 tcp 23 0 ff rate 128 64

When we check R3 you can see that it knows about the reservation that we just configured:

R3#show ip rsvp installed 
RSVP: FastEthernet0/0
BPS    To              From            Protoc DPort  Sport  
128K   192.168.123.2   192.168.123.1   TCP    23     0 

That’s all I wanted to share about DSBM for now.

hostname R1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.123.1 255.255.255.0
 ip rsvp bandwidth
!
ip rsvp sender-host 192.168.123.2 192.168.123.1 TCP 23 0 128 64
!
end

hostname R2
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.123.2 255.255.255.0
 ip rsvp bandwidth
!
reservation-host 192.168.123.2 192.168.123.1 tcp 23 0 ff rate 128 64
!
end

hostname R3
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.123.3 255.255.255.0
 ip rsvp bandwidth 2048
 ip rsvp dsbm candidate
!

end

If you have any questions feel free to ask!

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.

PPP Multilink Link Fragmentation and Interleaving

PPP Multilink lets us bundle multiple physical interfaces into a single logical interface. We can use this to load balance on layer 2 instead of layer 3. Take a look at the following picture so I can give you an example:

Above we have two routers connected to each other with two serial links. If we want to use load balancing we could do this on layer 3, just configure a subnet on each serial link and activate both links in a routing protocol like EIGRP or OSPF.

When we use PPP multilink we can bundle the two serial links into one logical layer 3 interface and we’ll do load balancing on layer 2. PPP multilink will break the outgoing packets into smaller pieces, puts a sequence number on them and sends them out the serial interfaces. Another feature of PPP multilink is fragmentation. This could be useful when you are sending VoIP between the two routers.

Most voice codecs require a maximum delay of 10 ms between the different VoIP packets. Let’s say the serial link offers 128 Kbit of bandwidth…how long would it take to send a voice packet that is about 60 bytes?

60 bytes * 8 = 480 bits / 128.000 = 0.00375.

So it takes roughly 3.7 ms to send the voice packet which is far below the required 10 ms. We can run into issues however when we also send data packets over this link. Let’s say we have a 1500 bytes data packet that we want to send over this link:

1500 bytes * 8 = 12.000 / 128.000 = 0.093.

So it will take about 93 ms to send this packet over this 128 Kbit link. Imagine we are sending this data packet and a voice packet arrives at the router, it will have to wait for at least 93 ms before the data packet is out of the way…exceeding our 10 ms maximum delay.

Multilink PPP offers a solution by fragmenting the data packets and interleaving the voice packets between the data fragments. This way a large data packet will not delay a voice packet for too long.

Anyway now you have an idea what multilink PPP is about, let me show you how to configure it. I will use the following topology:

I am using two routers with only a single serial link between them. Even though it’s called multilink PPP you can still configure it on only one link. This is how we configure it:

R1(config)#interface virtual-template 1
R1(config-if)#bandwidth 128
R1(config-if)#ip address 192.168.12.1 255.255.255.0     
R1(config-if)#fair-queue 
R1(config-if)#ppp multilink fragment delay 10
R1(config-if)#ppp multilink interleave

R2(config)#interface virtual-template 1
R2(config-if)#bandwidth 128
R2(config-if)#ip address 192.168.12.2 255.255.255.0     
R2(config-if)#fair-queue 
R2(config-if)#ppp multilink fragment delay 10
R2(config-if)#ppp multilink interleave

We will use a virtual-template to configure the IP addresses and to configure PPP multilink. The ppp multilink fragment delay commands lets us configure the maximum delay. In my example I’ve set it to 10 ms. Don’t forget to use ppp multilink interleave or interleaving won’t work. I’m using WFQ to prioritize voice traffic before data traffic using the fair-queue command. Interleaving will occur between WFQ and the FIFO queue and has 2 queues, a normal and priority queue. non-fragmented traffic goes to the priority queue and fragmented traffic will use the normal queue. Now let’s link the virtual template to PPP multilink:

R1(config)#multilink virtual-template 1

R2(config)#multilink virtual-template 1

And last but not least, configure the interfaces to use PPP multilink:

R1(config)#interface serial 0/0
R1(config-if)#bandwidth 128
R1(config-if)#encapsulation ppp
R1(config-if)#ppp multilink 

R2(config)#interface serial 0/0
R2(config-if)#bandwidth 128
R2(config-if)#encapsulation ppp
R2(config-if)#ppp multilink 

Just make sure you enable PPP encapsulation and PPP multilink on the interfaces and you are done. Now let’s see if it’s working or not:

R1#show ppp multilink 

Virtual-Access2
  Bundle name: R2
  Remote Endpoint Discriminator: [1] R2
  Local Endpoint Discriminator: [1] R1
  Bundle up for 00:00:25, total bandwidth 128, load 1/255
  Receive buffer limit 12192 bytes, frag timeout 1000 ms
  Interleaving enabled
    0/0 fragments/bytes in reassembly list
    0 lost fragments, 0 reordered
    0/0 discarded fragments/bytes, 0 lost received
    0x2 received sequence, 0x2 sent sequence
  Member links: 1 (max not set, min not set)
    Se0/0, since 00:00:25, 160 weight, 152 frag size
No inactive multilink interfaces

R1#show interfaces virtual-access 2
Virtual-Access2 is up, line protocol is up 
  Hardware is Virtual Access interface
  Internet address is 192.168.12.1/24
  MTU 1500 bytes, BW 128 Kbit/sec, DLY 100000 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation PPP, LCP Open, multilink Open
  Open: IPCP
  MLP Bundle vaccess, cloned from Virtual-Template1
  Vaccess status 0x40, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 5 seconds on reset
  Last input 00:01:05, output never, output hang never
  Last clearing of "show interface" counters 00:01:05
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops) 
     Conversations  0/1/32 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 96 kilobits/sec
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2 packets input, 28 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     2 packets output, 40 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

Above you can see that PPP multilink is enabled and that we are using interleaving.

hostname R1
!
ip cef
!
multilink virtual-template 1
!
interface Serial0/0
 bandwidth 128
 ip address 192.168.12.1 255.255.255.0
 encapsulation ppp
 no fair-queue
 ppp multilink
!
interface Virtual-Template1
 bandwidth 128
 ip address 192.168.12.1 255.255.255.0
 fair-queue
 ppp multilink interleave
 ppp multilink fragment delay 10
!
end

hostname R2
!
ip cef
!
multilink virtual-template 1
!
interface Serial0/0
 bandwidth 128
 ip address 192.168.12.2 255.255.255.0
 encapsulation ppp
 no fair-queue
 ppp multilink
!
interface Virtual-Template1
 bandwidth 128
 ip address 192.168.12.2 255.255.255.0
 fair-queue
 ppp multilink interleave
 ppp multilink fragment delay 10
!
end

If you have any questions or comments let me know!