QoS on OC-3 When Carrier Hands Us GigE

Answered Question
Aug 22nd, 2007
User Badges:

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?

Correct Answer by mheusing about 9 years 10 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
avmabe Wed, 08/22/2007 - 06:24
User Badges:
  • Bronze, 100 points or more

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 Wed, 08/22/2007 - 09:37
User Badges:

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.

Correct Answer
mheusing Wed, 08/22/2007 - 17:04
User Badges:
  • Cisco Employee,

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

a.cruea1980 Thu, 08/23/2007 - 09:03
User Badges:
  • Bronze, 100 points or more

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 Mon, 08/27/2007 - 09:59
User Badges:
  • Bronze, 100 points or more

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 Wed, 08/29/2007 - 08:31
User Badges:
  • Bronze, 100 points or more

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 Wed, 08/29/2007 - 16:39
User Badges:
  • Super Bronze, 10000 points or more

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

Actions

This Discussion