EVC : Flexible Service Mapping

After 2 months of intense network re-designing (mixed with a little bit of vacation days) and following my two previous posts about Flexible Frame Matching and Flexible VLAN Tag Rewrite, i finally found some free time to write a post about the third step in configuring service instances using the EVC framework : Flexible Service Mapping.

Probably the biggest advantage of the EVC framework is the ability to support multiple services per physical port. This means that under a single physical port you can have any of the following mixed together :

- 802.1q trunk
- 802.1q tunnel
- Local connect
- Scalable EoMPLS (EoMPLS xconnect)
- Multipoint Bridging (L2 bridging)
- Multipoint Bridging (VPLS, SVI-based EoMPLS)
- L3 termination

Besides all of the above, by using the EVC framework you can combine multiple different services from different physical ports, i.e. when using multipoint bridging (aka bridge-domains), in order to put them into the same virtual circuit.



Local connect is a L2 point-to-point service between two service instances on the same system. The service instances can by under the same port (hair-pinning) or under different ports. In contrast with the traditional L2 bridging, this one doesn't use any MAC learning and it's solely between 2 points. Also Local Connect doesn't require any global VLAN resource.

In order to have the following two service instances connect to each other by a L2 point-to-point service, you need first to remove their difference, which is the outer tag (you can also remove both tags).

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10 second-dot1q 100
  rewrite ingress tag pop 1 symmetric

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20 second-dot1q 100
  rewrite ingress tag pop 1 symmetric

! EVC-LC-10-20 is just a name for this point-to-point connection
connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

Note : You can use the same service instance number under different physical ports.

In order to have the following two service instances be connected by Local Connect, you don't need any VLAN tag rewrite, because they both have the same vlans.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 10-20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

In order to have the following two service instances be connected by Local Connect, you can either translate the vlan on one of them, or remove the tags on both of them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20

connect EVC-LC-10-20 Gi1/1 10 Gi1/2 20

Scalable EoMPLS or EoMPLS xconnect is a L2 point-to-point service between two service instances on different systems. Like Local Connect it doesn't use any MAC learning and it's solely between 2 points. It also doesn't require any global VLAN resource (this applies to scalable EoMPLS only; for SVI-based EoMPLS check VPLS below).

You can have any VLAN tag rewrite configuration under the service instances, as long as you keep in mind the following :

a) If both sides are EVC based, then you need to have common VLAN tag rewrite configurations on both sides
b) If one side is not EVC based, then depending on whether it's a physical interface or a subinterface, you'll probably need to remove one tag from the EVC side (subinterfaces remove tags by default)

Note : By default, VC type 5 is used for EoMPLS. In case VC type 4 is negotiated and used, an additional tag will be added after the VLAN tag rewrite configuration and before the data gets EoMPLS encapsulated.

7600-1

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.2 10 encapsulation mpls

7600-2

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  xconnect 1.1.1.1 10 encapsulation mpls

Note : Have a look at Scalable EoMPLS for additional information.

Multipoint Bridging uses the concept of bridge-domains. Bridge-domain (BD) is like a traditional L2 broadcast domain where MAC-based forwarding is used for communication between participants (i'll try to write a new post with more details about bridge-domains). Bridge-domains use global VLAN resources.

In the following example, three service instances are put into the same bridge-domain by translating the tags where necessary.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
  bridge-domain 20

interface Gi1/2
 service instance 20 ethernet
  encapsulation dot1q 20
  bridge-domain 20

interface Gi1/3
 service instance 30 ethernet
  encapsulation dot1q 30
  rewrite ingress tag translate 1-to-1 dot1q 20 symmetric
  bridge-domain 20

The bridge-domain ID represents the global VLAN used in the system. Extra care needs to taken in case of L2 trunk/tunnel ports participating in a bridge-domain :

a) L2 trunk ports remove automatically the tag on ingress and add it automatically on egress. Equivalent EVC ports need that to be done manually by using the appropriate rewrite actions.
b) L2 tunnel ports add a new tag on ingress and remove it on egress. Equivalent EVC ports do not need any similar rewrite actions, because by default bridge-domains add a new tag on top of the already existing one.

In the following example two ports (a L2 trunk port and an EVC port) are put into the same bridge-domain (Vlan 20). Tag 10 needs to be removed from the EVC port before it joins bridge-domain 20.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 20

interface Gi2/1
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 20
 switchport mode trunk

In the following example two ports (a L2 tunnel port and an EVC port) are put into the same bridge-domain (Vlan 20). On the EVC port, tag 20 is added on top of tag 10 in order to have the incoming frames join bridge-domain 20.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  bridge-domain 20

interface Gi2/1
 switchport access vlan 20
 switchport mode dot1q-tunnel

VPLS or SVI-based EoMPLS can be accomplished by configuring xconnect under a SVI. This SVI is the same as the one defined by the bridge-domain ID.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

By adding "split-horizon" after the bridge-domain ID in both service instances, there can be no L2 communication between them.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

By adding an additional tag through a rewrite action in both service instances, you can differentiate them, while they are being transfered through the same VC.

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 21 symmetric
  bridge-domain 30 split-horizon

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 10-20
  rewrite ingress tag push dot1q 22 symmetric
  bridge-domain 30 split-horizon

interface Vlan 30
  xconnect 1.1.1.2 10 encapsulation mpls

SVI-based EoMPLS can be considered like a VPLS, where there is only one VC pointing to one neighbor.

Note : Have a look at SVI-based EoMPLS for additional information.

For L3 termination you have the usual two options : use subinterfaces or use bridge-domains (just like switchports) and SVIs. ES/ES+ and SIP-400 cards support termination of double-tagged traffic too.

Keep in mind the following :

a) you must remove all tags before terminating L3 traffic
b) you must use matching rules based on unique single or double tags (no vlan ranges are supported, although they might be accepted)

This is an example using a bridge-domain and the equivalent SVI:

interface Gi1/1
 service instance 10 ethernet
  encapsulation dot1q 10
  rewrite ingress tag pop 1 symmetric
  bridge-domain 40

interface Gi1/2
 service instance 10 ethernet
  encapsulation dot1q 20 second-dot1q 30
  rewrite ingress tag pop 2 symmetric
  bridge-domain 40

interface Vlan 40
  ip address 1.1.1.1 255.255.255.0

This is an example using subinterfaces:

interface Gi1/1.10
 encapsulation dot1q 10
 ip address 1.1.1.1 255.255.255.0

interface Gi1/1.20
 encapsulation dot1q 20 second-dot1q 30
 ip address 1.1.1.1 255.255.255.0

Note : ES cards have a major limitation : single-tagged vlans configured under a subinterface are global significant. On the other hand, double-tagged vlans are local significant. On the ES+ and SIP-400 cards, both single-tagged and double-tagged vlans are local significant.