Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Load Balancing and High Availability With Aggregated Multiservices Interfaces on MS-MPC and MS-MIC

 

Understanding Aggregated Multiservices Interfaces

This topic contains the following sections:

Aggregated Multiservices Interface

In Junos OS, you can combine multiple services interfaces to create a bundle of services interfaces that can function as a single interface. Such a bundle of interfaces is known as an aggregated multiservices interface (AMS), and is denoted as amsN in the configuration, where N is a unique number that identifies an AMS interface (for example, ams0).

AMS configuration provides higher scalability, improved performance, and better failover and load-balancing options.

AMS configuration enables service sets to support multiple services PICs by associating an AMS bundle with a service set. An AMS bundle can have up to 24 services PICs as member interfaces and can distribute services among the member interfaces.

Member interfaces are identified as mams in the configuration. The chassisd process in routers that support AMS configuration creates a mams entry for every multiservices interface on the router.

Starting with Junos OS Release 16.2 (except Junos OS Release 17.3R3-S7), an AMS interface can have up to 36 member interfaces. If you include more than 24 member interfaces, you must increase the service PIC boot timeout to 240 or 300 seconds for all service PICs. In Junos OS Release 16.1 and earlier and in Junos OS Release 17.3R3-S7, an AMS interface could have a maximum of 24 member interfaces.

Starting with Junos OS Release 17.1R1, AMS supports IPSec tunnel distribution for next-hop style service-sets. However, interface-style IPSec service sets are not supported.

Starting with Junos OS Release 19.2R1, you can use up to 60 PICs across different AMS bundles on a MX2020 router. The hard limit of maximum 36 member interfaces per AMS bundle still exists. However, in the chassis, there can be multiple AMS bundles such that 15 MS-MPC slots can be configured across these bundles.

When you configure services options at the ams interface level, the options apply to all member interfaces (mams) for the ams interface.

The options also apply to service sets configured on services interfaces corresponding to the ams interface’s member interfaces. All settings are per PIC. For example, session-limit applies per member and not at an aggregate level.

Note

You cannot configure services options at both the ams (aggregate) and member-interface level. If services options are configured on ms-x/y/z or vms-x/y/z, they also apply to service sets on mams-x/y/z.

When you want services options settings to apply uniformly to all members, configure services options at the ams interface level. If you need different settings for individual members, configure services options at the member interface level.

Note

Per-member drop of traffic and per-member next-hop configuration is required for NAT64. For NAPT44, this per-member specification allows arbitrary hash keys, providing better load-balancing options to allow dynamic NAT operations to be performed. For NAT64, NAPT44, and dynamic NAT44, it is not possible to determine which member allocates the dynamic NAT address. To ensure that reverse flow packets arrive at the same member as the forward flow packets, pool-address-based routes are used to steer reverse flow packets.

Note

Until Junos OS Release 13.3, for every media logical interface on which services were configured (interface style services), a logical interface alias was internally created. This interface alias stores the topology chains for features that are performed on the logical interface after an input service was processed to avoid packet loops in the system. With interface aliases, the maximum number of logical interfaces supported with services was reduced to half the supported maximum number because each logical interface consumed two entries, namely, one for the interface itself and the other for the interface alias.

Starting in Junos OS Release 14.1R4, input interface aliases are not created for MS-MPCs and MS-MICs. As a result, the maximum number of logical interfaces that are supported with services PICs is equal to the maximum number supported on the system. After input service processing by MS-MPCs and MS-MICs, the services PIC sends the packet to the Packet Forwarding Engine on the multiservices (ms-) logical interface where the corresponding service is configured. Post-services are not supported on MS- MPCs and MS-MICs in Junos OS Release 13.2 and later.

Note

You cannot include MS-DPCs or other MS-PICs in an AMS configuration that contains MS-MICs or MS-MPCs as member interfaces.

Note

If you modify a NAT pool that is being used by a service set assigned to an AMS interface, you must deactivate and activate the service set before the NAT pool changes take effect.

By default, the traffic distribution over the member interfaces of an AMS interface happens in a round-robin fashion. You can also configure the following hash key values to regulate the traffic distribution: source-ip, destination-ip , and protocol. For services that require traffic symmetry, you must configure symmetrical hashing. Symmetrical hashing configuration ensures that both forward and reverse traffic is routed through the same member interface.

With basic NAT44, load balancing on AMS interfaces of MS-MICs and MS-MPCs does not work properly if the ingress hash key is source IP address and the egress hash key is destination IP address.

If the service set is applied on the Gigabit Ethernet or 10-Gigabit Ethernet interface that functions as the NAT inside interface, then the hash keys used for load balancing might be configured in such a way that the ingress key is set as destination IP address and the egress key is set as source IP address. Because the source IP address undergoes NAT processing, it is not available for hashing the traffic in the reverse direction. Therefore, load balancing does not happen on the same IP address and forward and reverse traffic does not map to the same PIC. With the hash keys reversed, load balancing occurs correctly.

With next-hop services, for forward traffic, the ingress key on the inside interface load -balances traffic, and for reverse traffic, the ingress key on the outside interface load -balances traffic or per-member next hops steer reverse traffic. With interface-style services, the ingress key load-balances forward traffic and the egress key load-balances forward traffic or per-member next hops steer reverse traffic. Forward traffic is traffic entering from the inner side of a service set and reverse traffic is traffic entering from the outer side of a service set. The forward key is the hash key used for the forward direction of traffic and the reverse key is the hash key used for the reverse direction of traffic (depends on whether it relates to interface services or next-hop services style.)

With stateful firewalls, you can configure the following combinations of forward and reverse keys for load balancing. In the following combinations presented for hash keys, FOR-KEY refers to the forward key, REV-KEY denotes the reverse key, SIP signifies source IP address, DIP signifies destination IP address, and PROTO refers to protocol such as IP.

  • FOR-KEY: SIP, REV-KEY: DIP

  • FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO

  • FOR-KEY: DIP, REV-KEY: SIP

  • FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO

  • FOR-KEY: SIP,DIP REV-KEY: SIP, DIP

  • FOR-KEY: SIP,DIP,PROTO REV-KEY: SIP, DIP,PROTO

With static NAT configured as basic NAT44 or destination NAT44, and with stateful firewall configured or not, if the forward direction of traffic must undergo NAT processing, configure the hash keys as follows:

  • FOR-KEY: DIP, REV-KEY: SIP

  • FOR-KEY: DIP,PROTO REV-KEY: SIP, PROTO

If the reverse direction of traffic must undergo NAT processing, configure the hash keys as follows:

  • FOR-KEY: SIP, REV-KEY: DIP

  • FOR-KEY: SIP,PROTO REV-KEY: DIP, PROTO

With dynamic NAT configured, and with stateful firewall configured or not, only the forward direction traffic can undergo NAT. The forward hash key can be any combination of SIP, DIP, and protocol, and the reverse hash key is ignored.

Note

The Junos OS AMS configuration supports IPv4 and IPv6 traffic.

IPv6 Traffic on AMS Interfaces Overview

Starting in Junos OS release 14.2R1, you can use AMS interfaces for IPv6 traffic. To configure IPv6 support for an AMS interface, include the family inet6 statement at the [edit interfaces ams-interface-name unit 1] hierarchy level. When family inet and family inet6 are set for an AMS interface subunit, the hash-keys is configured at service-set level for interface style and at IFL level for next-hop style.

When a member interface of an AMS bundle fails, traffic destined to the failed member is redistributed among the remaining active members. The traffic (flows or sessions) traversing through the existing active members is unaffected. If M members are currently active, the expected result is that only about 1/M fraction of the traffic (flows/sessions) is impacted because that amount of traffic is shifted from the failed member to remain active members. When the failed member interface comes back online, only a fraction of the traffic is redistributed to the new member. If N members are currently active, the expected result is that only about 1/(N+1) fraction of the traffic (flows/sessions) is impacted because that amount of traffic moves to the new restored member. The 1/M and 1/(N+1) values assume that the flows are uniformly distributed among members, because a packet-hash is used to load-balance and because traffic usually contains a typical random combination of IP addresses (or any other fields that are used as load-balancing keys).

Similar to IPv4 traffic, for IPv6 packets, an AMS bundle must contain members of only one services PIC type. Separate AMS bundles on the same router can contain members of different services PIC types (for example, two MS-MICs in ams0, and two MS-MPC PICs in ams1).

