Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

MPLS Pseudowire Subscriber Logical Interfaces

Pseudowire Subscriber Logical Interfaces Overview

Subscriber management supports the creation of subscriber interfaces over point-to-point MPLS pseudowires. The pseudowire subscriber interface capability enables service providers to extend an MPLS domain from the access-aggregation network to the service edge, where subscriber management is performed. Service providers can take advantage of MPLS capabilities such as failover, rerouting, and uniform MPLS label provisioning, while using a single pseudowire to service a large number of DHCP and PPPoE subscribers in the service network.

Note:

Pseudowire subscriber logical interfaces are supported on Modular Port Concentrators (MPCs) with Ethernet Modular Interface Cards (MICs) only. PPPoE and L2TP termination is not supported when VPLS encapsulation and DHCP authentication is used for the transport logical interface. However, Broadband Subscriber Management Layer 2 Wholesale functionality is supported with VPLS encapsulation. A dynamic VLAN interface is created with VPLS encapsulation on a wholesaler router, that performs VLAN tag switching to terminate PPPoE/DHCP subscribers on the retailer network. For details, see Broadband Subscriber Management Layer 2 Wholesale Topology and Configuration Elements.

The pseudowire is a tunnel that is either an MPLS-based Layer 2 VPN or Layer 2 circuit. The pseudowire tunnel transports Ethernet encapsulated traffic from an access node (for example, a DSLAM or other aggregation device) to the MX Series router that hosts the subscriber management services. The termination of the pseudowire tunnel on the MX Series router is similar to a physical Ethernet termination, and is the point at which subscriber management functions are performed. A service provider can configure multiple pseudowires on a per-DSLAM basis and then provision support for a large number of subscribers on a specific pseudowire.

Figure 1 shows an MPLS network that provides subscriber management support.

At the access node end of the pseudowire, the subscriber traffic can be groomed into the pseudowire in a variety of ways, limited only by the number and types of interfaces that can be stacked on the pseudowire. You specify an anchor point, which identifies the logical tunnel interface that terminates the pseudowire tunnel at the access node.

Figure 1: MPLS Access Network with Subscriber Management SupportMPLS Access Network with Subscriber Management Support

Figure 2 shows the protocol stack for a pseudowire subscriber logical interface. The pseudowire is a virtual device that is stacked above the logical tunnel anchor point on the physical interface (the IFD), and supports a circuit-oriented Layer 2 protocol (either Layer 2 VPN or Layer 2 circuit). The Layer 2 protocol provides the transport and service logical interfaces, and supports the protocol family (IPv4, IPv6, or PPPoE).

Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the support for pseudowire subscriber service interface over redundant logical tunnels is introduced in Layer 3 VPNs and draft-rosen multicast VPNs. Earlier, Layer 3 VPNs provided support for pseudowire subscriber services over logical tunnel interfaces only, and these interfaces used unicast routing protocols, such as OSPF or BGP. With this support, you can provision a multicast routing protocol, Protocol Independent Multicast (PIM), on the pseudowire subscriber interfaces, which gets terminated on the virtual routing and forwarding (VRF) routing instance. Additionally, there is an increase in the scaling numbers of the pseudowire logical interface devices that provides additional resiliency support for pseudowire subscriber interfaces on redundant logical tunnel interfaces.

Note:

When a pseudowire subscriber service interface is anchored to a redundant logical tunnel whose member interface (or FPC) does not exist, the tunnel interface comes down. In such cases, the pseudowire interfaces (physical and logical) should also be down, but however, the pseudowire subscriber logical interface state remains up, although the Layer 2 circuit services, such as ping toward a customer edge (CE) device from the service side of the pseudowire subscriber service interface, are not available.

This is because the transport side of the pseudowire subscriber logical interface stays up causing the services to be up.

Figure 2: Pseudowire Subscriber Interface Protocol StackPseudowire Subscriber Interface Protocol Stack

The pseudowire configuration is transparent to the subscriber management applications and has no impact on the packet payloads that are used for subscriber management. Subscriber applications such as DHCP and PPPoE can be stacked over Layer 2 similar to the way in which they are stacked over a physical interface.

Starting with Junos OS release 16.1R1, family inet and family inet6 are supported on the services side of an MPLS pseudowire subscriber as well as non-subscriber logical interface.

Starting with Junos OS Release 16.1R1, Inline IPFIX is supported on the services side of an MPLS pseudowire subscriber logical interface.

Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, CCC encapsulation is supported on the transport side of an MPLS pseudowire subscriber logical interface.

Prior to Junos OS Release 19.1R1, the only supported encapsulation type on the pseudowire subscriber interfaces included:

  • Transport logical interfaces—Circuit cross-connect (CCC) encapsulation.

  • Service logical interfaces:

    • Ethernet VPLS encapsulation

    • VLAN bridge encapsulation

    • VLAN VPLS encapsulation

Starting in Junos OS Release 19.1R1, additional encapsulations are added to the pseudowire subscriber transport and service logical interfaces. The transport logical interface supports Ethernet VPLS encapsulation, and provisions for terminating the interface on the l2backhaul-vpn routing-instance. The service logical interface supports circuit cross-connect (CCC) encapsulation, and provisions for terminating the interface on locally switched Layer 2 circuits.

