Overview

Local L2X refers to an L2 connection between two ports or VLANs on the same device. In a local L2X, both interfaces are on the same router. The L2X can switch Layer 2 (frame) traffic between the ports. Based on the configuration, these cross connects can be uni-directional as well as bi-directional.

Remote L2X refers to L2 connection between two ports located on two different devices. In a remote L2X, the interfaces are located on two different routers and it requires an MPLS tunnel to transport the traffic between the two routers.

Local L2X: The following figure shows the Local L2X scenario.

Remote L2X: The following figure shows the remote L2X scenario.

Unidirectional refers to data either sent or received in one direction and Bidirectional implies the flow of traffic between two routers in both directions.

The bidirectional cross connect feature helps you to establish cross connection between two local ports with an L2X configuration. Bi-directional attribute is applicable only to local cross connect. Bidirectional connectivity requires a pair of unidirectional L2X or a single bidirectional L2X.

In L2X, ingress traffic is incoming traffic that enters the boundary of a network and egress traffic implies outgoing traffic that exits an entity or a network boundary.

Both port and VLAN cross-connects switches Layer 2 traffic from input interface to output interface. A port cross-connect switches all Layer 2 traffic arriving at an input interface, but a VLAN cross-connect only switches the Layer 2 traffic associated with a specific VLAN. A port-based L2X indicates a port-only configuration, so there are no VLANs involved.

Both single-tag and double-tagged (inner and outer VLAN tags) are supported. The port and VLAN L2X support both local and remote L2X configurations. In remote L2X connections, the VLAN cross-connects are typically configured on the MPLS tunnel ingress router.

Untagged traffic on L2X interfaces is also supported. However, there is no way to select only untagged traffic for cross-connecting. Therefore, only port cross connects are supported for untagged traffic.

RBFS supports VLAN operations such as VLAN add, VLAN swap, and VLAN delete on egress interface. RBFS supports similar functionality at the ingress side as well. That is, RBFS supports the following VLAN operations:

By default the encapsulation method is 802.1q. If an encapsulation method is not specified, 802.1q is the default mode.

In addition to setting the Ethertype for a VLAN operation, the 802.1ad support includes that ingress traffic for all tagged match options will match on both Ethertype 0x8100 (802.1q) and 0x88a8 (802.1ad) by default.

RBFS supports VLAN operations such as VLAN add, VLAN swap and VLAN delete on Ingress and Egress interfaces.

The current functionality has been extended to all the existing CLIs to accept ingress and egress VLAN operations and Ingress and Egress VLAN encapsulation values.

Both 802.1q and 802.1ad encapsulations are supported. The default encapsulation is 802.1q.

Traffic will be matched at ingress direction based on the match criterion. RtBrick Full Stack (RBFS) supports the following match parameters.

On a physical interface, there are five different match types. Traffic can be matched based on the following:

Some of the match types are mutually exclusive. For example, (ifp, outer_vlan, inner_vlan) and (ifp, outer_vlan, any inner_vlan) configuration on the same interface throws errors.

If ifp, any vlan match type is configured with any other match type, it will create conflicts.

The following table shows the supported match type validations.

Not all features are necessarily supported on each hardware platform. Refer to the Platform Guide for the features and the sub-features that are or are not supported by each platform.