cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
86341
Views
40
Helpful
101
Comments
xthuijs
Cisco Employee
Cisco Employee

Introduction

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)

Core Issue

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

TAG rewriting

     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

Resolution

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:

evc-overview.jpg

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.

An EFP is defined as follows:

RP/0/RSP0/CPU0:asr(config)#int gig 0/0/0/4.100 l2transport

RP/0/RSP0/CPU0:asr(config-subif)#encapsulation ?

  default  Packets 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 :

A)

EFP 1) VLAN: S-VLAN=1000, C-VLAN_range=1-1999,2001-4095

EFP 2) VLAN= S-VLAN=1000, C-VLAN=2000

B)

EFP 1) VLAN: S-VLAN=1000, C-VLAN=any

EFP 2) VLAN= S-VLAN=1000, C-VLAN=2000,

VLAN  TAG rewriting

The ASR9000/XR is capable of doing many translations on vlan to a packet.

The behavior is always symmetric (though this keyword is to be provided as part of that config command). The symmetry means that if we pop a tag on ingress, we push it back on egress.

the following rewrites are possible:

RP/0/RSP0/CPU0:A9K(config)#int gig 0/0/0/4.100 l2transport

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.

l2vpn.jpg

l2vpn-7600-9k.jpg

Using IRB/BVI

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

pop more tags.

interface BVI5
ipv4 address 31.1.1.1 255.255.255.0
mac-address 0.4343.3434

! 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.

interface TenGigE0/7/0/3.100 l2transport

encapsulation dot1q 100

rewrite ingress tag pop 1 symmetric

l2vpn

bridge group testing
  bridge-domain testing
   interface TenGigE0/7/0/3.100
   !
   interface GigabitEthernet0/1/0/14
   !
   routed interface BVI5
  !

Related Information

XR MTU calculations

Dot1q, Dot1ad and configuring "dot1q tunneling ethertype on the physical interface:

As per IEEE documentation, Ethertype 8100 is for 802.1q and Ethertype 88A8 is for 802.1ad.
IEEE also calls any kind of double tagging as QinQ, including dot1ad. That means that under IEEE's point of view, dot1ad = qinq.
Cisco, on the other hand, calls qinq a double dot1q, where both Ethertypes (inner and outer) are 8100.
Ethertype 9100 and 9200 were used as an option to differentiate the inner Ethertpe form the outer Ethertype,
but they are obsolete now and the standard became dot1ad (with Ethertype 88A8).
In order to configure ethertype 9100 and 9200 you have to explicitly issue the command dot1q tunneling ethertype 0x9100 or
dot1q tunneling ethertype 0x9200 under the physical interface you are configuring.
Summarizing:
encapsulation dot1q second dot1q                                     -> inner and outer ethertype are 8100
encapsulation dot1ad second dot1q                                   -> inner 8100, outer 88A8
encapsulation dot1q second dot1q (with ethertype 9100)      -> inner 8100, outer 9100
encapsulation dot1q second dot1q (with ethertype 9200)      -> inner 8100, outer 9200




Xander Thuijs, CCIE #6775

Sr. Tech Lead ASR9000

Comments
xthuijs
Cisco Employee
Cisco Employee

hi fredrik,

this was enhanced via CSCun59252   dhcp unicast offer on ambigious vlan request

which is in 513.

the way that the dhcp packets were injected was relying on underlaying socket structures that dhcp used to prebuild the L2 header(s). Now with this enhancement that was rectified and in 513/520 onwards you can use unicast offers on ambigious vlans.

This was specifically for the desing:

With CSCun59252, we have the following config-type working for unicast offer,

 interface Bundle-Ether1.1

   encapsulation ambiguous dot1q 10 , 100 , 1000

The ambigious any you may want to test in 53 and see if that works there now, but this wasnt the implementation intent in 513/520 mentioned.

regards

xander

Hi Xander,

