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.
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 or PTX 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.
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 prior to 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 around 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.
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:
- Specify the number of pseudowire logical interfaces that
the router can support.
See Configuring the Maximum Number of Pseudowire Logical Interface Devices Supported on the Router.
- Configure the pseudowire subscriber logical interface
device.
See Configuring a Pseudowire Subscriber Logical Interface Device.
- Configure the transport logical interface.
See Configuring the Transport Logical Interface for a Pseudowire Subscriber Logical Interface.
- 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.
To configure Layer 2 circuit signaling, see Configuring Layer 2 Circuit Signaling for Pseudowire Subscriber Logical Interfaces.
To configure Layer 2 VPN signaling, see Configuring Layer 2 VPN Signaling for Pseudowire Subscriber Logical Interfaces.
- Configure the service logical interface.
See Configuring the Service Logical Interface for a Pseudowire Subscriber Logical Interface.
- Configure the underlying interface device.
See Configuring an Underlying Interface for Dynamic PPPoE Subscriber Interfaces.
- Configure CoS parameters and BA classification.
See CoS Configuration Overview for MPLS Pseudowire Subscriber Interfaces .
- (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.
- (Optional) Configure interface set support for pseudowire
subscriber logical interfaces.
See Configuring Interface Sets and Understanding Interface Sets.
- (Optional) Stack PPPoE logical interfaces over a pseudowire logical device.
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.
Prior to Junos OS Release 17.2R1, you could specify a maximum of 2048 pseudowire logical interface devices for an MX Series router or PTX 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, prior to 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 or PTX 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.
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:
- Specify that you want to configure the pseudowire service.[edit chassis]user@host# edit pseudowire-service
- Set the maximum number of pseudowire logical interface
devices.[edit chassis pseudowire-service]user@host# set device-count 500
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:
- 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.
user@host# edit interfaces ps0 - 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.
[edit interfaces ps0]user@host# set anchor-point lt-1/0/10 - (Optional) Specify the MAC address for the pseudowire
logical interface device.
Note You should ensure that you change the MAC address prior to 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.
[edit interfaces ps0]user@host# set mac 00:00:5E:00:53:55 - (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. [edit interfaces ps0]user@host# set flexible-vlan-tagging
See Enabling VLAN Tagging for additional information about VLAN tagging.
- (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.
[edit interfaces]user@host# set logical-interface-unit encapsulation encapsulation-type - (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.[edit interfaces ps0]user@host# set mtu 2500
See Setting the Protocol MTU for additional information.
- (Optional) Specify that the pseudowire logical interface
device does not respond to gratuitous ARP requests. [edit interfaces ps0]user@host# set no-gratuitous-arp-request
See Configuring Gratuitous ARP for additional information.
- (Optional) Specify that reverse-path forwarding checks
are performed for traffic on the pseudowire logical interface device.[edit interfaces ps0]user@host# set rpf-check
See Understanding Unicast RPF (Routers) for additional information.
- 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:
- Deactivate the stacked pseudowires and commit. This may
require bringing down any subscribers using the pseudowires.[edit interfaces]user@host# deactivate psnumberuser@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/portuser@host# commit
- Reactivate the stacked pseudowires and commit.[edit interfaces]user@host# activate psnumberuser@host# commit
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 psnumberuser@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 countBind 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 activeuser@host# set redundancy-group member-interface lt-fpc/pic/port backupCommit 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 rltnumberuser@host# commit
- Reactivate the stacked pseudowires and commit.[edit interfaces]user@host# activate psnumberuser@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 psnumberuser@host# delete rltnumberuser@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/portuser@host# commit
- Reactivate the stacked pseudowires and commit.[edit interfaces]user@host# activate psnumberuser@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:
- Specify that you want to configure the pseudowire subscriber
logical interface device.[edit]user@host# edit interfaces ps0
- Specify that you want to configure unit 0, which represents
the transport logical interface. [edit interfaces ps0]user@host# edit unit 0
- (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.
[edit interfaces ps0 unit 0]user@host# set encapsulation ethernet-cccuser@host# set encapsulation ethernet-vplsuser@host# set family vpls core-facing - (Optional) Configure the termination of the transport
logical interface on l2backhaul-vpn routing-instance. This
support is enabled from Junos OS Release 19.1R1.[edit routing-instances routing-instance-name]user@host# set vlan-model one-to-one instance-role access instance-type l2backhaul-vpn interface ps1.0suser@host# set no-local-switching
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:
- Specify that you want to configure Layer 2 circuit parameters
at the protocols hierarchy level.[edit protocols]user@host# edit l2circuit
- Specify the IP address of the neighbor, to identify the
PE router used for the Layer 2 circuit. [edit protocols l2circuit]user@host# edit neighbor 192.168.102.15
- Specify the interface used by the Layer 2 circuit traffic. [edit protocols l2circuit neighbor 192.168.102.15]user@host# edit interface ps1.0
- Configure the virtual circuit ID that identifies the Layer
2 circuit for the pseudowire.[edit protocols l2circuit neighbor 192.168.102.15 interface ps1.0]user@host# set virtual-circuit-id 5
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:
- Specify the name of the routing instance you want to configure. [edit]user@host# edit routing-instances l2vpn0
- Configure the Layer 2 VPN routing instance type.[edit routing-instances l2vpn0]user@host# set instance-type l2vpn
- Associate the pseudowire logical interface for the Layer
2 VPN.[edit routing-instances l2vpn0]user@host# set interface ps1.0
- Configure the unique identifier for the routes that belong
to the Layer 2 VPN. [edit routing-instances l2vpn0]user@host# set route-distinguisher 198.51.100.101100
- Configure the VPN routing and forwarding (VRF) target
of the routing instance. [edit routing-instances l2vpn0]user@host# set vrf-target target:10:100
- Specify that you want to configure the Layer 2 VPN protocol
for the routing instance. [edit routing-instances l2vpn0]user@host# edit protocols l2vpn
- Configure the encapsulation type for the routing instance. [edit routing-instances l2vpn0 protocols l2vpn]user@host# set encapsulation-type ethernet
- Specify the site name and site identifier for the Layer
2 VPN. [edit routing-instances l2vpn0 protocols l2vpn]user@host# set site PE1 site-identifier 1
- Specify the interface that connects to the site, and the
remote interface to which you want the specified interface to connect. [edit routing-instances l2vpn0 protocols l2vpn]user@host# set interface ps1.0 remote-site-id 2
- Configure the tracing options for traffic that uses the
Layer 2 VPN. [edit routing-instances l2vpn0 protocols l2vpn]user@host# set traceoptions file l2vpn flag all
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:
- Specify that you want to configure the pseudowire subscriber
logical interface device.[edit]user@host# edit interfaces ps0
- Configure the unit for the service logical interface.
Use a non-zero unit number.[edit interfaces ps0]user@host# edit unit 1
- (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.
[edit interfaces ps0]user@host# set unit 1 encapsulation vlan-cccuser@host# ser vlan-id vlan-IDuser@host# set vlan-tags outer outer-tag inner inner-taguser@host# set vlan-id-list vlan-id-listuser@host# set family ccc - (Optional) Configure filters and policers on the family
circuit cross-connect encapsulation.[edit interfaces ps0]user@host# set unit 1 family ccc filter groupuser@host# set unit 1 family ccc filter input input-listuser@host# set unit 1 family ccc filter output output-listuser@host# set unit 1 family ccc policer inputuser@host# set unit 1 family ccc policer output
- Configure the VLAN tag IDs. [edit interfaces ps0 unit 1]user@host# set vlan-tags outer 1 inner 1
- Configure the interface to respond to ARP requests when
the device has an active route to the ARP request target address.[edit interfaces ps0 unit 1]user@host# set proxy-arp
- 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:
Specify that you want to configure IPv4.
[edit interfaces ps0 unit 1]user@host# edit family inetConfigure the parameters for the family.
[edit interfaces ps0 unit 1 family inet]user@host# set filter input filter 1 output filter 4user@host# set mac-validate looseuser@host# set input-hierarchical-policer policer-1user@host# set unnumbered-address lo0.0 preferred-source-address 198.51.100.11
- (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.[edit protocols]user@host# set l2circuit local-switching interface ps0.1 encapsulation-type ethernet-vlan ignore-encapsulation-mismatch ignore-mtu-mismatch