04-07-2009 07:39 AM - edited 03-04-2019 04:16 AM
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.
Solved! Go to Solution.
04-07-2009 08:22 AM
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
04-07-2009 08:22 AM
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
04-07-2009 08:43 AM
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
04-07-2009 11:42 AM
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
04-07-2009 12:48 PM
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
04-08-2009 07:35 AM
Thanks for all your help, I turned on FRF9 last night and it is working.
04-08-2009 07:49 AM
Awesome!! Glad to hear it.
Please rate all posts that have helped you.
Thanks
Victor
04-08-2009 08:53 AM
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
04-08-2009 09:00 AM
Hi, Giuseppe:
Thanks for the feedback and the rating. Im assuming it was you who rated me....:-)
Victor
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide