QOS question (interface bandwidth sbucommand)

cliff.bowles · ‎09-17-2007

I have the Cisco Press QOS book and here is a snippet: Pg. 297

"the policy-map queue-voip policy assigns VOIP traffic 50 percent of the bandwidth based on the bandwidth 50 percent command. But 50 percent of what? Well, the actual bandwidth is derived from the percentage of the bandwidth configured on the bandwidth interface subcommand. In this case, the bandwidth is set to 128, so the voip-rtp class gets 64k..."

So this quote tells me that when you assign a bandwith percentage in a policy map, the actual value is related to what you have put in as a bandwidth statement on the interface.

But I was working with a Provider on an upcoming MPLS project and they showed a quote saying that the bandwidth statement on the physical interface was optional and had nothing to do with the QOS policy-map configurations. In particular, they were talking about a MLPPP link.

My question: are virtual links treated differently than physical links as far as QOS policy-maps?

The reason we were even asking about this was that another engineer asked what would happen if we configured 6Mb as a bandwidth statement on a 4xT1 MLPPP interface, and one of the links dropped out? Would QOS CBWFQ still use the 6Mb as a reference or would it know that the actual bandwidth had changed to 4.5Mb?

If anyone has any guidance, it would be greatly appreciated. If you know of a link or two that addresses my question, save yourself the typing and I'll do the research :)

Thanks in advance,

CWB

a.cruea1980 · ‎09-17-2007

Okay, your book just said "the actual bandwidth is derived from the percentage of the bandwidth configured on the bandwidth interface subcommand". That says to me, the physical interface. I've got it on my router at home hooked up to a cable modem so that the router knows when to expect saturation. Works like a charm.

I'm sure you've looked at Cisco's actual definition of the bandwidth command; all it does is communicate the available and expected bandwidth of the interface to higher-level protocols. It's also used for metrics. However, in your case, you're hooked up via T1's; IIRC, you have to specify your channels and the bandwidth of those channels, so the bandwidth command would be unnecessary. The router would also sense when those channels came up and down, and adjust accordingly.

I can warn you, though, don't be surprised to have people posting up the link to the bandwidth command reference, and then saying you have no clue what you're talking about. Seems all people can really see is "it's a routing metric", not that it communicates available bandwidth to higher-level protocols.

[edit]Sorry, I meant to say this before. . .take what I've said about T-lines with a small grain of salt. . .I'm going completely off memory of what I've read and the opinion of my co-worker, so I could well be wrong in that regard.

Joseph W. Doherty · ‎09-17-2007

I currently work with routers doing T-1/E-1 MLPPP using percentage based QoS policy maps (IOS 12.4). Unfortunately, I'm not on-line with one at the moment, but I believe if you don't specify the bandwidth, QoS picks up the bandwidth of the bundle for the active links at their full bandwidth per link. I think the QoS percentage bandwidth value changes as a link joins or leaves the bundle.

cliff.bowles · ‎09-18-2007

Thanks, both of you. It seems I have baffled quite a few people with that statement from the book. As far as I can tell, the bandwidth statement is relevant for sub-rate interfaces but not for standard or aggregated interfaces. This makes sense in a way... if you have a point-to-point T1, what would you be accomplishing by setting a bandwidth statement (as far as QOS goes)? Any bandwidth statement lower or higher than the default would be detrimental to your QOS policy.

I just can't seem to find documentation describing where you would and would not ever want to do this. I also can't find documentation describing exactly when the interface bandwidth subcommand is relevant, and when it's just optional.

Thanks for the responses!

CWB

a.cruea1980 · ‎09-18-2007

It's relevant when you have an interface that isn't matched up on speed to your line; ie, I have a cable modem hooked up to my 1811. Since it's a FE interface, it'll never know when the line is saturated as the upload is limited to 2Mb, but the interface is 100Mb. So, you set the bandwidth command at something like "bandwidth 2000" (I actually set mine at 1.5Mbps), and it causes queuing to kick in when the specified bandwidth is reached. That way, your queue is getting used, and you're not dropping anything. With a cable modem, for example, I may well get an upload of 1.8Mbps, so why would I create a policy to drop things over 1.5Mbps? Instead, use the bandwidth command so the router starts diverting to the queue but doesn't chop off bandwidth.

Make some sense? It's a rather abstract idea.

a.cruea1980 · ‎09-25-2007

Oh, and I just found this. . .

CISCO AUTOQOS VOIP REQUIREMENTS AND DESIGN CONSIDERATIONS

The following are the minimum required steps to enable Cisco AutoQoS for VoIP traffic for WAN interfaces:

1. Configure an IP address on a low-speed (768 kbps or lower) interface or a sub-interface.

2. Configure "bandwidth" under any participating interfaces or sub-interfaces. For ATM PVC, configure "vbr-nrt" under the PVC.

Note: Asterisks (*) denote the resulting configuration commands (CLI) generated as a result of configuring Cisco AutoQoS.

For low-speed interfaces or PVCs the configured IP address will be moved to the virtual template/multilink interface automatically by Cisco AutoQoS.

Using Cisco AutoQoS, VoIP traffic is automatically provided with the required QoS template for voice traffic by configuring autoqos voip on an interface or PVC. Cisco AutoQoS enables the required QoS based on Cisco best practice methodologies (the configuration generated by Cisco AutoQoS can be modified if desired).

The type and bandwidth of the interface is considered when deciding the appropriate techniques required for the template. The classification is used to differentiate the voice packets from the data packets and handle them appropriately. The LLQ-PQ is applied to the voice packets to meet the latency requirements. LFI reduces the jitter of voice packets by preventing them from becoming stuck behind large, 1,500 byte (Ethernet MTU) data packets. Using cRTP the 40-byte IP header of the voice packet is reduced to 2-4 bytes, thereby reducing voice bandwidth requirements. Please note, for low-speed links (links less than 768 kbps), the AutoQoS command must be applied on both sides of the link.

For Cisco AutoQoS, global templates for policy-map, class-maps, and access-lists are created to classify VoIP packets, and to provide LLQ. Interface templates are created depending on the type of interface and bandwidth configured on the interface.

Cisco AutoQoS VoIP cannot be configured if a pre-existing QoS service policy is already attached to an interface or PVC (see the Considerations, Caveats, and Restrictions for AutoQoS VoIP section of this document for more information).

Taken from here:

http://www.cisco.com/en/US/tech/tk543/tk759/tk879/technologies_white_paper0900aecd800a8561.shtml

cliff.bowles · ‎09-25-2007

Well... the search continues. I have now emailed our Sales engineer asking for clarification about when the bandwidth statement is, and is not, relevant. I pasted your snippet in the email - thanks for that.

We recently had a Cisco engineer onsite to answer questions about another product and I pitched the question to her. She is on the team that helps develop the router code. She said that she couldn't answer my question about the QOS and bandwidth statements in general, but that she could answer it specifically in regards to MLPPP. She said that she knew for certain that the router code explicitly ignores the bandwidth statement on MLPPP interface and the default bandwidth derived from the number of links in the bundle is used. Therefore, if you add or remove links from the bundle, QOS recalculates accordingly.

That relieves any concerns about the MLPPP. I'm still wondering about other links. If I have a point-to-point T1 and I put a bandwidth statement on there, will QOS ignore it or not? Sometimes you put bandwidth statements on links to affect routing metrics (instead of "cost") and I'd like to know when I'm affecting QOS by doing this.

thanks for the input!

CWB