Service Instance Explained

Ethernet Virtual Circuits (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.

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.

An Ethernet flow point (EFP) service instance is a logical interface that connects a bridge domain to a
physical port or to an EtherChannel. Configuring a service instance on a Layer 2 port creates a
pseudoport or EFP on which you configure EVC features. Each service instance has a unique number
per interface, but you can use the same number on different interfaces because service instances on
different ports are not related.
An EFP classifies frames from the same physical port to one of the multiple service instances associated
with that port, based on user-defined criteria. Each EFP can be associated with different forwarding
actions and behavior.
The three major characteristics (or parameters) of an EFP are
• Encapsulation
• Rewrite Information
• Forwarding instance or method (bridge-domain or xconnect)

An EVC is a conceptual service pipe within the service provider network. A bridge domain is a local broadcast domain that is VLAN-ID-agnostic. An Ethernet flow point (EFP) service instance is a logical interface that connects a bridge domain to a physical port or to an EtherChannel group.

An EVC broadcast domain is determined by a bridge domain and the EFPs that are connected to it. You can connect multiple EFPs to the same bridge domain on the same physical interface, and each EFP can have its own matching criteria and rewrite operation. An incoming frame is matched against EFP matching criteria on the interface, learned on the matching EFP, and forwarded to one or more EFPs in the bridge domain. If there are no matching EFPs, the frame is dropped.

An Ethernet flow point (EFP) SERVICE INSTANCE is a logical interface that connects a bridge domain to a physical port or to an EtherChannel. Configuring a service instance on a Layer 2 port creates a pseudoport or EFP on which you configure EVC features.

Based on the configured type of encapsulation each service instance can match different types of Ethernet frames, we find QinQ (for double-tagged frames), single-tagged frames, untagged frames, interestingly we see a default keyword that catch-all things that are not matched by any other service instances.

To match frames arriving on G1 interfaces we must associate an encapsulation type to each service instance:

PE1(config-if-srv)#encapsulation ?
  default          catch-all unconfigured encapsulation
  dot1ad           802.1ad – Provider Bridges
  dot1q            IEEE 802.1Q Virtual LAN or S-VLAN
  priority-tagged  Priority tagged EFP
  untagged         Untagged encapsulation

Ref: Cisco.com