With the support of additional encapsulation types, you can benefit from demux of a l2backhaul VPN into multiple VPN services, such as Layer 2 circuit and Layer 3 VPN. Because pseudowire subscriber interfaces are anchored on redundant logical tunnels, this enhancement also provides line card redundancy.

Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, distributed denial-of-service (DDoS) protection is supported on the services side of an MPLS pseudowire subscriber logical interface.

Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, Policer and Filter are supported on the services side of an MPLS pseudowire subscriber logical interface.

Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, accurate transmit statistics on logical interface are supported on the services side of an MPLS pseudowire subscriber logical interface.

Starting with Junos OS Release 17.3R1 and later releases, stateful anchor point redundancy support is provided for pseudowire subscriber logical interface by the underlying redundant logical tunnel interface (rlt) in active-backup mode. This redundancy protects the access and the core facing link against anchor PFE (Packet Forwarding Engine) failure.

Anchor Redundancy Pseudowire Subscriber Logical Interfaces Overview

In MPLS pseudowire deployments that use pseudowire subscriber logical interfaces, failure of the Packet Forwarding Engine hosting the logical tunnel that anchors those logical interfaces leads to traffic loss and subsequent subscriber session loss.

The Packet Forwarding Engine does not rely on the control plane for failure detection; instead it uses a liveness detection mechanism, with an underlying heartbeat-based algorithm, to detect the failure of other Packet Forwarding Engines in the system. The failure of a Packet Forwarding Engine also indicates the failure of the hosted logical tunnel, which ultimately lead to session loss. To avoid this session loss, a redundant anchor point is required to which the session can be moved without losing any traffic.

Starting from Junos OS Release 17.3 onward, pseudowire subscriber logical interfaces can be instantiated over an underlying redundant logical tunnel (rlt) interface in active-backup mode. This is in addition to installing pseudowires over a single logical tunnel interfaces. The most noticeable advantage of implementing the pseudowire subscriber logical interface over redundant logical tunnel interfaces is to provide redundancy of the underlying forwarding path.

Prior to Junos OS Release 18.3R1, you could specify a maximum of 2048 pseudowire subscriber redundant logical tunnel interface devices for an MX Series router. Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the pseudowire redundant logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.

Junos OS Release 17.3 also supports an enhanced aggregated infrastructure for a Packet Forwarding Engine to provide anchor point redundancy. Enhanced aggregated infrastructure requires a minimum of one control logical interface that needs to be created on a redundant logical tunnel interface. Both transport and services logical interfaces created for the pseudowire subscriber logical interface are stacked on the underlaying control logical interface for the redundant logical tunnel. This stacking model is used for both redundant and nonredundant pseudowire subscriber logical interfaces.

The following events have to trigger the removal of the physical interface from a redundant group:

  • Hardware failure on Modular PIC Concentrator (MPC) or Modular Interfaces Card (MIC).

  • MPC failure due to microkernel crash.

  • MPC or MIC taken offline administratively.

  • Power failure on an MPC or a MIC.

Figure 3 provides the details of pseudowire subscriber logical interface stacking over a redundant logical tunnel interface.

Figure 3: Pseudowire Subscriber Logical Interface Stacking over Redundant Logical Tunnel InterfacePseudowire Subscriber Logical Interface Stacking over Redundant Logical Tunnel Interface
Note:

Static service ifl is not stacked over transport ifl when RLT is used.

By default, Link Protection for redundant tunnel interfaces is revertive. In case of the active link failure, traffic is routed through the backup link. When the active link is reestablished, traffic is automatically routed back to the active link. This causes traffic loss and subscriber session loss.

To overcome the traffic and session loss, you can configure nonrevertive link protection for redundant tunnel interfaces by using the configuration statement set interfaces rltX logical-tunnel-options link-protection non-revertive. With this configuration, when the active link is reestablished, traffic is not routed back to the active link and continue to be forwarded on the backup link. Therefore, there is no traffic loss or subscriber session loss. You can also manually switch traffic from the backup link to the active link by using the request interface (revert | switchover) interface-name command.

CAUTION:

The manual switching of the traffic incurs traffic loss.

Note:
  • A control logical interface is created implicitly on an redundant tunnel interface with the pseudowire subscriber logical interface configuration and thus no additional configuration is needed.

  • A redundant logical tunnel interface allows 32 member logical tunnel physical interfaces. However, a pseudowire subscriber logical interface hosted on the redundant logical tunnel interface limits the number of logical tunnel physical interfaces to two.

Note:

You cannot disable the underlying redundant logical tunnel (rlt) interface or the underlying logical tunnel (lt) interface when a pseudowire is anchored on that interface. If you want to disable the underlying interface, you must first deactivate the pseudowire.

Starting in Junos OS Release 18.4R1, the support for inline distribution of single-hop Bidirectional Forwarding Detection (BFD) sessions is extended to pseudowire subscriber over redundant logical tunnel interfaces. For pseudowire subscriber over logical tunnel interfaces, the interfaces are anchored on a single Flexible PIC Concentrator (FPC), as a result, the inline distribution of single-hop BFD sessions is supported by default. With pseudowire redundant logical interfaces, the member logical tunnel interfaces can be hosted on different linecards. Because the distribution address is not available for the redundant logical interfaces, the distribution of single-hop BFD sessions was operated in a centralized mode before Junos OS Release 18.4R1.

