10-31-2007 11:46 AM - last edited on 03-25-2019 03:04 PM by ciscomoderator
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.
10-31-2007 12:57 PM
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!
10-31-2007 02:01 PM
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?
10-31-2007 03:17 PM
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.
10-31-2007 05:14 PM
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).
10-31-2007 05:40 PM
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.
10-31-2007 08:34 PM
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
10-31-2007 09:19 PM
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!
11-12-2007 09:00 AM
Any ideas on this one?
11-12-2007 10:39 AM
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
11-12-2007 10:43 AM
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.
11-26-2007 12:05 PM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: