In this article we'll be discussing the EVC (Ethernet Virtual Circuit) infrastructure that the ASR9000 and IOS-XR use to define L2 services.
You'll find in this article how packets coming in on an interface are being matched against an EFP (Ethernet Flow Point), how to manipulate the vlan tags and use them in XCONNECT (VPWS) or Bridging (eg VPLS) scenarios with the optional L3 endpoint to provide IRB (Integrated Route Bridging)
The way that IOS-XR handles EVC's is a bit different then the way that IOS handles it when for instance using the 7600.
When starting with IOS-XR and the ASR9000 there are a few things that you will want to be aware of when defining L2 services.
A couple of the key differences are:
- XR does have the concept of a trunk interface
- therefore XR cannot do vlan pruning
- XR does not strip vlan tags by default.
- XR does not have the concept of an "interface VLAN" a.k.a. SVI's (Switch Virtual Interface), instead it uses a BVI (Bridge Virtual Interface) that can be inserted into the bridge-domain.
Flexible VLAN matching
How the ASR9000 matches traffic to an EFP
how to modify the vlan headers and how that works
Defining L2 services
and a comparison with IOS
Providing L3 services in L2VPN
using IRB/BVI interfaces
In order to define an L2 service, we need to match traffic to a particular interface. In IOS-XR and the ASR9000 we use the Ethernet Flow Point (EFP) to match this traffic. An EFP is effectively a subinterface of a physical interface with the keyword "l2transport" attached to it. This l2transport defines that we are going to use this (sub) interface for L2 Services. We can match L2 and L3 interfaces on a single physical port:
Flexible VLAN matching
When traffic is coming in on a port, we use the TCAM to find out which particular subinterface this traffic matches on. With that in mind there are a couple of rules as to how traffic is matched.
defaultPackets unmatched by other service instances
If a particular packet is not matching any other specific EFP on this physical port, this "Default" will capture all unmatched traffic.
dot1ad IEEE 802.1ad VLAN-tagged packets
dot1q IEEE 802.1Q VLAN-tagged packets
untagged Packets with no explicit VLAN tag
If there is no vlan tag on the packet, the "untagged" EFP will capture this traffic, this is effectively plain ethernet and useful for instance to capture
BPDU's for instance.
When we are going to match on say dot1q encapsulated traffic we have a variaty of how we can match vlan tagged traffic (see also foot note below in the "Related Information" section on the ethertypes used).
RP/0/RSP1/CPU0:A9K-BOTTOM(config-subif)#encapsulation dot1q ? <1-4094> Start of VLAN range <1-4094> Single VLAN id any Match any VLAN id priority-tagged IEEE 802.1ad priority-tagged packets
At the first level of dot1q classification we can select a vlan, vlan-range or any. These are obvious. The option "Priority tagged" allows us to capture vlan encapped traffic that is with a vlan id of 0.
RP/0/RSP1/CPU0:A9K-BOTTOM(config-subif)#encapsulation dot1q 100 ? comma comma exact Do not allow further inner tags ingress Perform MAC-based matching second-dot1q IEEE 802.1Q VLAN-tagged packets
Here is an important concept that is to be highlighted. You see the "word" exact" here. What that means is, in the absence of the keyword exact, if the outter vlan header is "100" in this example, this EFP is matched. so that means that also qinq frames that are of the 100 outter and 200 inner kind (if there is no specific EFP for the qiq combo 100/200 available) will match this EFP.
Just a few examples:
encapsulation dot1q 100: will match any number of vlan headers as long as the outter vlan id is 100
encapsulation dot1q 100 second any: will match any qiq frame where the outter vlan is 100
encapsulation dot1q 100 second 200: will match vlan tagged packets whereby the outter is 100, the inner is 200 and also a potential vlan combo of 100/200/300
encapsulation dot1q 100 second 200 exact: will match vlan tagged packets whereby the outter is 100, the inner is 200 and no other vlan tags are on the packet then these 2 specified.
Normally "longest match" will win, or better put, the most specific match will win.
ASR9000 doesn't support best match for VLAN ranges, but we do support best match if the "any" keyword is used.
So the configuration :
EFP 1 VLAN: S-VLAN=1000, C-VLAN_range=1-4095
EFP 2 VLAN= S-VLAN=1000, C-VLAN=2000
isn't allowed because the more specific C-vlan is part of the range. The parser will reject this config upon commit.
The following options A and B, achieving the same, are allowed :
RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag ? pop Remove one or more tags push Push one or more tags translate Replace tags with other tags
RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag pop ? 1 Remove outer tag only 2 Remove two outermost tags
RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag push ? dot1ad Push a Dot1ad tag (ethertype 88a8) dot1q Push a Dot1Q tag (ethertype 8100 by default, or 9100/9200 is specied on the main interface for the outter most tag)
RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag push dot1q 100 ? second-dot1q Push another Dot1Q tag symmetric All rewrites must be symmetric
RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag translate ? 1-to-1 Replace the outermost tag with another tag 1-to-2 Replace the outermost tag with two tags 2-to-1 Replace the outermost two tags with one tag 2-to-2 Replace the outermost two tags with two other tags
If you want to make a cross connect or bridge between two EFP's where one EFP is vlan 100 and the other EFP is vlan 200,
you need to make sure you pop the tags so that the vlan 100 is removed from the packet so it, by means of symmetry, will get vlan 200 on the egress
of the other EFP.
L2VPN configuration examples and comparison to 7600
The following picture highlights how to create L2 services on the ASR9000.
To provide L3 services in a bridge-domain, you can add a routed interface to the bridge domain.
What is important here is that the BVI is not vlan tagged. So in order for the EFP's to talk to the BVI, we need to pop ALL Tags on ingress!!
This means that frames with more then 2 tags cannot be natively using the BVI, unless we do some workarounds such as loopback cables to
! when creating the bvi verify the show int bvi to see if the mac address is correctly programmed, these macs are coming from the backplane mac table, ! if we ran out because of so many bundle interfaces etc, you may need to provide a mac manually.