Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

ASR9000/XR : Understanding ethernet filter strict

Introduction

Since the ASR9000 implements a layer 2 environment via the EVC model, there are some differences as to how things work compared to regular IOS  that implements the IEEE model.            

Core Issue

When using Bridge-Domains in the ASR9000, we need to make sure that the traffic forwarded out of the EFP members has the correct vlan setting.

Since the EVC model does not imply tag rewrite and popping by default, you need to make sure that your tag rewrite configuration is correct.

In the easiest form, it makes the most sense to always pop all tags on the EFP's symmetrically such that the bridge domain internally sees untagged traffic. This is a requirement already for when the BD has a BVI interface. The BVI interface is not VLAN aware and needs to see untagged traffic.

Traffic eggressing out of other EFP's will get their respective tags applied again, normally, so that the have the right tags on the packet when packets are transmitted by the EFP. The "symmetric" keyword of the rewrite ingress tag command will take care of that.

However that behavior is NOT by default.

You might end up in the scenario that your traffic is sent out of an EFP with encap of vlan 20 as per configuration might see a tag of 10/100 if the ingress EFP has that vlan stack and not popping it.

Resolution

The ethernet filter strict command will help in the prevention of packets with incorrect vlan tags from being transmitted out of EFPs.

This command is NOT on by default as it comes with a slight performance hit in terms of pps and if the configuration is properly done it is normally not necessary. In so many words this command protects against misconfigurations at the VLAN encapsulation of packets transmitted out of EFPs.


Packets that fail the strict filter have different drop reasons in the NP (see the NP drop counter article on the support forums for more detail).

Examples

Consider the following examples:

When we have 3 interfaces in a BD

EFP1

Int e1.1
Encap dot1q 10

EFP2
Int e2.2
Encap dot1q 20

EFP3
Int e10.10
Encap dot1q 20

L2VPN configuration
l2vpn bridge-domain foo
Int e1.1
Int e2.2
Int e10.10

CASES:
Then when a packet comes from int e10.10 and gets flooded... Where should this packet go to?

  1. int      e10.10? - no, because of “my packet rule” (split horizon)
  2. int      e2.2? - yes
  3. int      e1.1? - this would be possibly the most questionable one...
In 3 we would send out a packet with encap 20 out of a vlan 10 efp.
Filter strict will prevent that behavior.

It is of course proper behavior to do tag translations via the rewrite ingress tag rules.


DROPS related to strict filtering.

Here a few use cases and examples and drops one might see.

The drop rules for Layer2 pkt on the egress efp2 are (assume traffic from efp1 to efp2):

1) num_tags
EGR_VLANOPS_DROP
This check is done with or without “ethernet egress-filter strict”
Efp1 encap untagged; efp2 encap 20 + rewrite push 30
Efp1 encap 10; efp2 encap 20,30 + rewrite trans 2-2

2) pre tags:
EGR_PREFILTER_VLAN_DROP
This check is done only when “Ethernet egress-filter strict” is configured
Efp1 encap 10; efp2 encap 20 + rewrite trans 1-1 vlan 30
Efp1 encap 10; efp2 encap 20 + rewrite push vlan 30

3) TCAM miss:
RESOLVE_EFP_FILTER_TCAM_MISS_DROP
This check is done only when “Ethernet egress-filter strict” is configured

Efp1 encap 10,20; efp2 encap 30 + rewrite push 10
Efp1 encap 10; efp2 encap untagged

4) uIDB miss match:
RESOLVE_EFP_FILTER_MISS_MATCH_DROP
This check is done only when “Ethernet egress-filter strict” is configured
Efp1 encap untagged; efp2 encap 10
Efp1 encap 10,20 + rewrite pop2; efp2 encap 30

Related Information

Understanding the EVC model

Xander Thuijs, CCIE #6775

Sr. Tech Lead ASR9000

Version history
Revision #:
1 of 1
Last update:
‎05-09-2011 01:40 PM
Updated by:
 
Labels (1)
Comments
New Member

Hello Xander,

Your post is very helpful!

Is there any limitation regarding the L2 subinterfaces that have ethernet egress filter enabled?

Do you know what is the impact in terms of pps if we enable this feature?

Thank you in advance.

