[c-nsp] Shared Policy Instances and Aggregate Policing on ASR9K

[Chris Mason]

Apologies, but it seems to have messed up my formating... trying again...

I am looking for some clarification on QoS on the ASR9K with respect to VLANs and aggregate policing. I have 3 VLANs running over a Bundle and I am receiving unmarked traffic that I need to unconditionally mark based on VLAN.

(I have omitted the ingress policy-map and class-map syntax for brevity so I hope the following makes sense)

interface Bundle-Ether100.101
 set dscp cs2
!
interface Bundle-Ether100.102
 priority level 1
 police rate percent 50
 set dscp ef
!
interface Bundle-Ether100.103
 priority level 1
 police rate percent 50
 set dscp ef
!

I am receiving EF traffic on two different sub-interfaces but I don't want to receive more than 50% EF in total on each of the physical interfaces in the Bundle. I am unable to apply the policy to the main Bundle interface as I need to mark traffic based on a per VLAN basis (ok, I could probably match vlan in that scenario). However, it is my understanding that this is what a Shared Policy Instance is meant for and was wondering if the following would give my desired result?

interface Bundle-Ether100.101
 set dscp cs2
!
interface Bundle-Ether100.102
 priority level 1
 police rate percent 50
 set dscp ef
 shared-policy-instance SPI-EF50
!
interface Bundle-Ether100.103
 priority level 1
 police rate percent 50
 set dscp ef
 shared-policy-instance SPI-EF50
!

I would tie both the two policies attached to the EF VLANs to the same SPI - would this limit my EF traffic to 50% of the total physical bandwidth or would this not give me my desired result?

Thanks in advance,
Chris

(as a side note, how come 'puck.nether.net' rejects messages when I attempt to post to the list from a subscribed Google Mail address? They are getting rejected with the following message:

Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 535 535-5.7.1 Username and Password not accepted.

How come it needs a Username/Password when delivering to the MX?)