The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes the Cisco NX-OS unicast routing commands that begin with the letter H.
To enable the hardware when both ejectors are open, card is powered down, use the hardware ejector enable command.
network-admin
network-operator
vdc-admin
vdc-operator
|
|
This example shows how to enable the hardware when both ejectors are open:
|
|
---|---|
Displays information about dynamic TCAM allocation for each module. |
To enable or disable dynamic TCAM block allocation in the Forwarding Information Base (FIB), use the hardware forwarding dynamic-allocation command.
hardware forwarding dynamic-allocation { enable | disable }
network-admin
network-operator
vdc-admin
vdc-operator
|
|
As of Cisco NX-OS Release 5.0(x), dynamic TCAM allocation is enabled by default and cannot be disabled.
Use the hardware forwarding dynamic-allocation enable command to reallocate unused blocks in the FIB.
Use the hardware forwarding dynamic-allocation disable command to disable the dynamic TCAM allocation. This command returns the TCAM to the default allocation if there are no routes in the reallocated blocks.
This example shows how to enable dynamic TCAM allocation:
|
|
---|---|
Displays information about dynamic TCAM allocation for each module. |
To expand the number of routes available on the Cisco NX-OS device, use the hardware forwarding l3 resource route non-deterministic command. To set the revert to the default settings, use the no form of the command.
hardware forwarding l3 resource route non-deterministic
no hardware forwarding l3 resource route non-deterministic
|
|
We recommend that you use the hardware forwarding l3 resource route non-deterministic command only under the advisement of Cisco.
This example shows how to expand the number of routes available on the Cisco NX-OS device:
|
|
---|---|
Enable or disable dynamic TCAM block allocation in the Forwarding Information Base (FIB). |
To enable Address Resolution Protocol (ARP) throttling, use the hardware ip glean throttle command. To return to the default setting, use the no form of this command.
|
|
---|---|
Note We recommend that you configure the IP glean throttle feature by using the hardware ip glean throttle command to filter the unnecessary glean packets that are sent to the supervisor for ARP resolution for the next hops that are not reachable or do not exist. IP glean throttling boosts software performance and helps to manage traffic more efficiently.
This example shows how to enable ARP throttling:
switch(config)# hardware ip glean throttle
switch(config)#
|
|
---|---|
To limit the maximum number of drop adjacencies that will be installed in the Forwarding Information Base (FIB), use the hardware ip glean throttle maximum command. If no form is used, default limits will be applied.
hardware ip glean throttle maximum count
no hardware ip glean throttle maximum count
The default value for count is 1000. The minimum value is 0 and the maximum value is 32767 entries
|
|
---|---|
If the maximum number of entries are exceeded, the packets for which ARP is not resolved continue to be processed in the software instead of getting dropped in the hardware.
This example shows how to limit the maximum number of drop adjacencies that are installed in the FIB:
switch(config)# hardware ip glean throttle maximum 2134
switch(config)#
|
|
---|---|
To generate a syslog if the number of packets that get dropped for a specific flow exceeds the configured packet count, use the hardware ip glean throttle syslog command. To return to the default setting, use the no form of this command.
hardware ip glean throttle syslog pkt-count
no ha rdware ip glean throttle syslog pkt-count
The default value for count is 10000. The minimum value is 0 and the maximum value is 64 k (65535) packets
|
|
---|---|
After the timeout period is exceeded, the drop adjacencies are removed from the FIB.
This command does not require a license.
Note The Adjmgr generates a syslog for the configured packet count that will not be accurate to the glean packets dropped hit in FIB. The drop statistics collected from the FIB in S/w (Adjmgr) occurs every two minutes. The Adjmgr generates a syslog only after it receives the stats from the FIB every two minutes only for the adjacencies where the drop count exceeds the configured packet count.
This example shows how to generate a syslog if the number of packets that get dropped for a specific flow exceed the configured packet count:
switch(config)# hardware ip glean throttle syslog 1030
switch(config)#
|
|
---|---|
To configure a timeout for the installed drop adjacencies to remain in the Forwarding Information Base (FIB), use the hardware ip glean throttle timeout command. To return to the default setting, use the no form of this command.
hardware ip glean throttle timeout timeout-in-sec
no hardware ip glean throttle timeout timeout-in-sec
|
|
---|---|
After the timeout period is exceeded, the drop adjacencies are removed from the FIB.
This example shows how to limit the maximum number of drop adjacencies that are installed in the FIB:
switch(config)# hardware ip glean throttle timeout 300
switch(config)#
|
|
---|---|
To configure IP packet verification, use the hardware ip verify command. To disable IP packet verification, use the no form of this command.
hardware ip verify { checksum | fragment | protocol | tcp tiny-frag | version }
no hardware ip verify { checksum | fragment }
All address tests disabled (since Cisco NX-OS Release 5.1(3)).
|
|
---|---|
Use the hardware ip verify command to configure packet verification tests on IPv4 and IPv6 packets based on checksum or fragments.
This command is not supported in F Series modules.
This example shows how to drop fragmented IPv4 or IPv6 packets:
|
|
---|---|
Configures IPv4 and IPv6 packet verification checks based on addresses. |
|
To enable packet verification tests on IP addresses, use the hardware ip verify address command. To disable packet verification tests, use the no form of this command.
hardware ip verify address { destination zero | identical | reserved | source {broadcast | multicast }}
no hardware ip verify address { destination zero | identical | reserved | source {broadcast | multicast }}
|
|
---|---|
Use the hardware ip verify address command to configure packet verification tests on IPv4 and IPv6 packets based on addresses.
This command replaces the platform ip verify address command.
Prior to Cisco NX-OS Release 5.1(3), for Fabric Extender (FEX), you must manually disable the hardware ip verify address reserved option.
In Cisco NX-OS Release 5.1(3), you must disable the hardware ip verify address identical option before enabling the Multiprotocol Label Switching (MPLS) feature.
This example shows how to drop broadcast IPv4 packets:
|
|
---|---|
Configures IPv4 and IPv6 packet verification checks based on checksum or fragments. |
|
To configure IPv4 packet verification tests based on packet length, use the hardware ip verify length command. To disable the tests, use the no form of this command.
hardware ip verify length { consistent | maximum { max-frag | max-tcp | udp } | minimum }
no hardware ip verify length { consistent | maximum { max-frag | max-tcp | udp } | minimum }
|
|
---|---|
Use the hardware ip verify length command to configure packet verification tests on IPv4 and IPv6 packets based on packet length.
This command replaces the platform ip verify length command.
This example shows how to drop minimum-length IPv4 packets:
|
|
---|---|
Configures IPv4 packet verification checks based on checksum or fragments. |
|
Configures IPv4 and IPv6 packet verification checks based on addresses. |
|
To configure IPv6 packet verification tests, use the hardware ipv6 verify command. To disable the tests, use the no form of this command.
hardware ipv6 verify { length { consistent | maximum { max-frag | max-tcp | udp } | tcp tiny-frag | version }
no hardware ip verify { checksum | fragment }
|
|
---|---|
Use the hardware ipv6 verify command to configure packet verification tests on IPv6 packets.
This example shows how to drop all IPv4 packets:
|
|
---|---|
Configures IPv4 and IPv6 packet verification checks based on addresses. |
|
To configure hardware proxy layer 3 forwarding information, use the hardware proxy layer-3 forwarding command. To set the default value, use the no form of the command.
hardware proxy layer-3 forwarding { exclude | use } {{ none } { interface ethernet slot/port | module slot-number } [ module-type f1 ]}
no hardware proxy layer-3 forwarding
(Optional) Specifies type of modules to perform proxyl ayer 3 forwarding for hardware proxy layer 3 forwarding exclude interface ethernet F1 modules. |
|
|
The N7K-F132-15 module only runs Layer 2 switching. So, when you have both this module and an M Series module in one Nexus 7000 Series chassis and you are performing Layer 3 procedures, the system uses proxy routing.
This example shows how to configure hardware proxy forwarding information:
switch(config)# hardware proxy layer-3 forwarding exclude interface ethernet 2/1-16, ethernet 3/1, ethernet 4/1-2
|
|
---|---|
Displays detail information on the proxylayer 3 functionality. |
To specify the interval between hello packets that Cisco NX-OS sends on an Open Shortest Path First (OSPF) virtual link, use the hello-interval command. To return to the default, use the no form of this command.
Hello interval (in seconds). The value must be the same for all nodes on a specific virtual link. The range is from 1 to 65535. |
|
|
---|---|
Use the hello-interval command in virtual link configuration mode to set the hello interval for OSPF across a virtual link. A shorter hello interval detects topological changes faster but causes more routing traffic. The hello interval must be the same for all devices on a virtual link.
This example shows how to configure the hello interval to 15 seconds:
|
|
---|---|
Sets the time period to declare a neighbor as down if the local device receives no hello packets. |
To specify the interval between hello packets that Cisco NX-OS sends on an Open Shortest Path First version 3 (OSPFv3) virtual link, use the hello-interval command. To return to the default, use the no form of this command.
Hello interval (in seconds). The value must be the same for all nodes on a specific virtual link. The range is from 1 to 65535. |
|
|
---|---|
Use the hello-interval command in virtual link configuration mode to set the hello interval for OSPFv3 across a virtual link. A shorter hello interval detects topological changes faster but causes more routing traffic. The hello interval must be the same for all devices on a virtual link.
This example shows how to configure the hello interval to 15 seconds:
|
|
---|---|
Sets the time period to declare a neighbor as down if the local device receives no hello packets. |
To enable the exchange of the dynamic host name for IS-IS, use the hostname dynamic configuration mode command. To disable the exchange of the dynamic host name for IS-IS, use the no form of this com mand
Router configuration
VRF configuration
|
|
---|---|
The hostname dynamic command allows you to enable the IS-IS routers to flood their host name to system ID mapping information across the IS-IS network.
This example shows how to enable the exchange of the dynamic host name for IS-IS:
This example shows how to disable the exchange of the dynamic host name for IS-IS:
|
|
---|---|
To enter Hot Standby Router Protocol (HSRP) configuration mode and create an HSRP group, use the hsrp command. To disable HSRP, use the no form of this command.
hsrp group-number [ ipv4 | ipv6 ]
no hsrp group-number [ ipv4 | ipv6 ]
|
|
---|---|
You must globally enable HSRP before you can configure any HSRP options or create an HSRP group.
The switch creates an IPv4 HSRP group if the ipv6 keyword is not specified.
The keyword ipv4 is optional if only IPv4 with the group ID exists on the interface. If both the IPv4 and IPv6 groups exist on the same interface, you must specify the address type as IPv4 or IPv6.
To configure IPv6 HRSP groups, you must configure HSRP version 2 on the interface.
The IPv4 and IPv6 groups can share the same group ID within an interface.
This example shows how to create and activate an HSRP group:
This example shows how to create and activate an IPv6 HSRP group:
|
|
---|---|
Creates a virtual IP address for the HSRP group. The IP address must be in the same subnet as the interface IP address |
To create an Hot Standby Redundancy Protocol (HSRP) group and enter HSRP configuration mode, use the hsrp command. To remove the HSRP group configuration, use the no form of this command.
|
|
---|---|
This example shows how to create an HSRP group and enter HSRP configuration mode:
This example shows how to remove the HSRP group configuration:
|
|
---|---|
To configure the MAC refresh interval for the Hot Standby Redundancy Protocol (HSRP) slave group, use the hsrp mac-refresh command.
|
|
---|---|
You can use the hsrp mac-refresh command to minimize the number of hello messages that are sent out and reduce HSRP protocol overheads and CPU utilization when multiple subinterfaces are configured.
The hsrp mac-refresh command is not available for individual subinterfaces. It applies to all groups on all subinterfaces.
This example shows how to configure the MAC refresh interval for an HSRP slave group:
|
|
---|---|
To enabled extended hold timers for the Hot Standby Router Protocol (HSRP), use the hsrp timers extended-hold command. To revert to default, use the no form of this command.
hsrp timers extended-hold [ timer ]
(Optional) Extended hold time, in seconds. The range is from 10 to 255. |
|
|
---|---|
Use the hsrp timers extended-hold command to configure extended Non-stop Forwarding (NSF) support for HSRP.
Note You must configure extended hold timers on all HSRP routers if you configure non-default extended hold timers. You can configure different extended holdtimer values on each HSRP routers, based on the expected system switchover delays.
This example shows how to configure the extended hold time for HSRP:
|
|
---|---|
To configure the Hot Standby Redundancy Protocol (HSRP) version 2, use the hsrp version 2 command.
|
|
---|---|
Because the multiple group optimization (MGO) supports only HSRP version 2, you must set the HSRP version to version 2.
This example shows how to configures the HSRP version:
|
|
---|---|