Thanks for the pointer! CSCun59252 seems to only have implemented this for the scenario you described, this does not work with ambiguous outer vlan and second-vlan ANY in 5.2.4 or 5.3.2. I'll open a TAC case about this.

Regards,

FRedrik

xthuijs
Cisco Employee
Cisco Employee

hi frederik,

ok thanks for the verification, I had hoped that some dhcp rework in 53 might have alleviated that restriction, but it looks like it is still the same as earlier. In that case no real need for a tac case to investigate. the "any" piece requires quite a bit of rework on the inject path, so it may not be a quick simple bug fix, but maybe ask TAC to file a ddts so we can track it in our bng dev efforts.

The alternative of explicitly mentioning the vlans for the amb range is not usable for you? (too many, or too much variation in the vlans making this alternative unusable or merely looking for an ease of configuration/use with the any range?).

xander

Hi Xanders,

Yes this is mainly for config and PW scale as we have scenarios with large variations of outer VLAN combinations where it would simplify things greatly to be able to do bind outer VLAN ranges to a single interface. We are doing this today, but then there is the limitation of the second-vlan only being able to be configured as "any" if we use ambiguous VLAN range as outer VLAN.

If we enable broadcast-flag policy check with this configuration, it fails, hence my request.

Also this seems like a somewhat unfinished feature to ship. Makes me wonder if the decision to always broadcast DHCP to clients was taken simply because of the code wasn't there to build egress packets on ambiguous interfaces? :). According to the RFCs this seems to be more of an unwanted workaround that should be avoided if at all possible.

On the config mentioned when using the default broadcasting of DHCP to clients, the correct inner and outer VLAN combo will still be chosen for the broadcasted packet, so all the info exists there.. I can't really see why the feature to send unicast packets the same way wasn't implemented, but I'm no coder either.

Thanks for your reply, will keep you updated on the DDTS if that's the route to take.

Regards,
Fredrik

xthuijs
Cisco Employee
Cisco Employee

Understood thanks for that, and yes keep me updated if there is a ddts filed.

As for the reasons, sometimes there are architectural limitations that require us to take a "shortcut". For instance, at the time that certain services were coded, the ambigious vlan was not in play. That means that certain functions and processes were assuming certain info to be available or structures that they could rely on.

So while I agree that certain limitations are a bit umpf, and one could say that it requires then a rewrite of those functions that can't support that functionality, that comes with a cost too: stability and time. So my philosophy is that I rather provide something that is reasonable, decent and fast(er) and work on eliminating limitations as we go and see if the use of a workaround is acceptable. If not, we can definitely look at working them out!

anyways, little side story there, since you asked :)

cheers!

xander

Julie Tupling
Level 1
Level 1

Xander,

We have a small service provider network and we have a customer that has an external circuit from London that connects their network to ours in NYC. They are currently only using that to extend their network to their equipment at our teleport in Vernon. The traffic is currently untagged.  They also want to extend their network to our location in Brewster... and so they would then configure 2 vlans in their network.  The router in NY is an ASR 9006 and the routers in Vernon and Brewster are ASR 920s. How do we modify the config to allow 2 VLANs in NY and send one VLAN to Brewster and the other to Vernon? The circuit from London is a 50Mb circuit and they want to split the traffic between our 2 locations.

Can we add a service instance for each VLAN from the customer?  Do we have to do subinterfaces? I'm not really fluent in XR and going between XR and XE gets a little confusing.

Current NY config:

interface GigabitEthernet0/1/0/1
  mtu 9000
  speed 100
  l2transport
    l2protocol cpsv tunnel

l2vpn

 bridge group 501
  bridge-domain NSSL-20mb
   mtu 9000
   interface GigabitEthernet0/1/0/1
!
   vfi 501
     neighbor 10.255.255.2 pw-id 501

Current Vernon ASR 920 config 

