ECMP Flow-Based Forwarding
This topic provides a brief overview of equal-cost multipath (ECMP) for forwarding and reverse side traffic on Junos OS SRX Series Firewalls and vSRX Virtual Firewall instances. For comprehensive coverage of the ECMP implementation on Junos OS SRX Series Firewalls and vSRX Virtual Firewall instances.
Understanding ECMP Flow-Based Forwarding
Equal-cost multipath (ECMP) is a network routing strategy that allows for traffic of the same session, or flow—that is, traffic with the same source and destination—to be transmitted across multiple paths of equal cost. It is a mechanism that allows you to load balance traffic and increase bandwidth by fully utilizing otherwise unused bandwidth on links to the same destination.
When forwarding a packet, the routing technology must decide which next-hop path to use. In making a determination, the device takes into account the packet header fields that identify a flow. When ECMP is used, next-hop paths of equal cost are identified based on routing metric calculations and hash algorithms. That is, routes of equal cost have the same preference and metric values, and the same cost to the network. The ECMP process identifies a set of routers, each of which is a legitimate equal cost next hop towards the destination. The routes that are identified are referred to as an ECMP set. Because it addresses only the next hop destination, ECMP can be used with most routing protocols.
An equal-cost multipath (ECMP) set is formed when the routing table contains multiple next-hop addresses for the same destination with equal cost. (Routes of equal cost have the same preference and metric values.) If there is an ECMP set for the active route, Junos OS uses a hash algorithm to choose one of the next-hop addresses in the ECMP set to install in the forwarding table.
You can configure Junos OS so that multiple next-hop entries in an ECMP set are installed in the forwarding table. On Juniper Networks devices, per-flow load balancing can be performed to spread traffic across multiple paths between routing devices. On Juniper Networks security devices, source and destination IP addresses and protocols are examined to determine individual traffic flows. Packets for the same flow are forwarded on the same interface; the interface does not change when there are additions or changes to the ECMP set. This is important for features such as source NAT, where the translation is performed only during the first path of session establishment for IDP, ALG, and route-based VPN tunnels. If a packet arrives on a given interface in an ECMP set, the security device ensures that reverse traffic is forwarded through the same interface.
ECMP flow-based forwarding on security devices applies to IPv4 and IPv6 unicast traffic flows. Starting with Junos OS Release 15.1X49-D60, ECMP flow-based forwarding of IPv6 unicast traffic is supported on all SRX Series Firewalls and vSRX Virtual Firewall instances. Multicast flow is not supported.
On Juniper Networks security devices, the maximum number of next-hop addresses in an ECMP set that can be installed in the forwarding table is 16. If there are more than 16 next-hop addresses in an ECMP set, only the first 16 addresses are used.
In a chassis cluster deployment, a local interface is an interface that is on the same node as the interface on which a packet arrives, and a remote interface is an interface that is on the other chassis cluster node. If an ECMP route has both local and remote interfaces in a chassis cluster, then the local interface is favored for the next hop.
If a next-hop address is no longer part of the ECMP set or if it is removed from the routing table because of a route change, a flow that uses the next hop is rerouted and the session is not affected. Rerouting of the flow also occurs if there is a configuration change that takes away the next-hop address or if an administrator takes down the next-hop interface without deleting it. If a next-hop address is removed from the routing table because the interface is deleted or the session is intentionally cleared, the session is killed without being rerouted.
We recommend that interfaces in an ECMP set be in the same security zone. If a flow is rerouted and the rerouted flow uses an interface in a different security zone than the original route, the session is killed.
To configure ECMP flow-based forwarding on Juniper Networks security devices, first define a
load-balancing routing policy by including one or more policy-statement
configuration statements at the [edit policy-options] hierarchy level,
with the action load-balance per-flow. Then apply the routing policy to
routes exported from the routing table to the forwarding table. To do this, include the
forwarding-table and export configuration
statements at the [edit routing-options] hierarchy level.
- ECMP Implementation for Junos OS SRX Series Firewalls and vSRX Virtual Firewall Instances
- ECMP for Reverse Traffic
ECMP Implementation for Junos OS SRX Series Firewalls and vSRX Virtual Firewall Instances
You can configure ECMP for SRX Series Firewalls and vSRX Virtual Firewall instances to implement per-flow load balancing to spread traffic across multiple paths between routing devices. Routes of equal cost have the same preference and metric values. These devices examine the source IP address, the destination IP address, and the protocol to determine individual traffic flows. Traffic with the same source IP address, destination IP address, and protocol number that is permitted by a security policy is forwarded to the same next hop. Junos OS on these devices uses the flow information in its hashing logic.
For Junos OS SRX Series Firewalls and vSRX Virtual Firewall instances, an ECMP set is formed when the routing table contains multiple next-hop addresses for the same destination with equal cost. ECMP allows for multiple next-hop entries in an ECMP set to be installed in the forwarding table. Packets for the same flow are forwarded on the same interface; the interface does not change when there are additions or changes to the ECMP set.
If there is an ECMP set for the active route, Junos OS uses a hash algorithm to choose one of the next-hop addresses in the ECMP set to install in the forwarding table.
ECMP flow-based forwarding on SRX Series Firewalls and vSRX Virtual Firewall instances applies to IPv4 and IPv6 unicast traffic flows. Starting in Junos OS Release 15.1X49-D60 and Junos OS Release 17.3R1, ECMP flow-based forwarding of IPv6 unicast traffic is supported on all SRX Series Firewalls and vSRX Virtual Firewall instances. Multicast flow is not supported.
ECMP for Reverse Traffic
Starting in Junos OS Release 17.3, if you enable ECMP support for reverse traffic, the SRX Series Firewall uses a hash algorithm to determine the interface to use for reverse traffic in a flow. This process is similar to asymmetric routing in which a packet traverses from a source to a destination in one path and takes a different path when it returns to the source.
If you do not enable this feature, the SRX Series Firewall selects a route in the ECMP set to the incoming interface for reverse traffic, which is the default behavior.
You use the allow-reverse-ecmp configuration statement in the [edit
security flow] hierarchy to configure ECMP flow-based forwarding to use
a hash algorithm in selecting a route in the ECMP set for reverse traffic transit.
That is, if you enable this function, rather than selecting a route to the incoming
interface, the SRX Series Firewall uses a hash algorithm to select a route in the
ECMP set for reverse traffic.
Because the ECMP flow-based policy is zone-based, ECMP reverse lookup support ensures that the egress interface used for reverse traffic is in the same zone as the ingress interface used for arriving traffic.
Interfaces in an ECMP set must be in the same security zone. If the egress interface zone is different from the ingress interface zone, a session can be created but the packets will be dropped.
If you decide to enable reverse ECMP, be aware of the following condition and take action to avoid it: When ECMP flow-based forwarding is used, the SRX Series Firewall could cause upstream devices to see only one-way traffic of a session. Problems might ensue for upstream devices that maintain session state, for example, for TCP-proxy and SYN-proxy. The issue is similar to asynchronous routing behavior.
Example: Configuring ECMP Flow-Based Forwarding
This example shows how to configure ECMP flow-based forwarding.
Requirements
No special configuration beyond device initialization is required before configuring this feature.
Overview
This example configures three static ECMP routes on an SRX Series Firewall. Each static route
uses a different next-hop router to reach the destination server. The interfaces
towards the routers are assigned to the untrust security zone. This example creates
a load-balancing routing policy named load-balancing-policy and
applies the policy to all routes exported from the routing table to the forwarding
table.
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.
## Interfaces ## set interfaces ge-0/0/2 unit 0 family inet address 192.168.4.1/24 set interfaces ge-0/0/4 unit 0 family inet address 192.168.1.1/24 set interfaces ge-0/0/6 unit 0 family inet address 192.168.2.1/24 set interfaces ge-0/0/7 unit 0 family inet address 192.168.3.1/24 ## Static routes ## set routing-options static route 172.16.1.0/24 next-hop 192.168.1.2 set routing-options static route 172.16.1.0/24 next-hop 192.168.2.2 set routing-options static route 172.16.1.0/24 next-hop 192.168.3.2 ## Security zones, address book entry, and policy ## set security zones security-zone trust interfaces ge-0/0/2 set security zones security-zone untrust interfaces ge-0/0/4 set security zones security-zone untrust interfaces ge-0/0/6 set security zones security-zone untrust interfaces ge-0/0/7 set security address-book global address FTP-servers 172.16.1.0/24 set security policies from-zone trust to-zone untrust policy permit-ftp match source-address any set security policies from-zone trust to-zone untrust policy permit-ftp match destination-address FTP-servers set security policies from-zone trust to-zone untrust policy permit-ftp match application junos-ftp set security policies from-zone trust to-zone untrust policy permit-ftp then permit ## ECMP routing policy ## set policy-options policy-statement load-balancing-policy then load-balance per-flow set routing-options forwarding-table export load-balancing-policy
Procedure
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy.
To configure ECMP flow-based forwarding:
Configure interfaces.
[edit interaces] user@host# set ge-0/0/2 unit 0 family inet address 192.168.4.1/24 user@host# set ge-0/0/4 unit 0 family inet address 192.168.1.1/24 user@host# set ge-0/0/6 unit 0 family inet address 192.168.2.1/24 user@host# set ge-0/0/7 unit 0 family inet address 192.168.3.1/24
Configure static routes.
[edit routing-options] user@host# set static route 172.16.1.0/24 next-hop 192.168.1.2 user@host# set static route 172.16.1.0/24 next-hop 192.168.2.2 user@host# set static route 172.16.1.0/24 next-hop 192.168.3.2
Create the
trustanduntrustsecurity zones, and include the related interfaces.[edit security] user@host# set zones security-zone trust interfaces ge-0/0/2 user@host# set zones security-zone untrust interfaces ge-0/0/4 user@host# set zones security-zone untrust interfaces ge-0/0/6 user@host# set zones security-zone untrust interfaces ge-0/0/7
Configure an address book entry for the server subnet.
This entry is used in the security policy.
[edit security address-book] user@host# set global address FTP-servers 172.16.1.0/24
Configure a security policy.
[edit security policies from-zone trust to-zone untrust] user@host# set policy permit-ftp match source-address any user@host# set policy permit-ftp match destination-address FTP-servers user@host# set policy permit-ftp match application junos-ftp user@host# set policy permit-ftp then permit
Create a load-balancing routing policy.
[edit policy-options] user@host# set policy-statement load-balancing-policy then load-balance per-flow
Apply the routing policy to all routes exported from the routing table to the forwarding table.
[edit routing-options] user@host# set forwarding-table export load-balancing-policy
Results
From configuration mode, confirm your configuration
by issuing the show interfaces, show security, show policy-options, and show routing-options commands. If the output does not display the intended configuration,
repeat the instructions in this example to correct the configuration.
[edit]
user@host# show interfaces
ge-0/0/2 {
unit 0 {
family inet {
address 192.168.4.1/24;
}
}
}
ge-0/0/4 {
unit 0 {
family inet {
address 192.168.1.1/24;
}
}
}
ge-0/0/6 {
unit 0 {
family inet {
address 192.168.2.1/24;
}
}
}
ge-0/0/7 {
unit 0 {
family inet {
address 192.168.3.1/24;
}
}
}
user@host# show security
address-book {
global {
address FTP-servers 172.16.1.0/24;
}
}
policies {
from-zone trust to-zone untrust {
policy permit-ftp {
match {
source-address any;
destination-address FTP-servers;
application junos-ftp;
}
then {
permit;
}
}
}
}
zones {
security-zone trust {
interfaces {
ge-0/0/2.0;
}
}
security-zone untrust {
interfaces {
ge-0/0/4.0;
ge-0/0/6.0;
ge-0/0/7.0;
}
}
}
user@host# show policy-options
policy-statement load-balancing-policy {
then {
load-balance per-flow;
}
}
[edit]
user@host# show routing-options
static {
route 172.16.1.0/24 next-hop [ 192.168.1.2 192.168.2.2 192.168.3.2 ];
}
forwarding-table {
export load-balancing-policy;
}
If you are done configuring the device, enter commit from configuration mode.
Verification
Verifying the Forwarding Table
Purpose
Verify that the route information for all ECMP routes appears in the forwarding table.
Action
From operational mode, enter the show route forwarding-table destination 172.16.1.0 command.
user@host> show route forwarding-table destination 172.16.1.0
Routing table: default.inet
Internet:
Destination Type RtRef Next hop Type Index NhRef Netif
172.16.1.0/24 user 0 ulst 262142 2
192.168.1.2 ucst 560 2 ge-0/0/4.0
192.168.2.2 ucst 561 2 ge-0/0/6.0
192.168.3.2 ucst 562 2 ge-0/0/7.0
...Meaning
The output shows a next hop type of ulst, which means the route has multiple eligible next hops. Packets
destined for the 172.16.1.0 network can use any next hop in the list.
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.