08-22-2007 05:00 AM - edited 03-03-2019 06:25 PM
We have a 155Mbps OC-3 WAN link from our carrier. However, the carrier hand-off to us is Gig-E. We want to apply QoS to this circuit to prioritize important traffic.
The question: since the carrier hands us Gig-E instead of native OC-3, will traffic ever queue up on the Gig-E hand-off interface so that our QoS policy will be effective?
Solved! Go to Solution.
08-22-2007 05:04 PM
Hi,
What will solve your problems is called hierarchical policies. Basically a simple queueing policy will not help in your case, because queueing on an interface only sets in, if the interface is overloaded. If, however, you already send more that 1 GE, your OC3 would be overrun long before.
Hierarchical policies example:
ip cef
class traffic1
match protocol telnet
class traffic2
match protocol citrix
class traffic3
match protocol http
policy-map shapeOC3
class class-default
shape average 140000000
service-policy output Prio
policy-map Prio
class traffic1
bandwidth percent 10
class traffic2
bandwidth percent 30
class traffic3
bandwidth percent 50
interface GigabitEthernet1/0
ip address 10.1.1.1 255.255.255.252
service-policy output shapeOC3
The first policy shapes to f.e. 140 mbps. Do not go to 155 mbps, because you need room for Layer2 overhead. The second policy allows you to prioritize the traffic, which is important to you. You need to adjust classes and values to your environment.
Hope this helps! Please rate all posts.
Regards, Martin
08-22-2007 06:24 AM
Yes, this is possible to do. You just have to architect QOS queues to be what you want them and then apply it to the device. It doesn't matter if the phy connection is a GigE if you create queues that are smaller.
08-22-2007 09:37 AM
As Andrew notes, you can have queues form on a gig-E, of course though, your other (LAN?) side would need more than gig bandwidth for that to happen.
What you might also need to consider if you only contracted for 155 Mbps, what happens if you burst above that (assuming again that you can)? You might need to implement a shaper to guarantee you stay within contract.
QoS is most useful when you overrun your bandwidth, either physically or logically.
08-22-2007 05:04 PM
Hi,
What will solve your problems is called hierarchical policies. Basically a simple queueing policy will not help in your case, because queueing on an interface only sets in, if the interface is overloaded. If, however, you already send more that 1 GE, your OC3 would be overrun long before.
Hierarchical policies example:
ip cef
class traffic1
match protocol telnet
class traffic2
match protocol citrix
class traffic3
match protocol http
policy-map shapeOC3
class class-default
shape average 140000000
service-policy output Prio
policy-map Prio
class traffic1
bandwidth percent 10
class traffic2
bandwidth percent 30
class traffic3
bandwidth percent 50
interface GigabitEthernet1/0
ip address 10.1.1.1 255.255.255.252
service-policy output shapeOC3
The first policy shapes to f.e. 140 mbps. Do not go to 155 mbps, because you need room for Layer2 overhead. The second policy allows you to prioritize the traffic, which is important to you. You need to adjust classes and values to your environment.
Hope this helps! Please rate all posts.
Regards, Martin
08-23-2007 03:02 AM
Yes, this confirms what I suspected. I need to shape the bandwidth, and do CBWFQ within the shaper to enforce policy. For anyone else with a similar issue, it's documented here:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/part20/ch10/qsbcbts.htm
A perfect answer, thanks much.
08-23-2007 09:03 AM
I could be wrong, but if I read properly, a less CPU-intensive way may be just to set the "bandwidth" in your interface config. You'll still be able to blow over 155Mbps, though, on a transfer, but it will force your router to implement QoS when the kilobits specified in "bandwidth" are reached.
I use this for my router at home with a cable modem, and it works like a champ to implement QoS.
08-27-2007 09:59 AM
That won't work
"Bandwidth" is informational for routing protocol purposes only.
Some platforms have specific commands for a few interface types that can limit/queue egress without actually doing shaping, but you have to dig the docs for them. It's different from interface type to interface type and different on the same type of interface with different cards or on different chassis.
The best bet is to use the more generic cbQoS feature set.
08-29-2007 08:31 AM
http://www.cisco.com/en/US/docs/ios/11_0/router/command/reference/rinterfc.html#wp1396
After reading these two guides and consulting a few CCNPs, I had been under the impression for a while the bandwidth command could be used for telling the QoS on an interface that the linked speed is not the proper speed for the interface. IE, you're linked at 100M, but the actual bandwidth is 10M, so implement QoS when you start tapping 10M worth of usage.
It would be nice if Cisco could clarify what exactly "higher level" protocols are, though. Do they mean QoS-type? TCP is referenced there, so do they mean, say, layer 3 or 4?
08-29-2007 04:39 PM
Perhaps part of the confusion is "bandwidth" can be used as a statement within CBWFQ, which impacts how CBWFQ QoS behaves.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide