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??

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joseph W. Doherty Mon, 09/17/2007 - 18:14
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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
User Badges:
  • Super Bronze, 10000 points or more

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