QoS on Main Frame Relay Interface

Unanswered Question
Oct 31st, 2007

Is there any drawback to applying the service-policy to the main frame relay interface? I only will EVER have 1 subinterface w/ 1 DLCI configured. I would rather not have to turn on frame-relay traffic shaping and shape traffic. I found that putting this policy under the dlci and turning on frame-relay traffic shaping slows down the circuit because it defaults it to 56k CIR.

Please advise.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Paolo Bevilacqua Wed, 10/31/2007 - 12:57

If it is an IP based service-policy, will not work when applied to main interface while IP is configured on the subinterface.

If you need the to configure traffic shaping, need not to worry about the defaults, because you are expected to configure the correct parameters for each and any PVC that you have.

Hope this helps, please rate post if it does!

mlitka Wed, 10/31/2007 - 14:01

I see. OK well the problem I ran into before when setting up Frame Relay Traffic Shaping is that I followed the Cisco QoS SRND Guide and it suggested to set the CIR and minCIR to 95% of the bandwidth the the interval to 10 ms. This caused fragmentation of the packets and drops for any packets with the df-bit set. Any suggestions?

Paolo Bevilacqua Wed, 10/31/2007 - 15:17

Hi,

No, fragmentation should not got enabled by mere CIR settings, please forward the config you were using.

Anyway, if you want to try to maximize use of the circuit, do not set any CIR, because when you do that correctly, the real value could be much more penalizing than 95% of access speed.

mlitka Wed, 10/31/2007 - 17:14

I posted my config in this thread previously:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1ddff0f0/5#selected_message

Edison replied and told me I would be fragmenting with that config:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Network%20Infrastructure&topic=WAN%2C%20Routing%20and%20Switching&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40%5E1%40%40.1ddff0f0/6#selected_message

What would you recommend then? I have 1024k and 512k frame-relay access tails to a service provider-based MPLS network (so no FECN/BECN) that I need to apply service-policies to. (They are on different routers).

Paolo Bevilacqua Wed, 10/31/2007 - 17:40

Ok,

It gets a little complicated.

First, I'm not sure like Edison is, that if a packet with size bigger that BC comes in at moment shaping is active, it will be dropped if DF set or fragmented if DF reset. If it was fragmented, the receiving host would reassemble the packets, so no big deal.

I think that such a behavior would cause a sort of variable MTU size that could confuse hosts doing MTU path-discovery.

My point could be proven by configuring a smallish BC setting and checking with "debug ip icmp".

Anyway, back to the original issue.

From my understanding, your SP doesn't provide a real CIR on these circuits. In lack of that, and in lack of explicit congestion notification, you have no other choice that not configuring any CIR or FR traffic shaping.

You should then monitor and compare PVC counters on both routers, to see if over time there is any mismatch is seth with receivied.

Such a mismatch would indicate that your SP MPLS service is unable to reliably deliver all the traffic you are presenting to the interface at access speed.

Hope all that can make sense to you.

mlitka Wed, 10/31/2007 - 21:19

Paolo -

Thanks a lot for your help. I am still a little confused here. You are saying my options would be either to use FRTS and set CIR to 0 or not enable FRTS at all? I don't have access to the PE so I am not sure how I could compare the PVC counters.

This would seem like a pretty typical scenario these days as most providers, in this case Verizon Business, are offering frame relay access tails as a access technology into their MPLS clouds.

I would really prefer not to use FRTS and just be able to set a service-policy on a subinterface. But when I do this I get an error saying that I can't apply a CBWFQ policy on a subinterface.

This is the policy I am trying to apply:

policy-map qos_queue

class critical-data

bandwidth remaining percent 39

random-detect dscp-based

class class-default

fair-queue

Any ideas?

Thanks again!

thotsaphon Mon, 11/12/2007 - 10:39

Hi MICHAEL

As far as I could let you know.You can't directly apply service-policy into subinterface.

You need map-class command for doing that.I didn't lap it up. but you should try this.

****You did****

policy-map qos_queue

class critical-data

bandwidth remaining percent 39

random-detect dscp-based

class class-default

fair-queue

****We added****

map-class frame-relay should_be_ok

service-policy output qos_queue

interface Serial0/0.1 point-to-point

class should_be_ok

Hopes this helps

Thot

mlitka Mon, 11/12/2007 - 10:43

Thot -

This would enable by default a CIR of 64k. I would rather not use traffic shaping at all. It is really unnecessary as this is simply an access tail to a Service Provider MPLS cloud. I may just have to scrap the sub-interface and apply all my configuration on the main interface. Although I do have it ocnfigured on the main interface and it is currently working fine. My understanding is that if I ever need to reference IP addresses in my policy the will not work correctly. Currently I am using DSCP values to match and apply my queuing.

mlitka Mon, 11/26/2007 - 12:05

Paolo -

Can you point me to some documentation where you found this? I was on with TAC earlier and they were not able to verify.

Thanks!

Mike

Actions

This Discussion