With the support for inline distribution of single-hop BFD sessions over pseudowire redundant logical interfaces, there is a scaling advantage of up to 2000 single-hop BFD sessions at an interval of one second, and improvement in detection time enhancing the performance of the sessions.

The BFD operation for pseudowire subscriber over redundant logical interfaces is as follows:

  1. When a new BFD session gets added it can either be anchored on an active or a backup FPC.

  2. When either of the FPCs fail or reboot, all the sessions hosted on that FPC go down, and re-anchoring is triggered for the next available distribution address. The BFD sessions come back up after the sessions are installed on the other FPC and BFD packet exchange is started.

    However, it is also possible that the sessions on the backup FPC might not go down when active FPC fails depending on the BFD detection time configured, as the forwarding state for the new active FPC might take some time to be programmed.

  3. When the active FPC fails, all the BFD sessions get anchored on the backup FPC. Similarly, if the backup FPC fails, all the BFD sessions get anchored on the active FPC.

  4. The BFD session re-anchoring is not triggered when the active FPC is online again.

  5. With the non-revertive behavior enabled, when the previously active FPC is online again, the sessions are not expected to go down. With the default revertive behavior, it is possible that forwarding state needs to be updated and depending on the detection time configuration, the session may or may not flap.

Note:

Take the following into consideration with the support of inline distribution of single-hop BFD sessions on pseudowire subscriber over logical tunnel interfaces:

  • On FPC type MPC 7e, with the activation of 7000 routing instance, it takes about six minutes for the 7000 BGP sessions to get established on the pseudowire subscriber interfaces anchored on redundant logical tunnel interfaces.

  • A new system log error message - JTASK_SCHED_SLIP - is recorded during nonstop active routing (NSR). This is expected behavior of NSR with high scale and can be safely ignored, unless there are other issues, such as session flaps, that require action to be taken.

Starting in Junos OS Release 21.4R1, we've introduced CoS support for a BNG on subscriber-interface on pseudowire over an active-active redundant logical tunnel (RLT) interface for subscriber applications such as DHCP and PPPoE. This CoS property is achieved by providing the scheduling nodes for the logical tunnel links. For dynamic interfaces, interface sets, static underlying interfaces, and dynamic underlying interfaces over RLT, CoS allocates scheduling nodes for each link in the RLT, which has multiple logical tunnel links in active-active mode. In case of targeted interfaces and targeted interface sets, which have primary and backup links, CoS allocates scheduling nodes on the primary and backup links to optimize the use of scheduling nodes. Traffic for the subscriber targeted interfaces will be distributed to all the primary LT links when CoS is applied at the subscriber level. Also, traffic from any given subscriber is always processed by the same Packet Forwarding Engine.

Figure 4 provides the details of the parent and child interfaces used for the four-level scheduler hierarchy for subscriber access. The dynamic PPPoE IFL and dynamic IFL-set are child nodes. The dynamic svlan IFL-set and dynamic or static uifl node are parent nodes.

Figure 4: Four-level Scheduler Hierarchy for Subscriber AccessFour-level Scheduler Hierarchy for Subscriber Access

When you enable targeting in a node, you must enable targeting for all the child nodes for CoS to function properly. To enable the child nodes, configure the dynamic profile at the [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile]. Create dynamic profile by configuring dynamic targeted interfaces and interface sets at the [edit dynamic-profiles].

Here's an example of the dynamic profile configuration:

Also, you must configure the network-services enhanced-ip at the [edit chassis] hierarchy level because this feature works only in enhanced IP mode.

The active-active multiple link mode with targeting uses the targeting algorithms for RLT interface to distribute clients among the different RLT member (primary/secondary leg pairs). Targeting can be applied for dynamic subscribers and dynamic interface sets. The targeting algorithm goes through the list of pseudo IFLs associated with the member link pair and selects the first pseudo IFL that has sufficient capacity based on the configured rebalance-subscriber-granularity.

When targeting is enabled, the subscriber is assigned a default targeting weight based on the client type. The targeting algorithm uses allocation weight in the pseudo IFL selection process and IFL’s debit weight is the weight counted against the assigned pseudo IFL. For all objects except the IFLset, the allocation and debit weight are the same and you can modify through the client profile. In case of the IFLset, only the allocation weight attribute can be modified through the client profile, and debit weight for the IFLset is fixed at a value of 0.

Table 1: Default Weights for Different Client Types

Client Type

Allocation Weight

Debit Weight

Dvlan

1

1

IpDemux

1

1

PPP

1

1

IFLset

32

0

PWHT for ACX Devices Overview

For ACX devices using BNG CUPS mode for subscriber management, PWHT terminates MPLS pseudowire control and forwards data packets to their destination using standard IP protocol.

Pseudowire and PWHT (pseudowire headend termination) features on ACX devices that support this feature require the device to be running in BNG CUPS mode. In CUPS mode, the control plane is run from a centralized cloud, while the user plane runs on the device. All pseudowire and PWHT features are available to you in BNG CUPS mode. See BNG CUPS User Guide for more details on how to configure your device in CUPS mode.

Use Feature Explorer to confirm platform and release support for specific features.

