Cisco ME 3800x and ME 3600x Switches Software Configuration Guide, Cisco IOS Release 15.4(2)S

Ethernet Virtual Connections

You use the ethernet evc evc-id global configuration command to create an Ethernet virtual connection (EVC). The evc-id or name is a text string from 1 to 100 bytes. Entering this command puts the device into service configuration mode (config-srv) where you configure all parameters that are common to an EVC.

In this mode you can enter these commands:

• default —Sets a command to its defaults
• exit —Exits EVC configuration mode
• no — Negates a command or sets its defaults
• oam —Specifies the OAM Protocol
• uni —Configures a count UNI under EVC

Service Instances and EFPs

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. You can configure a service instance only on trunk ports with no allowed VLANs. Any other configuration is not allowed. After you have configured a service instance on an interface, switchport commands are not allowed on the interface. You can also configure a service instance on an EtherChannel group.

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
• errdisable —Configures error disable
• ethernet —Configures Ethernet-lmi parameters
• exit — Exits from service instance configuration mode
• 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.

On a Layer 2 port with no service instance configured, multiple switchport commands are available ( access, backup, block, host, mode, and trunk). When one or more service instances are configured on a Layer 2 port, no switchport commands are accepted on that interface.

Encapsulation

Encapsulation defines the matching criteria that maps a VLAN, a range of VLANs, cost 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, priority-tagged and untagged. Valid Ethertypes (type) are 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—any ethertype tag after the VLAN tag

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 switch before any rewrites and to packets egressing the switch after all rewrites.

Note The switch does not allow overlapping encapsulation configurations. See the “Examples of Unsupported Configurations” section.

Bridge Domains

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 (based on encapsulation criteria), while VLAN domain membership is determined by the VLAN tag in the packet.

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 8000.

Note Egress policies will not work if the egress EFPs bridge identifier is greater than 4095.

The switches support up to 8000 bridge domains on the highest end platform and license.

Split-Horizon

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.

VPLS core pseudowires or split-horizon enabled pseudowires are put in split horizon group 0. Therefore, EFPs in group 0 are not able to forward to or receive packets from these pseudowires.

Enter the bridge-domain bridge-id split-horizon group group_id service-instance configuration mode command to configure a split-horizon group. The group_id is an integer from 0 to 2. All members of the bridge-domain that are configured with the same group_id are part of the same 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 64 service instances per bridge domain. When a bridge domain contains a service instance that is part of a split-horizon group, this decreases the number of service instances allowed to be configured in that split-horizon group. The switch supports up to three split-horizon groups plus the default (no group).

In Table 12-2 , the left column means that a bridge domain belongs to a service instance that is part of the indicated split horizon group. Therefore, if a service instance joins split-horizon group 2, it can have no more than 16 members in split horizon group 2 in the same bridge domain. We recommend that you add split horizon groups in numerical order to maximize the number of service instances that can belong to a group.

Split Horizon Groups

An IOS XR bridge domain aggregates attachment circuits (ACs) and pseudowires (PWs) in one of three groups called Split Horizon Groups. When applied to bridge domains, Split Horizon refers to the flooding and forwarding behavior between members of a Split Horizon group. In general, frames received on one member of a split horizon group are not flooded out to the other members of the same group.

Bridge Domain traffic is either unicast or multicast.

Flooding traffic consists of unknown unicast destination MAC address frames; frames sent to Ethernet multicast addresses (Spanning Tree BPDUs, etc.); Ethernet broadcast frames (MAC address FF-FF-FF-FF-FF-FF).

Known Unicast traffic consists of frames sent to bridge ports that were learned from that port using MAC learning.

Traffic flooding is performed for broadcast, multicast and unknown unicast destination address. Unicast traffic consists of frames sent to bridge ports that were learned using MAC learning.

Rewrite Operations

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 switch 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 ME 3800X and ME 3600X switches support only these 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.

Possible translation combinations are 1-to-1, 1-to-2, 2-to-1, and 2-to-2. When forwarding to or from a Layer 2 port, you cannot achieve 2-to2 translation because a Layer 2 port is implicitly defined to be rewrite ingress tag pop 1 symmetric.

The switch does not support egress rewrite operations beyond the second VLAN that a packet carries into a switch. Because of the egress rewrite limitation, if an EFP has a pop 2 rewrite operation at ingress, no other EFP in the same bridge domain can have a rewrite operation. See the “Global Rewrite Operation Limitation on a Switch” section.

Default EVC Configuration

No EFPs are configured. No service instances or bridge domains are configured.

Configuration Guidelines

• You can configure 4000 bridge domains on the ME 3600X switch.
• On the ME 3800X switch, the number of bridge domains that you can configure depends on the license that is installed on the switch:

– The metro services licenses support 4000 bridge domains.

– The metro IP services licenses support 2000 bridge domains.

– The metro aggregation services license supports 4000 bridge domain and the scaled version supports 8000 bridge domains.

• All licenses support a maximum of 64 EFPs per bridge domain.
• The number of EFP scales on ME3600x and ME3800x depends on the number of TCAM-MAPD entries. The maximum TCAM-MAPD entry is 4096. The number of TCAM-MAPD entries for an EFP configuration varies between 01-22 based on the VLAN configuration in the EFP encapsulation.

Following are the possible combinations of encapsulation in a VLAN configuration.

– When the encapsulation is a single VLAN, or has a list of VLANs, then encapsulation VLAN contains one TCAM-MAPD entry for each VLAN in the list.

– When the encapsulation has both dot1q and second dot1q VLANs, then the number of TCAM-MAPD entry contains multiples of TCAM-MAPD entries of dot1q and second dot1q.

– When the encapsulation VLAN has VLAN range, then the TCAM-MAPD entry is calculated based on the first and last values in the range.

For example, encapsulation dot1q X-Y or encapsulation dot1q 101-199

The number of TCAM-MAPD entry is calculated as follows:

1. Arrive at two byte binary value of X-1. Let us say A equals to 0000 0000 0110 0100.

2. Arrive at two byte binary value of Y+1. Let us say B equals to 0000 0000 1100 1000.

3. Remove the common bits between A and B from LHS. Stop as you encounter difference in bits.

4. Apply the formula Number of TCAM-MAPD entries = Number of ones in B + Number of zeros in A. That is Number of TCAM-MAPD entries= 3 + 5

Calculate the maximum number of EFPs using the formula:

Maximum number of EFPs = Minimum(4096/Number of TCAM-MAPD entries for efps, 3990).

That is Maximum number of EFPs= Minimum (4096/8, 3990) = 512

• On ME 3600X you can configure the following number of EFPs and cross connects per port:

– 3990 service instances per port

– 512 EFP xconnects per port

– 512 overall on device

• On ME 3800X you can configure the following number of EFPs and cross connects per port:

– 3990 service instances per port

– 3990 EFP xconnects per port

– 8000 overall on device

• Layer 2 protocol tunneling is not supported on cross-connect EFPs.
• You can configure a service instance only on trunk ports with no allowed VLANs. Any other configuration is not allowed. To configure a service instance on an interface, these commands are prerequisites:

• After you have configured a service instance on an interface, switchport commands are not allowed on that interface.
• You must configure encapsulation on a service instance before configuring bridge domain.
• The native VLAN ID specified in switchport trunk native vlan-id is not used by EVC.
• ISL trunk encapsulation is not supported.
• When an EFP encapsulation is the default (matching or allowing all ingress frames), you cannot configure any other encapsulation on an EFP on the same port and bridge-domain as the default encapsulation. There can be only one default encapsulation per port.
• The switch does not support overlapping configurations on the same interface and same bridge domain. If you have configured a VLAN range encapsulation, or encapsulation default, or encapsulation any on service instance 1, you cannot configure any other encapsulations that also match previous encapsulations in the same interface and bridge domain. See the “Examples of Unsupported Configurations” section.
• Ensure a valid service such as Bridge Domain or xconnect is configured in the configured service instance for l2protocol peer or forward or Tunnel. For example:

Creating Service Instances

Beginning in privileged EXEC mode, follow these steps to create an EFP service instance:

Use the no forms of the commands to remove the service instance, encapsulation type, or bridge domain or to disable the rewrite operation.

Configuration Examples

Configuring a Service Instance

Encapsulation Using a VLAN Range

Two Service Instances Joining the Same Bridge Domain

In this example, service instance 1 on interfaces Gigabit Ethernet 0/1 and 0/2 can bridge between each other.

Bridge Domains and VLAN Encapsulation

Unlike VLANs, the bridge-domain number does not need to match the VLAN encapsulation number.

However, when encapsulations do not match in the same bridge domain, traffic cannot be forwarded. In this example, the service instances on Gigabit Ethernet 0/1 and 0/2 can not forward between each other, since the encapsulations don’t match (filtering criteria). However, you can use the rewrite command to allow communication between these two.

Rewrite

In this example, a packet that matches the encapsulation will have one tag removed (popped off). The symmetric keyword allows the reverse direction to have the inverse action: a packet that egresses out this service instance will have the encapsulation (VLAN 10) added (pushed on).

Example of EVC push with hairpinning:

Example of EVC push with POP1 and POP2:

Split Horizon

In this example, service instances 1 and 2 cannot forward and receive packets from each other. Service instance 3 can forward traffic to any service instance in bridge domain 8000 since no other service instance in bridge domain 8000 is in split-horizon group 2. Service instance 4 can forward traffic to any service instance in bridge domain 8000 since it has not joined any split-horizon groups.

Hairpinning

The switch supports hairpinning , which refers to traffic ingressing and egressing same interface. To achieve haripinning, configure two EFPs in the same bridge domain on the same physical interface, as in this example.

Egress Filtering

In EVC switching, egress filtering is performed before the frame is sent on the egress EFP. Egress filtering ensures that when a frame is sent, it conforms to the matching criteria of the service instance applied on the ingress direction. EFP does not require egress filtering if the number of pops is the same as the number of VLANs specified in the encapsulation command.

Note Specifying the cos keyword in the encapsulation command is relevant only in the ingress direction. For egress filtering, cos is ignored.

For example, consider the following configuration.

If a packet with VLAN tag 10 or 20 is received on Gigabit Ethernet 0/3, the ingress logical port would be service instance 3. For the frame to be forwarded on a service instance, the egress frame must match the encapsulation defined on that service instance after the rewrite is done. Service instance 1 checks for outermost VLAN 20; service instance 2 checks for VLAN 30. In this example, the frame with VLAN tags 10 and 20 can be sent to service instance 1 but not to service instance 2.

l2protocol Forward Option

The l2protocol forward option causes the EVC interface to flood the untagged/tagged BPDU packets on:

• another trunk interface on the same VLAN/BD
• SVI or VFI Pseudowire
• EVCs on the same BD
• EVC on Xconnect

You can apply the l2protocol forward command to CDP, DTP, ELMI, ESMC, LACP, LLDP, LOAM, PAGP, PTPPD, STP, UDLD and VTP traffic.

Layer 2 Protocol (L2PT) can forward LinkOAM, ESMC, ELMI, and other reserved MAC addresses in the IEEE range of 0180C2000000-0F to comply with CE2.O requirements.

Limitations:

• Pause frames that use 0180C2000001 cannot be L2PT forwarded or dropped because they are consumed by the forwarding ASIC's physical registers without sending them to the CPU.
• Dot1x that uses 0180c2000003 is disabled by the Cisco ME 3800 and ME 3600 switches. This functionality is the same as in previous releases.
• L2PT tunneling for the reserved MACs is not supported since the reserved MACs do not have known link types. Reserved MACs tunneled with 0180C200000B are replaced to ensure packets egress.
• The LinkOAM, ELMI, and ESMC protocols are considered to be "L2PT peer" even if the L2PT CLI is not applied on the interface. Unlike other protocols, L2PT code assumes it to be drop. This is done to avoid L2PT peer configuration for LinkOAM, ELMI, and ESMC since these protocols previously worked without L2PT configurations.

Table 12-3 CE2.0 Protocol List

This is an example of how to configure the l2protocol forward option:

Examples of Unsupported Configurations

Overlapping Encapsulation

The switch does not allow overlapping encapsulation. Overlapping encapsulation configuration occurs when two EFPs are configured on the same port and the same bridge domain and the set of encapsulations on one EFP is a subset of the encapsulations on the other EFP.

These are examples of overlapping encapsulation:

Example 1

Service instance 2 configuration is rejected because the service instance 1 encapsulation default is a superset of service instance 2 encapsulation dot1q 10.

Example 2

Service instance 2 configuration is rejected because service instance 1 encapsulation dot1q any is superset of service instance 2 encapsulation dot1q 10.

Example 3

Service instance 2 configuration is rejected. Both service instances have the same dot1q vlan 10 encapsulation, but matching cos 3 in service instance 1 is subset of service instance 2 cos match all (the default when not specified). Matching etype ipv4 in service instance 2 is a subset of service instance 1 etype match all (the default when not specified).

Global Rewrite Operation Limitation on a Switch

The switch does not support egress rewrite operations beyond the second VLAN that a packet carries into a switch. Because of the egress rewrite limitation, if an EFP has a pop 2 rewrite operation at ingress, no other EFP in the same bridge domain can have a rewrite operation.

In these examples, service instance 1 and the switchport characteristics are configured prior to service instance 2. In the examples, dot1q 30 identifies a third VLAN to be parsed.

Example 1

Service instance 1 pops two tags at ingress, and service instance 2 does not have rewrite (push) operation at egress. The configuration for service instance 2 is rejected because it is configuring a match on the third VLAN of the packet bridged from service instance 1 to dot1q VLAN encapsulation of service instance 2.

Example 2

Service instance 1 pops two tags at ingress, and service instance 2 pushes only the outermost VLAN. The service instance 2 configuration is rejected since it configures a match on the third VLAN of the packet bridged from service instance 1 to the second-dot1q 30 encapsulation of service instance 2.

Example 3

Service instance 1 pops only one tag, and service instance 2 needs to parse the second and third VLANs. Service instance 2 configuration is rejected since it needs to match on the third VLAN of the packet bridged from service instance 1 to second-dot1q 30 encapsulation of service instance 2.

Example 4

The switchport pops the outermost VLAN implicitly, and service instance 2 needs to parse the second and third VLANs. In this case, the service instance 2 configuration is rejected because it needs to match on the third VLAN of the packet bridged from the switchport to the second-dot1q encapsulation of service instance 2.

Note In all of these examples, if service instance 2 was configured before service instance 1, the configuration for service instance 1 would be rejected.

Restricted number of tags supported on EVC and switchport

Where the EVC matches two tags and there is no rewrite, the configuration is rejected when a second switch port is configured on that VLAN.

A configuration like the example shown below is not supported as the gigabitethernet 2 will be active on vlan 100

EFPs and EtherChannels

You can configure EFP service instances on EtherChannel port channels, but EtherChannels are not supported on ports configured with service instances. Load-balancing on port channels is based on the MAC address or IP address of the traffic flow on the EtherChannel interface.

This example configures a service instance on an EtherChannel port channel, which is required for the port channel to be operational. Configuration on the ports in the port channel are independent from the service instance configuration.

EFPs and Layer 2 Protocols

For Layer 2 protocols (CDP, UDLD, LLDP, MSTP, LACP, PAgP, VTP, and DTP) to peer with a neighbor on a port that has an EFP service instance configured, you need to enter the l2 protocol peer protocol service-instance configuration command on the service instance.

This example shows how to configure CDP to peer with a neighbor on a a service instance:

MAC Address Forwarding, Learning and Aging on EFPs

• 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. For native VLAN frames, the bridge domain equal to the access VLAN configured in the interface is used.

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 switch. 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.

You can disable learning on a bridge domain by entering the no mac address-table learning bridge-domain bridge-id global configuration command. To save Layer 2 forwarding entries, you can disable MAC learning when there are only two EFPs connected to a bridge domain.

• 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 PVST+ 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 dynamic address aging time per VLAN by entering the mac address-table aging time [ 0 | 10-1000000 ] bridge-domain bridge-id. The range is in seconds. 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.
• Static MAC addresses cannot be configured on EFPs. Static MAC addresses are only supported on switch ports.

Configuring IEEE 802.1Q Tunneling and Layer 2 Protocol Tunneling Using EFPs

Tunneling is a feature used by service providers whose networks carry traffic of multiple customers and who are required to maintain the VLAN and Layer 2 protocol configurations of each customer without impacting the traffic of other customers. The ME 3800X and ME 3600X switches use EFPs to support QinQ and Layer 2 protocol tunneling.

802.1Q Tunneling (QinQ)

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 12-1 shows the tag structures of the double-tagged packets.

Figure 12-1 Original (Normal), 802.1Q, and Double-Tagged Ethernet Packet Formats

In Figure 12-2, 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.

Figure 12-2 802.1Q Tunnel Ports in a Service-Provider Network

You can use EFPs to configure 802.1Q tunneling in two ways:

Method 1

