Frame-relay compression and fragmentation.

Link optimization on frame-relay.

Using frame-relay, bandwidth is especially a concern.

It is possible to optimize this bandwidth in several ways.

I will concentrate this post about compression and fragmentation.

First off, with compression on frame-relay there several methods of accomplishing this.

You can have payload compression, tcp compression and RTP compression. How they are each

configured depends on your interface.

I will show how all of these are configured using a mix of point-to-point and multipoint interfaces.

Fragmentation is fundamentally a method to “chop up” packets when they reach a certain size. This feature is

also configured differently depending on the interface type. Again, i will show this on both types of interfaces.

and R2:

And finally R3:

And lets verify reachability before we start messing about with things:

Great. Now we are ready to apply some things.

First of, lets add some compression to payload traffic on our p2p interface towards R2.

On the subinterface itself, you can simply specify directly that you want to enable compression.

Check out your options:

They each work differently and with varying results. I will leave it up to you to figure out more about the individual algorithms they use.

For now, lets use packet-by-packet compression which is more CPU intensive than the rest of them.

We are getting timeouts. Why?

Well, compression is a two way thing. It must be configured on each side of the PVC in order to maintain reachability.

Verify the compression by using:

So its sending compressed information to the other side, but getting nothing back.

Lets configure R2 to use compression as well.

Now, lets try a ping test from R1 again:

Looks great. Lets check out the compression statistics on both R1 and R2:

And R2:

We can actually see that the routers have not transmitted anything that is not being compressed.

Before we move on, lets verify R1s connectivity to R3 again, just to be sure:

Everything seems to be in working order.

Remember that R1s interface towards R3 is a multipoint subinterface and R3s interface towards R1 is the physical frame-relay interface.

Now if you just use the same command set as we did on the P2P interface, you will get the following error:

We need to apply this on our frame-relay map command in order for it to be working:

And on R3s s0/0 interface as well:

Lets verify with a ping from R1:

And show the compression:

Note that we dont see individual compression statistics for each dlci or subinterface.

Now lets change pace and look at some fragmentation. First off, i want to configure fragmentation on the link between

R1 and R2. Lets do it!

One very important thing to note, is the fact that fragmentation is part of the “traffic-shaping” command set.

We cannot do fragmentation without having frame-relay traffic-shaping enabled. This ofcourse has some consequences on our dlcis, but i will leave this unexplored in this post.

So, on R1, we need to create a map-class and apply this to our P2P interface.

Next, we need to apply this to our interface:

Lets verify without having traffic-shaping enabled:

And then lets enable traffic-shaping:

Now we can see that it has been enabled.

We are actually faced with a dilemma at the moment. Right now we have compression enabled on our interfaces which makes it very hard to test things out. Even if we did a ping with a size of 400 bytes, it would be compressed very heavily and thus not be fragmented. I have opted for disabling our compression to keep everything simple:

And R2:

Now remember that a ping command adds 2 bytes of “overhead”, so lets ping from R1 to R2 with a payload of 398 bytes, which will make the packet 400 bytes in total:

Nothing has been fragmented yet.

Lets say 400 instead of 398:

We can see that we are now fragmenting our packets, but since R2 is not doing the same, the ping fails.

Lets add the same on R2:

And verify:

Lets try out the ping from R1 again:

And lets verify from R2:

Awesome. Our fragmentation is now working as it should between R1 and R2.

This will have to do for the first segment of the post. Next time i will cover some of the RTP and TCP compression methods.

Take care!!