PWHT is used to terminate MPLS pseudowire control at the service provider edge router. Upon exit from the pseudowire, control information is punted to the centralized control plane, while regular data is forwarded to its destination as standard IP packets.

To configure PWHT on your ACX device, your device must first be configured for CUPS mode. Please see Configuring BNG CUPS Controller and Configuring BNG User Planes for more information.

PWHT configuration happens in the user plane (your device) rather than in the control plane (cloud). This is done because the logical tunnel (lt) and pseudowire (ps) interfaces must be created inside the user plane within Junos OS Evolved. The commands to configure your lt and ps interfaces are the same as in Junos OS; however, ACX devices require the slot and core numbers of the PWHT anchor in the configuration. ACX devices also require you to manually configure your bandwidth reservation.

Here is an example of a configuration for an FEB-based ACX device.

Here is an example of a configuration for an FPC-based ACX device.

Here is an example of a pseudowire (ps) interface configuration.

Configuring PWHT for ACX Devices

How to configure PWHT on ACX devices in BNG CUPS mode.

ACX devices that support PWHT features must be in CUPS mode. Refer to BNG CUPS User Guide to configure your device in CUPS mode.

To configure your lt interface and total reserved bandwidth, follow these steps.

  1. Configure the logical tunnel interface and the total bandwidth you want to reserve for the logical tunnel. Bandwidth must be configured in Gbps. ACX devices cut the total bandwidth value you set in half for upstream and downstream directions. For example, if you set a total bandwdith of 10Gbps, then 5 Gbps would be reserved for upstream traffic and 5 Gpbs would be reserved for downstream traffic.

    For FPC-based devices, use the following command:

    For FEB-based devices, use the following command:

  2. (Optional) If the bandwidth requirements for your interface will be very high, you will also need to configure bandwidth recycling. You will need to evaluate the specific bandwidth requirements of your PWHT interface and configure these values based on your network configuration.

    Use the following commands to configure bandwidth recycling:

  3. After your logical tunnel and bandwidth have been configured, you will configure your pseudowire interface. Like the lt and bandwidth settings, the ps interface will also be configured in the user plane.
    1. Set the anchor point for your ps interface.
    2. Configure your VLAN options for the ps interface. Protocol type must be dhcp-v4, dchp-v6, or pppoe.

Configuring a Pseudowire Subscriber Logical Interface

A pseudowire subscriber logical interface terminates an MPLS pseudowire tunnel from an access node to the MX Series router that hosts subscriber management, and enables you to perform subscriber management services at the interface.

To create a pseudowire subscriber logical interface:

  1. Specify the number of pseudowire logical interfaces that the router can support.
  2. Configure the pseudowire subscriber logical interface device.
  3. Configure the transport logical interface.
  4. Configure the signaling for the pseudowire subscriber interface. You can use either Layer 2 circuit signaling or Layer 2 VPN signaling. The two signaling types are mutually exclusive for a given pseudowire.
  5. Configure the service logical interface.
  6. Configure the underlying interface device.
  7. Configure CoS parameters and BA classification.
  8. (Optional) Associate a dynamic profile with the pseudowire subscriber logical interface.

    You can associate DHCP, PPPoE, IP demux, and VLAN dynamic profiles with pseudowire subscriber logical interfaces. The support is similar to the typical Ethernet interface support.

    Note:

    When using a PPPoE dynamic profile to create a pseudowire subscriber logical interface over a demux interface device, the dynamic profile must explicitly specify the correct pseudowire interface device over which the interface is created. The dynamic profile does not automatically create the interface over the demux0 interface device, as is the case with a VLAN demux interface.

  9. (Optional) Configure interface set support for pseudowire subscriber logical interfaces.
  10. (Optional) Stack PPPoE logical interfaces over a pseudowire logical device.
  11. (Optional) Load balancing support for subscriber traffic on pseudowire service (PS) interface. See Configuring load balancing support for subscriber traffic.
  12. (Optional) Configure the pseudowire interface for single-link targeting. See

Configuring the Maximum Number of Pseudowire Logical Interface Devices Supported on the Router

You must set the maximum number of pseudowire logical interface devices (pseudowire tunnels) that the router can use for subscriber logical interfaces. Setting the maximum number also defines the interface names for the pseudowire interfaces. When you subsequently configure the interfaces, you must specify the interface names in the range from ps0 up to ps(device-count - 1).

For example, if you set the maximum number of devices to 5, then you can configure only interfaces ps0, ps1, ps2, ps3, and ps4.

Before Junos OS Release 17.2R1, you could specify a maximum of 2048 pseudowire logical interface devices for an MX Series router. Starting in Junos OS Release 17.2R1, on MX Series routers with MPC and MIC interfaces, the pseudowire logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.

Similarly, before Junos OS Release 18.3R1, you could specify a maximum of 2048 pseudowire subscriber redundant logical tunnel (rlt) interface devices for an MX Series router. Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the pseudowire redundant logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.

Starting in Junos OS Release 20.4R1, on MX2010 and MX2020 routers with the MX2K-MPC9E or MX2K-MPC11E line card, you can specify up to 18000 pseudowire logical interface devices.

