Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Webcast-Catalyst9k
New Member

Hierarchical Qos?

Hello,

do you think this can work?

!

class-map match-all CUSTOMER1

match access-group name cust1

class-map match-all CUSTOMER2

match access-group name cust2

class-map match-any CUSTOMER3

match access-group name cust3

class-map match-any CUSTOMER4

match access-group name cust4

!

!

policy-map Shaping

class CUSTOMER1

shape average 128000

class CUSTOMER2

shape average 192000

class CUSTOMER3

shape average 256000

class CUSTOMER4

shape average 512000

class class-deafult

!

!

policy-map LMQOS

class voice

set ip dscp ef

class High

set ip dscp af32

bandwidth 2048

service-policy Shaping

class Low

set ip dscp af31

bandwidth 2048

service-policy Shaping

class best-effort

set ip dscp default

service-policy Shaping

!

ip access-list extended cust1

permit ip 1.1.1.0 0.0.0.255 10.10.10.0 0.0.0.255

!

ip access-list extended cust2

permit ip 2.2.2.0 0.0.0.255 10.10.10.0 0.0.0.255

!

ip access-list extended cust3

permit ip 3.3.3.0 0.0.0.255 10.10.10.0 0.0.0.255

!

ip access-list extended cust4

permit ip 4.4.4/0 0.0.0.255 10.10.10.0 0.0.0.255

!

The goal is to shape specific traffic in each class and also perform queing.

Or is there any better (working) way to achieve this?

Thanks

peter

1 ACCEPTED SOLUTION

Accepted Solutions
Silver

Re: Hierarchical Qos?

I can understand that concern. The problem, though, is when you apply a 128k shaper to the 3 different classes of service you've specified, they will operate independantly. So in theory, you'll be shaping at 384k to that destination.

The way i've proposed actually will attempt to preserve the traffic classes. A single LLQ will be made from all different LLQ classes in order to preserve that traffic (up to line rate, or configured "priority" values). Also, when the interface is under congestion, it will begin dequeueing at a lower rate from the shaping queues, but the shaping queues will still give priority to the classes you've put a bandwidth guarantee on.

4 REPLIES
Silver

Re: Hierarchical Qos?

It should work but it looks like you still have some classes to define; voice, high, low and best-effort

-mike pls rate if helpful

Silver

Re: Hierarchical Qos?

From the look of your config, it looks like you've got a "CIR" on a per-location basis, so you want to use shaping to not exceed that value. You also want to do QoS to preserve different classes on a per-site basis. If so, you're close, but you applied the policy-maps backwards. I think this is what you were going for:

policy-map Shaping

class CUSTOMER1

shape average 128000

service-policy LMQOS

class CUSTOMER2

shape average 192000

service-policy LMQOS

class CUSTOMER3

shape average 256000

service-policy LMQOS

class CUSTOMER4

shape average 512000

service-policy LMQOS

!

!

policy-map LMQOS

class voice

set ip dscp ef

priority percent 20

class High

set ip dscp af32

bandwidth percent 15

class Low

set ip dscp af31

bandwidth percent 10

class best-effort

set ip dscp default

!

Since we're applying the same policy to different speed classes, I went ahead and modified your QOS to guarantee based on percentage, rather than absolute values. This way you wont need independant per-site policy-maps.

And, much like the other comment in this thread, you may want to guarantee bandwidth for voice, and create a LLQ by using the "priority" command under voice. I went ahead and modified your config to contain this.

New Member

Re: Hierarchical Qos?

Thanks for reply. I applied policy-map backward because I want first sort the packets in a correct order and then shape this flow. That means packets with highest priority will not be dropped.

Silver

Re: Hierarchical Qos?

I can understand that concern. The problem, though, is when you apply a 128k shaper to the 3 different classes of service you've specified, they will operate independantly. So in theory, you'll be shaping at 384k to that destination.

The way i've proposed actually will attempt to preserve the traffic classes. A single LLQ will be made from all different LLQ classes in order to preserve that traffic (up to line rate, or configured "priority" values). Also, when the interface is under congestion, it will begin dequeueing at a lower rate from the shaping queues, but the shaping queues will still give priority to the classes you've put a bandwidth guarantee on.

123
Views
3
Helpful
4
Replies
CreatePlease to create content