Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Link Services Interface Redundancy

Layer 2 Service Package Capabilities and Interfaces

As described in Enabling Service Packages, you can configure the AS or Multiservices PIC and the internal ASM in the M7i platform to use either the Layer 2 or the Layer 3 service package.

When you enable the Layer 2 service package, the AS or Multiservices PIC supports link services. On the AS or Multiservices PIC and the ASM, link services include the following:

  • Junos CoS components—Configuring CoS Scheduling Queues on Logical LSQ Interfaces describes how the Junos CoS components work on link services IQ (lsq) interfaces. For detailed information about Junos CoS components, see the Class of Service User Guide (Routers and EX9200 Switches).

  • Data compression using the compressed Real-Time Transport Protocol (CRTP) for use in voice over IP (VoIP) transmission.

    Note:

    On LSQ interfaces, all multilink traffic for a single bundle is sent to a single processor. If CRTP is enabled on the bundle, it adds overhead to the CPU. Because T3 network interfaces support only one link per bundle, make sure you configure a fragmentation map for compressed traffic on these interfaces and specify the no-fragmentation option. For more information, see Configuring Delay-Sensitive Packet Interleaving and Configuring CoS Fragmentation by Forwarding Class on LSQ Interfaces.

  • Link fragment interleaving (LFI) on Frame Relay links using FRF.12 end-to-end fragmentation—The standard for FRF.12 is defined in the specification FRF.12, Frame Relay Fragmentation Implementation Agreement.

  • LFI on Multilink Point-to-Point Protocol (MLPPP) links.

  • Multilink Frame Relay (MLFR) end-to-end (FRF.15)—The standard for FRF.15 is defined in the specification FRF.15, End-to-End Multilink Frame Relay Implementation Agreement.

  • Multilink Frame Relay (MLFR) UNI NNI (FRF.16)—The standard for FRF.16 is defined in the specification FRF.16.1, Multilink Frame Relay UNI/NNI Implementation Agreement.

  • MLPPP—The standard for MLPPP is defined in the specification RFC 1990, The PPP Multilink Protocol (MP).

  • Multiclass extension to MLPPP—The standard is defined in the specification RFC 2686, The Multi-Class Extension to Multi-Link PPP.

For the LSQ interface on the AS or Multiservices PIC, the configuration syntax is almost the same as for Multilink and Link Services PICs. The primary difference is the use of the interface-type descriptor lsq instead of ml or ls. When you enable the Layer 2 service package on the AS or Multiservices PIC, the following interfaces are automatically created:

Interface types gr, ip, mt, pd, pe, and vt are standard tunnel interfaces that are available on the AS or Multiservices PIC whether you enable the Layer 2 or the Layer 3 service package. These tunnel interfaces function the same way for both service packages, except that the Layer 2 service package does not support some tunnel functions, as shown in Table 5 on page 24. For more information about tunnel interfaces, see Tunnel and Encryption Services Interfaces User Guide for Routing Devices.

Note:

Interface type sp is created because it is needed by the Junos OS. For the Layer 2 service package, the sp interface is not configurable, but you should not disable it.

Interface type lsq-fpc/pic/port is the physical link services IQ interface (lsq). Interface types lsq-fpc/pic/port:0 through lsq-fpc/pic/port:N represent FRF.16 bundles. These interface types are created when you include the mlfr-uni-nni-bundles statement at the [edit chassis fpc slot-number pic pic-number] hierarchy level. For more information, see Configuring CoS Scheduling Queues on Logical LSQ Interfaces.

Note:

On DS0, E1, or T1 interfaces in LSQ bundles, you can configure the bandwidth statement, but the router does not use the bandwidth value if the interfaces are included in an MLPPP or MLFR bundle. The bandwidth is calculated internally according to the time slots, framing, and byte-encoding of the interface. For more information about these properties, see the Junos OS Network Interfaces Library for Routing Devices.

Configuring LSQ Interface Redundancy Across Multiple Routers Using SONET APS

Link services IQ (lsq-) interfaces that are paired with SONET PICs can use the Automatic Protection Switching (APS) configuration already available on SONET networks to provide failure recovery. SONET APS provides stateless failure recovery, if it is configured on SONET interfaces in separate chassis and each SONET PIC is paired with an AS or Multiservices PIC in the same chassis. If one of the following conditions for APS failure is met, the associated SONET PIC triggers recovery to the backup circuit and its associated AS or Multiservices PIC. The failure conditions are:

  • Failure of Link Services IQ PIC

  • Failure of FPC that hosts the Link Services IQ PIC

  • Failure of Packet Forwarding Engine

  • Failure of chassis

The guidelines for configuring SONET APS are described in the Junos OS Network Interfaces Library for Routing Devices.

The following sections describe how to configure failover properties:

Configuring the Association between LSQ and SONET Interfaces

To configure the association between AS or Multiservices PICs hosting link services IQ interfaces and the SONET interfaces, include the lsq-failure-options statement at the [edit interfaces] hierarchy level:

For example, consider the following network scenario:

  • Primary router includes interfaces oc3-0/2/0 and lsq-1/1/0.

  • Backup router includes interfaces oc3-2/2/0 and lsq-3/2/0.

Configure SONET APS, with oc3-0/2/0 as the working circuit and oc3-2/2/0 as the protect circuit. Include the trigger-link-failure statement to extend failure to the LSQ PICs:

Note:

You must configure the lsq-failure-options statement on the primary router only. The configuration is not supported on the backup router.

To inhibit the router from sending PPP termination-request messages to the remote host if the Link Services IQ PIC fails, include the no-termination-request statement at the [edit interfaces lsq-fpc/pic/port lsq-failure-options] hierarchy level:

This functionality is supported on link PICs as well. To inhibit the router from sending PPP termination-request messages to the remote host if a link PIC fails, include the no-termination-request statement at the [edit interfaces interface-name ppp-options] hierarchy level.

The no-termination-request statement is supported only with MLPPP and SONET APS configurations and works with PPP, PPP over Frame Relay, and MLPPP interfaces only, on the following PICs:

  • Channelized OC3 IQ PICs

  • Channelized OC12 IQ PICs

  • Channelized STM1 IQ PICs

  • Channelized STM4 IQ PICs

Configuring SONET APS Interoperability with Cisco Systems FRF.16

Juniper Networks routers configured with APS might not interoperate correctly with Cisco FRF.16. To enable interoperation, include the cisco-interoperability statement at the [edit interfaces lsq-fpc/pic/port mlfr-uni-nni-bundle-options] hierarchy level:

The send-lip-remove-link-for-link-reject option prompts the router to send a Link Integrity Protocol remove link when it receives an add-link rejection message.

Restrictions on APS Redundancy for LSQ Interfaces

The following restrictions apply to LSQ failure recovery:

  • It applies only to Link Services IQ PICs installed in M Series routers, except for M320 routers.

  • You must configure the failure-options statement on physical LSQ interfaces, not on MLFR channelized units.

  • The Link Services IQ PICs must be associated with SONET link PICs. The paired PICs can be installed on different routers or in the same router; in other words, both interchassis and intrachassis recovery are supported

  • Failure recovery is stateless; as a result, route flapping and loss of link state is expected in interchassis recovery, requiring PPP renegotiation. In intrachassis recovery, no impact on traffic is anticipated with Routing Engine failover, but PIC failover results in PPP renegotiation.

  • The switchover is not revertive: when the original hardware is restored to service, traffic does not automatically revert back to it.

  • Normal APS switchover and PIC-triggered APS switchover can be distinguished only by checking the system log messages.

    Note:

    When an AS PIC experiences persistent back pressure as a result of high traffic volume for 3 seconds, the condition triggers an automatic core dump and reboot of the PIC to help clear the blockage. A system log message at level LOG_ERR is generated. This mechanism applies to both Layer 2 and Layer 3 service packages.

See Also

Configuring LSQ Interface Redundancy in a Single Router Using SONET APS

Stateless switchover from one Link Services IQ PIC to another within the same router can be configured by using the SONET APS mechanism described in Configuring LSQ Interface Redundancy Across Multiple Routers Using SONET APS. Each Link Services IQ PIC must be associated with a specified SONET link PIC within the same router.

Note:

For complete intrachassis recovery, including recovery from Routing Engine failover, graceful Routing Engine switchover (GRES) must be enabled on the router. For more information, see the Junos OS Administration Library for Routing Devices.

See Also

Configuring LSQ Interface Redundancy in a Single Router Using Virtual Interfaces

You can configure failure recovery on M Series, MX Series, and T Series routers that have multiple AS or Multiservices PICs and DPCs with lsq- interfaces by specifying a virtual LSQ redundancy (rlsq) interface in which the primary Link Services IQ PIC is active and a secondary PIC is on standby. If the primary PIC fails, the secondary PIC becomes active, and all LSQ processing is transferred to it. To determine which PIC is currently active, issue the show interfaces redundancy command.

Note:

This configuration does not require the use of SONET APS for failover. Network interfaces that do not support SONET can be used, such as T1 or E1 interfaces.

The following sections provide more information:

Configuring Redundant Paired LSQ Interfaces

The physical interface type rlsq specifies the pairings between primary and secondary lsq interfaces to enable redundancy. To configure a backup lsq interface, include the redundancy-options statement at the [edit interfaces rlsqnumber] hierarchy level:

