Understanding Ethernet Virtual Circuits (EVC)


May 12, 2015 4:32 AM
Dec 10th, 2011

The Problem

On traditional switches whenever we have a trunk interface we use the VLAN tag to demultiplex the VLANs. The switch needs to determine which MAC Address table to look in for a forwarding decision. To do this we require the switch to do two things:

1.) Have the VLAN configured globally

2.) Perform MAC learning in this VLAN

The challenge with this is that it requires us to use finite resources, perhaps without reason. Since the 802.1q VLAN tag is only 12-bits wide we can only configure a maximum of 4096 VLANs. Furthermore switches have a finite amount of CAM space for MAC Learning limiting the number of hosts we can support. 

In modern provider and cloud environments there is a need to scale beyond these limitations.

Enter EVCs

Ethernet Virtual Circuits (EVCs) allow us to leverage existing 802.1q VLAN tags in a brand new way. Traditionally the VLAN tag defined both classification (which VLAN) and forwarding (which CAM table to do a MAC lookup in). Now, with EVCs we can separate these concepts; the VLAN tag is used for classification and the Service Instance defines the forwarding action. For example we could allocate VLAN 10 to different customers on every switchport and forward each customer's traffic across different MPLS Pseudowires, but never actually configure VLAN 10 globally!

How It Works (Ingress)

As an 802.1q tagged frame enters an interface that has been configured with an EVC we will determine which EVC it is classified into based on the tags on the frame. Within the EVC we define what action we wish to do with that frame. Let's take a look at a sample EVC configuration.

interface GigabitEthernet0/2

switchport trunk allowed vlan none 

switchport mode trunk

service instance 6 ethernet

  encapsulation dot1q 10

  rewrite ingress tag pop 1 symmetric

  xconnect 33 encapsulation mpls

Now, let's break down each piece of this configuration. 

switchport trunk allowed vlan none 

switchport mode trunk

These lines tell the interface that we need to process 802.1q tags as a trunk interface should, however we will not actually pass any VLANs through this interface. VLAN tags received on Service Instance interfaces have no direct relationship to VLANs configured on the switch. Furthermore Service Instance interfaces do not do any MAC learning (except through a bridge-domain VLAN interface, which is discussed later). Because of this we do not want to allow any globally configured VLANs across this trunk interface. We only need to enable VLAN tag processing and let the Service Instance figure out what to do with the frame.

service instance 6 ethernet

This defines the service instance. The number is arbitrary; it has nothing to do with the VLANs that will be processed by this particular Service Instance The "ethernet" keyword is always used.

encapsulation dot1q 10

This is how we map an incoming tag to a service instance. If VLAN tag 10 is received on this interface it will be put into service instance 6.

rewrite ingress tag pop 1 symmetric

Since the incoming tag no longer has any inherent meaning beyond this specific interface we need a way to discard that tag before forwarding the frame on. The rewrite ingress command does just that. In this case we will remove exactly 1 tag, This command is optional and there are a number options that can be done beyond simply removing the tag including, VLAN translation and imposing additional tags. We will discuss some of these options and the "symmetric" keyword a little later.

Finally, what is our forwarding action with that frame?

xconnect 33 encapsulation mpls

This tells us that the frame should be sent across the L2VPN MPLS cloud. Since before this we configure the rewrite ingress tag pop 1 symmetric command we will send a frame with no VLAN Tags across the MPLS pseudowire. There are a multiple possible forwarding actions including routing and local switching (connect)

How It Works (Egress)

As a frame is received it will be classified to go out the Service Instance interface based on how it arrived on this switch in the first place. For example if the frame is received across MPLS pseudowire 33, we automatically know it is part of service instance 6

Continuing to work bottom up in the configuration we come to the symmetric part of rewrite ingress tag pop 1 symmetric. Since we popped 1 tag ingress, to be symmetric we need to push 1 tag egress. The symmetric keyword will always be used with the rewrite command.

We determine which tag to impose based on the encapsulation dot1q 10 command. As the frame egresses the interface impose VLAN Tag of 10. Keep in mind that the access layer device that is sending us tagged frames is most likely a traditional Layer-2 switch and needs the tag it sends to be the same tag it receives for proper classification.


Flow Direction.png


Step-by-Step Example

