Nested QoS Scalability

Unanswered Question

Hi Guys,

I was wondering whether QoS nesting can be used to provide multi-site QoS with minimal policy configuration.

I have a 7200 series router connected at the central site serving 50+ locations of varying bandwidth. What I was attempting to do was create some predefined parent policies and then nest that map in each child policy that relates to each site. Example:

policy-map 256k-site

class voice

bandwidth 64

policy-map site-1

service-policy 256k-site

policy-map site-2

service-policy 256k-site

Would this work by creating 2 seperate queues for each site based on the parent policy or would the 2 sites just end up sharing the software queue??

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joseph W. Doherty Mon, 09/17/2007 - 18:14

You can use the same policy on multiple interfaces. If you using a later IOS, you can define policy bandwidths using percentages (except, I believe, for shaping/policing). What do you need to vary per remote site policy?

There in lies the problem. The presentation is one single frame relay interface otherwise yes I would definatly use bandwidth percent policies.

As it stands access lists are being used to identify the relevant remote site traffic which is associated with a class. A policy is then assigned under that class e.g.

ip access-list extended remote-office

permit ip any xxx.xxx.xxx.0 0.0.0.255

class-map match-any traffic-remote-office

match access-group name remote-office

class traffic-remote-office

shape average 512000

service-policy traffic-512

Joseph W. Doherty Tue, 09/18/2007 - 03:00

Yup, using embedded shapers does make a bit of a problem.

What I've done in a similar situation was have parent policies for the various bandwidths being used by different sites. E.g. one for 128, 256, 512, 1024, etc. Each of these parent policies would use the same child policy that used percentages.

One other possible difference was I used subinterfaces for each PVC, each with its own policy.

Another issue was LLQ not supporting percentages until 12.4 (or 12.3T?).

Pseudo config:

policy-map remote-384

shape average 384000

service policy remote-condition

policy-map remote-512

shape average 512000

service policy remote-condition

class-map realtime

match protocol voice

class-map gold

match protocol citrix

policy-map remote-condition

class realtime

priority percentage 50

class gold

bandwidth remaining percentage 60

interface serial 0

interface serial 0.23

pvc 23

service policy remote-384 out

interface serial 0.45

pvc 45

service policy remote-512 out

interface serial 0.81

pvc 81

service policy remote-384 out

I would definatley use percentage based policing on the PVC's... if I had any PVC's that is.

The problem is that the WAN connections actually run over a provider MPLS network with a single frame relay interface presentation with no PVC's.

Thats why im sort of trying to use simple access lists to identify the traffic rather than just applying the relevant policies to the PVC.

I am assuming that IOS is not going to treat my attempt at creating virtual queues in the same way as it would if I had multiple PVC's and attached the policy to each cicuit.

Joseph W. Doherty Tue, 09/18/2007 - 03:35

Ah, I understand.

Then you could do this.

Pseudo config:

ip access-list extended remote-office-1

permit ip any xxx.xxx.xxx.0 0.0.0.255

ip access-list extended remote-office-2

permit ip any xxx.xxx.xxx.0 0.0.0.255

ip access-list extended remote-office-#

permit ip any xxx.xxx.xxx.0 0.0.0.255

class-map realtime

match protocol voice

class-map gold

match protocol citrix

class-map match-any traffic-remote-office-1

match access-group name remote-office

class-map match-any traffic-remote-office-2

match access-group name remote-office

class-map match-any traffic-remote-office-#

match access-group name remote-office

policy-map remote-condition

class realtime

priority percentage 50

class gold

bandwidth remaining percentage 60

policy-map remotes

class match-any traffic-remote-office-1

shape average 512000

service policy remote-condition

class match-any traffic-remote-office-2

shape average 256000

service policy remote-condition

class match-any traffic-remote-office-#

shape average #

service policy remote-condition

interface serial 0

service policy remotes out

Thats exactly it Joseph! The question is will IOS look at this and say...

"ok i am going to create a different software queue for each remote site based on the remote-condition map"

or

"because this is a single interface i am going to share the remote-condition policy bandwidth between the relevant sites"

Bear in mind there are no PVC's so the circuit is "unaware" of the remote site bandwidth capabilities, as such I cannot use percentage based QoS.

Pseudo config:

ip access-list extended remote-office-1

permit ip any xxx.xxx.xxx.0 0.0.0.255

ip access-list extended remote-office-2

permit ip any xxx.xxx.xxx.0 0.0.0.255

ip access-list extended remote-office-3

permit ip any xxx.xxx.xxx.0 0.0.0.255

ip access-list extended remote-office-#

permit ip any xxx.xxx.xxx.0 0.0.0.255

class-map realtime

match protocol voice

class-map gold

match protocol citrix

class-map match-any traffic-remote-office-1

match access-group name remote-office-1

class-map match-any traffic-remote-office-2

match access-group name remote-office-2

class-map match-any traffic-remote-office-3

match access-group name remote-office-3

class-map match-any traffic-remote-office-#

match access-group name remote-office-#

policy-map remote-condition-256

class realtime

priority 128

class gold

bandwidth 64

policy-map remote-condition-512

class realtime

priority 256

class gold

bandwidth 128

policy-map remotes

class match-any traffic-remote-office-1

shape average 512000

service policy remote-condition-512

class match-any traffic-remote-office-2

shape average 256000

service policy remote-condition-256

class match-any traffic-remote-office-3

shape average 256000

service policy remote-condition-256

class match-any traffic-remote-office-#

shape average #

service policy remote-condition-#

interface serial 0

service policy remotes out

Joseph W. Doherty Tue, 09/18/2007 - 04:02

Each class will have it's own queue.

Each class has a shaper which will limit bandwidth utilization to that class. (NB: the shaper seems to create a FQ, so you might not even need the subpolicy unless other prioritization is important to you.)

The subpolicy's bandwidth percentages, which really set ratios between the classes (within the subpolicy), should work.

In using similar policies, I recall noticing queues forming both within the parent's class shaper and the child's classes.

Actions

This Discussion