Hi Ivan, The policy should work on EFP regardless of bridge or xconnect. Which image are you using?
Regards, Waris -----Original Message----- From: Ivan [mailto:[email protected]] Sent: Wednesday, September 12, 2012 7:30 PM To: Waris Sagheer (waris) Cc: Ivan; cisco-nsp Subject: RE: [c-nsp] ME3600X Output Drops Hi Warris, Thanks again for your answers. The requirement to match at vlan level is because I understood from your examples to apply a policy at the EVC level this was required "<<<<< Using vlan level confirms it is the second level and the child policy is the third level" I have found that a policy such as the following seems to work and handle both tagged and untagged traffic and can be applied to a EVC. (I wish to apply the same policy to all EVCs regardless of whether the traffic is tagged or not unless customisation is required) class-map match-any vlan match vlan 1-4094 policy-map EVC-LEAF class class-default queue-limit 491520 bytes policy-map EVC-VLAN class vlan service-policy EVC-LEAF class class-default service-policy EVC-LEAF ################ Separate to this, and partly why I was confused, is that I have found the polices applied to the EVC seem to work when bridging but not for a xconnect. Can you confirm this is expected behavior? I would prefer to avoid having to bridge and xconnect on the vlan interface. interface GigabitEthernet0/5 switchport trunk allowed vlan none switchport mode trunk service instance 60 ethernet encapsulation dot1q 60 service-policy output EVC-VLAN bridge-domain 60 <--------------- bridged service instance 70 ethernet encapsulation dot1q 70 service-policy output EVC-VLAN xconnect 1.2.3.4 70 encapsulation mpls <--------------- xconnect Switch#show policy-map interface gi0/5 service instance 60 GigabitEthernet0/5: EFP 60 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any Queue-limit 491520 bytes Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any Queue-limit 491520 bytes <----------------------------queue-limit Queue-limit current-queue-depth 0 bytes Output Queue: Tail Packets Drop: 0 Tail Bytes Drop: 0 Switch#show policy-map interface gi0/5 service instance 70 GigabitEthernet0/5: EFP 70 Service-policy output: EVC-VLAN Class-map: vlan (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps Match: vlan 1-4094 Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any Service-policy : EVC-LEAF Class-map: class-default (match-any) 0 packets, 0 bytes 5 minute offered rate 0000 bps, drop rate 0000 bps Match: any > Hi Ivan, > There is no difference in terms of queue depth in case of policy at > the port level vs policy at the EVC from hardware programming perspective. > Port level policy would consume less queues as compare to queues per EVC. > Policy at EVC has separate queues per service instance. However policy > at the port level, queues are shared by the all the service instances > under that port. > Selection of the policy depends on the requirement. If there are > separate customers on the EVC then per EVC policy should be used. > For you last question, shouldn't untagged means no tag then why is > there a requirement to match on the VLAN level? What kind of traffic > is there in case of "default"? Is it tagged or untagged? > If tagged, is there a range? > > Regards, > Waris > > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