Here's a sample topology, with two access switches processing different VLANs. The service instance configurations are on PE Blue and PE Purple.


Example Configuration.png

So a few things to note here:

  • The access layer switches are sending and expecting different VLAN tags.
  • The service instance numbers are arbitrary
  • The VLAN tag will be popped before being sent into the MPLS cloud

Frame Example 1.png

A client connect to the access port will send an untagged frame. This frame will be have VLAN tag 10 added to it by the access layer switch and sent to the PE with the service instance configuration.

The Blue PE will see VLAN tag 10 and place it into service instance 9. Since we have configured the 'rewrite ingress pop 1 symmetric' command, we will pop the first tag before applying an MPLS label and forwarding into the MPLS cloud.

Frame Example 2.png


As the labeled packet leaves the MPLS cloud we place the untagged frame into PE Red's service instance 18, based on the "xconnect" command. From there since the "rewrite ingress pop 1 symmetric" command is configured and this is an egress frame we know we need to impose one. The tag imposed is based on the "encapsulation dot1q" configuration, so in this case, VLAN tag 11 is imposed on the frame before sending back out to the access layer switch.

EVC Options

Flexible Matching

One of the things that make EVCs so powerful is their flexible matching criteria. EVCs allow us to classify inbound frames in a highly flexible manner based on 1 or more VLAN tags or CoS values. Here are some examples


encapsulation dot1q 10Match the single VLAN tag 10

encapsulation dot1q 25 second-dot1q 13

Match first VLAN tag 25 and second tag 13
encapsulation dot1q any second-dot1q 22Match any double tagged frame with a second tag of 22

encapsulation dot1q 16 cos 4

Match a single tag 16 when it has CoS value 4
encapsulation dot1q untaggedMatch the native (untagged) VLAN
encapsulation dot1q defaultThe catch all class for all traffic not previously classified


The options here are not exhaustive but just some examples. The other thing to remember about tag matching is that we follow a longest match criteria.


Rewrite Options

Along with a number of flexible matching options we have numerous tag rewrite options.


rewrite ingress tag pop 1 symmetricremove the top 802.1q tag
rewrite ingress tag pop 2 symmetricremove the top two 802.1q tags

rewrite ingress tag translate 1-to-1 dot1q  28 symmetric

remove the top tag and replace it with 28

rewrite ingress tag translate 2-to-2 dot1 22 second-dot1q 23

remove the top two tags and replace them with 22 and 23 (23 will be the inner tag)
rewrite ingress tag push dot1q 56 second-dot1q 55push two new tags on top of the existing frame. The top tag will be 56; inner tag of 55


Forwarding Options

An EVC can be attached to an MPLS xconnect and we can send the traffic across an MPLS cloud.

For more flexibility EVCs introduce the concept of the Bridge Domain. A Bridge Domain is what is traditionally thought of as a Layer 3 SVI. Unlike the VLAN tags that are being processed by the configured EVCs bridge-domains do require the VLAN to be configured globally on the device and use platform wide resources. 

Here is an example of an interface configured with a bridge-domain: 

interface g0/2

  service instance 1 ethernet

    encapsulation dot1q 18

    rewrite ingres tag pop 1 symmetric

    bridge-domain 44


interface Vlan44

  ip address


The packet, without VLAN tags, will be passed to the VLAN44 interface for normal routing to occur.

We can also tie multiple service instances to the same bridge-domain to make forwarding tagged traffic highly flexible.


interface g0/2

  service instance 1 ethernet

    encapsulation dot1q 18

    rewrite ingres tag pop 1 symmetric

    bridge-domain 44

  service instance 2 ethernet

    encapsulation dot1q 66

    rewrite ingress tag pop 1 symmetric

   bridge-domain 44


interface Vlan44

  ip address


This configuration will allow either the service instances to speak between one another or out to other routed subnets. More broadly, Vlan 44 will bridge together the two service instances and forward frames based on MAC learning. As a frame enters Service Instance 1, the VLAN tag will be removed, the frame will be passed to Vlan 44 where the destination MAC will be looked up. If the destination is out the other Service Instance, the frame will be placed on Service Instance 2 and a new VLAN tag will be added. 

Bridge domains also allow for the configuration of a "split-horizon" (bridge-domain 44 split-horizon) to prevent inter-EVC communication, only allowing for routing outside of the bridge domain.

