Flexible Cross-Connect Service

Service providers have a massive number of Attachment Circuits (ACs) (in millions) that need to be backhauled across their MPLS/IP network. These service providers want to multiplex a large number of ACs across several physical interfaces spread across one or more PEs onto a single VPWS service tunnel to reduce the number of EVPN service labels associated with EVPN-VPWS service tunnels and, thus, the associated OAM monitoring. This is where flexible cross-connect (FXC) services can help.
We had 2 test runs. The first run was configured under the default flexible cross-connect mode. In this mode of operation, many ACs across several Ethernet Segments are multiplexed into a single EVPN VPWS service tunnel represented by a single VPWS service ID. The participating PEs do not need to signal the VLANs (normalized VIDs) in EVPN BGP.
We sent cross-VLAN  unicast traffic from 2 VLANs at each end and noted that there was no packet loss. After that, we executed the switchover for the multihomed part of the network. While some packet loss was anticipated during this process, we observed that traffic recovered within three seconds.

The second run was configured under VLAN-Signaled Flexible cross-connect mode. In this mode of operation, similar to the default FXC mode, many normalized VIDs representing ACs across several Ethernet Segments/interfaces are multiplexed into a single EVPN VPWS service tunnel. However, this single tunnel is represented by multiple VPWS service IDs (one per normalized VID), and these normalized VIDs are signaled using EVPN BGP. For each normalized VID on each Ethernet Segment, the PE generates an Ethernet A-D per EVI route where the ESI field represents the ES ID, the Ethernet Tag field is set to the normalized VID, and the MPLS label field is set to a dynamically generated EVPN label representing the P2P EVPN service tunnel. This label is the same for all ACs multiplexed into a single EVPN VPWS service tunnel. This route is sent with a Route Target (RT) representing the EVI.
We sent cross-VLAN  unicast traffic from 2 VLANs at each end and noted that there was no packet loss. After that, we executed the switchover for the multihomed part of the network. While some packet loss was anticipated during this process, we observed that traffic recovered within three seconds.
Spirent TestCenter was used as the traffic generator for this test.