In this example, for Customer A, interface Gigabit Ethernet 0/1 is the customer-facing port, and Gigabit Ethernet 0/2 is a trunk port facing the service provider network. For Customer B, Gigabit Ethernet 0/3 is the customer-facing port, and Gigabit Ethernet 0/4 is the trunk port facing the service provider network.

Customer A

For Customer A, service instance 1 on Gigabit Ethernet port 0/1 is configured with the VLAN encapsulations used by the customer: C-VLANs 1–100. These are forwarded on bridge-domain 5000. The service provider facing port is configured with a service instance on the same bridge-domain and with an encapsulation dot1q command matching the S-VLAN. The rewrite ingress tag pop 1 symmetric command also implies a push of the configured encapsulation on egress packets. Therefore, the original packets with VLAN tags between 1 and 100 are encapsulated with another S-VLAN (VLAN 30) tag when exiting Gigabit Ethernet port 0/2.

Similarly, for double- tagged (S-VLAN = 30, C-VLAN = 1–100) packets coming from the provider network, the rewrite ingress tag pop 1 symmetric command causes the outer S-VLAN tag to be popped and the original C-VLAN tagged frame to be forwarded over bridge-domain 5000 out to Gigabit Ethernet port 0/1.

The same scenario applies to Customer B.

Customer B

Method 2

QinQ is also supported when sending packets between an EFP and a switchport trunk, because the switchport trunk is implicitly defined as rewrite ingress tag pop 1 symmetric. The same external behavior as Method 1 can be achieved with this configuration:

Customer A

Again, service instance 1 on Gigabit Ethernet port 0/1 is configured with the VLAN encapsulations used by the customer: C-VLANs 1–100. These are forwarded on bridge-domain 30. The service provider facing port is configured as a trunk port. The trunk port implicitly pushes a tag matching the bridge-domain that the packet is forwarded on (in this case S-VLAN 30).

Note The bridge-domain used must be allowed on the trunk port. This means it must be in the range 1 to 4094 and must be allowed on that trunk port (switchport trunk allowed vlan must include 30).

For double tagged (S-VLAN = 30, C-VLAN = 1 to 100) packets coming in from the provider network, the trunk port implicitly pops the outer S-VLAN (30) and forwards the packet on that bridge-domain.

Customer B

For information about the effect on cost of service (CoS) for different EFT tagging operations, see the “CoS Mapping” section in Chapter35, “Configuring Quality of Service (QoS)”

VLAN Translation Example Configurations

• To configure untagged to tagged packets, for implicit push on ingress and pop on the ingress, configure the ingress port as:

Configure the egress port with switchport mode trunk.

• For 1-to-1 VLAN translation (EFP to EFP), ingress port configuration:

Egress port configuration:

• For 1-to-2 VLAN translation (EFP to EFP), ingress port configuration:

Egress port configuration:

• For 2-to-1 VLAN translation (EFP to EFP), ingress port configuration:

Egress port configuration:

• For 2-to-2 VLAN translation (EFP to EFP), ingress port configuration:

Egress port configuration:

Layer 2 Protocol Tunneling

Customers at different sites connected across a service-provider network need to use various Layer 2 protocols to scale their topologies to include all remote sites, as well as the local sites. STP must run properly, and every VLAN should build a proper spanning tree that includes the local site and all remote sites across the service-provider network. Cisco Discovery Protocol (CDP) must discover neighboring Cisco devices from local and remote sites.

VLAN Trunking Protocol (VTP) must provide consistent VLAN configuration throughout all sites in the customer network that are participating in VTP. Similarly, DTP, LACP, LLDP, PAgP, and UDLD can also run across the service-provider network.

When protocol tunneling is enabled, edge switches on the inbound side of the service-provider network encapsulate Layer 2 protocol packets with a special MAC address (0100.0CCD.CDD0) and send them across the service-provider network. Core switches in the network do not process these packets but forward them as normal (unknown multicast data) packets. Layer 2 protocol data units (PDUs) for the configured protocols cross the service-provider network and are delivered to customer switches on the outbound side of the service-provider network. Identical packets are received by all customer ports on the same VLANs with these results:

• Users on each of a customer's sites can properly run STP, and every VLAN can build a correct spanning tree based on parameters from all sites and not just from the local site.
• CDP discovers and shows information about the other Cisco devices connected through the service-provider network.
• VTP provides consistent VLAN configuration throughout the customer network, propagating to all switches through the service provider that support VTP.