Finally, we can take multiple EVCs, and send all of them over an MPLS Pseudowire

interface g0/2

  service instance 1 ethernet

    encapsulation dot1q 18

    rewrite ingres tag pop 1 symmetric

    bridge-domain 44 split-horizon

  service instance 2 ethernet

    encapsulation dot1q 66

    rewrite ingress tag pop 1 symmetric

    bridge-domain 44 split-horizon


interface Vlan44

  xconnect 55 encapsulation mpls


This will allow us to take two different VLANs and send them to the same MPLS endpoint, removing the VLAN tags in the process. In this scenario we will learn MAC address on both service instances and send them both over the single xconnect, but we prevent traffic on service instance 2 from being sent to service instance 1.

Final Thoughts

Since the way EVCs work is so different from traditional switching not all switching platforms are capable of doing the EVC frame manipulation independently of the forwarding action. Newer platforms like the me3600x or me3800x were designed from the ground up with this kind of capability in mind. The 7600 platform requires newer Ethernet Services (ES) modules to do the additional work that the Supervisor and DFC forwarding engines are unable to do. This guide is also not an exhaustive list of supported platforms or configurations, but merely to demonstrate some deployment options and how traffic forwarding operates in these new EVC environments.

Overall Rating: 5 (25 ratings)
rsimoni Mon, 12/26/2011 - 10:18

great doc!

Sudeep Valengattil Sat, 01/07/2012 - 01:58

Gr8t  doc.. like the way you explained...Thanks Alfred!!

rgatti Thu, 01/12/2012 - 06:56

This is a really good document. Added to my bookmark.

Thanks Pete!!

vkommine Wed, 02/08/2012 - 02:10

Very good explanation about EVC. Thanks for such a good document.

Stephane Bonnet Sun, 02/26/2012 - 06:32

Good explanation, EVC rocks !

morawat Sun, 03/18/2012 - 11:57

Awesome Doc !!!!!

fred_shao Thu, 06/21/2012 - 22:13

Great article with clarity and simplicity!

agalleni Wed, 08/29/2012 - 01:24

Crystal clear!

ovirk Sat, 09/29/2012 - 22:33


Great doc which can help you understand EVC concept in 15-20 minute.

Thanks a lot Alfred

rajs2 Thu, 10/11/2012 - 20:12

Great Doc. Explained in simple way

sumit_kalawatia Fri, 12/07/2012 - 08:48

Excellent doc. Thanks Alfred.

shreerampardhy Wed, 12/26/2012 - 19:25

Hello Alfred,

One question - in teh last secniaro that you have mentioned two service instances on teh same interface. The BVI that is configured is same for both the Service instances and the xconnect command is now configured under the BVI interface.

I am trying to understand how the packets are decapsulated at teh remote egress end. Lets say that the packet is receviced at the ingress box on service instance 1 with vlan tag of 18.This will get encapsulated in pseudowire ( after removing the vlan tag ) and sent to the remote end. At teh remote end there will be a linking of the BVI with the two Service instances ( considering that we have exact same configuration at the remote end ). How will the remote end ( egress router ) understand which Service instance should the packet be sent out.

From what I undertand, the Service instance is going to define your encapsulation vlan id.



plumbis Wed, 12/26/2012 - 19:53


The other part that is missing in your example is mac learning. When we tie the EVC to a bridge domain we make it multipoint and we must do mac learning in that bridge-domain. We would have a mac address pointing out one of the service instances. If you were to issue show mac address-table vlan 44 (where 44 is the bridge-domain) you would see MACs learned from the service instance.

shreerampardhy Thu, 12/27/2012 - 03:06

Hello Alfred,

Thank you very much for the explaination. Another thing, when we have Broadcast, Multicast, Unknown Unicast packets comming at the egress, how does the mapping happen in that case? Will the egress router send it to both the Service instances? Usually for the PBB solution, there is a particular destination Mac address ( combination of the OUI and ISID ) that is used which restricts the boundary of such frames? Is there anything similar here?



plumbis Thu, 12/27/2012 - 06:09

I think the PBB case is handled a little differently since it is about massive L2 scalability. In this case, when tied to a bridge domain we can't violate the traditional rules of bridging and still use a flooding behavior.

Sherif Atef Ahm... Tue, 01/08/2013 - 17:32