The PFE hosting the maximum pseudowire logical interface devices provides the configuration flexibility needed for special cases that might occur for business edge scenarios. However, you can exceed the available PFE resources as you configure additional services on the pseudowire logical interface devices ports. To support a scaled configuration, ensure that you populate the appropriate number of PFEs for the chassis, and that you distribute the pseudowire logical interface devices across the PFEs in such a way that ensures that no PFE is overwhelmed by the anticipated peak load. As part of the network planning for your particular deployment, you must consider the exact mix of the distribution of the pseudowire logical interface devices and the services associated with the devices.

Best Practice:

A configured pseudowire logical interface device consumes resources from shared pools even when the device has no active subscriber logical interfaces. To conserve resources, do not deploy an excessive number of pseudowire devices that you do not intend to use.

To configure the number of pseudowire logical interface devices that you want the router to support:

  1. Specify that you want to configure the pseudowire service.
  2. Set the maximum number of pseudowire logical interface devices.

Configuring a Pseudowire Subscriber Logical Interface Device

To configure a pseudowire logical interface device that the router uses for subscriber logical interfaces, you specify the logical tunnel that processes the pseudowire termination. You can also use redundant logical tunnels to provide redundancy for member logical tunnels. You can configure additional optional parameters for the interface device, such as VLAN tagging method, MTU, and gratuitous ARP support.

Note:

You must create a logical tunnel for the pseudowire logical interface device. If you are using redundant logical tunnels, you must create the redundant tunnel.

To configure the pseudowire subscriber interface device:

  1. Specify that you want to configure the pseudowire subscriber logical interface device.
    Note:

    The available interface names are determined by the [edit chassis pseudowire-service device-count] statement. The names you specify must be in the range ps0 through ps(device-count - 1). If you specify an interface name outside that range, the pseudowire interface is not created.

  2. Specify the logical tunnel interface that is the anchor point for the pseudowire logical interface device. The anchor point must be an lt device in the format lt-fpc/pic/port.
    CAUTION:

    Do not reconfigure the logical tunnel interface that is associated with the pseudowire subscriber interface device unless you first deactivate all subscribers that are using the pseudowire subscriber interface.

    Note:

    Tunnel services must be enabled on the lt interface that is the anchor point or a member link in a redundant logical tunnel. You use the command, set chassis fpc slot-number pic pic-number tunnel-services bandwidth bandwidth to enable tunnel services.

    Note:

    You cannot disable the underlying logical tunnel (lt) interface or redundant logical tunnel (rlt) interface when a pseudowire is anchored on that interface. If you want to disable the underlying interface, you must first deactivate the pseudowire.

  3. (Optional) Specify the MAC address for the pseudowire logical interface device.
    Note:

    You should ensure that you change the MAC address before passing traffic or binding subscribers on the pseudowire port. Changing the MAC address when the pseudowire port is active (for example, while an upper layer protocol is negotiating) can negatively impact network performance until adjacencies learn of the new MAC address.

  4. (Optional) Specify the VLAN tagging method used for the pseudowire logical interface device. You can specify single tagging, dual (stacked) tagging, mixed (flexible) tagging, or no tagging.

    See Enabling VLAN Tagging for additional information about VLAN tagging.

  5. (Optional) Specify the encapsulation type for the pseudowire logical interface device.

    Starting in Junos OS Release 19.1R1, you can configure additional encapsulations – Ethernet VPLS and circuit cross-connect-based encapsulations – for the transport and service pseudowire subscriber logical interface devices, respectively.

  6. (Optional) Specify the MTU for the pseudowire logical interface device. If you do not explicitly configure the MTU, the router uses the default value of 1500.

    See Setting the Protocol MTU for additional information.

  7. (Optional) Specify that the pseudowire logical interface device does not respond to gratuitous ARP requests.

    See Configuring Gratuitous ARP for additional information.

  8. (Optional) Specify that reverse-path forwarding checks are performed for traffic on the pseudowire logical interface device.

    See Understanding Unicast RPF (Routers) for additional information.

  9. Configure additional optional parameters for the pseudowire logical interface device, such as description, apply-groups, apply-groups-except, and traceoptions.

Changing the Anchor Point for a Pseudowire Subscriber Logical Interface Device

You cannot dynamically change an anchor point that has active pseudowire devices stacked above it. You must commit certain changes before you move the anchor point. Examples of this situation include moving the anchor point from one logical tunnel to another logical tunnel, from a logical tunnel to a redundant logical tunnel, and from a redundant logical tunnel to a logical tunnel.

To move the anchor point between logical tunnel interfaces:

  1. Deactivate the stacked pseudowires and commit. This may require bringing down any subscribers using the pseudowires.
  2. Change the anchor on the deactivated pseudowire to the new logical tunnel interface and commit.
  3. Reactivate the stacked pseudowires and commit.

To move the anchor point from a logical tunnel interface to a redundant logical tunnel interface:

  1. Deactivate the stacked pseudowires and commit. This may require bringing down any subscribers using the pseudowires.

  2. Add the new redundant logical tunnel interface and commit.

    1. Create the tunnel and set the maximum number of devices allowed.

    2. Bind each member logical tunnel to the redundant logical tunnel.

      Note:

      Redundant logical tunnels require members to be in active-backup mode. The backup logical tunnel must be on a different FPC than the active logical tunnel. For example, if the active tunnel is on FPC 3, then the backup tunnel must be on a different FPC, such as FPC 4.

    3. Commit your changes.

  3. Change the anchor on the deactivated pseudowire to the new redundant logical tunnel interface and commit.

  4. Reactivate the stacked pseudowires and commit.

