Port-based PXC

The concept of a port-based PXC (a PXC based on a faceplate port in loopback mode) is shown in Figure 1. This PXC does not require an optical transceiver.

Figure 1. Port-based PXC

The faceplate port is placed in a cross-connect mode with the following CLI commands:

MD-CLI

configure {
    port-xc {
        pxc 1 {
            admin-state enable
            port-id 1/x1/1/c1/1
        }
    }
}

Multiple PXCs can be created on the same underlying cross-connect:

MD-CLI

configure {
    port-xc {
        pxc 1 {
            admin-state enable
            port-id 1/x1/1/c1/1
        }
        pxc 2 {
            admin-state enable
            port-id 1/x1/1/c1/1
        }
        pxc 3 {
            admin-state enable
            port-id 1/x1/1/c1/1
        }
}

A faceplate port that has been placed in the loopback mode for PXC use, supports only hybrid mode of operation and dot1q encapsulation. The recommendation is that the MTU value be configured to the maximum value. dot1x tunneling is enabled and cannot be changed.

The pre-set dot1q Ethernet encapsulation on the faceplate port is irrelevant from the operator’s perspective and there is no need to change it. The relevant encapsulation carrying service tags defined on PXC subports and that encapsulation is configurable. For more information, see PXC sub-ports.

The following guidelines apply to a PXC configuration based on faceplate ports:

Only unused faceplate ports (not associated with an interface or SAP) can be referenced within a PXC ID configuration.
When the faceplate port is allocated to a PXC, it cannot be used outside of the PXC context. For example, an IP interface cannot use the faceplate port directly, or a SAP under a such port cannot be associated with an Epipe or VPLS service.