Hello Alfred
Excellent document .. Many Thanks

I have a question please. For below config you mentioned in BVI example

Kindly confirm my understanding

For ingress direction, packets will arrive to interface with vlan ID 18, then this tag will be popped and will go to SVI 44 so packets can be routed/switched normally with vlan ID 44

For egree direction, reverse will happen. Packets will come with vlan ID 44 and if it will be switched to service instance 1 (according to mac-learning) vlan ID 44 will be removed and vlan ID 18 will be added

Am I correct ?

interface g0/2

  service instance 1 ethernet

    encapsulation dot1q 18

    rewrite ingres tag pop 1 symmetric

    bridge-domain 44


interface Vlan44

  ip address

Sherif Ismail
plumbis Tue, 01/08/2013 - 18:20

Sherif, you are exactly right. The CAM table will say that the destination mac is out g0/2, service instance 1. Any frame that egresses g0/2, service instance 1 MUST have dot1q tag 18 imposed on to it.

Sherif Atef Ahm... Wed, 01/09/2013 - 04:33

Great .. Many Thanks

Ryota Takao Mon, 01/14/2013 - 22:56

This is a really good document, and very helpful.

cnliuwz Thu, 01/24/2013 - 06:57


bhavesh262584 Tue, 03/05/2013 - 03:09

Excellent Document!!!!!

I was in search of such document which explains the EVCs properly.

Many Thanks

jayant5805 Wed, 07/10/2013 - 06:58

can u plz tell the source of document i would like to read such good books in depth

Nicolas Blancpain Sat, 11/02/2013 - 01:55

Great doc !

Is this feature supported by ASRs ?

Sherif Atef Ahm... Sun, 11/03/2013 - 17:20

Hi Alfred

First I would like to thank you for continous support
I have few questions please regarding EVC .. So as not to enlarge comment section I have posted them in a different post



Appreicate please If you can assist

Many Thanks

jvinu2000 Tue, 01/28/2014 - 08:28

great post, very useful

could somebody help me? I'm trying to conect C1 to C3 and C2 to C3 with the same vlan:



Rob Ahad Tue, 03/25/2014 - 02:17

Thank you for the  crystal clear explanation.

shekchau Fri, 09/12/2014 - 13:41


sukhjit.hayre Tue, 05/20/2014 - 10:32

In your first example, how would you re-write dot1q vlan 10 to dotq1 vlan 11 at the other CE side, this won't work as you have spanning-tree bpdu's propergating on the trunk (pvst out of the box) and it will go into a blocking inconsistent state due to a vlan miss-match at both ends i.e at the end of the CE trunks even if it permits all vlans it will receive vlan x bpdu when it's not in an stp forwarding state for vlan x and go blocking, let me know what im missing ;0)

plumbis Sat, 05/24/2014 - 12:57

Sukhjit, you are correct there would be STP concerns. If VLAN translation was done then there would be a need for STP isolation as well.

Asif Maqbool Fri, 10/24/2014 - 22:14

Hello Pumbis,

this is great Document, as you know that we can create 8000 service instance on one router interface, so do you have idea that what is the benefit of this if we have only can create 4094 802.1q encapsulation.


Thanks and Regards,

BoydOgonda Wed, 06/25/2014 - 06:24

Good clear explanation,,, thanks

Angelayan_2 Wed, 08/20/2014 - 10:20

appreciate this post. Helps a lot. It could be better if we could have more thorough and detailed documentation for desiging purpose. 

Jagjit Brar Sun, 11/09/2014 - 21:43

Great doc

Richard Clayton Thu, 12/11/2014 - 01:52

Brilliant explanation, saved me hours of trawling through Cisco docs, Cisco should create easy to digest articles like this for all of their features to compliment their standard offering.

Ugur Ersoy Wed, 04/29/2015 - 05:06

Great explanation. I appreciate.

Odetayo Adelabu Tue, 05/12/2015 - 04:32

Wonderfully precise explanation. By the beginning of the second paragraph I already have a good idea of what is being explained. Thumbs Up


Login or Register to take actions

This Document

Posted December 10, 2011 at 7:47 AM
Updated December 30, 2014 at 11:30 PM
Comments:37 Overall Rating:5
Views:286377 Contributors:30

Related Content