The number of flows distributed, in an ideal environment, can be 1/N in a best-case scenario when the Nth member goes up or down. However, this assumption considers that the hash keys load-balance the real or dynamic traffic. For example, consider a real-world deployment where member A is serving only one flow, whereas member B is serving 10 flows. If member B goes down, then the number of flows disrupted is 10/11. The NAT pool-split behavior is designed to utilize the benefits of the rehash-minimization feature. The splitting of a NAT pool is performed for dynamic NAT scenarios (dynamic NAT, NAT64, and NAPT44).

If the original and redistributed flows are defined as follows:

  • Member-original-flows—The traffic mapped to a member when all members are up.

  • Member-redistributed-flows—The additional traffic mapped to a member when some other member fails. These traffic flows might need to be rebalanced when member interfaces come up and go down.

With the preceding definitions of the original and redistributed flows for member interfaces, the following observations apply:

  • The member-original-flows of a member stay intact as long as that member is up. Such flows are not impacted when other members move between the up and down states.

  • The member-redistributed-flows of a member can change when other members go up or down. This change of flows occurs because these additional flows need to be rebalanced among all active members. Therefore, the member-redistributed-flow can vary a lot based on other members going down or up. Although it might seem that when a member goes down, the flows on active-members are preserved, and that when a member goes up, flows on active-members are not preserved in an effective way, this behavior is only because of static or hash-based rebalancing of traffic among active members.

The rehash-minimization feature handles the operational changes in a member interface status only (such as member offline or member Junos OS reset). It does not handle changes in configuration. For example, addition or deletion, or activation and deactivation, of member interfaces at the [edit interfaces amsN load-balancing-options member-interface mams-a/b/0] hierarchy level requires the member PICs to be bounced. Twice NAT or hairpinning is not supported, similar to IPv4 support for AMS interfaces.

Member Failure Options and High Availability Settings

Because multiple service interfaces are configured as part of an AMS bundle, AMS configuration also provides for failover and high availability support. You can either configure one of the member interfaces as a backup interface that becomes active when any one of the other member interfaces goes down, or configure the AMS in such a way that when one of the member interfaces goes down, the traffic assigned to that interface is shared across the active interfaces.

The member-failure-options configuration statement enables you to configure how to handle traffic when a member interface fails. One option is to redistribute the traffic immediately among the other member interfaces. However, redistribution of traffic involves recalculating the hash tags, and might cause some disruption in traffic on all the member interfaces.

The other option is to configure the AMS to drop all traffic that is assigned to the failed member interface. With this you can optionally configure an interval, rejoin-timeout, for the AMS to wait for the failed interface to come back online after which the AMS can redistribute the traffic among other member interfaces. If the failed member interface comes back online before the configured wait time, traffic continues unaffected on all member interfaces, including the interface that has come back online and resumed the operations.

You can also control the rejoining of the failed interface when it comes back online. If you do not include the enable-rejoin statement in the member-failure-options configuration, the failed interface cannot rejoin the AMS when it comes back online. In such cases, you can manually rejoin that to the AMS by executing the request interfaces revert interface-name operational mode command.

The rejoin-timeout and enable-rejoin statements enable you to minimize traffic disruptions when member interfaces flap.

Note

When member-failure-options are not configured, the default behavior is to drop member traffic with a rejoin timeout of 120 seconds.

The high-availability-options configuration enables you to designate one of the member interfaces as a backup interface. The backup interface does not participate in routing operations as long as it remains a backup interface. When a member interface fails, the backup interface handles the traffic assigned to the failed interface. When the failed interface comes back online, it becomes the new backup interface.

In a many-to-one configuration (N:1), a single backup interface supports all other member interfaces in the group. If any of the member interfaces fails, the backup interface takes over. In this stateless configuration, data is not synchronized between the backup interface and the other member interfaces.

Starting in Junos OS Release 16.1, in a one-to-one configuration, a single active interface is paired with a single backup interface. If the active interface fails, the backup interface does take over. Configurations using member-failure-options are not available for one-to-one (1:1) high availability configurations.

When both member-failure-options and high-availability-options are configured for an AMS, the high-availability-options configuration takes precedence over the member-failure-options configuration. If a second failure occurs before the failed interface comes back online to be the new backup, the member-failure-options configuration takes effect.

