ON THIS PAGE
Anchor Redundancy Pseudowire Subscriber Logical Interfaces Overview
Configuring the Maximum Number of Pseudowire Logical Interface Devices Supported on the Router
Configuring a Pseudowire Subscriber Logical Interface Device
Changing the Anchor Point for a Pseudowire Subscriber Logical Interface Device
Configuring the Transport Logical Interface for a Pseudowire Subscriber Logical Interface
Configuring Layer 2 Circuit Signaling for Pseudowire Subscriber Logical Interfaces
Configuring Layer 2 VPN Signaling for Pseudowire Subscriber Logical Interfaces
Configuring the Service Logical Interface for a Pseudowire Subscriber Logical Interface
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.
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 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.
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.
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.
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.
The manual switching of the traffic incurs traffic loss.
-
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.
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:
-
When a new BFD session gets added it can either be anchored on an active or a backup FPC.
-
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.
-
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.
-
The BFD session re-anchoring is not triggered when the active FPC is online again.
-
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.
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.
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:
dvlanProf { interfaces { "$junos-interface-ifd-name" { unit "$junos-interface-unit" { demux-source [ inet inet6 ]; no-traps; proxy-arp; vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id"; targeted-distribution; family inet { unnumbered-address lo0.0 preferred-source-address 100.0.0.1; } family inet6 { unnumbered-address lo0.0 preferred-source-address 1000:0::1; } family pppoe { duplicate-protection; dynamic-profile pppoeClientSvlanSetVar; } } } } }
pppoeClientSvlanSetVar { interfaces { interface-set "$junos-svlan-interface-set-name" { targeted-distribution; interface pp0 { unit "$junos-interface-unit"; } } pp0 { unit "$junos-interface-unit" { actual-transit-statistics; ppp-options { pap; } pppoe-options { underlying-interface "$junos-underlying-interface"; server; } targeted-distribution; keepalives interval 30; family inet { unnumbered-address "$junos-loopback-interface"; } } } } }
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.
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.
chassis { feb 0 { pfe 0 { core 0 { channel 0 { tunnel-services { bandwidth 10g; } } } } } }
Here is an example of a configuration for an FPC-based ACX device.
chassis { fpc 0 { pfe 0 { core 0 { channel 0 { tunnel-services { bandwidth 10g; } } } } } }
Here is an example of a pseudowire (ps) interface configuration.
interfaces { ps1 { anchor-point { lt-0/0/0:0 { } flexible-vlan-tagging; auto-configure { stacked-vlan-ranges { dynamic-profile svlan-prof { accept [dhcp-v4 dchp-v6 pppoe]; ranges { any,any; } } } } } }
See Also
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.
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:
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.
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:
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.
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:
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:
To move the anchor point from a logical tunnel interface to a redundant logical tunnel interface:
Deactivate the stacked pseudowires and commit. This may require bringing down any subscribers using the pseudowires.
[edit interfaces] user@host# deactivate psnumber user@host# commit
Add the new redundant logical tunnel interface and commit.
Create the tunnel and set the maximum number of devices allowed.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count count
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.
[edit interfaces rltnumber] user@host# set redundancy-group member-interface lt-fpc/pic/port active user@host# set redundancy-group member-interface lt-fpc/pic/port backup
Commit your changes.
[edit interfaces rltnumber] user@host# commit
Change the anchor on the deactivated pseudowire to the new redundant logical tunnel interface and commit.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Reactivate the stacked pseudowires and commit.
[edit interfaces] user@host# activate psnumber user@host# 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:
Deactivate the stacked pseudowires; this may require bringing down any subscribers using the pseudowires. Delete the redundant logical tunnel interface and commit your changes.
[edit interfaces] user@host# deactivate psnumber user@host# delete rltnumber user@host# commit
Change the anchor on the deactivated pseudowire to the new logical tunnel interface and commit.
[edit interfaces] user@host# set psnumber anchor-point lt-fpc/pic/port user@host# commit
Reactivate the stacked pseudowires and commit.
[edit interfaces] user@host# activate psnumber user@host# 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.
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:
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:
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:
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.
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:
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:
- Configure the target LDP session for the Layer 2 circuit. See Configuring LDP for Layer 2 Circuits .
- Configure the Layer 3 VPN. See Introduction to Configuring Layer 3 VPNs.
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:
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:
See Also
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.
ethernet-tcc
encapsulation on the interface. The pseudowire is VC type
11.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.family inet
and family inet6
are supported on the services side of an MPLS pseudowire subscriber
as well as non-subscriber logical interface.