configurable bandwidth for qos

[dogfugitive]

Hi.

I'm configuring MQC between a 6500 and a 7304 on a Gi interface. I'm using the bandwidth command to mirror a bottleneck further on in the network and then bandwidth percent for each traffic class. Reading the documentation for bandwidth, I expected to get a complaint from the IOS when I configured > 75% of the bandwidth for the classes and applied the service-policy, but I'm not (I haven't used the max-reserved-bandwidth command either).

Does this mean I need to include my own form of bandwidth reservation for the stuff that normal gets that 25% left over, and if so would class-default catch this traffic? Or is that the configurable 100% I see is actually onyl 75% of the interface bandwidth to start with (despite the fact that the output of sh policy-map int gix/y tells me the total kbps assigned equals the bandwidth of sh int gix/y).

Thoughts greatly appreciated, many thanks, regards.

[mohammedmahmoud]

Hi,

You'll get the error when applying the service-policy under the interface, as before applying it to the interface the router doesn't know the bandwidth which it should calculate its 75%:

policy-map voice

class voice

priority 256

interface serial0/0.1 p

bandwidth 64

Router(config-if)#service-policy output voice

I/f serial0/0.1 class voice requested bandwidth 256 (kbps), available only 48 (kbps)

Where the interface had "bandwidth 64" under it, with 48 being the 75%.

I hope that i've been informative.

HTH, please do rate all helpful replies,

Mohammed Mahmoud.

[Edison Ortiz]

Can you post the MQC config along with

'show policy-map interface xxx'

and

'show queueing interface xxx' ?

Thanks

[mheusing · Accepted solution]

Hi,

few thoughts.

First, you should use nested policy-maps to"mirror a bottleneck". As far as I understand, you want to apply a Qos policy, which ensures to not overload a bottleneck further down the line!? If so, an example config could look like this:

class-map match-all important

match protocol http

class-map match-all MoreImportant

match protocol telnet

policy-map ShapeBottleneck

class class-default

shape average 50000000

service-policy output QoS4Apps

policy-map QoS4Apps

class MoreImportant

bandwidth percent 60

class important

bandwidth percent 30

class class-default

fair-queue

random-detect

As you see, the sum in the example is more than 75%, in fact in could be 100% of the SHAPED bandwidth.

The 75% rule for INTERFACE bandwidth come from the fact that you always need some bandwidth for L2 keepalives, etc. which are not counted in the policy-map.

Thus giving 100% to user traffic is not reasonable.

IF you use the nested policy-map example given above, there will be much less traffic in outgoing direction than the interface can handle. Thus reserving bandwidth for L2 keepalives, etc. is not a requirement and accordingly IOS allows to give 100% of the SHAPED bandwidth to user applications.

OK, honestly I am not quite sure about your config in place. Can you post the relevant parts please? Especially highlight, whether you are refering to the "bandwidth" interface command, the "bandwith" command in policy-maps (CBWFQ) or in nested policy-maps.

In case my example above did not address your problem to solve, could you please help a non-native speaker to get the essential parts? ;-)

In case my example above did solve your issue: please, live happily ever after!

Hope this helps!

Regards, Martin

[dogfugitive]

Thanks for this reply Martin, you have grasped the situation perfectly!

Using the principle you describe I guess the maximum shape value would be 75% of the bottleneck bandwidth in order not to swamp the bottleneck further on in the network with the shaped "user" traffic when it's mixed with the L2 traffic etc. local to that link.

Thanks again.

[mheusing]

Hi dogfugitive,

To shape at 75% max of bottleneck is probably overcautious. The 75% rule is very conservative as it should work as a factory default under any thinkable condition. In addition it allows room for class-default traffic.

So shaping closer to 100% might be OK, but the maximum value will depend on L2 overhead per packet, packet sizes and the like.

Example: if the bottleneck is an STM4 (with EoSONET) and you are shaping to 75%, you are leaving 155 Mbps for L2 overhead and such. This will in general not be required. In this case even above 90% might work.

Regards, Martin

[Jon Marshall]

Hi Martin

I'm assuming your'e the same Martin who is 5th all time on the list ???

If so, congrats on new job, good to have you back in group and why start all over again ??

Jon

[royalblues]

Martin,

I was about to ask the same question which jon did in his previous post

Congratulations and good to see you back

Narayan

[mheusing]

Hi,

Yes I am the mheusinger on the all time list. Thank you for congratulating me. I am now part of the AS Education team - have a look at http://www.cisco.com/go/ndm in case you are interested in the classes offered. Besides there are customer specifically tailored workshops offered as well.

Regards, Martin

[Edit] P.S.: I am currently ramping up on CRS-1 and IOS XR, which - besides MPLS - will be my topics to teach.

[Djule2804]

Hi,

Could you say me if it is possible to use "nested policy-map" on Cisco 2600

I'm using Cisco 2621XM routers with 12.3(6) IOS.

I think I read somewhere that it's not possible but I'm not sure.

Thanks

[griffinmark]

Would applying GTS on the interface and then a normal service policy not work?

interface FastEthernet0/0

bandwidth 5000

ip address 1.1.1.1 255.255.255.0

traffic-shape rate 5000000 125000 125000 1000

service-policy output TEST

end

[mheusing]

Hi Mark,

though I never tried it, I would say it does not do the same. I would assume it is the same as having shaping and CBWFQ in the same policy-map. The main problem solved by the nested policy-maps is:

First, queueing will only kick in on a phisical interface, if the interface is overloaded. So the complete CBWFQ config is completely irrelevant unless you have an overload condition (full HW queue). In your case the shaper would prevent that from happening.

Second, the normal shaper queue is FIFO, thus no traffic differentiation happens.

In a sense, the nested policy-map allows to replace the FIFO shaper queue with a more appropriate CBWFQ policy allowing the traffic prioritisation required.

Hope this helps!

Regards, Martin

[griffinmark]

Hmm, It seems to work in a similar config I have in production.

I have an MPLS VPN customer connecting via T1s where some sites are sub T1 rates. Since I knew that the customer was going to need to quickly upgrade speeds at certain sites I configured the CPE cisco routers to shape down to the sub rate speeds instead of channelizing.

In addition, priority queuing is configured via a service policy for RTP and signaling.

Monitoring of link utilization shows the proper max speeds, for example one site is 128kbs shaped and at 100% utilization it is getting around 128kbs.

Additionally when I monitor the actual policy applied to the interface I do see matched packets and bytes which should indicate actual qos queuing is taking place.

I guess I assumed that GTS would modify the interfaces software queue down to the configured value essentially causing the buffer to fill faster which would still trigger priority/CBWFQ queuing.

Crap, now you got me worried, guess I better go do a little more testing in the lab :)

[Djule2804]

Hi,

Could you say me if it is possible to use "nested policy-map" on Cisco 2600

I'm using Cisco 2621XM routers with 12.3(6) IOS.

I think I read somewhere that it's not possible but I'm not sure.

Thanks