Best Regards,

Michalis

Cisco Employee

hi michaelis!

thank you :) this functionality cost you about 10-15% pps performance. so a typhoon capable of 45 Mpps (each direction) would likely see a 5-10Mpps performance loss. this would merely mean that the minimum packet size to reach line rate goes up, as it is still able to drive the BW for the circuit(s) attached.

note also that this functionality is merely required when you have a "simple" design whereby you aggregate different vlans inside the same bridge domain. For instance when you have one BD and link 2 vlans together between 2 AC's of vlan 10 and 2 AC's of vlan 20 this functionality will make sure that a vlan 10 received packet will not get out of a vlan 20 AC.

A cleaner solution would be to create 2 BD's, one for vlan 10 and one for vlan 20, so that this functionality of filter strict is not even necessary.

cheers!

xander

New Member

Hello Xander,

Thank you very much for the prompt reply.

 

The case is that we have a service with two vlan tags in multiple subinterfaces. The outer vlan tag is the same in all L2 subinterfaces but the inner vlan tag is different in each subinterface. All subinterfaces are in the same bridge-domain.

 

So in each L2 subinterface we pop the outer vlan tag but we want the inner vlan tag in order to differentiate the traffic.  We can use split horizon so as to avoid  the local attachment circuit’s communication but we extend the service to another A9K with VPLS so we can’t apply the same solution to the remote attachment circuits.

 

The impact is the same regardless the number of the subinterfaces that we have enabled the filter? For example if we have enabled it in 100 subinterfaces we’ll have the same impact as if we have enabled it in one? Is there any difference if we use satellite ASR9000v switches?

 

Tomahawk linecards have the same impact as typhoon?

 

I’m very sorry to shoot so many questions at you but I have to grab the chance :)

Cheers,

Michalis

Cisco Employee

ah thats no problem michalis, that is what this forum is for, the Q&A :)

when you enable the functionality on an EFP (l2 subinterface) the performance impact is there, simply becuase of the extra cycles that need to be spent in the pipeline to process and validate the dot1q tag. also to note, the packet will get delivered to the egress EFP but might get dropped there if the validation fails, so we effectively give the npu something to do and process and it might need to drop the packet, so the egress npu will see that performance impact.

split horizon indeed will prevent one AC to talk directly to another AC if they are in the same SHG.

for a 9000v, all features are processed on teh a9k host/npu, the 9000v simply forwards what it receives, from the phy int to the 9k host or from ICL towards the phy int.

perf impact is same between TY/TH, albeit TH is a faster more capable one then typhoon so the pps impact is lesser then on typhoon.

cheers!

xander

A good practice is that if L2 customers should not be talking to each other, not only in a single BD, but globally across the service, then the best option is to put each customer into its own L2VPN, i.e. BD(for p2mp or mp2mp services) or dedicated PW (p2p services).

Same principle applies to L3 customers –we tend to put them in their discrete L3VPNs rather than aggregating multiple customers into one VRF and securing communication using ACLs.

 

adam

New Member

I totally agree with you.

 

The problem though Is that I want a kind of e-tree service so as the spokes can talk only with the HUB.

 

With dual-attached spokes in two different HUBs (A9K)  with VPLS I think is not possible an e-tree configuration.

 

The only way (as far as I know) to implement e-tree with A9K is with single hub by using split horizon groups.

I think there are two options how to achieve dual hub and spoke e-tree L2VPN using BDs and SHGs

Details are in the attached pfd file.

 

But it’s hard to guess without not knowing your topology or use case.

 

adam

New Member

Hello Adam,

Thank you very much for your reply.

The problem is that I need an AC-Spoke on the HUB PE but I think that there is no way to implement something like this.

Michalis

I see what you mean, that’s a tricky one,

I have added two options for the hub site solution, page 3 and 4 in the attached pdf file, but I’m not sure about option2 on the last page (pw between two BDs on the same box, that is probably not going to fly).

adam

New Member

Thank you very much Xander!

Cheers,

Michalis

I’m so sorry I somehow forgot to attach the PDF file with the two options you can use to achieve resiliency for AC-Spoke when you have AC-Spoke connected to the HUB PE.

 

Please see page 3 and 4 of the attached PDF

 