Warm Standby Redundancy

Starting in Junos OS Release 17.2R1, you can use the same services interface as the backup in multiple AMS interfaces, resulting in an N:1 warm standby option for MS-MPCs and MS-MICs.

Each warm standby AMS interface contains two members; one member is the service interface you want to protect, called the primary interface, and one member is the secondary (backup) interface. The primary interface is the active interface and the backup interface does not handle any traffic unless the primary interface fails.

To configure warm standby on an AMS interface, you use the redundancy-options statement. You cannot use the load-balancing-options statement in a warm standby AMS interface.

To switch from the primary interface to the secondary interface, issue the request interface switchover amsN command.

To revert to the primary interface from the secondary interface, issue the request interface revert amsN command.

Configuring Aggregated Multiservices Interfaces

The aggregated multiservices (AMS) interface configuration in Junos OS enables you to combine services interfaces from multiple PICs to create a bundle of interfaces that can function as a single interface. You identify the PIC that you want to act as the backup.

  1. Create an aggregated multiservices interface and add member interfaces. Starting in Junos OS Release 19.3R2, an MX-SPC3 Next Gen Services AMS interface can have up to 16 member interfaces with a maximum of 8 MX-SPC3 services cards with up to 2 PICs on each card. Starting with Junos OS Release 16.2, an MS-MPC AMS interface can have up to 36 member interfaces. In Junos OS Release 16.1 and earlier, an AMS interface can have a maximum of 24 member interfaces.Note

    The member interface format is mams-a/b/0, where a is the Flexible PIC Concentrator (FPC) slot number and b is the PIC slot number.

    For example on an MS-MPC, which can have up to four PICs:

    For example on an MX-SPC3, which can have up to two PICs:

  2. Configure logical units for the AMS interface.

    For example:

  3. Configure member failure options.

    For example:

  4. Configure the preferred backup.

    For example:

  5. Note

    This step is not applicable to the Next Gen Services MX-SPC3 services card in the MX240, MX480 or MX960 chassis.

    If the AMS interface has more than 24 member interfaces, set the service PIC boot timeout value to 240 or 300 seconds for every services PIC on the MX Series router. We recommend that you use a value of 240.Note

    Starting with Junos OS Release 16.2, an AMS interface can have up to 36 member interfaces. In Junos OS Release 16.1 and earlier, an AMS interface could have a maximum of 24 member interfaces.

    For example:

Configuring Load Balancing on AMS Infrastructure

Configuring load balancing requires an aggregated multiservices (AMS) system. AMS involves grouping several services PICs together. An AMS configuration eliminates the need for separate routers within a system. The primary benefit of having an AMS configuration is the ability to support load balancing of traffic across multiple services PICs.

AMS is supported on the MS-MPC and MS-MIC. Starting in Junos OS Release 19.3R2, AMS interfaces are also supported on the MX-SPC3 if you are running Next Gen Services.

High availability (HA) is supported on AMS infrastructure on all MX Series 5G Universal Routing Platforms. AMS has several benefits:

  • Support for configuring behavior if a services PIC that is part of the AMS configuration fails

  • Support for specifying hash keys for each service set in either direction

  • Support for adding routes to individual PICs within the AMS system

Configuring AMS Infrastructure

AMS supports load balancing across multiple service sets. All ingress or egress traffic for a service set can be load balanced across different services PICs. To enable load balancing, you have to configure an aggregate interface with existing services interfaces.

To configure failure behavior in AMS, include the member-failure-options statement:

If a PIC fails, you can configure the traffic to the failed PIC to be redistributed by using the redistribute-all-traffic statement at the [edit interfaces interface-name load-balancing-options member-failure-options] hierarchy level. If the drop-member-traffic statement is used, all traffic to the failed PIC is dropped. Both options are mutually exclusive.

Note

If member-failure-options is not explicitly configured, the default behavior is to drop member traffic with a rejoin timeout of 120 seconds.

Only mams- interfaces (services interfaces that are part of AMS) can be aggregated. After an AMS interface has been configured, you cannot configure the individual constituent mams- interfaces. A mams- interface cannot be used as an ams interface (this is not applicable to Next Gen Services MX-SPC3). AMS supports IPv4 (family inet) and IPv6 (family inet6). You cannot configure addresses on an AMS interface. Network Address Translation (NAT) is the only application that runs on AMS infrastructure at this time.

