Compression and LMI Type

Answered Question
Apr 7th, 2009

I was asked to test turning on compression on our Wide Area Frame Relay network. I am aware of the different types of compression and the behavoir of Frame Relay. My problem is I wanted to test Payload Compression. I picked one of my 23 sites and used the following commands at the hub and at the spoke.

frame-relay interface-dlci 208 CISCO

frame-relay payload-compression packet-by-packet

This worked GREAT, I am seeing 1.9 compression rates and there were no problems.

Since then I have tried to do the same commands at a number of my other sites and it causes traffic to hang every time.

While I was investigating I saw the on the one site where this worked the following.....

LMI DLCI 0 LMI type is CCITT frame relay DTE

when I do a "sho int" command.

all of my other sites sho

LMI DLCI 1023 LMI type is CISCO frame relay DTE

My question is .....

Isn't this a function of my provider? I am using Verizon's FR network and they set or specify the LMI type right? I don't see in the router where I specify it. I know you can but I just took the defaults. Also should this make a difference? Souldn't I be able to do payload compression regardless of what the LMI type is?

Thanks in advance for any help.

I have this problem too.
0 votes
Correct Answer by lamav about 7 years 8 months ago

The LMI type on your router must match the LMI type being used by the provider.

If you dont know the LMI type, you can use LMI Autosense.

If you do know the type, you can configure it.

View this link:

http://www.cisco.com/en/US/docs/ios/12_1/wan/configuration/guide/wcdfrely.html#wp1001081

I have never read any literature that presents a relationship between configured LMI and Frame Relay compression.

I do see that you are using Cisco proprietary compression instead of the universal FRF.9 extension to FRF.8.

You may have a compatability issue with non-Cisco routers in the service provider's cloud.

Have you tried using the FRF.9 open standard?

HTH

Victor

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
lamav Tue, 04/07/2009 - 08:22

The LMI type on your router must match the LMI type being used by the provider.

If you dont know the LMI type, you can use LMI Autosense.

If you do know the type, you can configure it.

View this link:

http://www.cisco.com/en/US/docs/ios/12_1/wan/configuration/guide/wcdfrely.html#wp1001081

I have never read any literature that presents a relationship between configured LMI and Frame Relay compression.

I do see that you are using Cisco proprietary compression instead of the universal FRF.9 extension to FRF.8.

You may have a compatability issue with non-Cisco routers in the service provider's cloud.

Have you tried using the FRF.9 open standard?

HTH

Victor

srroeder Tue, 04/07/2009 - 08:43

Thanks for the reply,

Yes I realize they have to match but I wanted assurance that this was something coming from Verizon and not something I had set. I assume it is since all 27 of my routers are configured the same and this is the only one that has defaulted to CCITT.

I am going to try the frame-relay payload-compression frf9 stac command tonight on one of my other sites and see if it works.

Thanks again

Giuseppe Larosa Tue, 04/07/2009 - 11:42

Hello Steve,

LMI autosense is enabled by default in modern IOS images.

It works by initially sending an LMI frame for each type and adapting to the FR switch answer.

So yes it is the service provider switch that uses CCITT LMI on this site.

However, LMI type can be different at the two ends of an PVC.

What needs to be the same is the FR encapsulation.

In any case FR compression is a form of payload compression a regular FR header is needed to allow the compressed frame to be correctly switched on the service provider FR network.

As Victor correctly suggests it is better to try to use standards based FRF.9 but I'm not sure it is enough.

Hope to help

Giuseppe

lamav Tue, 04/07/2009 - 12:48

Giuseppe:

"As Victor correctly suggests it is better to try to use standards based FRF.9 but I'm not sure it is enough."

I agree, it may not be enough because the service provider may have to do some engineering on their end.

If the OP is using FRF.8 (ATM-to-Frame Relay), then he may encounter an issue at the provider edge because Cisco ATM does not support Annex B of FRF.8, which is the extension dealing with compressed data. The SP in that case would have to tunnel Frame Relay through the ATM cloud.

But, its worth a shot to try. He certainly has nothing to lose.

"However, LMI type can be different at the two ends of an PVC."

I'm not sure exactly what you mean by that, but the LMI does have to match between the router's interface and the service provider's frame relay switch interface. That's how I interpreted the OP's concern.

If you mean that each router -- hub and spoke -- can use different LMI types between themselves and their local frame relay switch, then, yes, of course, I agree.

HTH

Victor

srroeder Wed, 04/08/2009 - 07:35

Thanks for all your help, I turned on FRF9 last night and it is working.

lamav Wed, 04/08/2009 - 07:49

Awesome!! Glad to hear it.

Please rate all posts that have helped you.

Thanks

Victor

Giuseppe Larosa Wed, 04/08/2009 - 08:53

Hello Victor,

>> If you mean that each router -- hub and spoke -- can use different LMI types between themselves and their local frame relay switch, then, yes, of course, I agree.

I was meaning this, I hadn't thought at possible implications of FR-ATM interworking and compression that you have explained.

This makes sense and explain the issue of the OP.

Thanks

Best Regards

Giuseppe

lamav Wed, 04/08/2009 - 09:00

Hi, Giuseppe:

Thanks for the feedback and the rating. Im assuming it was you who rated me....:-)

Victor

Actions

This Discussion