Configuring Load Sharing in the Unicast FIB
Dynamic routing protocols, such as Open Shortest Path First (OSPF), support load balancing with equal-cost multipath (ECMP). The routing protocol determines its best routes based on the metrics configured for the protocol and installs up to the protocol-configured maximum paths in the unicast RIB. The unicast RIB compares the administrative distances of all routing protocol paths in the RIB and selects a best path set from all of the path sets installed by the routing protocols. The unicast RIB installs this best path set into the FIB for use by the forwarding plane.
The forwarding plane uses a load-sharing algorithm to select one of the installed paths in the FIB to use for a given data packet.
You can globally configure the following load-sharing settings:
- load-share mode—Selects the best path based on the destination address and port or the source and the destination address and port.
- Universal ID—Sets the random seed for the hash algorithm. You do not need to configure the Universal ID. Cisco NX-OS chooses the Universal ID if you do not configure it.
Note Load sharing uses the same path for all packets in a given flow. A flow is defined by the load-sharing method that you configure. For example, if you configure source-destination load sharing, then all packets with the same source IP address and destination IP address pair follow the same path.
To configure the unicast FIB load-sharing algorithm, use the following command in global configuration mode:
|
|
ip load-sharing address {source |
destination port destination |
source-destination [
port
source-destination ]} [
universal-id
seed ]
switch(config)# ip load-sharing address source-destination
|
Configures the unicast FIB load-sharing algorithm for data traffic. The universal-id range is from 1 to 4294967295. A new load sharing option is supported for ECMP, based on the source IP address. The new CLI option looks for the source IP address only on the traffic to load the balance, ignoring the rest of the parameters, for example, the destination IP address and the Layer 4 source port/destination port. |
Configuring Hash Offset
To avoid ECMP polarization in a multi-tier ECMP session, you must configure a different ECMP hash-offset on each tier. Starting with Release 6.0(2)U5(1), a new CLI for ECMP hash concatenation is introduced to achieve uniform distribution of the traffic across 16 way ECMP paths. The updated CLI support exists for Cisco Nexus 3100 Series switches and not on Cisco Nexus 3000 Series switches. You can configure the hash offset in the range of <0-15> in non-concatenate mode and in the range of <0-63> in concatenate mode.
In concatenation mode, if the hash-offset is set to 0 and concatenation is set, the show running-config command displays hardware ecmp hash-offset 0 concatenation. The hash-offset is programmed as per value. On downgrade, if concatenation is configured, the CAP check asks to remove the configuration.
In non-concatenation mode, if the hash-offset is set to 0 and concatenation is reset, the show running-config command does not display hardware ecmp hash-offset 0. The hash-offset is programmed as per value if the hash-offset value is in range 0-15. The hash-offset displays CLI error if the value is in range 16-63 (The non-concatenated mode supports hash-offset for 0-15 range).
The hash-offset in show running-config is visible as per the configured value.
To configure an ECMP hash-offset, use the following commands in global configuration mode:
|
|
#
hardware ecmp hash-offset
?
|
Configures the ECMP hash-offset. The range is from 0 to 63. The hash offset in the range <0-15> is for the non-concatenate mode. The hash offset in the range <0-63> is for the concatenate mode. |
#hardware ecmp hash-offset
number
switch(config)# hardware ecmp hash-offset 5
|
Configures the ECMP hash-offset in the non-concatenate mode. The range is from 0 to 15. The default value is 0. |
#hardware ecmp hash-offset <0-63> concatenation
switch(config)# hardware ecmp hash-offset 63 concatenation
|
Configures the ECMP hash-offset in the concatenate mode. Note Concatenation support exists for Cisco Nexus 3100 series switches and not for Cisco Nexus 3000 series switches. This CLI generates an error on Cisco Nexus 3000 series switches. |
You can use the ECMP hash-offset configured by using the hardware ecmp hash-offset command along with different universal IDs configured by using the ip load-sharing address command to produce various hash results in the load-sharing algorithm.
Configuring Hash Polynomial
Starting with Release 6.0(2)U5(1), new CLI is added for the CRC configuration.
|
|
|
Enters configuration mode. |
switch(config)#
hardware ecmp
?
hash-offset Configure hash offset
hash-polynomial Configure hash polynomial
|
Displays hash-offset and hash-polynomial as the configuration options for hardware ECMP. |
switch config)#
hardware ecmp hash-polynomial ?
CRC16 Hash polynomial CRC16
CRC32HI Hash polynomial CRC32 HI
|
Displays CRC16 and CRC32HI as configuration options for Hash polynomial. |
switch config)#show running-config
|
Displays the running configuration. |
To display the unicast FIB load-sharing algorithm, use the following command in any mode:
|
|
switch(config)# show ip load-sharing
|
Displays the unicast FIB load-sharing algorithm for data traffic. |
To display the route that the unicast RIB and FIB use for a particular source address and destination address, use the following command in any mode:
|
|
show routing hash
source-addr dest-addr [
ip-proto
ip-protocol ] [
source-l4-port dest-l4-port ] [
vrf
vrf-name ]
switch# show routing hash 1.1.1.6.5.5 5.3 ip-proto 0x11 10 234
|
Displays the route that the unicast RIB FIB use for a source and destination address pair. The source address and destination address format is x.x.x.x. The source port and destination port range is from 1 to 65535. The VRF name can be any case-sensitive, alphanumeric string up to 64 characters. The ip-proto option corresponds to the protocol field of the IP header. |
This example shows how to display the route selected for a source/destination pair:
switch# show routing hash 1.1.1.6.5.5.5.3 ip-proto 0x11 10 234
Load-share parameters used for software forwarding:
load-share mode: address source-destination port source-destination
Universal-id seed: 0xe05e2e85
Invoking pc_ic_ecmp_resolution
Hashing to path *Eth1/29%
5.5.5.0/24 ubest/mbest: 3/0
*via 2.2.2.1, Eth1/18, [1/0], 00:14:14, static
*via 3.3.3.1, Eth1/29, [1/0], 00:14:14, static
*via 4.4.4.1, Eth1/34, [1/0], 00:14:14, static
Triggering the Layer 3 Consistency Checker
You can manually trigger the Layer 3 consistency checker.
To manually trigger the Layer 3 consistency checkerfor IPv4 or IPv6 routes, use the following commands in global configuration mode:
|
|
test [
ipv4 ] [ipv6] [
unicast] forwarding inconsistency [
vrf
vrf-name ] [
module {
1 |
all }]
switch(config)# test forwarding inconsistency
|
Starts a Layer 3 consistency check. The vrf-name can be any case-sensitive, alphanumeric string up to 32 characters. The slot to be checked can be either 1 or all. |
To stop the Layer 3 consistency checker for IPv4 or IPv6 routes, use the following commands in global configuration mode:
|
|
test forwarding [
ipv4 ] [ipv6] [
unicast ]
inconsistency [
vrf
vrf-name ] [
module {
1 |
all }]
stop
switch(config)# test forwarding inconsistency stop
|
Stops a Layer 3 consistency check. The vrf-name can be any case-sensitive, alphanumeric string up to 64 characters. The slot can be either 1 or all. |
To display the Layer 3 inconsistencies for IPv4 or IPv6 routes, use the following commands in any mode:
|
|
show forwarding [
ipv4 ] [ipv6]
inconsistency [
vrf
vrf-name ] [
module {
1 |
all }]
switch(config)# show forwarding inconsistency
|
Displays the results of a Layer 3 consistency check. The vrf-name can be any case-sensitive, alphanumeric string up to 32 characters. The slot can be either 1 or all. |