Note

You cannot configure unit 0 on an AMS interface.

To support multiple applications and different types of translation, AMS infrastructure supports configuring hashing for each service set. You can configure the hash keys separately for ingress and egress. The default configuration uses source IP, destination IP, and the protocol for hashing; incoming-interface for ingress and outgoing-interface for egress are also available.

Note

When using AMS in a load-balanced setup for the NAT solution, the number of NAT IP addresses must be greater than or equal to the number of active mams-interfaces you have added to the AMS bundle.

Configuring High Availability

In an AMS system configured with high availability, a designated services PIC acts as a backup for other active PICs that are part of the AMS system in a many-to-one (N:1) backup configuration. In a N:1 backup configuration, one PIC is available as backup for all other active PICs. If any of the active PICs fail, the backup PIC takes over for the failed PIC. In an N:1 (stateless) backup configuration, traffic states and data structures are not synchronized between the active PICs and the backup PIC.

An AMS system also supports a one-to-one (1:1) configuration. In the case of 1:1 backup, a backup interface is paired with a single active interface. If the active interface fails, the backup interface takes over. In a 1:1 (stateful) configuration, traffic states and data structures are synchronized between the active PICs and the backup PIC. Stateful synchronization is required for high availability of IPsec connections. For IPsec connections, AMS supports 1:1 configuration only.

Note

IPsec connections are not supported on the MX-SPC3 in this release.

High availability for load balancing is configured by adding the high-availability-options statement at the [edit interfaces interface-name load-balancing-options] hierarchy level.

To configure N:1 high availability, include the high-availability-options statement with the many-to-one option:

Starting in Junos OS Release 16.1, you can configure stateful 1:1 high availability on an MS-MPC. To configure stateful 1:1 high availability, at the [edit interfaces interface-name load-balancing-options] hierarchy level, include the high-availability-options statement with the one-to-one option:

Note

The Next Gen Services MX-SPC3 services card does not support AMS 1:1 high availability.

Load Balancing Network Address Translation Flows

Network Address Translation (NAT) has been programmed as a plug-in and is a function of load balancing and high availability. The plug-in runs on AMS infrastructure. All flows for translation are automatically distributed to different services PICs that are part of the AMS infrastructure. In case of failure of an active services PIC, the configured backup PIC takes over the NAT pool resources of the failed PIC. The hashing method selected depends on the type of NAT. Using NAT on AMS infrastructure has a few limitations:

  • NAT flows to failed PICs cannot be restored.

  • There is no support for IPv6 flows.

    IPv6 address pools are not supported with AMS, however NAT64 is supported with AMS, so that IPv6 flows enters AMS.

    NAT64 is supported for Next Gen Services on the MX-SPC3 services card, there is no support of NAT66. IPv6 flows for different NAT services are supported except where the translation is required to be IPv6 to IPv6 or IPv4 to IPv6.

  • Twice NAT is not supported for load balancing on MS-MPC cards.

    Twice NAT is supported for load balancing on the Next Gen Services MX-SPC3 services card.

  • Deterministic NAT uses warm-standby AMS configuration and can distribute the load using multiple AMS bundles in warm-standby mode.

Configuring Warm Standby for Services Interfaces

You can configure an N:1 warm standby option for MS-MPCs, MS-MICs, and MX-SPC3s by creating multiple aggregated multiservices (AMS) interfaces, each of which contains the service interface you want to backup and the service interface that acts as the backup. The same backup service interface can be used in all these AMS interfaces. Starting in Junos OS Release 19.3R2, the N:1 warm standby option is also supported on the MX-SPC3 if you are running Next Gen Services.

To configure warm standby for services interfaces:

  1. Create an AMS interface.

    The variable N is a unique number, such as 0 or 1.

  2. Specify the primary service interface that you want to backup.

    The variable a is the FPC slot number and b is the PIC slot number for the primary service interface.

  3. Specify the secondary service interface, which backs up the primary interface.

    The variable a is the FPC slot number and b is the PIC slot number for the secondary service interface.

  4. Repeat Steps 1 through 3 to create an AMS interface for each service interface that you want to backup. You can use the same secondary service interface in each AMS interface.