For the rlsq interface, number can be from 0 through 1023. If the primary lsq interface fails, traffic processing switches to the secondary interface. The secondary interface remains active even after the primary interface recovers. If the secondary interface fails and the primary interface is active, processing switches to the primary interface.

The hot-standby option is used with one-to-one redundancy configurations, in which one working PIC is supported by one backup PIC. It is supported with MLPPP, CRTP, FRF.15, and FRF.16 configurations for the LSQ interface to achieve an uninterrupted LSQ service. It sets the requirement for the failure detection and recovery time to be less than 5 seconds. The behavior is revertive, but you can manually switch between the primary and secondary PICs by issuing the request interfaces (revert | switchover) rlsqnumber operational mode command. It also provides a switch over time of 5 seconds and less for FRF.15 and a maximum of 10 seconds for FRF.16.

The warm-standby option is used with redundancy configurations in which one backup PIC supports multiple working PICs. Recovery times are not guaranteed, because the configuration must be completely restored on the backup PIC after a failure is detected.

Certain combinations of hot-standby and warm-standby configuration are not permitted and result in a configuration error. The following examples are permitted:

  • Interface rlsq0 configured with primary lsq-0/0/0 and warm-standby, in combination with interface rlsq0:0 configured with primary lsq-0/0/0:0

  • Interface rlsq0:0 configured with primary lsq-0/0/0:0, in combination with interface rlsq0:1 configured with primary lsq-0/0/0:1

The following example combinations are not permitted:

  • Interface rlsq0 configured with primary lsq-0/0/0 and hot-standby, in combination with interface rlsq0:0 configured with primary lsq-0/0/0:0

  • Interface rlsq0:0 configured with primary lsq-0/0/0:0, in combination with interface rlsq1:0 configured with primary lsq-0/0/0:0

  • Interface rlsq0:0 configured with primary lsq-0/0/0:1, in combination with interface rlsq1:1 configured with primary lsq-0/0/0:1

  • Interface rlsq0 configured with primary lsq-0/0/0, in combination with interface rlsq1 configured with primary lsq-0/0/0

In addition, the same physical interface cannot be reused as the primary interface for more than one rlsq interface, nor can any of the associated logical interfaces. For example, primary interface lsq-0/0/0 cannot be reused in another rlsq interface as lsq-0/0/0:0.

Restrictions on Redundant LSQ Interfaces

Link Services IQ PIC failure occurs under the following conditions:

  • The primary PIC fails to boot. In this case, the rlsq interface does not come up and manual intervention is necessary to reboot or replace the PIC, or to rename the primary PIC to the secondary one in the rlsq configuration.

  • If the following conditions are not met when configuring an rlsq interface:

    • The unit number allocated to the rlsq interface is less than the number of Multilink Frame Relay user-to-network interface network-to-network interface (UNI-NNI) (FRF.16) bundles allocated on the Link Services PIC.

    • Data-link connection identifier (DLCI) is configured for the rlsq interface.

    If these conditions are not met, the rlsq interface does not boot. When you issue the show interfaces redundancy command, the state of the rlsq interface is indicated as Waiting for primary MS PIC.

  • The primary PIC becomes active and then fails. The secondary PIC automatically takes over processing.

  • A failover to the secondary PIC takes place. The secondary PIC then fails. If the primary PIC has been restored to active state, processing switches to it.

  • The FPC that contains the Link Services IQ PIC fails.

