Layer 2 routed virtual connections (VCs)
A Layer 2 VC is a construct with sub-interfaces on each end, defined by VLANs. In the current ECX Fabric implementation, the VC is provisioned as part of a larger solution when the provider has specified a Layer 2 service profile—unlike with other components, a user cannot currently define one independently (this will come later). Therefore, any Layer 2 connection to a Layer 2 service profile automatically includes a VC.
Encapsulations supported: 802.1Q (TPID: 0x8100) and 802.1ad (TPID: 0x8100, 0x88a8, 0x9100). The TPID on the frames sent to ECX Fabric on the A-side must match the value specified when the port is ordered. In the case of QnQ this value (TPID) is on the outer tag while the inner tag uses 0x8100.
The TPID on the frames sent to ECX Fabric on the A-side must match the value specified when the port was ordered. In the case of Q-in-Q this value (TPID) is on the outer tag while the inner tag uses 0x8100, regardless of what was specified.
ECX Fabric can “translate” between A and Z sides of a VC so that each side can have whatever VLAN ID and encapsulation each side needs (except where specifically noted below).
Dot1q to Dot1q example where C-Tag does not match A and Z sides
Untagged example: if requested by the user, untagged traffic can be sent to a single destination or RI (with a connector). ECX Fabric "pushes" a tag while the frames are on the platform, and the Z side can have it delivered with tags, if desired
Dot1q to Q-in-Q example: the A side C-tag will be considered the "inner" tag and the Z side determines the S-Tag. This is relatively rare except for a couple of providers. Providers can also simplify this for user by "naming tags:" details for this feature ca n be found in the section for preparing Layer 2 services for sale
Q-in-Q to Q-in-Q example: S-tag translation can occur, and the "inner" or C-Tags that sit inside the frame are not visible. ECX Fabric is unaware of them and cannot operate on them
Buyers can set up multiple Layer 2 VCs and connectors in a given metro, on a single or multiple ECX Fabric ports, at their discretion and the business rules imposed by their administrator.
Layer 3 routed VCs
ECX Fabric has pre-defined policies which will mark local preference on BGP prefixes based on the received community value from customers.
Although no single VC or connector can exceed the size of the port or port group it resides on, the ECX Fabric will allow users to provision multiple VCs and connectors in which the aggregate rate limit is greater than the size of the ports they reside on. While this will not result in dropped traffic by itself, the combined actual and simultaneous usage of all the services could cause drops, and the ECX Fabric SLA is only valid up to the capacity of the ports. Customers are responsible for management of their traffic patterns and usage.
Implementation example: User has a single 1G port and has provisioned two services to two separate providers (Blue for 100M, Orange for 500M), and a primary and secondary 500M service to Green that requires redundancy. If the primary and secondary VCs are set to active/active, and all services are sending the maximum amount of traffic, customer may experience random packet drops