The following example is based on a PXC on a faceplate port. Subscriber traffic with QinQ encapsulation arriving on two different line cards (3 and 4) is terminated on the PXC LAG on line cards 1 and 2. With this method, if one of the ingress line cards (3 or 4) fails, the subscriber traffic remains unaffected (continues to be terminated on line cards 1 and 2) provided that the correct protection mechanism is implemented in the access part of the network. This protection mechanism in the access part of the network must ensure that traffic arriving on card 3 can be rerouted to card 4 if card 3 fails. The opposite must be true as well (the path to card 4 must be protected by a path to card 3).
PXC can be on any card, independent of ingress ports.
The following is an example of faceplate (physical) port configuration on cards 3 and 4:
MD-CLI commands
[pr:/configure]
port 3/1/1 {
description "access I/O port on card 3; ecap is null which means that all
VLAN tagged and untagged traffic will be accepted”
ethernet {
mode access
encap-type null
}
}
port 4/1/1 {
description "access I/O port on card 4; ecap is null which means that all
VLAN tagged and untagged traffic will be accepted”
ethernet {
mode access
encap-type null
}
}
The following is an example of a PXC configuration on cards 1 and 2:
MD-CLI commands
[pr:/configure]
port-xc {
pxc 1 create {
admin-state enable
description "PXC on card 1”
port 1/1/1
}
pxc 2 create {
admin-state enable
description "PXC on card 2”
port 2/1/1
}
}
The operator must manually configure the sub-port encapsulation (the default is dot1q). PXC sub-ports transparently pass traffic with preserved QinQ tags from the .b side of the PXC to the .a side of the PXC where a *.* capture SAP is configured.
MD-CLI commands
[pr:/configure]
port pxc-1.a {
admin-state enable
description "termination PXC side; *.* capture SAP will be configured here”
encap-type qinq
}
port pxc-1.b {
admin-state enable
description "transit PXC side; all VLAN tags (*) will be transparently
passed via this side”
encap-type dot1q
}
port pxc-2.a
admin-state enable
description "together with pxc-1.a, this sub-port is a member of LAG 1”
encap-type qinq
}
port pxc-2.b {
admin-state enable
description "together with pxc-1.b, this sub-port is a member of LAG 2”
encap-type dot1q
}
The following is an example of a PXC LAG configuration:
MD-CLI commands
[pr:/configure]
lag 1 {
admin-state enable
description "terminating side of the cross-connect”
port pxc-1.a {
}
port pxc-2.a {
}
}
lag 2 {
admin-state enable
description "transient side of the cross-connect”
port pxc-1.b {
}
port pxc-2.b {
}
}
Passing traffic from the ingress side on access (ports 3/1/1 and 4/1/1) via the transient PXC sub-ports pxc-1.b and pxc-2.b to the termination side of the PXC is performed through VPLS.
MD-CLI commands
[pr:/configure]
service vpls 1 {
admin-state enable
customer 1
description "stitching access side to the anchor"
split-horizon-group "access (I/O) side" {
}
sap 3/1/1 {
admin-state enable
description "I/O port”
split-horizon-group "access"
}
sap 4/1/1 {
admin-state enable
description "I/O port”
split-horizon-group "access"
}
sap lag-2:* {
admin-state enable
description "transit side od PXC”
}
}
The following is an example of capture SAPs on the anchor:
MD-CLI commands
[pr:/configure]
service vpls 3 {
admin-state enable
customer 1
description "VPLS with capture SAPs”
capture-sap lag-1:10.* {
admin-state enable
description "termination side of PXC; traffic with S-tag=10 will be extracted here”
trigger-packet {
dhcp true
dhcpv6 true
pppoe true
}
}
capture-sap lag-1:11.* {
admin-state enable
description "termination side of PXC; traffic with S-tag=11 will be extracted here”.