Customers use Layer 2 protocol tunneling to tunnel BPDUs through a service-provider network without interfering with internal provider network BPDUs.

Note On ME 3800X and ME 3600X switches, Layer 2 protocol tunneling is supported on EFPs, but not on switchports. Layer 2 protocol tunneling is not supported on cross-connect EFPs.

In Figure 12-3, Customer X has four switches in the same VLAN, which are connected through the service-provider network. If the network does not tunnel PDUs, switches on the far ends of the network cannot properly run STP, CDP, and other Layer 2 protocols. For example, STP for a VLAN on a switch in Customer X, Site 1, will build a spanning tree on the switches at that site without considering convergence parameters based on Customer X's switch in Site 2. This could result in the topology shown in Figure 12-4.

Figure 12-3 Layer 2 Protocol Tunneling

Figure 12-4 Layer 2 Network Topology without Proper Convergence

In a service-provider network, you can use Layer 2 protocol tunneling to enhance the creation of EtherChannels by emulating a point-to-point network topology. When you enable protocol tunneling (PAgP or LACP) on the service-provider switch, remote customer switches receive the PDUs and can negotiate the automatic creation of EtherChannels.

For example, in Figure 12-5, Customer A has two switches in the same VLAN that are connected through the SP network. When the network tunnels PDUs, switches on the far ends of the network can negotiate the automatic creation of EtherChannels without needing dedicated lines.

Figure 12-5 Layer 2 Protocol Tunneling for EtherChannels

Use the l2protocol tunnel protocol service-instance configuration command to enable Layer 2 protocol tunneling on a service instance:

Valid protocols include CDP, DTP, LACP, LLDP, PAgP, STP, VTP, and UDLD. If a protocol is not specified for a service instance, the protocol frame is dropped at the interface.

This is an example of Layer 2 protocol tunneling configuration:

Note To enable tunneling of most Layer 2 protocol, you must configure encapsulation untagged because Layer 2 protocol PDUs are usually untagged.

EFPs and Ethernet over Multiprotocol Layer Switching (EoMPLS)

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 ports and switchports. 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 and switchports also still apply.

See the “EoMPLS and EVC” section for more information and a configuration example.

Bridge Domain Routing

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

• You must configure SVIs 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.

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

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

Note If an EFP with double tag encapsulation is configured with allowed vlan list of any other trunk ports and there is no rewrite configuration, then configuration is blocked by the CLI. To resolve this issue ensure that the conflicting port is in UP state.

EFPs and Switchport MAC Addresses

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

To see MAC address information for VLANs 1 to 4094, use the show mac address-table vlan privileged EXEC command. For VLANs 4096 to 8000, use the show mac address-table bridge-domain privileged EXEC command. All other show mac address-table commands also support bridge domains as well as VLANs.

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.

Note Static Mac Addresses are not supported on EFPs, static mac is only supported on switchports.

EVC and Switchports

Bridging EFPs and switchports in the same switch is a typical configuration in the edge of the network where network facing interfaces are switchports and user network interfaces are EVC ports where various VLAN rewrites take place. The user-facing interfaces have EVC configuration because the incoming VLANs are only significant on the ingress interface (customer VLANs), which requires VLAN tagging modification. All the network -facing interfaces have VLAN tags, which are globally significant in the provider network.

In order for EFPs and switchports to bridge frames to each other, they must belong to the same bridge domain. For switchports, the bridge domain is set to the incoming VLAN tags. The ingress rewritten VLAN tag at the customer interface would match the bridge domain ID, which represents an S-VLAN for the service provider.

Network port configurations:

Customer port configurations:

EVCs and switchports can exist simultaneously on the same switch. When an EFP joins a bridge domain 1 through 4095, it is part of the same flood domain as VLANs 1 through 4095. If an EFP uses a bridge domain greater than or equal to 4096, it belongs to the EFP-only flood domain.

This example shows VLANs and EFPs sharing the same flooding domain.

When data packets are forwarded between EFPs and switchports, the EFP and switchport configurations are applied to the packet. This removes the ambiguity of the tagging behavior between them.

