Frame Relay Shaping Not Reaching 100% BW Utilization

Cucumber

This is driving me a bit crazy folks.>

My monthly WAN link graphs about bandwidth utilization are not reaching 100% but a mere 98%. I use an SNMP application that gathers info each 5 minutes from each link. By the way Im experiencing this in all my links; which are houndreds.

The graphs usually peak at 98% of the links. I know 5 minutes SNMP data are usually average and average graphs will not show burst that brings the link into 100%, but its a bit odd that they wont ever never reach an average of 100%,not even once, I know these users and they are bandwidth predators, however the graphs' peaks are 98%....I want to see at least one 100% peak!

MY common sense tellse me Im complety wrong about this need because obviously its almost impossible to keep an smooth 100% traffic rate for 5 minutes in a row, even with shaping... but maybe my crazy-half-self is right and something is missing in my configs, Care to take a look? Im doing FrameRelay shaping, BTW any of you ever get a 100% in your graphs?

(I added random detection and fair-queue to my default class and reduced droped frames a bit, but couldnt reach the 100% just yet.)

policy-map QOSSTUFF
class VoiceClass
priority percent 50
police cir 192000 bc 6000 be 6000
conform-action transmit
exceed-action drop
class DataClass
bandwidth percent 40
queue-limit 48
police cir 128000 bc 4000 be 4000
conform-action transmit
exceed-action set-prec-transmit 1
class class-default
fair-queue
random-detect dscp-based

interface Serial0/0/0
bandwidth 384
ip address x.x.x.x y.y.y.252
no ip proxy-arp
ip accounting output-packets
encapsulation frame-relay IETF
frame-relay traffic-shaping
frame-relay interface-dlci 8
class FRF12
frame-relay lmi-type cisco
max-reserved-bandwidth 100

map-class frame-relay FRF12
frame-relay cir 384000
frame-relay bc 3840
frame-relay be 0
frame-relay mincir 384000
frame-relay fragment 480
service-policy output QOSSTUFF

Mrock4

You WANT 100% utilization of your WAN links? Why?

marlon23

RED is congestion avoidance mechanism, so I think it is working correctly in your case

Have you tried to play with queue size ? (hold-queue in & out)

kryolla

Look at the stats of your shaping que instead of SNMP polls if the provider is policing at 384000 and you are shaping at that rate look at sh fr pvc dlci 8 and sh int s0/0/0. I think FRTS has 2 shaping queues 1 for dlci and 1 for the physical interface and there has to be some co-ordination between the 2.

Mrock shaping is so it doesnt drop packets above 100% utilization, your access rate or line / clocking rate can be different than what you are allowed on the link.

kpjungle

This is an interesting question

The DLCI frame-relay takes precedence takes priority, so I dont think theres anything there.

Second, im wondering what the LLQ with the priority command and a manual police really does as LLQ polices by default. Third, im curious as why you dont use the Be with the police command (if the manual police command takes precedence), as any "saved-up" date wont be utilized when a burst suddenly appears. This would push up the total utilization even more.
Fourth, the WRED in the default class should be kicking in when the queues start to fill up and the threshold for WRED has been reached. The more full, the more packet drops, until you have a tail-drop situation.

I would try to use the frame-relay traffic shaping without the service-policy to see if it actually helps any.

Also, you could check your frame-relay PVC, to see if any BECN's have been received from the provider.

But theres a reason the max-reserved bandwidth is set to 75% (even though this might be too conservative). You will still have some data-link layer traffic that needs to be passed back and forward, such as LMI messages.

APA

Is your WRED profile dropping packets too early??? It sounds like it is....... Also have a look at the queue limit you placed on your data class- could this be too small causing tail-drops for that class???

show policy-map int s 0/0/0

show policy-map QOSSTUFF

show queueing int s 0/0/0

I can't remember the frame-relay commands as I don't use it much.... I'll have to have a hunt around my QoS notes and get back to you...

networker050184

APA wrote: »

Is your WRED profile dropping packets too early??? It sounds like it is....... Also have a look at the queue limit you placed on your data class- could this be too small causing tail-drops for that class???

+1 to all this.

tomset

You've reserved 90% of your link with this policy map. By default, can't you only reserve 75% of the link so that the remaining 25% is used for network control traffic?

class VoiceClass
priority percent 50
police cir 192000 bc 6000 be 6000
conform-action transmit
exceed-action drop
class DataClass
bandwidth percent 40

networker050184

tomset wrote: »

You've reserved 90% of your link with this policy map. By default, can't you only reserve 75% of the link so that the remaining 25% is used for network control traffic?

class VoiceClass
priority percent 50
police cir 192000 bc 6000 be 6000
conform-action transmit
exceed-action drop
class DataClass
bandwidth percent 40

Look at the max-reserved-bandwidth command.

tomset

networker050184 wrote: »

Look at the max-reserved-bandwidth command.

Ah ha! I missed that - LOL

Mrock4

kryolla wrote: »

Mrock shaping is so it doesnt drop packets above 100% utilization, your access rate or line / clocking rate can be different than what you are allowed on the link.

I understand what traffic shaping is, or at least I think I have an idea (see link): http://www.sgtccie.com/blog/2009/05/frame-relay-traffic-shaping-frts/

What my question was, is why the OP wants his links at 100%..on a production network with "hundreds" of WAN links. I'm simply inquiring as to why the links are that high all of the time..what applications are being run that cause that kind of utilization?

Cucumber

Thanks for all the responses so far people, I appreciate all inputs.

Well, I am using BE=0 because I read in some document that this is the recommended value when using VoIP. We are using VoIP extensively. Actually the document I read stated Bc = cir/100, mincir=cir, and Be=0, this yields the best results for VoIP.
This is the link:
VoIP over Frame Relay with Quality of Service (Fragmentation, Traffic Shaping, LLQ / IP RTP Priority) - Cisco Systems

Hey Mrock, Regarding your question, which is a good one, I want to reach 100%, yes, why? Because I am experiencing dropped packets, dropped packets are a sign of interface congestion, so I do know my interfaces are getting congested because they drop packets, what I would like to get then is a better shaping, to drop less packets, and to utilize the link at full capacity.We all know BW is like closet space or parking slots, everybody wants more but they are limited and most of the times you are stuck with the space you have. In my case I pack everything I can into my closet space, if there is still room there I want to use it.

My links are not showing high utilization all the time, actually their behaviour is site dependant. Some sites experiencie congestion for a couple of hours in the morning, others in the afternoon, other at night (DB sync perhaps), etc. Fact is, most of them become congested sometime in the day, and they drop packets at that very same time.

Finally why do I want to have less dropped packets? because I dont want to break the service level agreement regarding dropped packets with the costumer. Nowadays, everything is measured for contract reasons: dropped packets, latency, jitter, etc etc, failing to achieve the contracted SLA means money penalizations.

Mrock4 wrote: »

I understand what traffic shaping is, or at least I think I have an idea (see link): SGT CCIE | Frame Relay Traffic Shaping (FRTS)

What my question was, is why the OP wants his links at 100%..on a production network with "hundreds" of WAN links. I'm simply inquiring as to why the links are that high all of the time..what applications are being run that cause that kind of utilization?

Mrock4

Cucumber wrote: »

My links are not showing high utilization all the time, actually their behaviour is site dependant. Some sites experiencie congestion for a couple of hours in the morning, others in the afternoon, other at night (DB sync perhaps), etc. Fact is, most of them become congested sometime in the day, and they drop packets at that very same time.

This makes a lot more sense to me..I just had a hard time picturing hundreds of WAN links at 100% usage 24/7..that would be expensive.