To move the anchor point from a redundant logical tunnel interface to a logical tunnel interface that is a member of the redundant logical tunnel:

  1. Deactivate the stacked pseudowires; this may require bringing down any subscribers using the pseudowires. Delete the redundant logical tunnel interface and commit your changes.

  2. Change the anchor on the deactivated pseudowire to the new logical tunnel interface and commit.

  3. Reactivate the stacked pseudowires and commit.

Configuring the Transport Logical Interface for a Pseudowire Subscriber Logical Interface

This topic describes how to configure a pseudowire transport logical interface. A pseudowire device can have only one transport logical interface.

A pseudowire logical device and its related pseudowire logical interfaces are dependent on the state of the underlying logical transport interface device, which is either the Layer 2 VPN or Layer 2 circuit.

Note:

We recommend that you use unit 0 to represent the transport logical interface for the pseudowire device. Non-zero unit numbers represent service logical interfaces used for pseudowire subscriber interfaces.

To configure a pseudowire transport logical interface:

  1. Specify that you want to configure the pseudowire subscriber logical interface device.
  2. Specify that you want to configure unit 0, which represents the transport logical interface.
  3. (Optional) Specify the encapsulation method for the transport logical interface.

    Starting in Junos OS Release 19.1R1, you can configure Ethernet VPLS encapsulation, in addition to circuit cross-connect-based encapsulations for pseudowire subscriber transport logical interfaces.

  4. (Optional) Configure the termination of the transport logical interface on l2backhaul-vpn routing-instance. This support is enabled from Junos OS Release 19.1R1.

Configuring Layer 2 Circuit Signaling for Pseudowire Subscriber Logical Interfaces

This topic describes the steps for configuring Layer 2 circuit signaling used for the pseudowire subscriber logical interface support. You can also use Layer 2 VPN signaling for pseudowire subscriber logical interfaces. The two methods are mutually exclusive; you can use only one method for a particular pseudowire.

To configure Layer 2 circuit signaling for pseudowire interfaces:

  1. Specify that you want to configure Layer 2 circuit parameters at the protocols hierarchy level.
  2. Specify the IP address of the neighbor, to identify the PE router used for the Layer 2 circuit.
  3. Specify the interface used by the Layer 2 circuit traffic.
  4. Configure the virtual circuit ID that identifies the Layer 2 circuit for the pseudowire.

For more information about Layer 2 circuits, see Configuring Interfaces for Layer 2 Circuits.

Configuring Layer 2 VPN Signaling for Pseudowire Subscriber Logical Interfaces

This topic describes the steps for configuring Layer 2 VPN signaling used for the pseudowire subscriber logical interface support. You can also use Layer 2 circuit signaling for pseudowire subscriber logical interfaces. The two methods are mutually exclusive; you can use only one method on a particular pseudowire.

To configure Layer 2 VPN signaling for pseudowire interfaces:

  1. Specify the name of the routing instance you want to configure.
  2. Configure the Layer 2 VPN routing instance type.
  3. Associate the pseudowire logical interface for the Layer 2 VPN.
  4. Configure the unique identifier for the routes that belong to the Layer 2 VPN.
  5. Configure the VPN routing and forwarding (VRF) target of the routing instance.
  6. Specify that you want to configure the Layer 2 VPN protocol for the routing instance.
  7. Configure the encapsulation type for the routing instance.
  8. Specify the site name and site identifier for the Layer 2 VPN.
  9. Specify the interface that connects to the site, and the remote interface to which you want the specified interface to connect.
  10. Configure the tracing options for traffic that uses the Layer 2 VPN.

Configuring the Service Logical Interface for a Pseudowire Subscriber Logical Interface

This topic describes how to configure a pseudowire service logical interface. Service logical interfaces represent the attachment circuits for pseudowire logical interfaces.

As described in the Pseudowire Subscriber Logical Interfaces Overview, you can choose whether to configure a service logical interface together with a higher subscriber logical interface, depending upon the business need. In a broadband edge configuration, the higher subscriber logical interface is the demarcation point for subscribers. However, in a business edge configuration, the service logical interface is the demarcation point for the business subscribers, and also serves as the subscriber logical interface, so no subscriber logical interfaces are explicitly configured.

Note:

Non-zero unit numbers represent service logical interfaces used for pseudowire subscriber interfaces. Use unit 0 to represent the transport logical interface for the pseudowire device.

To configure a pseudowire service logical interface:

  1. Specify that you want to configure the pseudowire subscriber logical interface device.
  2. Configure the unit for the service logical interface. Use a non-zero unit number.
  3. (Optional) Specify the encapsulation type for the service logical interface.

    Starting in Junos OS Release 19.1R1, you can configure circuit cross-connect-based encapsulations, in addition to the Ethernet VPLS, VLAN bridge, and VLAN VPLS encapsulations for pseudowire subscriber service logical interfaces.

    The pseudowire subscriber service logical interfaces support single-tagged traffic, double-tagged traffic, and list of VLANs on the single logical interface.

  4. (Optional) Configure filters and policers on the family circuit cross-connect encapsulation.
  5. Configure the VLAN tag IDs.
  6. Configure the interface to respond to ARP requests when the device has an active route to the ARP request target address.
  7. Specify that you want to configure the protocol family information. Pseudowire service logical interfaces support IPv4 (inet), IPv6 (inet6), and PPPoE (pppoe) protocol families.

    For example, to configure the IPv4 family:

    1. Specify that you want to configure IPv4.

    2. Configure the parameters for the family.

  8. (Optional) Configure the termination of the service logical interface on locally switched Layer 2 circuits. This support is enabled from Junos OS Release 19.1R1.

