Configuring a service instance on a Layer 2 port or EtherChannel creates a pseudoport or Ethernet flow point (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.

If you have defined an EVC by entering the ethernet evc evc-id global configuration command, you can associate the EVC with the service instance (optional). There is no default behavior for a service instance.

Use the service instance number ethernet [name] interface configuration command to create an EFP on a Layer 2 interface or EtherChannel and to enter service instance configuration mode. You use service instance configuration mode to configure all management and control date plane attributes and parameters that apply to the service instance on a per-interface basis.

• The service instance number is the EFP identifier, an integer from 1 to 4000.

• The optional ethernet name is the name of a previously configured EVC. You do not need to enter an EVC name, but you must enter ethernet . Different EFPs can share the same name when they correspond to the same EVC. EFPs are tied to a global EVC through the common name.

When you enter service instance configuration mode, you can configure these options:

• default —Sets a command to its defaults

• description —Adds a service instance specific description

• encapsulation —Configures Ethernet frame match criteria

• ethernet —Configures Ethernet-lmi parameters

• exit — Exits from service instance configuration mode

• ip —Interface Internet Protocol config commands

• ipv6 —IPv6 interface subcommands

• l2protocol —Configures Layer 2 control protocol processing

• mac —Commands for MAC address-based features

• no —Negates a command or sets its defaults

• service-policy —Attaches a policy-map to an EFP

• shutdown —Takes the service instance out of service

  Enter the [no] shutdown service-instance configuration mode to shut down or bring up a service instance.

• snmp —Modify SNMP service instance parameters

Encapsulation defines the matching criteria that maps a VLAN, a range of VLANs, class of service (CoS) bits, Ethertype, or a combination of these to a service instance. You configure encapsulation in service instance configuration mode. You must configure one encapsulation command per EFP (service instance).

Use the encapsulation service-instance configuration mode command to set encapsulation criteria. Different types of encapsulations are default, dot1q, dot1ad, priority-tagged and untagged. Supported Ethertypes include ipv4, ipv6, pppoe-all, pppoe-discovery, and pppoe-session.

Encapsulation classification options also include:

• outer tag VLAN

• outer tag CoS

• inner tag VLAN

• inner tag CoS

• payload ethertype

After you have entered an encapsulation method, these keyword options are available in service instance configuration mode:

• bridge-domain —Configures a bridge domain

• rewrite —Configures Ethernet rewrite criteria

If a packet entering or leaving a port does not match any of the encapsulations on that port, the packet is dropped, resulting in filtering on both ingress and egress. The encapsulation must match the packet on the wire to determine filtering criteria. On the wire refers to packets ingressing the router before any rewrites and to packets egressing the router after all rewrites.

Note	The router does not allow overlapping encapsulation configurations.

A service instance must be attached to a bridge domain. Flooding and communication behavior of a bridge domain is similar to that of a VLAN domain. Bridge-domain membership is determined by which service instances have joined it, while VLAN domain membership is determined by the VLAN tag in the packet.

You can configure the platform bdi enable-state-up global command to enable the BDI interface up without the no shut command. You can disable this functionality by using the no platform bdi enable-state-up command on the interface.

Note	You must configure encapsulation before you can configure the bridge domain.

Use the bridge-domain bridge-id service-instance configuration mode command to bind the EFP to a bridge domain instance. The bridge-id is the identifier for the bridge domain instance, an integer from 1 to 4000.

You can enable BDI MTU using the enable_bdi_mtu sdm template.

Router(config)# interface bdi 120
Router(config-if)# bandwidth 10000000
Router(config-if)# end

Router# show interface bdi 120 
BDI120 is up, line protocol is up 
  Hardware is BDI, address is 7426.acf7.2ebf (bia 7426.acf7.2ebf)
  Internet address is 192.168.1.1/24
  MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec

The split-horizon feature allows service instances in a bridge domain to join groups. Service instances in the same bridge domain and split-horizon group cannot forward data between each other, but can forward data between other service instances that are in the same bridge domain, but not in the same split-horizon group.

Service instances do not have to be in a split-horizon group. If a service instance does not belong to a group, it can send and receive from all ports within the bridge domain. A service instance cannot join more than one split-horizon group.

EFPs that are not configured with an explicit group_id do not belong to any group.

You can configure no more than 128 service instances per bridge domain. These 128 EFPs can be distributed among split-horizon groups 0 to 13.

VPLS uses a reserved internal split group 15 which does not overlap with manually configured split groups. In case VPLS is configured on same bridge domain, scale of 128 EFPs can still be achieved on the same bridge domain.

128 EFPs and 64 VFIs are supported on the same bridge domain.

Restrictions

• Maximum number of EFPs per bridge-domain is 128. The EFPs can be distributed among split-horizon groups 0 to 13.

• VPLS uses the reserved internal Split-horizon group 15 which does not overlap with manually configured split groups. In case VPLS is configured on the same bridge-domain, the scale of 128 EFPs is achieved on the same bridge-domain.

• 64 VFIs are supported on the same bridge-domain.

You can use the rewrite command to modify packet VLAN tags. You can use this command to emulate traditional 802.1Q tagging, where packets enter a router on the native VLAN and VLAN tagging properties are added on egress. You can also use the rewrite command to facilitate VLAN translation and QinQ.

The supported rewrite commands:

• rewrite ingress tag pop 1 symmetric

• rewrite ingress tag pop 2 symmetric

• rewrite ingress tag push dot1q vlan-id symmetric

Enter the rewrite ingress tag pop {1 | 2} symmetric service-instance configuration mode command to specify the encapsulation adjustment to be performed on the frame ingress to the EFP. Entering pop 1 pops (removes) the outermost tag; entering pop 2 removes two outermost tags.

Note

The symmetric keyword is required to complete rewrite to configuration. When you enter the symmetric keyword, the egress counterpart performs the inverse action and pushes (adds) the encapsulation VLAN. You can use the symmetric keyword only with ingress rewrites and only when single VLANs are configured in encapsulation. If you configure a list of VLANs or a VLAN range or encapsulation default or encapsulation any , the symmetric keyword is not accepted for rewrite operations.

The router supports multicast static MAC addresses, which allow you to enable multicast at the layer 2 level. You can use multicast static MAC addresses to forward multicast packets to specific EFPs on a network.

Layer 2 protocol peering, forwarding, and tunneling on CDP, LACP, LLDP, PAGP, STP, UDLD, and VTP traffic is supported. For more information about these features, see:

• Layer 2 Protocol Peering, page 14

• Layer 2 Protocol Forwarding, page 14

From Cisco IOS XE Cupertino 17.9.1, Layer 2 protocol forwarding and discarding options are supported for the following protocols:

• Multiple Registration Protocol (MRP) Block

• Cisco bridge protocol data unit (BPDU)

• Cisco STP UplinkFast

• Cisco Connectivity Fault Management (CFM)

Starting with Cisco IOS XE Fuji 16.7.1, you can forward, tunnel, or discard Multiple VLAN Registration Protocol (MVRP) or Multiple MAC Registration Protocol (MMRP) for a service instance on an ethernet interface.

R55(config-if-srv)#service instance 1 ethernet
R55(config-if-srv)#l2protocol forward
  R4     Reserved Protocol using DA Mac 0180.C200.0004
  R5     Reserved Protocol using DA Mac 0180.C200.0005
  R6     Reserved Protocol using DA Mac 0180.C200.0006
  R8     Reserved Protocol using DA Mac 0180.C200.0008
  R9     Reserved Protocol using DA Mac 0180.C200.0009
  RA     Reserved Protocol using DA Mac 0180.C200.000A
  RB     Reserved Protocol using DA Mac 0180.C200.000B
  RC     Reserved Protocol using DA Mac 0180.C200.000C
  RD     Reserved Protocol using DA Mac 0180.C200.000D
  RF     Reserved Protocol using DA Mac 0180.C200.000F
  cbpdu  Cisco Bridge Protocol Data Unit
  ccfm   Cisco CFM
  cdp    Cisco Discovery Protocol
  cstp   Cisco STP Uplink Fast
  dot1x  Dot1x Protocol
  elmi   ELMI Protocol
  esmc   ESMC Protocol
  lacp   LACP Protocol
  lldp   Link Layer Discovery Protocol
  loam   Link OAM Protocol
  mmrp   Multiple MAC Registration Protocol
  mrpb   MRP Block Protocol
  mvrp   Multiple VLAN Registration Protocol
  pagp   Port Aggregation Protocol
  ptppd  PTP Peer Delay Protocol
  stp    Spanning Tree Protocol
  udld   UDLD Protocol
  vtp    Vlan Trunking Protocol
  <cr>   <cr>

R55(config-if-srv)#l2protocol forward
 Configured Platform supported protocols
 cdp stp vtp pagp dot1x lldp lacp udld loam esmc elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF 
mmrp mvrp mrpb cbpdu cstp ccfm
R55(config-if-srv)#do show run int gi0/0/1
Building configuration...

Current configuration : 287 bytes
!
interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  l2protocol forward cdp stp vtp pagp dot1x lldp lacp udld loam esmc 
elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF mmrp mvrp mrpb cbpdu cstp ccfm
  bridge-domain 1
 !
end
R55(config-if-srv)#l2protocol forward 
R55(config-if-srv)#l2protocol forward 
 Configured Platform supported protocols  cdp stp vtp pagp dot1x lldp lacp udld loam esmc elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF mmrp mvrp mrpb cbpdu cstp ccfm
R55(config-if-srv)#do show run int gi0/0/1
Building configuration...

Current configuration : 287 bytes
!
interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  l2protocol forward cdp stp vtp pagp dot1x lldp lacp udld 
loam esmc elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF mmrp mvrp mrpb cbpdu cstp ccfm 
  bridge-domain 1
 !
end

R55#show ethernet service instance id 1 int GigabitEthernet0/0/1 platform 
Service Instance (EFP) L2 PDU Handing Info
EFP               CDP   STP   VTP   DTP   PAGP  LLDP  LACP  UDLD  LOAM  ESMC  ELMI  PTPPD  RES4  RES5  RES6  RES8  RES9  RESA  RESB  RESC  RESD  RESF  MMRP  MVRP  MRPB  CBPD  CSTP  CCFM  CFG  NH   
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Gi0/0/1.Efp1      FRWD  FRWD  FRWD  DROP  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD   FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  FRWD  N    N    

EFP L2PT Tunnel statistics
----------------------------------------
L2protocol        Encapped      Decapped
----------------------------------------
CDP:              0             0         
STP:              0             0         
VTP:              0             0         
DTP:              0             0         
PAGP:             0             0         
LLDP:             0             0         
LACP:             0             0         
UDLD:             0             0         
LOAM:             0             0         
ESMC:             0             0         
ELMI:             0             0         
PTPPD:            0             0         
MMRP:             0             0         
MVRP:             0             0         
MRPB:             0             0         
CBPDU:             0             0         
CSTP:             0             0         
CCFM:             0             0         
Total Active Session(s): 1
Total Internal Session(s): 1
Total External Session(s): 0

R55(config-if-srv)#l2protocol discard ?
  R4     Reserved Protocol using DA Mac 0180.C200.0004
  R5     Reserved Protocol using DA Mac 0180.C200.0005
  R6     Reserved Protocol using DA Mac 0180.C200.0006
  R8     Reserved Protocol using DA Mac 0180.C200.0008
  R9     Reserved Protocol using DA Mac 0180.C200.0009
  RA     Reserved Protocol using DA Mac 0180.C200.000A
  RB     Reserved Protocol using DA Mac 0180.C200.000B
  RC     Reserved Protocol using DA Mac 0180.C200.000C
  RD     Reserved Protocol using DA Mac 0180.C200.000D
  RF     Reserved Protocol using DA Mac 0180.C200.000F
  cbpdu  Cisco Bridge Protocol Data Unit
  ccfm   Cisco CFM
  cdp    Cisco Discovery Protocol
  cstp   Cisco STP Uplink Fast
  dot1x  Dot1x Protocol
  elmi   ELMI Protocol
  esmc   ESMC Protocol
  lacp   LACP Protocol
  lldp   Link Layer Discovery Protocol
  loam   Link OAM Protocol
  mmrp   Multiple MAC Registration Protocol
  mrpb   MRP Block Protocol
  mvrp   Multiple VLAN Registration Protocol
  pagp   Port Aggregation Protocol
  ptppd  PTP Peer Delay Protocol
  stp    Spanning Tree Protocol
  udld   UDLD Protocol
  vtp    Vlan Trunking Protocol
  <cr>   <cr>
R55(config-if-srv)#l2protocol discard 
 Configured Platform supported protocols  cdp stp vtp pagp dot1x lldp lacp udld loam esmc elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF mmrp mvrp mrpb cbpdu cstp ccfm
R55(config-if-srv)#do show run int gi0/0/1
Building configuration...

Current configuration : 287 bytes
!
interface GigabitEthernet0/0/1
 no ip address
 negotiation auto
 service instance 1 ethernet
  encapsulation untagged
  l2protocol discard cdp stp vtp pagp dot1x lldp lacp udld loam esmc elmi ptppd R4 R5 R6 R8 R9 RA RB RC RD RF mmrp mvrp mrpb cbpdu cstp ccfm
  bridge-domain 1
 !
end

Use the following steps to configure EFP as track client:

1. Configure track to check the reachability.

2. Configure EFP (service instance 100 on the interface 0/3/4) as the track client.

Router# config terminal
Configuring from terminal, memory, or network [terminal]? 
Enter configuration commands, one per line.  End with CNTL/Z.
Router(config)#track 10 ip route 5.5.5.5 255.255.255.255 reachability
Router(config-track)#exit

Router(config)#interface TenGigabitEthernet0/3/4
Router(config-if)# service instance 100 ethernet
Router(config-if-srv)#  track 10
Router(config-if-srv)#exit

Service provider customers often have specific requirements for VLAN IDs and the number of VLANs to be supported. The VLAN ranges required by different customers in the same service-provider network might overlap, and traffic of customers through the infrastructure might be mixed. Assigning a unique range of VLAN IDs to each customer would restrict customer configurations and could easily exceed the VLAN limit (4096) of the 802.1Q specification.

Using the EVCs, service providers can encapsulate packets that enter the service-provider network with multiple customer VLAN IDs (C-VLANs) and a single 0x8100 Ethertype VLAN tag with a service provider VLAN (S-VLAN). Within the service provider network, packets are switched based on the S-VLAN. When the packets egress the service provider network onto the customer network, the S-VLAN tag is decapsulated and the original customer packet is restored.

Figure below shows the tag structures of the double-tagged packets.

In figure below, Customer A was assigned VLAN 30, and Customer B was assigned VLAN 40. Packets entering the edge switches with 802.1Q tags are double-tagged when they enter the service-provider network, with the outer tag containing VLAN ID 30 or 40, appropriately, and the inner tag containing the original VLAN number, for example, VLAN 100. Even if both Customers A and B have VLAN 100 in their networks, the traffic remains segregated within the service-provider network because the outer tag is different. Each customer controls its own VLAN numbering space, which is independent of the VLAN numbering space used by other customers and the VLAN numbering space used by the service-provider network. At the outbound port, the original VLAN numbers on the customer's network are recovered.

When you configure a pseudowire under a VLAN interface (for example, VLAN 33), the pseudowire becomes a virtual Layer 2 port in that VLAN (VLAN 33), or bridge domain. In this bridge domain, you can configure other types of Layer 2 ports, such as EFP portss. Switching functionalities, such as MAC address learning, flooding, and forwarding to learned MAC addresses, apply to all the Layer 2 ports, including the pseudowire.

Note	When a pseudowire is present in the same bridge domain as an EFP, you cannot configure the EFP with the rewrite ingress tag pop 2 symmetric service instance configuration command. Other restrictions about switching between EFPs or between EFPs also still apply.

For more information about configuring pseudowire, see the Cisco ASR 920 Router Chassis Software Configuration Guide.

The switch supports IP routing and multicast routing for bridge domains, including Layer 3 and Layer 2 VPNs, using the BDI model. There are the limitations:

• You must configure BDIs for bridge-domain routing.

• The bridge domain must be in the range of 1 to 4094 to match the supported VLAN range.

• You can use bridge domain routing with only native packets.

  Bridge domain routing only works if proper tag popping is configured on the corresponding EFP BD. For example, if an EFP is configured with a single tag then rewrite should be pop 1 symmetric. If the EFP is configured with double tag then rewrite should be pop 2 symmetric. For double tag EFP, pop 1 symmetric and routing on the BDI is not supported.

  Note	Traffic engineering is not supported for BDI Routing.

Note	You can configure the platform bdi enable-state-up global command to enable the BDI interface up without the no shut command when active. You can disable this functionality by using the <no> platform bdi enable-state-up command.

This is an example of configuring bridge-domain routing with a single tag EFP:

Router (config)# interface gigabitethernet0/2 
Router (config-if)# service instance 1 Ethernet 
Router (config-if-srv)# encapsulation dot1q 10 
Router (config-if-srv)# rewrite ingress tag pop 1 symmetric 
Router (config-if-srv)# bridge-domain 100

Router (config)# interface bdi 100
Router (config-if)# ip address 20.1.1.1 255.255.255.255

This is an example of configuring bridge-domain routing with two tags:

Router (config)# interface gigabitethernet0/2 
Router (config-if)# service instance 1 Ethernet 
Router (config-if-srv)# encapsulation dot1q 10 second-dot1q 20
Router (config-if-srv)# rewrite ingress tag pop 2 symmetric 
Router (config-if-srv)# bridge-domain 100

Router (config)# interface bdi 100
Router (config-if)# ip address 20.1.1.1 255.255.255.255

Because forwarding can occur between EFPs and trunk ports, MAC address movement can occur on learned addresses. Addresses learned on EFPs will have the format of interface + EFP ID, for example gigabitethernet 0/0/1 + EFP 1. When an address moves between a non-secured EFP and a trunk port, the behavior is similar to that of moving between trunk ports.

To see MAC address information for bridge domains, use the show mac-address-table bdomain domain command.

When an EFP property changes (bridge domain, rewrite, encapsulation, split-horizon, secured or unsecured, or a state change), the old dynamic MAC addresses are flushed from their existing tables. This is to prevent old invalid entries from lingering.

EFP bridge domains are supported by the Multiple Spanning Tree Protocol (MSTP). These restrictions apply when running STP with bridge domains.

• EVC supports only MSTP.

• All incoming VLANs (outer-most or single) mapped to a bridge domain must belong to the same MST instance or loops could occur.

• For all EFPs that are mapped to the same MST instance, you must configure backup EFPs on every redundant path to prevent loss of connectivity due to STP blocking a port.

• When STP mode is PVST+ or PVRST, EFP information is not passed to the protocol. EVC only supports only MSTP.

• Changing STP mode from MST to PVRST is not allowed.

Layer 3 unicast routing and Layer 3 multicast routing are supported on bridge domains with multiple EFPs. This feature provides the following functionality:

• Broadcast domains are determined through bridge-domains rather than VLANs

• Multiple EFPs on a single bridge domain and physical interface with Layer 3 multicast routing enabled is not supported in RSP3.

• Each EFP has its own match criteria and its own ingress and egress rewrite operations

Cross-connect provides the ability to match the encapsulation of received packets on the ingress side of an EFP interface and send them out with the same encapsulation through the egress side of the EFP interface. Cross-connect bridge-domain entries are provided, and encapsulation matching is achieved by matching bridge-domain entries for the EFPs on which cross-connect is configured.

The following types of encapsulation tags are supported:

• untagged

• rewrite tags with pop1

• Layer 2 forwarding is based on the bridge domain ID and the destination MAC address. The frame is forwarded to an EFP if the binding between the bridge domain, destination MAC address, and EFP is known. Otherwise, the frame is flooded to all the EFPs or ports in the bridge domain.

• MAC address learning is based on bridge domain ID, source MAC addresses, and logical port number. MAC addresses are managed per bridge domain when the incoming packet is examined and matched against the EFPs configured on the interface. If there is no EFP configured, the bridge domain ID equal to the outer-most VLAN tag is used as forwarding and learning look-up key.

  If there is no matching entry in the Layer 2 forwarding table for the ingress frame, the frame is flooded to all the ports within the bridge domain. Flooding within the bridge domain occurs for unknown unicast, unknown multicast, and broadcast.

• Dynamic addresses are addresses learned from the source MAC address when the frame enters the router. All unknown source MAC addresses are sent to the CPU along with ingress logical port number and bridge domain ID for learning. Once the MAC address is learned, the subsequent frame with the destination MAC address is forwarded to the learned port. When a MAC address moves to a different port, the Layer 2 forwarding entry is updated with the corresponding port.

  Note	The router does not currently support the no mac address-table learning bridge-domain bridge-id global configuration command.

• Dynamic addresses are aged out if there is no frame from the host with the MAC address. If the aged-out frame is received by the switch, it is flooded to the EFPs in the bridge domain and the Layer 2 forwarding entry is created again. The default for aging dynamic addresses is 5 minutes. However, when MST undergoes a topology change, the aging time is reduced to the forward-delay time configured by the spanning tree. The aging time reverts back to the last configured value when the topology change expires.

  You can configure a dynamic address aging time per bridge domain using the mac aging-time time command. The range is in seconds and valid values are 120-300. The default value is 300. An aging time of 0 means that the address aging is disabled.

• MAC address movement is detected when the host moves from one port to another. If a host moves to another port or EFP, the learning lookup for the installed entry fails because the ingress logical port number does not match and a new learning cache entry is created. The detection of MAC address movement is disabled for static MAC addresses where the forwarding behavior is configured by the user.