adam

New Member

Thank you very much Adam!

Cheers,

Michalis

New Member

Hi Xander,

Great article.

Thanks much.

What will be the behaviour with “Ethernet egress-filter strict” when we also have an untagged port in the bridge-domain?

Sincerely,

Leonardo Gama.

Cisco Employee

ha funny you mention that, because we cannot applyt his config on untagged interfaces as there are no tags to match for that matter.

theoretically, if the untagged intf is in a bdomain together with tagged interfaces, one could see a use for this scenario, but generally, yeah what is generally right, untagged interfaces are kept separate strictly, since untagged intfs are usually not seen on trunk interfaces (and native vlan tagged for instance or marked with vlan 0).

cheers!

xander

New Member

Great, so I understand that if we have the untagged intf in a bdomain together with tagged interfaces, traffic from this untagged intf will not be forwarded to the interfaces configured with  "ethernet filter strict", right?

Sincerely.

Cisco Employee

oh just to be clear: the filter strict cannot be applied to an untagged interface.

but the untagged CAN be put together in a bridge domain with a tagged interface.

this would merely mean that a packet with a vlan may get out of that main interface off that untagged EFP.

(unusual design/case though).

xander

New Member

i am having below config:

EFP1

Int e1.1
Encap dot1q 10-200

EFP2
Int e2.2
Encap dot1q 10-200

EFP3
Int e10.10
Encap dot1q 20

L2VPN configuration
l2vpn bridge-domain foo
Int e1.1
Int e2.2
Int e10.10

1. Then when a packet comes from int e10.10 and gets flooded... Where should this packet go to?

2. How does it work when apply the filter ?

Cisco Employee

to prevent any unexpected behaviour you should use explicit encapsulation on attachment circuits and rewrite the tag on ingress. That way you will ensure that all devices in the bridge domain can communicate with each other (which you would expect to happen in a bridge domain). With or without the filter the communication between devices that use different encapsulation will be broken in your example.

hope this helps,

/Aleksandar

New Member

hi Aleksandar, thanks for reply.

we are having too many VLANs ( around 1k) to move to per vlan per bridge domain :(

BTW, if frame from vlan 20 is flood to vlan 10, what vlan does the frame retain ? vlan 10 or vlan 20 or both or untags ?

Cisco Employee

hi ty, you would see the situation from a main interface level. in your original EFP example, when EFP 1, Ethernet1 receives a vlan 20, it will MATCH the efp1 e1.1 interface (for stats and service application), which means based on the BD config it will go out as vlan 20 on E2 and E10. Accounted for on E2.2 and E10.10.

Now when there is a vlan 10, it matches e1.1, gets sent with vlan 10 out of e2 and accounted for on e2.2 and will get out e10 also, accounted for on the main interface.

So E10 will see a vlan 10 packet on the wire.

this is what ether filter strict will prevent since you dont have an explicit config covering a vlan 10 on e10.

xander

EFP1

Int e1.1

Encap dot1q 10-200

EFP2

Int e2.2

Encap dot1q 10-200

EFP3

Int e10.10

Encap dot1q 20

Cisco Employee

without explicitly configured tag rewrite, we don't change the dot1q tag on the frame. So if a frame with dot1q tag 10 is received on your EFP1, it should be sent out of int e2 and e10 with dot1q encap 10.

If you don't have a BVI in the bridge domain, you don't really need a rewrite.

Also, if all VLANs on a given physical interface are in the same bridge domain, you can configure the physical interface as l2transport, instead of creating sub-interfaces with VLAN range.

New Member

Hi all, thanks for reply.

So, it is a good practice to explicitly apply "Ether filter strict" on all EFPs ?

If i apply the filter to one EFP or many EFPs, any performance different ? 

It is the same concept for IOS-XE like ASR920 ?

Cisco Employee

ideally you would have a BD per vlan. but if that is not possibly and you have overlapping vlan ranges on different trunk interfaces and you'd want to filter 'pruned' vlans from certain main interfaces when not configured, then use the filter strict.

xander

New Member

Hi Xander,

"Pruned VLAN"  is (1) to manually filter VLAN per trunk or (2) using any pruned protocol like VTP ?

Regards,