Evc Mpls Config

Postings may contain unverified user-created content and change frequently. The content is provided as-is andis not warrantied by Cisco.

1

Understanding Ethernet Virtual Circuits (EVC)

The ProblemOn traditional switches whenever we have a trunk interface we use the VLAN tag todemultiplex the VLANs. The switch needs to determine which MAC Address table to look infor 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 4096VLANs. Furthermore switches have a finite amount of CAM space for MAC Learning limitingthe number of hosts we can support.

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

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



2

How It Works (Ingress)As an 802.1q tagged frame enters an interface that has been configured with an EVC wewill determine which EVC it is classified into based on the tags on the frame. Within theEVC we define what action we wish to do with that frame. Let's take a look at a sample EVCconfiguration.

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 192.168.1.1 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 interfaceshould, however we will not actually pass any VLANs through this interface. VLAN tagsreceived on Service Instance interfaces have no direct relationship to VLANs configured onthe switch. Furthermore Service Instance interfaces do not do any MAC learning (exceptthrough a bridge-domain VLAN interface, which is discussed later). Because of this we donot want to allow any globally configured VLANs across this trunk interface. We only needto enable VLAN tag processing and let the Service Instance figure out what to do with theframe.



3


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


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


Since the incoming tag no longer has any inherent meaning beyond this specific interfacewe need a way to discard that tag before forwarding the frame on. The rewrite ingresscommand does just that. In this case we will remove exactly 1 tag, This command is optionaland 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 andthe "symmetric" keyword a little later.

Finally, what is our forwarding action with that frame?


This tells us that the frame should be sent across the L2VPN MPLS cloud. Since before thiswe configure the rewrite ingress tag pop 1 symmetric command we will send a frame with no



4

VLAN Tags across the MPLS pseudowire. There are a multiple possible forwarding actionsincluding 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 onhow it arrived on this switch in the first place. For example if the frame is received acrossMPLS 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 rewriteingress tag pop 1 symmetric. Since we popped 1 tag ingress, to be symmetric we need topush 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 theframe egresses the interface impose VLAN Tag of 10. Keep in mind that the access layerdevice that is sending us tagged frames is most likely a traditional Layer-2 switch and needsthe tag it sends to be the same tag it receives for proper classification.

Step-by-Step ExampleHere's a sample topology, with two access switches processing different VLANs. Theservice instance configurations are on PE Blue and PE Purple.

https://supportforums.cisco.com/servlet/JiveServlet/showImage/68865/Flow+Direction.png



5

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

https://supportforums.cisco.com/servlet/JiveServlet/showImage/68873/Example+Configuration.png



6

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

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

https://supportforums.cisco.com/servlet/JiveServlet/showImage/68875/Frame+Example+1.png



7

As the labeled packet leaves the MPLS cloud we place the untagged frame into PE Red'sservice instance 18, based on the "xconnect" command. From there since the "rewriteingress pop 1 symmetric" command is configured and this is an egress frame we know weneed 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 accesslayer switch.

EVC Options

Flexible Matching

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

https://supportforums.cisco.com/servlet/JiveServlet/showImage/68881/Frame+Example+2.png



8

Configuration Effect

encapsulation dot1q 10 Match 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 22 Match 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 untagged Match the native (untagged) VLAN

encapsulation dot1q default The catch all class for all traffic not previously classified

The options here are not exhaustive but just some examples. The other thing to rememberabout 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.

Configuration Effect

rewrite ingress tag pop 1 symmetric remove the top 802.1q tag

rewrite ingress tag pop 2 symmetric remove the top two 802.1q tags

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

remove the top tag and replace it with 28

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

remove the top two tags and replace them with 22 and23 (23 will be the inner tag)

rewrite ingress tag push dot1q 56 second-dot1q 55 push two new tags on top of the existing frame. The toptag 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 MPLScloud.



9

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

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

interface g0/2



rewrite ingres tag pop 1 symmetric

bridge-domain 44

!

interface Vlan44

ip address 192.168.1.1 255.255.255.0

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

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

interface g0/2




10



bridge-domain 44




bridge-domain 44

!

interface Vlan44

ip address 192.168.1.1 255.255.255.0

This configuration will allow either the service instances to speak between one anotheror out to other routed subnets. More broadly, Vlan 44 will bridge together the two serviceinstances and forward frames based on MAC learning. As a frame enters Service Instance1, the VLAN tag will be removed, the frame will be passed to Vlan 44 where the destinationMAC will be looked up. If the destination is out the other Service Instance, the frame will beplaced 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 bridgedomain.

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

interface g0/2




11



bridge-domain 44 split-horizon




bridge-domain 44 split-horizon

!

interface Vlan44


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 bothservice instances and send them both over the single xconnect, but we prevent traffic onservice instance 2 from being sent to service instance 1.

Final ThoughtsSince the way EVCs work is so different from traditional switching not all switching platformsare 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 thiskind of capability in mind. The 7600 platform requires newer Ethernet Services (ES) modulesto 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 merelyto demonstrate some deployment options and how traffic forwarding operates in these newEVC environments.

http://www.cisco.com/en/US/products/ps10956/index.html

http://www.cisco.com/en/US/products/ps10965/index.html

http://www.cisco.com/en/US/prod/collateral/routers/ps368/data_sheet_c78-570730.html

Documents

Evc Mpls Config