Certain applications in the SR OS require extra traffic processing in the forwarding plane. Such additional traffic processing is facilitated by an internal cross-connect that uses PXC ports (described in the Port Cross-Connect). Application-specific use of the cross-connect is built on the common premise that the traffic must be steered from the input ports to the PXC ports where the traffic can be looped for additional processing in the forwarding plane. To shield the operator from the intricacies involved when configuring application-specific cross-connect attributes, a CLI construct referred to as Forwarding Path Extensions (FPE) simplifies provisioning of various applications which rely on PXC functionality. The following are examples of applications that rely on PXC and FPE:
-
anchored PW-ports where PW payload termination in Layer 3 services is disjointed from I/O ports in the system
-
VXLAN termination on non-system IPv4 addresses and VXLAN IPv6 underlay
- origination or termination of a service with an SRv6 tunnel
- GTP-U tunnel termination for Fixed Wireless Access (FWA)
Application-specific uses of PXC ports and FPEs are described in the respective user guides (7450 ESS, 7750 SR, and VSR Triple Play Service Delivery Architecture Guide, 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: IES and VPRN, and 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide: VLL, VPLS, PBB, and EVPN).
The FPE configuration provides information to the SR OS node necessary to associate the application with the PXC (paired PXC sub-ports or PXC based LAG IDs). Consequently, the SR OS node sets up the internal logic utilizing PXC as required by the application.
An example of FPE provisioning is provided in Figure 1.
-
The first three steps are applicable to PXC port provisioning.
-
Association between the application and the PXC is performed in steps 4 and 5. In this particular example, two applications can be configured: PW-port or VXLAN-termination (non-system IPv4 termination or IPv6 underlay). These applications require internal configuration of SDPs and their IDs are allocated from the user configurable range. To prevent conflict between the user provisioned SDP IDs and internally configured SDP ID in FPE case, a range of SDP IDs that are used by FPE is reserved by the sdp-id-range commands under the config>fwd-path-ext CLI hierarchy.
-
Application-specific configuration is performed in step 6, partially by the operator and partially by the system. This is described in the application-specific user guides.
After the PXC sub-port or LAG is associated with an FPE object, the operator cannot use CLI to manually create IP interfaces and SAPs under these PXC sub-ports or LAGs. Only the SR OS system is allowed to reference these PXC sub-ports or LAGs in internal IP interfaces and SAPs, as required by each application.
The operator can modify PXC sub-port and LAG parameters (QoS, LAG profiles, and so on). To remove PXC sub-ports or LAGs from the FPE object, they must not be associated with an application.
Multipath FPE
Some applications require load-balancing over multiple PXC ports or LAGs of PXC ports; for example, the subscriber management application has limited forwarding and QoS resources per line card. To optimize resource usage, it is recommended to load balance sessions over multiple line cards. However, the subscriber-management application cannot use a LAG of PXCs for load-balancing because a LAG reserves subscriber-management resources on each line card that has LAG members. To solve this issue, use the configure fwd-path-ext fpe multi-path command to configure an FPE with multiple paths, each of which can be a PXC port or a LAG of PXC ports.
Support for multipath FPEs is application specific.