After working around with many interesting fragmentation part in Cisco IOS, i assumed to have a lab on the Multilink PPP scenario where your Edge router have multiple connection to the ISP Edge router and you would like to Fragment the Data, first let’s look what the fragmentation is and how it works:

Link Fragmentation and Interleaving:

LFI is a QoS tool that address bandwidth constraints to some degree, which directly lower delay by defeating a side effect of a small transmit clock speed, namely Serialization Delay ( already discussed in previous post ).

When a router starts to send a frame out of an interface, it sends the complete frame, if a small, delay-sensitive frame needs to exit an interface, and the router has just begun to send a large frame, the small frame must wait until the whole large frame has been sent before the router will send the small, delay-sensitive frame.

LFI tools attack the serialization delay problem by ensuring that large packets do not delay smaller packets, it accomplishes this by dividing larger packets (fragmentation) and interleaving later arriving smaller packets in between the fragments from the larger packet, typically VoIP Packets.

Lab:

If you have point-to-point link, and need to perform LFI, you must migrate from your current layer 2 protocol to MLP, to use MLP LFI. Multi Link enable you to have multiple parallel point-to-point links between a pair of devices, such as a router. The main motivation of MLP was to allow dial applications to continue adding additional switched WAN connections between the endpoints when more bandwidth was needed.

Let’s take following scenario throughout the lab:

In the above scenario, R1 will fragment the data received from Site-A toward R2 ( Site-B ), Router 1 and Router 2 are connected via Serial Interfaces and we will bundle both serials into a single multilink.

Configuration on R2 is nothing then only a interface ip addresses and routing protocol let’s assume RIP in our case:

Above configuration in R2 is very straight forward, you see that the links are configured for multilink Bundle and also the multilink configuration, now let’s start the fragmentation and interleaving under the both routers in 5 steps:

Step 1:

In the example, multilink group 1 defines the interesting parameters in this example. Under the interface multilink 1 command, the IP address configuration (192.168.12.0/32), along with the bandwidth command, is listed. The multilink ppp command implies that this multilink group indeed uses multilink PPP. The multilink group 1 command tells IOS that this interface (multilink 1) is part of multilink group 1; this same command links each physical interface to the multilink group configuration. Now the interface configuration details that will be shared by all links in the same MLP bundle have been configured.

To add R1’s serial 0/1 and serial 0/0 interface to the MLP bundle, the multilink group 1interface subcommand is added under serial 0/1 and serial 0/0, After the equivalent configuration has been added to R2, a single leased point-to-point serial link was up between R1 and R2, and each router was able to ping the other across the link.

Step 2:

The following command next shows the addition of the ppp multilink fragment-delay 10 command. Interestingly, this command does not enable fragmentation, but rather defines the maximum fragment size. Because the bandwidth was already set to 128, IOS calculates the fragment size as bandwidth * max-delay (in seconds), or 128,000 * .01, which results in a 1280 bit (160 byte)fragment size.

Before the ppp multilink fragment-delay 10 command was added, in this example, MLP did not fragment. If the ppp multilink fragment-delay command had not been added, and four links were active in the MLP bundle, MLP would fragment frames into four equal-sized fragments. If three links were active, each frame would be fragmented into three equal-sized fragments, and so on. With one active link, MLP does not actually fragment the frames until the ppp multilink fragment-delay command is added. After adding the ppp multilink fragment-delay 10 command in the example, the voice-call quality did not improve.

So far, the configuration asked for fragmentation, but not for interleaving. Without interleaving, the unfragmented packets still must wait on all the fragments of larger packets to be serialized. In the context of QoS, it seems rather silly not to automatically interleave the shorter, unfragmented frames. Remember, however, that MLP fragments frames to load balance across multiple links without running into the problems relating to out-of-order packets. Adding fragmentation for 10ms fragments, the same command has to be entered into R2:

ppp multink fragment delay 10

The above command has to be under Interface multlink 1 on both R1 and R2 and after the above command you can verify this by (show interface multilink 1), the output will be something like below:

R1# show interface multilink 1

MANY LINES OMITTED FOR BRAVITY:

Queueing strategy: weighted fair
Output queue: 64/1000/64/1055 (size/max total/threshold/drops)

MANY LINES OMITTED FOR BRAVITY:

Step 3:

To gain the QoS advantage of reducing serialization delay by interleaving packets, the ppp multilink interleave command is added to the configuration next. The show interfaces command that follows lists a line that now shows a counter for interleaved packets, with the counter indeed showing that some packets have been interleaved. Now the example has added all the requirements for MLP LFI, and all seems well — but it is not! The voice quality is still barely tolerable, with long delay and many breaks in the speech.

The voice quality still suffers because of the queuing tool, WFQ. Notice that the next command in the example, show queue multilink 1, lists a voice flow with some statistics highlighted for the voice flow. The command lists drops for the highlighted voice flow, which is making a large impact of voice quality. Although the voice packets that get serviced do get interleaved, causing the interleave counter in the show interfaces command to increment, the quality still suffers because of the queuing delay and drops.

This step is adding the interleaving feature on the both Routers ( router 1 and router 2 ), the command is:

ppp multilink interleave

The above command has to be under Interface multlink 1 on both R1 and R2 and after the above command you can verify this by (show interface multilink 1), the output will be something like below:

R1# show interface multilink 1

MANY LINES OMITTED FOR BRAVITY:

Output queue: 27/1000/64/1405/164 (size/max total/threshold/drops/interleaves)

MANY LINES OMITTED FOR BRAVITY:

R1# show queue multilink 1

MANY LINES OMITTED FOR BRAVITY:

(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/4/0/982
Conversation 4, linktype: ip, length: 74
TOS: 0 prot: 6, source port 80, destination port 1517

(depth/weight/total drops/no-buffer drops/interleaves) 52/32384/1700/0/0

TOS: 0 prot: 17, source port 18490, destination port 17228

MANY LINES OMITTED FOR BRAVITY:

Step 4:

The best ways to prevent the drops is to enable Low Latency Queuing (LLQ) for the voice traffic. In this case, the configuration shows an older Queuing tool, IP RTP priority, which is enabled with the ip rtp priority 65 command. (However, LLQ is still recommended today for voice traffic.) After adding
the ip rtp priority command, the show interfaces command still shows interleaves, which is good, but the show queue command does not show any drops for the voice flow. In fact, the voice-call quality improved significantly.

This step is adding the RTP Priority Queuing Configuration, the same has been configured under R2:

ip rtp priority 16384 16383 65

You can add the above command under the R1 and R2 interface multilink, and you can verify the same with the below command:

R1# show interface multilink 1

MANY LINES OMITTED FOR BRAVITY:

Output queue: 17/1000/64/1783/4441 (size/max total/threshold/drops/interleaves)

MANY LINES OMITTED FOR BRAVITY:

R1# show queue multilink 1

MANY LINES OMITTED FOR BRAVITY:

(depth/weight/total drops/no-buffer drops/interleaves) 1/0/0/0/0

TOS: 0 prot: 17, source port 18490, destination port 17228

(depth/weight/total drops/no-buffer drops/interleaves) 1/32384/11/0/1282

TOS: 0 prot: 6, source port 80, destination port 1513

MANY LINES OMITTED FOR BRAVITY:

Step 5:

The final step is the verification on R1 and R2 that both has been configured for LFI on the MLP, however Cisco IOS software enables to use a couple of styles of configuration to configure MLS, this example/lab above shows the use of Virtual interface called a Multilink Interface.

Cheers,