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
- IPv6 Traffic on AMS Interfaces Overview
- Member Failure Options and High Availability Settings
- Warm Standby Redundancy
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-MPCs 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.
Starting in Junos OS Release 19.3R2, AMS interfaces are supported with the MX-SPC3. The following table indicates the details of maximum number of MX-SPC3s, maximum number of PICs, and the maximum number of AMS members in a bundle:
| MX Platforms | Maximum number of MX-SPC3s | Maximum number of PICs | Maximum number of AMS members |
|---|---|---|---|
| MX240 | 2 | 4 | 4 |
| MX480 | 5 | 10 | 10 |
| MX960 | 7 | 14 | 14 |
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.
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.
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.
You cannot include MS-DPCs or other MS-PICs in an AMS configuration that contains MS-MICs or MS-MPCs as member interfaces.
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.
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 all 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.
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.
See Also
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 supported on the MX-SPC3.
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
- Configuring High Availability
- Load Balancing Network Address Translation Flows
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:
[edit interfaces ams1] load-balancing-options { member-failure-options { drop-member-traffic { rejoin-timeout rejoin-timeout; } redistribute-all-traffic { enable-rejoin; } } }
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.
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.
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.
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.
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:
[edit interfaces ams1] load-balancing-options { high-availability-options { many-to-one { preferred-backup preferred-backup; } } }
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:
The Next Gen Services MX-SPC3 services card does not support AMS 1:1 high availability.
[edit interfaces ams1] load-balancing-options { high-availability-options { one-to-one { preferred-backup preferred-backup; } } }
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 supported on the MX-SPC3.
To configure warm standby for services interfaces:
See Also
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.
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
Procedure
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
set interfaces ams0 load-balancing-options member-interface mams-0/0/0 set interfaces ams0 load-balancing-options member-interface mams-0/1/0 set interfaces ams0 load-balancing-options member-interface mams-1/0/0 set interfaces ams0 load-balancing-options member-interface mams-1/1/0 set interfaces ams0 load-balancing-options member-interface mams-2/0/0 set interfaces ams0 load-balancing-options member-interface mams-2/1/0
Configuring Logical Units
set interfaces ams0 unit 1 family inet
Configuring Member Failure Options
set interfaces ams0 load-balancing-options member-failure-options drop-member-traffic rejoin-timeout 300 set interfaces ams0 load-balancing-options member-failure-options drop-member-traffic enable-rejoin
Configuring High Availability Options
set interfaces ams0 load-balancing-options high-availability-options many-to-one preferred-backup mams-1/0/0
Configuring Service Set and Interface Services
set services service-set ams-ss1 interface-service service-interface ams0.1 set services service-set ams-ss1 interface-service load-balancing-options hash-keys ingress-key source-ip set services service-set ams-ss1 interface-service load-balancing-options hash-keys egress-key destination-ip
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.
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.
[edit] user@router1# set interfaces ams0 load-balancing-options member-interface mams-0/0/0 user@router1# set interfaces ams0 load-balancing-options member-interface mams-0/1/0 user@router1# set interfaces ams0 load-balancing-options member-interface mams-1/0/0 user@router1# set interfaces ams0 load-balancing-options member-interface mams-1/1/0 user@router1# set interfaces ams0 load-balancing-options member-interface mams-2/0/0 user@router1# set interfaces ams0 load-balancing-options member-interface mams-2/1/0
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.
[edit interfaces] user@router1# set ams0 unit 1 family inet
Configure member failure options.
[edit interfaces ams0] user@router1# set load-balancing-options member-failure-options drop-member-traffic rejoin-timeout 300 user@router1# set load-balancing-options member-failure-options drop-member-traffic enable-rejoin
Note:This example shows the
drop-member-trafficconfiguration. 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 theredistribute-all-trafficstatement instead of thedrop-member-trafficstatement.The default behavior, when the
member-failure-optionsconfiguration is not included, is to drop member traffic with a rejoin timeout of 120 seconds.Configure the high-availability options.
[edit interfaces ams0] user@router1# set load-balancing-options high-availability-options many-to-one preferred-backup mams-1/0/0
Configure interface style services.
[edit services] user@router1# set service-set ams-ss1 interface-service service-interface ams0.1 user@router1# set service-set ams-ss1 interface-service load-balancing-options hash-keys ingress-key source-ip user@router1# set service-set ams-ss1 interface-service load-balancing-options hash-keys egress-key destination-ip
If you are done configuring the device, commit the configuration.
[edit] user@router1# commit
Table 1: Key Configuration Statements Used in this Example Statement
Description
member-interfaceAdds a member interface (mams) to the AMS bundle.
drop-member-trafficSpecifies that all traffic to a member be dropped in case the member interface fails.
rejoin-timeoutSpecifies 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-rejoinSpecifies 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-backupDesignates a member interface as the floating backup.
interface-servicesSpecifies a service interface, an AMS interface in this example, to handle interface services.
hash-keysSpecifies the load-balancing hash keys. You can configure the following hash key values:
source-ip,destination-ip,iif(incoming interface),oif(outgoing interface), andprotocol.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.
user@router1# show interfaces ams0
load-balancing-options {
member-interface mams-0/0/0;
member-interface mams-0/1/0;
member-interface mams-1/0/0;
member-interface mams-1/1/0;
member-interface mams-2/0/0;
member-interface mams-2/1/0;
member-failure-options {
drop-member-traffic {
rejoin-timeout 300;
enable-rejoin;
}
}
high-availability-options {
many-to-one {
preferred-backup mams-1/0/0;
}
}
}
unit 1 {
family inet;
}
user@router1# show services
service-set ams-ss1 {
interface-service {
service-interface ams0.1;
load-balancing-options {
hash-keys {
ingress-key source-ip;
egress-key destination-ip;
}
}
}
}
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
Load-balancing interfaces detail
Interface : ams0
State : Up
Last change : 00:01:28
Member count : 6
HA Model : Many-to-One
Members :
Interface Weight State
mams-0/0/0 10 Active
mams-0/1/0 10 Active
mams-1/0/0 10 Backup
mams-1/1/0 10 Active
mams-2/0/0 10 Active
mams-2/1/0 10 Active
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
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
set interfaces ams0 load-balancing-options member-interface mams-1/0/0 set interfaces ams0 load-balancing-options member-interface mams-1/1/0 set interfaces ams0 load-balancing-options member-interface mams-2/0/0 set interfaces ams0 load-balancing-options member-interface mams-2/1/0 set interfaces ams0 unit 1 family inet set interfaces ams0 unit 1 service-domain inside set interfaces ams0 unit 2 family inet set interfaces ams0 unit 2 service-domain outside
Configuring Routing Instances that Use AMS interfaces
set routing-instances ri-internal instance-type virtual-router set routing-instances ri-internal interface ge-0/0/2.0 set routing-instances ri-internal interface ams0.1 set routing-instances ri-internal routing-options static route 22.22.22.0/24 next-hop ams0.1 set routing-instances ri-external instance-type virtual-router set routing-instances ri-external interface ge-2/0/6.0 set routing-instances ri-external interface ams0.2 set routing-instances ri-external routing-options static route 0.0.0.0/0 next-hop ams0.2
Configuring Hash Keys
set interfaces ams0 unit 1 load-balancing-options hash-keys ingress-key source-ip protocol set interfaces ams0 unit 2 load-balancing-options hash-keys ingress-key destination-ip protocol
Configure Next Hop Services
set services service-set ams-test stateful-firewall-rules sfw1 set services service-set ams-test next-hop-service inside-service-interface ams0.1 set services service-set ams-test next-hop-service outside-service-interface ams0.2
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.
Configure an aggregated multiservices interface and the load-balancing options.
[edit interfaces ams0] user@router1# set load-balancing-options member-interface mams-1/0/0 user@router1# set load-balancing-options member-interface mams-1/1/0 user@router1# set load-balancing-options member-interface mams-2/0/0 user@router1# set load-balancing-options member-interface mams-2/1/0 user@router1# set unit 1 family inet user@router1# set unit 1 service-domain inside user@router1# set unit 2 family inet user@router1# set unit 2 service-domain outside
Configure routing instances that use the aggregated multiservices interfaces configured in the first step.
[edit routing-instances] user@router1# set ri-internal instance-type virtual-router user@router1# set ri-internal interface ge-0/0/2.0 user@router1# set ri-internal interface ams0.1 user@router1# set ri-internal routing-options static route 22.22.22.0/24 next-hop ams0.1 user@router1# set ri-external instance-type virtual-router user@router1# set ri-external interface ge-2/0/6.0 user@router1# set ri-external interface ams0.2 user@router1# set ri-external routing-options static route 0.0.0.0/0 next-hop ams0.2
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.
[edit interfaces ams0] user@router1# set unit 1 load-balancing-options hash-keys ingress-key source-ip protocol user@router1# set unit 2 load-balancing-options hash-keys ingress-key destination-ip protocol
Configure next-hop style services under the service-set configuration.
[edit services service-set ams-test] user@router1# set stateful-firewall-rules sfw1 user@router1# set next-hop-service inside-service-interface ams0.1 user@router1# set next-hop-service outside-service-interface ams0.2
Commit the configuration.
[edit] user@router1# commit
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.
user@router1# show interfaces ams0
load-balancing-options {
member-interface mams-1/0/0;
member-interface mams-1/1/0;
member-interface mams-2/0/0;
member-interface mams-2/1/0;
member-failure-options {
redistribute-all-traffic {
enable-rejoin;
}
}
}
unit 1 {
family inet;
service-domain inside;
load-balancing-options {
hash-keys {
ingress-key [ source-ip protocol ];
}
}
}
unit 2 {
family inet;
service-domain outside;
load-balancing-options {
hash-keys {
ingress-key [ destination-ip protocol ];
}
}
}
user@router1# show routing-instances
ri-internal {
instance-type virtual-router;
interface ge-0/0/2.0;
interface ams0.1
routing-options {
static {
route 22.22.22.0/24 next-hop ams0.1;
}
}
}
ri-external {
instance-type virtual-router;
interface ge-2/0/6.0;
interface ams0.2
routing-options {
static {
route 0.0.0.0/0 next-hop ams0.2;
}
}
}
user@router1# show services service-set ams
stateful-firewall-rules sfw1;
next-hop-service {
inside-service-interface ams0.1;
outside-service-interface ams0.2;
}
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.
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.
[edit interfaces ams0]
load-balancing-options {
member-interface mams-5/0/0;
member-interface mams-5/1/0;
}
unit 1 {
family inet;
}
unit 2 {
family inet;
}Configure hashing for the service set for both ingress and egress traffic.
[edit services service-set ss1]
interface-service {
service-interface ams0.1;
load-balancing-options {
hash-keys {
ingress-key destination-ip;
egress-key source-ip;
}
}
}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.
[edit services]
nat {
pool p1 {
address-range low 20.1.1.80 high 20.1.1.80;
}
pool p2 {
address 20.1.1.81/32;
}
}Configure the NAT rule and translation.
[edit services]
nat {
rule r1 {
match-direction input;
term t1 {
from {
source-address {
20.1.1.2/32;
}
}
then {
translated {
source-pool p1;
translation-type {
basic-nat44;
}
}
}
term t1 {
from {
source-address {
40.1.1.2/32;
}
}
then {
translated {
source-pool p2;
translation-type {
basic-nat44;
}
}
}
}
}A similar configuration can be applied for translation
types dynamic-nat44 and napt-44. Twice NAT cannot
run on AMS infrastructure at this time.
See Also
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.