6. Pseudowire Ports
This chapter provides information about pseudowire ports (PW ports), process overview, and implementation notes.
6.1. Overview
A PW port is primarily used to provide PW termination with the following characteristics:
- Provide access (SAP) based capabilities to a PW which has traditionally been a network port based concept within SR OS. For example, PW payload can be extracted onto a PW-port-based SAPs with granular queuing capabilities (queuing per SAP). This is in contrast with traditional PW termination on network ports where queuing is instantiated per physical port on egress or per MDA on ingress.
- Lookup dot1q and qinq VLAN tags underneath the PW labels and map the traffic to different services.
- Terminate subscriber traffic carried within the PW on a BNG. In this case PW-port-based SAPs are instantiated under a group interface with Enhanced Subscriber Management (ESM). In this case, a PW-port-based SAP is treated as any other regular SAP created directly on a physical port with full ESM capabilities.
Mapping between PWs and PW ports is performed on one-to-one basis.
There are two modes in which PW port can operate:
- A PW port bound to a specific physical port (I/O port) — A successful mapping between the PW and PW port requires that the PW terminates on the same physical port (I/O port) to which the PW port is bound. In this mode of operation, PW ports do not support re-routing of PWs between the I/O ports. For example, if a PW is rerouted to an alternate physical port due to a network failure, the PW port will become non-operational.
- A PW port independent of the physical port (I/O port) on which the PW is terminated. This capability relies on FPE functionality and hence the name FPE based PW port. The benefit of such PW port is that it can provide services in cases where traffic within PW is rerouted between I/O ports due to a network failure.
When the PW port is created, the mapping between the PW port and PW will depend on the mode of operation and application.
PW port creation:
Similar to any other Ethernet-based port, the PW port supports two encapsulation types, dot1q and qinq. Ether-type on a PW port is not configurable and it is set to a fixed value of 0x8100 for dot1q and qinq encapsulation.
6.2. PW Port Bound to a Physical Port
In this mode of operation, the PW port is bound to a specific physical port through an SDP binding context:
In this example, pw-port 1 is bound to a physical port 1/1/1.This PW port is mapped to the PW with vc-id 11 under the sdp 1 which must be terminated on port 1/1/1.A PW port is shaped by a virtual port scheduler (Vport) construct named vport-1 configured under port 1/1/1. SAPs created under such PW ports can be terminated in ESM, Layer 3 IES/VPRN interface or in an Epipe.
6.3. FPE-Based PW Port
The FPE based PW-port is primarily used to extract a PW payload onto an access based PW-port SAP, independent of the network I/O ports. FPE uses Port Cross-Connect (PXC) ports and provides an anchoring point for PW-port, independent of I/O ports, the term anchored PW-port can be interchangeably used with the term FPE based PW-port.The following are examples of applications which rely on FPE based PW-port:
- ESM over PW where MPLS/GRE based PW can be rerouted between I/O ports on an SR OS node without affecting ESM service
- Granular QoS per PW since the PW payload is terminated on an access based PW-port SAP 1759 → ingress/egress queues are created per SAP (as opposed to per network port on egress and per MDA on network ingress)
- PW-SAP with MPLS resiliency, where the LSP used by the PW terminated on a PW Ports is protected using MPLS mechanisms such as FRR and could therefore use any port on the system
- PW-port using LDP-over-RSVP tunnels
- A PW Port using a BGP VPWS
Although the primary role of FPE based PW-port is to terminate an external PW, in certain cases PW-port can be used to terminate traffic from regular SAP on I/O ports. This can be used to:
- Separate service termination point from the SAPs which are tied to I/O ports.
- Distribute load from a single I/O port to multiple line cards based on S-Tag (traffic from each S-tag can be mapped to a separate PW associated with different PXCs residing on different line cards).
6.3.1. Cross-Connect Between the External PW and the FPE-Based PW-Port
PW payload delivery from the I/O ports to the FPE based PW-port (and SAP) is facilitated via an internal cross-connect which is built on top of PXC sub-ports. Such cross-connect allows for mapping between PWs and PW-ports even in cases where PW payloads have overlapping VLANS. This concept is shown in Figure 206.
Figure 206: Multiplexing PWs over PXC-Based Internal Cross-Connect
Parameters associated with the PXC sub-ports or PXC based LAGs (QoS, lag-profiles, etc.) are accessible/configurable via CLI. For example, the operator may apply an egress port-scheduler on sub-port pxc-1.b in Figure 206 in order to manage the sum of the bandwidth from associated PW-ports (PW-ports 1 and 2). To avoid confusion during configuration of PXC sub-ports /LAGs, a clear definition of reference points on the cross-connect created via FPE is required:
- Terminating side of the cross-connect is closer to PW-ports (.b side)
- Transit side of the cross-connect is closer to I/O ports (.a side)
Since the creation of the cross-connect on FPE based PW-ports is highly automated through and FPE configurations, the SR OS system will:
- Assign PXC sub-ports .a to the transit side, and PXC sub-ports .b to the terminating side in case that a single PXC is used; see Figure 207.
Figure 207: Assign PXC Sub Ports
- Assign the xc-a LAG to the transit side, and the xc-b LAG to the terminating side if that a PXC based LAG is used; see Figure 208.
Figure 208: Assign the LAG
xc-a and xc-b can be associated with any PXC based LAG ID. For example, the following path configuration is allowed: xc-a with lag-id 100 (which includes pxc sub-ports pxc-2.a and pxc-3.b) and xc-b with lag-id 101 (which includes pxc sub-ports pxc-3.a and pxc-2.b). Regardless of the pxc sub-ports that are assigned to respective LAGs, the xc-a side of the path is used as the transit side of the cross-connect, while the xc-b side of the path is used as the termination side of the cross-connect.
6.3.2. PXC-Based PW-Port — Building the Cross-Connect
From a logical perspective, the internal cross-connect that maps the external PW to a PW-port is implemented as a switched Epipe service (vc-switching). This switched Epipe service switches an external PW to the internal PW that is terminated on a FPE based PW-port. In this fashion, the PW-port becomes independent of the I/O ports. Assuming that PXC and PW-port are already configured in the system, the following are the three main configuration steps required to terminate the payload carried over external PW on the PW-port SAP:
- Auto-setup of the internal transport tunnel over which the cross-connect is built
- Auto-setup of the internal PW, switching the external PW to the internal PW and terminating the PW on the FPE based PW-port
- Terminating the service on the PW-SAP
The status of the internally built constructs can be examines via various show commands (for example show service id <epipe-id> 1 sdp). The internal SDP id is allocated from the user space. To avoid conflict between the user provisioned SDP ids and the system provisioned SDP ids, a range of SDP ids that will be used for internal consumption must be reserved in advance. This is accomplished via the sdp-id-range commands under the config>fwd-path-ext hierarchy.
Configuration steps necessary to build PW-port based cross-connect over PXC are shown in the following diagrams (a single PXC is used in this example).
6.3.2.1. Building the Internal Transport Tunnel
The fpe command instructs the SR OS system to build an LSP tunnel over the PXC. This tunnel is used to multiplex PW traffic to respective PW-ports. Each external PW is switched to an internal PW (on top of this tunnel) and its payload is off-loaded to a respective PW-port.
After the fpe is configured (refer to “Forwarding Path Extensions” in the Interface Configuration Guide), the SR OS system will automatically configure steps 1, 2 and 3 in Figure 209. The objects created in steps 1, 2 and 3 can be seen via show commands. However, they are not visible to the operator in the configure branch of CLI.
The significance of the pw-port command under the fpe is to inform the system about the kind of cross-connect that needs to be built over PXC – in this case this cross-connect is PW-port specific. Applications other than PW-port may require different functionality over PXCs and this will be reflected by a different command under the fpe CLI hierarchy (for example vxlan-termination command instead of pw-port).
Note: the IP addresses setup on internal interfaces on PXC sub-ports are Martian IP addresses and they are shown in CLI as fpe_<id>.a and fpe_<id>.b.
Figure 209: Building the Internal LSP over PXCs
6.3.2.2. Mapping the External PW to the PW-Port
Mapping between the external PW and the FPE based PW-port is performed via an Epipe of type vc-switching. The user configurable Epipe (id 5 in this example) will aid in setting up steps 4, 5 and 6 in Figure 210:
- An internal PW is automatically added to the user configured Epipe 5
- A bind is created between the internal PW and the PW-port attached to PXC.
- External PW is switched to the internal PW.
At this stage, the external PW is mapped to the pw-port 1, as shown in Figure 210. The spoke-sdp 17000:1 and the binding under SDP 17001 (spoke-sdp 17001:100001) created in steps 4 and 5 (Figure 210) can be seen via show commands. However, they are not visible to the operator in the configure branch of CLI.
Figure 210: Mapping Between the External PW and the PXC Based PW-Port
6.3.2.3. Terminating the Service on PW-SAP
In the final step, PW-port SAP is applied to a service (Figure 211).
Figure 211: Service Termination on PW-SAP
6.3.3. FPE-Based PW-port Operational State
The FPE-based PW-port operational state is driven by the ability of the stitching service (see the following notes) to forward traffic. This includes the stitching service’s operational status and, if the external PW is TLDP signaled, the PW status bits. The operational flag for a non-operational PW-port is set to stitchingSvcTxDown.
Transitioning of the PW-port into down state due to a PXC failure (for example physical port fails), will bring the stitching service down with the following result:
- In case of TLDP-signaled PW, the psnIngressFault and psnEgressFault PW status bits is propagated to the remote end, indicating that the local stitching service is down.
- In case of EVPN, the EVPN route will be withdrawn, indicating that the local stitching service is down.
- In case of BGP-VPWS, the BGP-VPWS the ‘D’ bit of the Layer 2 Information Extended Community flag field is set, indicating that the local stitching service is down.
 | Note: The stitching service in this context is an Epipe service in vc-switching mode for BGP-VPWS or TLDP signaled PW, as follows: |
