Hi Warris,
Running me360x-universalk9-mz.152-2.S1.bin
Thanks
Ivan
On 16/Sep/2012 12:20 a.m., Waris Sagheer (waris) wrote:
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/