The following constraints apply to redundant LSQ configurations:

  • We recommend that primary and secondary PICs be configured in two different FPCs (in chassis other than M10i routers).

  • You cannot configure a Link Services IQ PIC with explicit bundle configurations and as a constituent of an rlsq interface.

  • Redundant LSQ configurations provide full GRES support. (You must configure GRES at the [edit chassis] hierarchy level; see the Junos OS Administration Library for Routing Devices.

  • If you configure the redundancy-options statement with the hot-standby option, the configuration must include one primary interface value and one secondary interface value.

  • Since the same interface name is used for hot-standby and warm-standby, if you modify the configuration to change this attribute, it is recommended that you first deactivate the interface, commit the new configuration, and then reactivate the interface.

  • You cannot make changes to an active redundancy-options configuration. You must deactivate the rlsqnumber interface configuration, change it, and reactivate it.

  • The rlsqnumber configuration becomes active only if the primary interface is active. When the configuration is first activated, the primary interface must be active; if not, the rlsq interface waits until the primary interface comes up.

  • You cannot modify the configuration of lsq interfaces after they have been included in an active rlsq interface.

  • All the operational mode commands that apply to rsp interfaces also apply to rlsq interfaces. You can issue show commands for the rlsq interface or the primary and secondary lsq interfaces. However, statistics on the link interfaces are not carried over following a Routing Engine switchover.

  • The rlsq interfaces also support the lsq-failure-options configuration, discussed in Configuring LSQ Interface Redundancy Across Multiple Routers Using SONET APS. If the primary and secondary Link Services IQ PICs fail and the lsq-failure-options statement is configured, the configuration triggers a SONET APS switchover.

  • Redundant LSQ configurations that require MLPPP Multilink Frame Relay (FRF.15 and FRF.16) are supported only with the warm-standby option.

  • Redundant LSQ support is extended to ATM network interfaces.

  • Channelized interfaces are used with FRF-16 bundles, for example rlsq0:0. The rlsq number and its constituents, the primary and secondary interfaces, must match for the configuration to be valid: either all must be channelized, or none. For an example of an FRF.16 configuration, see #id-configuring-lsq-interface-redundancy-in-a-single-router-using-virtual-interfaces__d81e788.

  • When you configure a channelized rlsq interface, you must use a channel index number from 0 through 254.

Note:

Adaptive Services and Multiservices PICs in layer-2 mode (running Layer 2 services) are not rebooted when a MAC flow-control situation is detected.

Configuring Link State Replication for Redundant Link PICs

Link state replication, also called interface preservation, is an addition to the SONET Automatic Protection Switching (APS) functionality that helps promote redundancy of the link PICs used in LSQ configurations.

Link state replication provides the ability to add two sets of links, one from the active (working) SONET PIC and the other from the backup (protect) SONET PIC to the same bundle. If the active SONET PIC fails, links from the standby PIC are used without causing a link renegotiation. All the negotiated state is replicated from the active links to the standby links to prevent link renegotiation. For more information about SONET APS configurations, see the Junos OS Network Interfaces Library for Routing Devices.

To configure link state replication, include the preserve-interface statement at the [edit interfaces interface-name sonet-options aps] hierarchy level on both network interfaces:

The following constraints apply to link PIC redundancy:

  • APS functionality must be available on the SONET PICs and the interface configurations must be identical on both ends of the link. Any configuration mismatch causes the commit operation to fail.

  • This feature is supported only with LSQ and SONET APS-enabled link PICs, including Channelized OC3, Channelized OC12, and Channelized STM1 intelligent queuing (IQ) PICs.

  • Link state replication supports MLPPP and PPP over Frame Relay (frame-relay-ppp) encapsulation, and fully supports GRES.

  • Enabling the interface or protocol traceoptions with a large number of MLPPP links can trigger Link Control Protocol (LCP) renegotiation during the link switchover time.

    Note:

    This renegotiation is more likely to take place for configurations with back-to-back Juniper Networks routers than in networks in which a Juniper Networks router is connected to an add/drop multiplexer (ADM).

  • In general, networks that connect a Juniper Networks router to an ADM allow faster MLPPP link switchover than those with back-to-back Juniper Networks routers. The MLPPP link switchover time difference may be significant, especially for networks with a large number of MLPPP links.

  • An aggressive LCP keepalive timeout configuration can lead to LCP renegotiation during the MLPPP link switchover. By default, the LCP keepalive timer interval is 10 seconds and the consecutive link down count is 3. The MLPPP links start LCP negotiation only after a timeout of 30 seconds. Lowering these configuration values may trigger one or more of the MLPPP links to renegotiate during the switchover time.

    Note:

    LCP renegotiation is more likely to take place for configurations with back-to-back Juniper Networks routers than in networks in which a Juniper Networks router is connected to an ADM.

As an example, the following configuration shows the link state replication configuration between the ports coc3-1/0/0 and coc3-2/0/0.

Examples: Configuring Redundant LSQ Interfaces for Failure Recovery

Configuring LSQ Interface Redundancy for MLPPP

The following configuration shows that lsq-1/1/0 and lsq-1/3/0 work as a pair and the redundancy type is hot-standby, which sets the requirement for the failure detection and recovery time to be less than 5 seconds:

The following example shows a related MLPPP configuration:

Note:

MLPPP protocol configuration is required for this configuration.

The following example shows a related CoS configuration:

The following example shows a complete link state replication configuration for MLPPP. This example uses two bundles, each with four T1 links. The first four T1 links (t1-*:1 through t1-*:4) form the first bundle and the last four T1 links (t1-*:5 through t1-*:8) form the second bundle. To minimize the duplication in the configuration, this example uses the [edit groups] statement; for more information, see the Junos OS Administration Library for Routing Devices. This type of configuration is not required; it simplifies the task and minimizes duplication.

Configuring LSQ Interface Redundancy for an FRF.15 Bundle

The following example shows a configuration for an FRF.15 bundle:

Configuring LSQ Interface Redundancy for an FRF.16 Bundle

The following example shows a configuration for an FRF.16 bundle:

See Also