Example: Configuring an Aggregated Multiservices Interface (AMS)

Hardware and Software Requirements

This example requires MX Series routers that have services interfaces installed in that and Junos OS Release 13.2 running on that.

Overview

The aggregated multiservices (AMS) interface configuration in Junos OS enables you to combine multiple services interfaces to create a bundle of interfaces that can function as a single interface. This example shows you how to configure an AMS interface, load-balancing options, member failure options, high availability settings on an AMS interface, and an interface-style service set configuration that uses the AMS interface.

Note

You cannot include MS-DPCs or other multiservices PICs in an AMS configuration that contains MS-MICs or MS-MPCs as member interfaces.

An MS-PIC contains only one interface, whereas the MS-MPC contains four interfaces. To utilize the entire MS-MPC in a single AMS bundle, all the four member interfaces need to be assigned to that AMS bundle.

Keep the following points in mind for every member interface (XLP chip) needs to be part of the AMS interface bundle:

  • XLP-based line cards from the same MPC can be part of multiple AMS bundles.

  • Multiple XLP chips from several MPCs can also be part of a single bundle (up to eight member interfaces in an AMS bundle, depending on the deployment requirement).

  • It is not necessary that all the XLP chips from the same MS-MPC must be part of the same AMS bundle. Some of the XLP chips can be part of an AMS bundle, while other XLP chips can be standalone ms- interfaces or need not be configured. However, the same XLP chip cannot be part of two different AMS interfaces at the same time. For example, each XLP chip from the same MS-MPC can be grouped into four different AMS bundles, based on the deployment needs.

  • A maximum of up to eight member interfaces can be assigned to an AMS bundle.

For more information about AMS interfaces, see Understanding Aggregated Multiservices Interfaces.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Adding Member Interfaces

Configuring Logical Units

Configuring Member Failure Options

Configuring High Availability Options

Configuring Service Set and Interface Services

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.

  1. Create an aggregated multiservices interface and add member interfaces.Note

    You cannot configure the same mams to be part of two different AMS interfaces at the same time.

  2. Configure logical units for the AMS interface.Note

    An AMS interface and its member interfaces cannot share the same logical interface units. For example, if one of the member interfaces has logical units 1 and 2 configured on it, you cannot configure logical units 1 and 2 for the AMS. Similarly, if you have configured logical units 3 and 4 on the AMS, you cannot configure those units on any of the member interfaces.

  3. Configure member failure options.
    Note

    This example shows the drop-member-traffic configuration. However, you if you would like to redistribute the traffic to other available members when one of the member interfaces goes down, you can include the redistribute-all-traffic statement instead of the drop-member-traffic statement.

    The default behavior, when the member-failure-options configuration is not included, is to drop member traffic with a rejoin timeout of 120 seconds.

  4. Configure the high-availability options.
  5. Configure interface style services.
  6. If you are done configuring the device, commit the configuration.

    Table 1: Key Configuration Statements Used in this Example

    Statement

    Description

    member-interface

    Adds a member interface (mams) to the AMS bundle.

    drop-member-traffic

    Specifies that all traffic to a member be dropped in case the member interface fails.

    rejoin-timeout

    Specifies the time interval, in seconds, for the AMS to wait before declaring a member interface down. If the failed member comes back online during this period, it can rejoin the AMS and resume traffic forwarding.

    The range is 0 through 1000 seconds.

    enable-rejoin

    Specifies whether a failed interface be allowed to rejoin the AMS when it comes back online.

    If this statement is not included in the configuration, you must manually add the interface to the AMS when the interface is back online.

    preferred-backup

    Designates a member interface as the floating backup.

    interface-services

    Specifies a service interface, an AMS interface in this example, to handle interface services.

    hash-keys

    Specifies the load-balancing hash keys. You can configure the following hash key values: source-ip, destination-ip, iif (incoming interface), oif (outgoing interface), and protocol.

    Note: For services that require traffic symmetry, you must configure symmetrical hashing. Symmetrical hashing configuration ensures that both forward and reverse traffic are routed through the same member interface.

Results

From the configuration mode, confirm your configuration by entering the show interfaces ams0 command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

Confirm that the configuration is working properly.

Verifying the AMS Configuration

Purpose

Verify the AMS configuration and status of member interfaces.

Action