The following illustrations show tagging behavior between an EFP and a switchport. A switchport trunk has an implicit outer VLAN pop at ingress and an implicit outer VLAN push at egress. When rewrite is enabled, a VLAN tag is popped at ingress and a VLAN tag corresponding to the bridge domain that bridged the packet is pushed at egress on the switchport trunk without any explicit configuration. When a VLAN tag is pushed on a packet egressing at the switchport, the VLAN ID corresponds to the bridge-domain ID over which the packet is bridged.

Figure 12-6 to Figure 12-8 show traffic between a switchport and an EFP when rewrite symmetric is enabled on the EFP.

Figure 12-6 Single-tagged Traffic Between a Switchport and an EFP with Rewrite

In this example, for traffic entering the switchport trunk port, the VLAN tag is popped on ingress at the switchport trunk port and the untagged packet is bridged over bridge domain 10. On egress, the rewrite operation results in a VLAN tag (encapsulation dot1q 10) to be pushed (added), and the packet egresses on the EFP with a single tag (VLAN l0).

For traffic entering the EFP, a VLAN tag is popped at the EFP with a rewrite and the untagged packet is bridged over bridge domain 10. At egress on the switchport trunk port, the VLAN tag corresponding to the bridge domain (VLAN 10) is pushed, and the packet egresses on the switchport with a single tag (VLAN l0).

Figure 12-7 Double-tagged Traffic Between a Switchport and an EFP with Rewrite

At ingress on the switchport, the outer most VLAN tag (VLAN 10) is popped at the switchport and the packet is bridged over bridge-domain 10 with a single tag (VLAN 20). On egress at the EFP with a rewrite, a VLAN tag equal to the encapsulation dot1q VLAN ID (10) is pushed, and the double-tagged packet (tagged with VLAN 10 and VLAN 20) goes out on the EFP.

For packets ingressing at the EFP, the outer most VLAN tag is popped at the EFP and the single-tagged packet (VLAN 10) is bridged over bridge-domain 10. On egress at the switchport, a VLAN tag equal to the bridge domain (VLAN 10) is pushed, and the double-tagged packet (VLAN 10 and 20) goes out the switchport.

Figure 12-8 Untagged Traffic Between a Switchport (with Native or Access VLAN) and an EFP with Rewrite

At ingress on the switchport, an untagged packet is bridged over bridge-domain 10. On egress at the EFP after a rewrite, a VLAN tag equal to the encapsulation dot1qVLAN (10) is pushed, and a single-tagged packet (VLAN 10) is sent out on the EFP.

For packets ingressing the EFP with a rewrite, a VLAN tag (VLAN 10) is popped at the EFP, and the untagged packet is bridged over bridge-domain 10. At egress on the switchport, the native VLAN or access VLAN matches the bridge-domain, and the packet is sent out as untagged.

Figure 12-9 to Figure 12-12 show traffic between a switchport and an EFP with no rewrite.

Figure 12-9 Single-tagged Traffic Between a Switchport and an EFP with no Rewrite

On ingress at the switchport, a VLAN tag is popped at the switchport trunk, and an untagged packet is bridged over bridge-domain 10. On egress at the EFP with no rewrite, there is an encapsulation mismatch because the bridged packet is untagged, and the encapsulation is 802.1q VLAN 10. Therefore, the packet is dropped.

Figure 12-10 Single-tagged and Double-tagged Traffic Between a Switchport and an EFP with no Rewrite

On ingress at the switchport, the outer most VLAN tag (VLAN 10) is popped at the switchport trunk and singled-tagged packet (VLAN 20) is bridged over bridge-domain 10. On egress at the EFP with no rewrite, the bridged packet tag (VLAN 20) matches the encapsulation, and a single-tagged packet (VLAN 20) is sent out on the EFP.

On ingress at the EFP with no rewrite, a single- tagged packet (VLAN 20) is bridged over bridge-domain 10. On egress at the switchport, a VLAN tag corresponding to the bridge-domain (VLAN 10) is pushed, and a double-tagged packet (VLAN 10 and VLAN 20) is sent out on the switchport.

Figure 12-11 Untagged Traffic From a Switchport (with Native or Access VLAN) to an EFP with No Rewrite

After ingress at the switchport, the untagged packet is bridged over bridge-domain 10. On egress at the EFP with no rewrite, there is an encapsulation mismatch because the bridged packet is untagged and the encapsulation is dot1q 10. Therefore, the packet is dropped.