Configuring a PWHT with VC 11 Type Support

You can configure a pseudowire headend termination (PWHT) interface on a service PE router and configure ethernet-tcc encapsulation on the pseudowire subscriber (PS) transport logical interface.

When you use this feature, the service PE router does not have to support TDM/SONET/SDH-encapsulated traffic coming from access-side customers. The IP-based point-to-point pseudowire—which is an LDP-signaled FEC 128 (virtual circuit (VC) type 11)—connects the service PE router to the access device that is connected to the CE router. You configure the pseudowire to terminate into a Layer 3 VPN instance or a global IP table.

The feature supports IPv4 and IPv6 payloads and unicast and multicast traffic.

The service PE router uses ARP mediation to resolve Layer 2 addresses when different resolution protocols are used on either end of a circuit. To the service PE router, the access CE router appears as though locally connected. This ARP mediation is provided by proxy ARP on IPv4 addresses and by Neighbor Discovery Protocol (NDP) on IPv6 addresses. The service PE router creates a local ARP entry that corresponds to the access CE router's IPv4 address or adds the access CE router's IPv6 address to the neighbor table.

Before you configure the interfaces and the l2circuit protocol for the PWHT with VC 11 type support:

Note:

When you enable family tcc and encapsulation ethernet-tcc on a PS interface, note the following constraints on the configuration:

  • Support for only one IP pseudowire per PS physical interface
  • No support for a control word; for BFD over the PS interface; or for active-standby, hot-standby, or all-active configuration on the IP pseudowire

To configure PWHT on the service PE router with termination into a Layer 3 VPN instance:

  1. Configure the redundant logical tunnel (RLT) with this command:
  2. Configure the interfaces—Configure the redundancy group and member interfaces on the rlt interface; configure the anchor point, which is on the rlt interface; and configure the PS transport and service logical interfaces. Configure family tcc and encapsulation-type ethernet-tcc on the transport logical interface. See an example of the interfaces configuration just after the Note.
    Note:
    • Configure only one PS service logical interface.
    • ARP could be generated on the service PE router for all IP addresses within the subnet configured on the PS service logical interface. To prevent generation of many ARPs, we recommend that you use a /30 or /31 subnet on the PS service logical interface.
  3. Configure the l2circuit protocol and include the send-ip-addr-list-tlv statement to signal that an IP TLV is sent. Configure the encapsulation type on the transport logical interface as internetworking. Here's an example of the protocol configuration:

    You can use the following show commands to view the results of this configuration:

    • Use the show route table l2circuit.0 command to see that VC type 11 has been enabled.
    • Use the show l2circuit connections extensive command to see that encapsulation is set to internetworking.
    • Use the show route table mpls.0 protocol l2circuit command to see that the label route and tcc route for forwarding the traffic out of the IP pseudowire and into the IP pseudowire have been added.

Configuring Load Balancing Support for Subscriber Traffic

Configure the RLT with the router's LT links in active-active mode. RLT applications can be enhanced to include LT child member links as an aggregated property.

Starting in Junos OS Release 21.4R1, we provide load balancing support for subscriber sessions on the PS interface over multiple LT child member links of the RLT at the same time. The load balancing property of the RLT interface allows subscriber traffic on the PS interface to be dispersed and load-balanced over different PICs and line-cards.

For RLT interface supports PS anchor point redundancy to enhance LAG mode. Use the enhanced-ip option or the enhanced-ethernet option at the [edit chassis network-services] hierarchy level while configuring PS IFD anchored on RLT.

Computed hash is used in selecting an ECMP path and load balancing. You can configure load balancing for IPv4 traffic over Layer 2 Ethernet pseudowires. You can also configure load balancing for Ethernet pseudowires based on IP information.

Limitations

  • The BNG load balancing support on the pseudowire subscriber (PS) interface feature is supported only for all trio-based line-cards supporting the BBE access model on the MX Series routers.

  • You cannot change the PS anchor point unless you disable the PS physical interface.

  • Transient traffic disruption may occur when you add or remove an RLT member. Adding or removing RLT member link behaviour is similar to any other aggregate interface behaviour.

  • Ingress stats for each LT member are not available. However, aggregate PS IFL or IFD statistics are available for both directions.

  • RLT active-active mode is supported only for subscriber services.

Below are not supported for the current load-balancing support on PS over RLT over multiple active child LT links

  • PS over RLT interface support on MX240, MX480, and MX960 line cards.

  • CoS support of hierarchical policer interface for active-active mode member links

  • CoS aggregated Ethernet support for subscriber traffic on pseudowire service (PS) interface

  • L2 Service IFL and business-edge (L3) support for active-active mode member link

  • PS interface support on non redundant

  • Hierarchical CoS support for anchor point redundancy of pseudowire subscriber logical Interfaces