From operational mode, enter the show command.

user@router1> show interfaces load-balancing detail

Meaning

Shows that ams0 has six member interfaces with a many-to-one backup configuration. Of the six member interfaces, five are in active state and one, mams-1/0/0, is in backup state.

Example: Configuring Next-Hop Style Services on an Aggregated Multiservices Interface

Hardware and Software Requirements

MX Series routers with services interfaces installed and running Junos OS Release 13.2.

Overview

Starting with Release 13.2, Junos OS extends next-hop style services support to aggregated multiservices (AMS) interfaces. In releases earlier than 12.3, only interface style services configurations were supported on AMS interfaces.

The next-hop style services configuration on AMS interfaces is different from the interface style services configuration. For next-hop style services, the load-balancing hash keys are defined as part of the logical unit configuration of the AMS interface. For interface style services, the hash keys configuration falls under the service-set configuration.

This example explains the next-hop style services configuration on an AMS interface, and shows the verification steps to verify that the configuration is working correctly.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

Configuring an aggregated multiservices interface

Configuring Routing Instances that Use AMS interfaces

Configuring Hash Keys

Configure Next Hop Services

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see “Using the CLI Editor in Configuration Mode” in the CLI User Guide.

  1. Configure an aggregated multiservices interface and the load-balancing options.
  2. Configure routing instances that use the aggregated multiservices interfaces configured in the first step.
  3. Configure hash keys for the aggregated multiservices interfaces. Note

    Unlike in the interface-style configuration where hash keys are defined in the service-set configuration, for next-hop services, the hash keys are specified in the AMS configuration under the logical units.

  4. Configure next-hop style services under the service-set configuration.
  5. Commit the configuration.

Results

From the configuration mode, confirm your configuration by entering the show interfaces ams0, show routing-instances, and show services service-set ams-test commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Example: Configuring Static Source Translation on AMS Infrastructure

This example shows a static source translation configured on an AMS interface. The flows will be load balanced across member interfaces with this example.

Configure the AMS interface ams0 with load balancing options.

Configure hashing for the service set for both ingress and egress traffic.

Note

Hashing is determined based on whether the service set is applied on the ingress or egress interface.

Configure two NAT pools because you have configured two member interfaces for the AMS interface.

Configure the NAT rule and translation.

Note

A similar configuration can be applied for translation types dynamic-nat44 and napt-44. Twice NAT cannot run on AMS infrastructure at this time.

Release History Table
Release
Description
Starting in Junos OS Release 19.3R2, an MX-SPC3 Next Gen Services AMS interface can have up to 16 member interfaces with a maximum of 8 MX-SPC3 services cards with up to 2 PICs on each card.
Starting in Junos OS Release 19.3R2, AMS interfaces are also supported on the MX-SPC3 if you are running Next Gen Services.
Starting in Junos OS Release 19.3R2, the N:1 warm standby option is also supported on the MX-SPC3 if you are running Next Gen Services.
Starting with Junos OS Release 19.2R1, you can use up to 60 PICs across different AMS bundles on a MX2020 router. The hard limit of maximum 36 member interfaces per AMS bundle still exists. However, in the chassis, there can be multiple AMS bundles such that 15 MS-MPC slots can be configured across these bundles.
Starting in Junos OS Release 17.2R1, you can use the same services interface as the backup in multiple AMS interfaces, resulting in an N:1 warm standby option for MS-MPCs and MS-MICs.
Starting with Junos OS Release 17.1R1, AMS supports IPSec tunnel distribution for next-hop style service-sets. However, interface-style IPSec service sets are not supported.
Starting with Junos OS Release 16.2 (except Junos OS Release 17.3R3-S7), an AMS interface can have up to 36 member interfaces.
Starting with Junos OS Release 16.2, an MS-MPC AMS interface can have up to 36 member interfaces.
Starting in Junos OS Release 16.1, in a one-to-one configuration, a single active interface is paired with a single backup interface. If the active interface fails, the backup interface does take over.
Starting in Junos OS Release 16.1, you can configure stateful 1:1 high availability on an MS-MPC.
Starting in Junos OS release 14.2R1, you can use AMS interfaces for IPv6 traffic.
Starting in Junos OS Release 14.1R4, input interface aliases are not created for MS-MPCs and MS-MICs.