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?

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.

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).

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.

Yes, you are correct Paolo. I did more testing tonight and I couldn't recreate any MTU issue (even with the CIR posted in the other thread).

Not sure what I was thinking that day, but my assessment was wrong.

As a side note, I found this article http://www.cisco.com/warp/public/788/voip/fr_traffic.html very informative

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!

Any ideas on this one?

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

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.

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