interface GigabitEthernet0/0/1
  mtu 9000
  no ip address
  negotiation auto
  service instance 501 ethernet
    encapsulation untagged
    bridge-domain 501
!

Thanks for any help you can provide...

Julie

xthuijs
Cisco Employee
Cisco Employee

hi julie, that is not too difficult to achieve.

looks like you're getting vlan 100 and 200 in on 0/1/0/1

and want to separate out these 2 vlans. this is how you do it on the a9k:

Define the 2 "EFP" for the 2 vlans incoming

int g 0/1/0/1.100 l2trans

encap dot1q 100

rewrite ingress tag pop 1 sym

int g 0/1/0/1.200 l2trans

encap dot1q 200

rewrite ingress tag pop 1 sym

Define the exit ports to the 920's:

int g 0/1/0/15.100 l2trans

encap dot1q 100

rewrite ingress tag pop 1 sym

int g 0/1/0/19.2 l2trans

encap dot1q 200

rewrite ingress tag pop 1 sym

Define the 2 bridge domains for the 2 services:

l2vpn

bridge group BLA

bridge-domain vlan200

int g 0/1/0/1.200

int g 0/1/0/19.200

bridge-domain vlan100

int g 0/1/0/15.100

int g 0/1/0/1.100

Since you only have 2 AC's, you could also put them in a xconnect, this doesnt do mac learning and is therefore faster, but doesn't allow you to extend the service beyond 2 ports. BD's will.

Also BD's allow for a BVI insertion in case you want to define an L3 addr into the bridge domain.

Finally in the example I assumed you wanted to "tag" the traffic down the 920's also.

we can leave them untagged as in your earlier design, and just impose the vlan 100 or 200 when it comes into the a9k from the 920 sites to get it ready for transmission out of the 9006 with the right vlan tags over the trunk.

the command for that would be:

rewrite ingress tag push 1 dot1q <vlan> sym

cheers!

xander

Julie Tupling
Level 1
Level 1

Xander,

My drawing was incorrect and I left out an important portion of our network configuration - we are using an MPLS backbone, so although I showed only the single VLAN on the links between the ASR 9006 and the 2 ASR 920s, they are actually MPLS backbone links with multiple VPLS circuits defined for customers.  There are other nodes between NYC & Brewster, but Vernon is directly connected to NYC 

How would we configure this using xconnect instead of VPLS circuits?

Here is the configs for the MPLS backbone ports on the ASR 9006 and ASR 920 routers

NYC ASR 9006

interface GigabitEthernet0/1/0/19
  cdp
  mtu 9216
  ipv4 address 10.1.1.0 255.255.255.254

interface GigabitEthernet0/1/0/15
  cdp
  mtu 9216
  ipv4 address 10.1.1.10 255.255.255.254

mpls ldp
  router-id 10.255.255.1
    interface GigabitEthernet0/1/0/19
    interface GigabitEthernet0/1/1/15

Vernon ASR 920

interface GigabitEthernet0/0/23
  mtu 9216
  ip address 10.1.1.1 255.255.255.254
  no ip redirects
  ip ospf network point-to-point
  ip ospf dead-interval 3
  ip ospf hello-interval 1
  ip ospf mtu-ignore
  carrier-delay msec 0
  negotiation auto
  mpls ip

Brewster ASR 920

interface GigabitEthernet0/0/23
  mtu 9216
  ip address 10.1.1.11 255.255.255.254
  no ip redirects
  ip ospf network point-to-point
  ip ospf dead-interval 3
  ip ospf hello-interval 1
  ip ospf mtu-ignore
  carrier-delay msec 0
  negotiation auto
  mpls ip

Sorry for the omission of important configuration information - it was a long day & I posted my initial post as I was getting ready to leave after a long day and I didn't put enough time into the drawing or the post.

Thanks,

Julie

xthuijs
Cisco Employee
Cisco Employee

in that case on the asr9006 in nyc, you could configure something like this:

the incoming vlans from g0/1/0/1 remains the same, but then the l2vpn config looks like:

l2vpn

xconnect group vl100-200

p2p vl100

int g 0/1/0/1.100

neighbor <ldp id of 920 vernon> pw-id <some pwid eg 100>

p2p vl200

neighbor <lpd if of 920 brewster> pw-id <some pwid eg 200>

this way we tie the vlans incoming to a pw towards the 920's.

xander

Julie Tupling
Level 1
Level 1

Xander,

Thanks for the additional information.  It is different than I thought it would be...  I thought you could configure multiple service instances on the interface without using subinterfaces - but I guess I was wrong.  

How would you configure the xconnect on the ASR 920s?  We've always used VPLS and sometimes going from the ASR 9006 (IOS XR) to ASR 920 (IOS XE) gets a little confusing.

Thanks,

Julie

ty.chan007
Level 1
Level 1

Hi ,

[1]

I am matching traffic as below:

!

interface Bundle-Ether8.1 l2transport

encapsulation dot1q 202-204 , 207 , 209-215 , 217-226 , 228 , 230-242 , 247-251 , 253-255 , 258-270
!

I am facing a problem where i can not use "Comma" more then 8 times or around that number.

Is it a limitation or somehow ?

[2]

If i am using "encapsulation dot1q default" , what could be potential problem that can happen ? my college said it was stable use "default" key word but more stable to specify exact VLAN.

Thanks,

xthuijs
Cisco Employee
Cisco Employee

correct there is a limitation of 8 specific ranges on a single line. it has to do with the tcam key size limitation. so it is not a soft restriction we added just because, but bound to what the tcam can handle/do which we use to match an incoming vlan matching to a specific efp.

using default is perfectly fine, it matches any non specifically matched vlan.

xander

pavchaud
Cisco Employee
Cisco Employee

Hello Xander,

For below configuration if i am using range  with poping tag  , how returned traffic will get tagged ?

means how box will identify which tag to add ?

RP/0/RSP1/CPU0:A9K-BOTTOM(config-subif)#encapsulation dot1q ?
  <1-4094>         Start of VLAN range
 

RP/0/RSP0/CPU0:A9K(config-subif)#rewrite ingress tag pop 1 symmetric

Regards

Pavan

xthuijs
Cisco Employee
Cisco Employee

hi pavan,

if ou have a unique dot1q or qiq combo then you can pop tags, for ambigious vlans / ranges, there is no table taht tracks this mac uses that vlan etc, so poppig tags can only be done for distinct vlans.

regards

xander

m-stawiski
Level 1
Level 1

Hi Xander

I am wondering you can help me with my migration task

I am trying to move config from IOS to ASR and strugle a bit

ISO config looke like bellow

interface GigabitEthernet4/8
description Test
!
interface GigabitEthernet4/8.201
description monitoring
encapsulation dot1Q 1201
ip vrf forwarding monitoring-vrf
ip address 10.10.10.1 255.255.255.252

!
interface GigabitEthernet4/8.202
description mpls
encapsulation dot1Q 202
ip vrf forwarding mpls-vrf
ip address 192.168.253.9 255.255.255.252
!
interface GigabitEthernet4/8.203
description internet feed
encapsulation dot1Q 203
ip address 100.100.100.1 255.255.255.252

so quite standard config - and now tricky part

new link will be presented as L2 subinterface on NNI like bellow

interface TenGigE0/7/0/3.100 l2transport
encapsulation dot1q 100
rewrite ingress tag pop 1 symmetric

I can have multiple BVI

interface BVI201
ipv4 address 10.10.10.1 255.255.255.252
vrf monitoring-vrf

interface BVI202
ipv4 address 192.168.253.9 255.255.255.252
vrf mpls-vrf

interface BVI203
ipv4 address 100.100.100.1 255.255.255.252

but don't know how to bind BVI with specific client vlans

Thx for any help in advance 

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