The same scenario applies when the switchport trunk is configured with the access VLAN ID or native VLAN ID.

Figure 12-12 Single-tagged Traffic From an EFP with No Rewrite to a Switchport (with Native or Access VLAN)

After ingress at the EFP with no rewrite, the single tagged packet (VLAN 10) is bridged over bridge-domain 10. On egress at the switchport, the native VLAN matches the bridge-domain and a single-tagged (VLAN 10) packet is sent out the switchport.

The same scenario applies when the switchport trunk is configured with the access VLAN ID or native VLAN ID.

Note Receiving a VLAN-tagged packet where the VLAN is equal to the switchport trunk native VLAN or the access VLAN is unexpected tagging behavior in switchport-only interactions. However, you can expect to receive tagged packets equal to the native VLAN or access VLAN when the switchport interacts with EFPs.

EFPs and MSTP

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

• 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 PVST+ or PVRST for a multicast port is not allowed.

L3 Unicast and Multicast Routing on a Bridge Domain with Multiple EFPs

L3 unicast routing and L3 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 L3 multicast routing enabled is supported
• Each EFP has its own match criteria and its own ingress and egress rewrite operations

Figure 12-13 shows an access-facing port with multiple EFPs configured to the route or bridge.

Figure 12-13 Multiple EFPs

Restrictions

IRB is required for L3 termination at the SVI with redundant L2 links.

For core-based deployments, MPLS is a preferred transport for any traffic type.

Configuring L3 Multicast Routing on a Bridge Domain

No new CLI support is required to configure this feature.

The following example shows how to configure L3 multicast routing on a bridge domain using existing IOS commands. You can configure a maximum of 26 EFPs on the bridge domain.

Cross-Connect on EFP Interfaces

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

Restrictions

• A bridge-domain cannot be configured on an EFP if cross-connect is already configured.
• Cross-connect works only when the MPLS license is enabled.
• Priority-tagged encapsulation is not a supported.

Configuring Cross-Connect on an EFP Interface

Beginning in privileged EXEC mode, follow these steps to configure cross-Connect on an EFP Interface.

Summary Steps

1. configure terminal

2. interface interface-id

3. service instance number ethernet [ name ]

4. encapsulation dot1q vlan_id cos cos_value second-dot1q vlan-id cos cos_value

5. xconnect peer-router-id vcid pw-class pw-class name

6. end

Detailed Steps

This is an example configuration of cross-connect on an EFP interface:

Local Connect on EFP Interfaces

Local connect (a Layer 2 point-to-point service) provides the ability to transparently transmit packets between two service instances which reside on the same box. This feature is different from traditional Layer 2 bridging. Local connect provides a point-to-point connection which connects the two service instances (end points). Packets are not forwarded based on MAC addresses.

In order to local connect two service instances which each have two VLAN tags, it requires a VLAN tag rewrite. Both of the service instances must remove both of their VLAN tags before the packet is locally transmitted to the other service instance. If the two service instances have matching VLAN ranges, local connect would not require a VLAN rewrite.

Restrictions

• The local connect feature does not require system wide VLAN resources. The number of local connects is limited by the number of service instances supported. Since one local connect requires two service instances, the maximum number of local connects supported per box is half the number of service instances supported.
• Like any EFP, egress filtering is not supported. It is the user's responsibility to configure the rewrites and tags on the EFPs to ensure the proper VLANs get inserted and deleted when traffic flows out of the local connect EFP.
• EFPs support Layer 2 protocol tunneling and Connectivity Fault Management (CFM) transparency.
• The following license parameters are required for this feature:

– 3600—Advanced Metro IP Access

– 3800—Metro Aggregation Services and Scaled Metro Aggregation Services

Note The user must create service instances in the traditional way for EVC bridge-domain or EVC xconnect. Only the service command is not needed per EVC.

Configuring Local Connect on an EFP Interface

Beginning in privileged EXEC mode, follow these steps to configure local connect on an EFP interface.

Summary Steps

1. configure terminal

2. interface interface-id

3. service instance number [ ethernet name ]

4. encapsulation dot1q vlan_id cos cos_value second-dot1q vlan-id cos cos_value

5. rewrite ingress tag pop {1 | 2} symmetric

6. connect connect-name interface1 number1 interface2 number2

7. end

Detailed Steps

This is a configuration example of local connect on an EFP interface: