cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8046
Views
4
Helpful
24
Comments
xthuijs
Cisco Employee
Cisco Employee

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

Comments

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

xthuijs
Cisco Employee
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

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

xthuijs
Cisco Employee
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

Adam Vitkovsky
Level 3
Level 3

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

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.

Adam Vitkovsky
Level 3
Level 3

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

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

Adam Vitkovsky
Level 3
Level 3

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

Thank you very much Xander!

Cheers,

Michalis

Adam Vitkovsky
Level 3
Level 3

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

Thank you very much Adam!

Cheers,

Michalis

Leonardo Gama
Level 1
Level 1

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.

xthuijs
Cisco Employee
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

Leonardo Gama
Level 1
Level 1

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Quick Links