| Note: The stitching service in this context is an Epipe service in a non-vc-switching mode for EVPN, as follows: |
6.3.4. QoS
QoS fundamentals for the case where multiple PWs are multiplexed over a single cross-connect are shown in Figure 212.
Figure 212: QoS on FPE-Based PW-Port
Egress QoS may be applied on both sides of the cross-connect (PXC sub-ports .a and .b) to control congestion on the cross-connect itself. This can be accomplished via an Egress Port Scheduler (EPS) applied to each sub-port.
EPS applied to pxc-1.a (transit side) will manage congestion on the cross-connect for traffic coming from the external PWs. A single set of queues will be shared by all PWs utilizing this cross-connect in this direction.
EPS applied to the pxc-1.b (terminating side) will be used to manage congestion on the cross-connect for traffic going toward the PWs (leaving the SR OS node). A set of queues will be dedicated to each PW-port SAP.
QoS on PXC sub-ports is described in the “PXC” section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Interface Configuration Guide.
6.3.4.1. Preservation of Forwarding Class Across PXC
The internal cross-connect utilized by FPE based PW-port is relying on an MPLS tunnel built over internal network interfaces configured on PXCs. Those internal network interfaces are using a default network policy 1 for egress traffic classification, remarking and marking purposes. Since the PXC cross-connect is MPLS based, the EXP bits in newly added MPLS header will be marked according to the default network policy (for brevity reasons, only the relevant parts of the network policy are shown here).
As seen in this excerpt from the default network egress policy, the forwarding classes AF and L1 marks the EXP bits with the same values. This renders the forwarding classes AF and L1 set on one side of PXC, indistinguishable from each other on the other side of the PXC. This effectively reduces the number of forwarding classes from 8 to 7 in deployment scenarios where the QoS treatment of traffic depends on preservation of forwarding classes across PXC. That is, in such scenarios, one of the forwarding classes AF or L1 should not be used.
6.3.5. Statistics on the FPE based PW-Port
An FPE-based PW-port is associated with an internal spoke-SDP as described in PXC-Based PW-Port — Building the Cross-Connect and FPE-Based PW-port Operational Stateh. Statistics for the number of forwarded/dropped packets/octets per direction on a PW-port are therefore maintained per this internal spoke-SDP. Octets field counts octets in customer frame (including customer’s Ethernet header with VLAN tags). The following command is used to display PW-port statistics along with the status of the internal spoke-SDP associated with the PW-Port:
6.3.6. Intra-Chassis Redundancy Models for PXC-Based PW Port
Intra-chassis redundancy models rely on PXC-based LAG. PXC-based LAG can contain multiple PXCs on the same line card (port redundancy) or PXCs across different line cards (port- and card-level redundancy).FPE-based PW ports also provide network level-redundancy where MPLS/IP can be rerouted to different I/O ports (due to network failure) without interruption of service.
6.4. L2oGRE Termination on FPE-Based PW Port
L2oGRE termination on an FPE-based PW port allows Layer 2 customer traffic to be transported over an IP network to an SR OS node deeper in the network. In the SR OS node, the customer's payload delivered within L2oGRE tunnel is extracted onto a PW SAP (configured under an interface, group interface, or Epipe) and handed off to an Layer 2 or Layer 3 service. This allows the operator to quickly and simply expand their service offering to their customers over an existing IP network. New service offerings become independent of the existing IP network to which CEs are attached.
For secure operation, the transit IPv4/IPv6 network should be trusted or alternatively, GRE traffic can be secured by IPSec (L2oGREoIPSec).
Figure 213 shows a typical example where a customer payload is tunneled in GRE through an IPv4 or IPv6 network for an Layer 2 or Layer 3 handoff in an SR OS node that is placed deeper in the network.
Figure 213: L2oGRE Network Examples
6.4.1. L2oGRE Packet Format
The L2oGRE packet format is as follows:
The supported GRE header in this context is defined in RFC 2784, Generic Routing Encapsulation (GRE). The protocol type is set to 0x6558 (bridged Ethernet), and the Checksum and Reserved1 fields are normally omitted. The SR OS can accept headers with those two fields present, but the system omits them when encapsulating packets on transmission. Therefore, the transmitted GRE header length in the SR OS is 4 bytes.
6.4.2. GRE Delivery Protocol
The GRE delivery protocol (transport protocol) can be IPv4 or IPv6.
If the GRE delivery protocol is IPv4, then the protocol field in IPv4 header is set to value 47 (GRE). The same value (47 – GRE) is used on the Next Header field if the delivery protocol is IPv6.
6.4.3. Tracking Payloads and Service Termination Points
A customer payload within L2oGRE can be extracted onto a PW SAP inside an SR OS node. This PW SAP can be configured under an interface, subscriber interface, or an Epipe. Once on a PW SAP, customer traffic can be passed further into the network to its destination using Layer 2 or Layer 3 services. End-to-end Layer 2 and Layer 3 scenarios are described in the following sections.
6.4.3.1. Plain L3 termination
Figure 214 shows an example of plain Layer 3 termination with MTUs.
Figure 214: L2oGRE MTUs
In this example:
- Communication occurs between points 1 and 5.
- There may be a router present at point 2. A router at point 2 would see the SR OS node as Layer 3 next-hop.
- The device in point 3 encapsulates Layer 2 Ethernet frames into GRE and sends them to the SR OS node.
- The SR OS node at point 4 de-encapsulates the packet and performs an Layer 3 lookup on the inner packet in order to deliver it to the destination.
The following is an example where PW SAP is configured under a Layer 3 interface with a PW carrying IP over Ethernet:
6.4.3.2. Layer 2 Termination
Figure 215 shows an example of Layer 2 termination and hand-off.
Figure 215: Layer 2 Termination and Hand-off
In this example:
- Communication occurs between points 1 and 6.
- There may be a router present at point 2. A router at point 2 would see a Layer 3 device at point 5 as a Layer 3 next-hop. Everything in between is Layer 2.
- The device at point 3 encapsulates Layer 2 Ethernet frames into GRE and sends them to the SR OS node (7x50).
- The SR OS node at point 4 de-encapsulates the packet and sends it into the Layer 2 service that leads to the node at point 5.
The following shows an example of PW SAP configured under an Epipe:
6.4.3.3. ESM Termination
The primary case for ESM termination is business services. Figure 216 shows an example of ESM termination.
Figure 216: ESM Termination
In this example:
- Communication occurs between points 1 and 4.
- RG (Residential GW) at point 2 encapsulates L2 customer frames into GRE and sends them the SR OS node (7x50 BNG).
- The BNG node at point 3 terminates the subscriber traffic, performs an Layer 3 lookup, and sends it to the destination.
The following shows an example where a PW SAP is configured under a subscriber interface:
The following shows an example with the capture of a PW SAP configured:
6.4.4. Configuration Steps
L2oGRE tunnels are emulated as an SDP of type gre-eth-bridged (shown as GRE-B in the output of relevant show commands). This SDP defines two end-points on the tunnel:
- Far-end IP addressThis defines the IP address of the remote device that terminates the tunnel.
- Local IP address where the tunnel is terminated within an SR OSThis is a special IP address within an SR OS node that is not associated with any interface. It is only used for L2oGRE tunnel termination.
Binding an L2oGRE tunnel to an FPE-based PW port within the SR OS is performed through an Epipe service. Once the connection is established, the tunnel payload can be extracted to a PW SAP that can be used similarly to a regular SAP under Layer 3 interfaces, subscriber interfaces, or an Epipe.
Table 83 describes the L2oGRE sample configuration steps.
Table 83: L2oGRE Tunnel Sample Configuration
Step | Sample CLI | Comments |
PXC-based PW Port related configuration | ||
PW Port creation | pw-port 1 encap-type dot1q dot1q-etype 0x8100 | L2oGRE tunnel will be terminated on this PW port. |
Port-XC creation | port-xc pxc 1 create port 1/1/1 | This command triggers automatic creation of PXC sub-ports: configure port pxc-1.a port pxc-1.b This is where the L2oGRE terminating PW port will be anchored. |
Creation of FPE that will be used for PW port anchoring | fwd-path-ext sdp-id-range from 17400 to 17500 fpe 1 create path pxc 1 pw-port | The application under this FPE will be the PW port termination. The use of PW port in this case is versatile and can be used to terminate an L2oGRE or MPLS/GRE-based PW. In this example, it will be used to terminate an L2oGRE tunnel. |
L2oGRE tunnel definition | ||
Configuration of GRE-bridged tunnel termination IPv4/IPv6 addresses. | service>system>gre-eth-bridged tunnel-termination 10.1.1.2 fpe 1 service>system>gre-eth-bridged tunnel-termination 2001:db8 ::1 fpe 1 | This is a special IPv4/IPv6 address that is not configured under any Layer 3 interface and it must not overlap with any IPv4/IPv6 address configured under an Layer 3 interface in Base router. Multiple termination IPv4/IPv6 addresses are supported. |
Configuration of L2oGRE SDP | service> sdp 2 gre-eth-bridged create far-end 10.1.1.2 local-end 10.1.1.2 or service> sdp 2 gre-eth-bridged create far-end 2001:db8::2 local-end 2001:db8::1 | This represents the L2oGRE tunnel within SR OS as defined by the tunnel end-point IPv4/IPv6 addresses. |
Stitching L2oGRE tunnel to an anchored PW port | ||
Association between the PW port and a PXC port via FPE. | service>epipe 1 pw-port 1 fpe 1 | This command anchors the PW port 1 to a PXC port referenced in FPE 1. |
Binding between L2oGRE tunnel and the PW port | service>epipe 1 pw-port 1 fpe 1 spoke-sdp 2:1 | L2oGRE will be terminated on a PW port and the Layer 2 payload within the tunnel will be extracted on the PW SAP |
PW SAP service association | ||
Creation of services that use PW SAP | service>epipe 100 sap pw-1:100 create service>vprn 101>if sap pw-1:101 create | |
6.4.5. Fragmentation and MTU Configuration
IP fragmentation is only supported for L2oGRE with IPv4 transport. Traffic is subjected to several MTU checks in the downstream direction (toward the remote end of the L2oGRE tunnel) within the SR OS node, as shown in Figure 216.
Figure 217: L2oGRE MTUs
In the example:
- Port MTU represents the maximum frame size on the outgoing physical port.
- IP MTU is the maximum IP packet size on the outgoing IP interface.
- SDP Path MTU represents the maximum size of a frame that is encapsulated with the GRE tunnel. Its value is determined by the smallest MTU size on the path between the two GRE tunnel terminating end-points. The SDP Path MTU is calculated automatically by subtracting transport IP and GRE header bytes from the configured IP MTU of the outgoing interface.
- Service MTU indicates the maximum frame size that the customer can accept over the service (PW SAP). Its value is determined by the MTU size within the customer's network. The service MTU is configured within the VC-switching Epipe that stitches the L2oGRE spoke SDP to a PW port. The default value is set to 1514 bytes.
MTU values:
Figure 216 shows an example of IPv4 as the GRE delivery protocol.
- Port MTU = 1600 bytes (this is operator's configured value)
- IP MTU (of the outgoing interface) = 1600 bytes- 22 bytes= 1578 bytes (this is operator's configured value)
- SDP Path MTU = automatically calculated and set to 1578 bytes - 24 bytes = 1554 bytes.
- Service MTU = This value must be configured to a value no higher than 1554 bytes (SDP Path MTU).
Frames within an SR OS cannot be fragmented on a service or SDP level. However, L2oGRE traffic can be fragmented at the port level and for IPv4 traffic at any downstream point, if the DF bit in the IP header is cleared. The DF bit setting is controlled by the config>service>sdp>allow-fragmentation and config>service>pw-template>allow-fragmentation commands.
L2oGRE-v6 frames are subjected to the same MTU checks as IPv4 frames. However, IPv6 frames will not be fragmented if their size exceeds MTU, and instead, are dropped.
6.4.6. Reassembly
L2oGRE reassembly for IPv4 transport is supported through a generic reassembly function that requires an MS-ISA. As fragmented traffic enters an SR OS node, it is redirected to an MS-ISA via filters. Once the traffic is reassembled in the MS-ISA, it is re-inserted into the forwarding complex where normal processing continues (as if the non-fragmented traffic originally entered the node).
Table 84 describes the configuration steps to support reassembly for GRE.
Table 84: Configuring Reassembly For GRE
Step | Sample CLI | Comments |
Creation of a NAT-group that contains MS-ISAs | configure isa nat-group 1 mda 1/1 mda 2/1 | The reassembly function is performed in a NAT group that contains one or more MS-ISAs. |
Referencing a reassembly group that will be used for traffic in the Base routing context | configure router reassembly-group 1 | Identification of the reassembly group that will be used for traffic in the Base routing context. Upon reassembly, traffic will be re-inserted in the same (Base) routing context. Reassembly group ID corresponds to the NAT group ID (in this case 1). There can be multiple NAT groups (reassembly groups) configured in the system and this command identifies the reassembly group that will be used in the Base routing context. |
Identifying and directing fragmented traffic to the reassembly function. | configure filter ip-filter <id> default-action forward entry <id> create match protocol gre fragment true exit action reassemble exit | Fragmented GRE traffic is identified via a filter and redirected to the reassembly function. This filter must be applied to all ingress interfaces on which GRE traffic is expected to arrive. |