To configure the load balancing support for subscriber traffic:

  1. Configure the extended DHCP local server options on the router, see Configure a Router as an Extended DHCP Local Server.
  2. Configure two logical tunnels on two different line cards to create a redundant logical tunnel (RLT).
  3. Configure RLT interface and include the logical tunnel interface in the redundancy group by configuring member-interface interface-name. Configuring RLT interface, see Configuring a Pseudowire Subscriber Logical Interface Device
  4. Configure dynamic profiles for subscriber management, see Dynamic Profiles for Subscriber Management.
  5. Configuring l2circuit with a backup neighbor that has the same virtual-circuit-id, see Example: Configuring Longest Match for LDP.
  6. Tunnel egress bandwidth utilisation can be verified using LT interface egress statistics. View your configuration for PS over RLT active-active mode support.

Change History Table

Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.

Release
Description
24.4R1-EVO
Starting in Junos OS Evolved Release 24.4R1, PWHT for subscriber management is supported on ACX platforms running in BNG CUPS mode. Use Feature Explorer to confirm platform and release support for specific features.
21.4R1
Starting in Junos OS Release 21.4R1, we've introduced CoS support for BNG on subscriber-interface on pseudowire (PS) over active-active redundant logical tunnel (RLT) interface for subscriber applications such as DHCP and PPPoE.
21.4R1
Starting in Junos OS Release 21.4R1, we provide load balancing support for subscriber sessions on the PS interface over multiple LT child member links of the RLT at the same time. The load balancing property of the RLT interface allows subscriber traffic on the PS interface to be dispersed and load-balanced over different PICs and line-cards.
21.2R1
Starting in Junos OS Release 21.2R1, you can configure a PWHT interface on a service PE router with ethernet-tcc encapsulation on the interface. The pseudowire is VC type 11.
20.4R1
Starting in Junos OS Release 20.4R1, on MX2010 and MX2020 routers with the MX2K-MPC9E or MX2K-MPC11E line card, you can specify up to 18000 pseudowire logical interface devices.
19.1R1
Starting in Junos OS Release 19.1R1, additional encapsulations are added to the pseudowire subscriber transport and service logical interfaces. The transport logical interface supports Ethernet VPLS encapsulation, and provisions for terminating the interface on the l2backhaul-vpn routing-instance. PPPoE and L2TP termination is not supported when VPLS encapsulation is used for the transport logical interface. The service logical interface supports circuit cross-connect (CCC) encapsulation, and provisions for terminating the interface on locally switched Layer 2 circuits.
19.1R1
Starting in Junos OS Release 19.1R1, you can configure additional encapsulations – Ethernet VPLS and circuit cross-connect-based encapsulations – for the transport and service pseudowire subscriber logical interface devices, respectively.
19.1R1
Starting in Junos OS Release 19.1R1, you can configure Ethernet VPLS encapsulation, in addition to circuit cross-connect-based encapsulations for pseudowire subscriber transport logical interfaces.
19.1R1
Starting in Junos OS Release 19.1R1, you can configure circuit cross-connect-based encapsulations, in addition to the Ethernet VPLS, VLAN bridge, and VLAN VPLS encapsulations for pseudowire subscriber service logical interfaces.
18.4R1
Starting in Junos OS Release 18.4R1, the support for inline distribution of single-hop Bidirectional Forwarding Detection (BFD) sessions is extended to pseudowire subscriber over redundant logical tunnel interfaces.
18.3R1
Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the support for pseudowire subscriber service interface over redundant logical tunnels is introduced in Layer 3 VPNs and draft-rosen multicast VPNs.
18.3R1
Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the pseudowire redundant logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.
18.3R1
Starting in Junos OS Release 18.3R1, on MX Series routers with MPC and MIC interfaces, the pseudowire redundant logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.
17.3R1
Starting with Junos OS Release 17.3R1 and later releases, stateful anchor point redundancy support is provided for pseudowire subscriber logical interface by the underlying redundant logical tunnel interface (rlt) in active-backup mode. This redundancy protects the access and the core facing link against anchor PFE (Packet Forwarding Engine) failure.
17.2R1
Starting in Junos OS Release 17.2R1, on MX Series routers with MPC and MIC interfaces, the pseudowire logical interface devices scaling numbers has increased to 7000 devices to provide additional resiliency support.
16.1R1
Starting with Junos OS release 16.1R1, family inet and family inet6 are supported on the services side of an MPLS pseudowire subscriber as well as non-subscriber logical interface.
16.1R1
Starting with Junos OS Release 16.1R1, Inline IPFIX is supported on the services side of an MPLS pseudowire subscriber logical interface.
15.1R3
Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, CCC encapsulation is supported on the transport side of an MPLS pseudowire subscriber logical interface.
15.1R3
Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, distributed denial-of-service (DDoS) protection is supported on the services side of an MPLS pseudowire subscriber logical interface.
15.1R3
Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, Policer and Filter are supported on the services side of an MPLS pseudowire subscriber logical interface.
15.1R3
Starting with Junos OS Release 15.1R3 and 16.1R1 and later releases, accurate transmit statistics on logical interface are supported on the services side of an MPLS pseudowire subscriber logical interface.