Solved: QoS on OC-3 When Carrier Hands Us GigE

ebanks2006 · ‎08-22-2007

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?

mheusing · ‎08-22-2007

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

View solution in original post

avmabe · ‎08-22-2007

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.

jwdoherty · ‎08-22-2007

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.

mheusing · ‎08-22-2007

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

ebanks2006 · ‎08-23-2007

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.

a.cruea1980 · ‎08-23-2007

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.

b.julin · ‎08-27-2007

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.

a.cruea1980 · ‎08-29-2007

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_command_reference_chapter09186a008011012d.html#wp1018151

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?

Joseph W. Doherty · ‎08-29-2007

Perhaps part of the confusion is "bandwidth" can be used as a statement within CBWFQ, which impacts how CBWFQ QoS behaves.