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.
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!
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?
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:
Edison replied and told me I would be fragmenting with that config:
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).
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
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:
bandwidth remaining percent 39
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.
bandwidth remaining percent 39
map-class frame-relay should_be_ok
service-policy output qos_queue
interface Serial0/0.1 point-to-point
Hopes this helps
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.
Can you point me to some documentation where you found this? I was on with TAC earlier and they were not able to verify.