Graceful shutdown of OSPF routing

OSPF routing can be gracefully shut down on HPE switches without losing packets that are in transit. OSPF neighbors are informed that the router should not be used for forwarding traffic, which allows for maintenance on the switch without interrupting traffic in the network. There is no effect on the saved switch configuration

Prior to a switch shutdown, the CLI/SNMP reload command or the CLI boot command is executed to initiate the sending of OSPF "empty hello list" messages on the interfaces that are part of the OSPF routing configuration. After a small delay (approximately 2 seconds) that allows the messages to be transmitted on all applicable interfaces, the boot or reload command continues.

Modules operating in nonstop mode

When a switch is in standalone mode and OSPF routing is enabled, the "empty hello list" is transmitted whenever the boot or reload commands are executed.

When the switch is operating in nonstop switching mode (redundant) and a single module is being reloaded or booted, the standby module will notify neighboring switches of the management module failover. If the failover fails, the "empty hello list" is transmitted before the switch is rebooted.

When a switch is operating with multiple management modules in warm standby mode, the "empty hello list" is sent when a reload or boot command is executed. The standby management module sends out OSPF hello packets after becoming the active management module.

OSPF equal-cost multipath (ECMP) for different subnets available through the same next-hop routes

The switches support optional load-sharing across redundant links where the network offers two, three, or four equal-cost next-hop routes for traffic to different subnets. (All traffic for different hosts in the same subnet goes through the same next-hop router.)

For example, in the OSPF network shown in Example of load-sharing traffic to different subnets through equal-cost next-hop routers, IP load-sharing is enabled on router "A". In this case, OSPF calculates three equal-cost next-hop routes for each of the subnets and then distributes per-subnet route assignments across these three routes.

Example of load-sharing traffic to different subnets through equal-cost next-hop routers

Example of load-sharing traffic to different subnets through equal-cost next-hop routers

Example of a routing table for the network in Example of load-sharing traffic to different subnets through equal-cost next-hop routers

Destination subnet Router "A" next hop
10.1.0.0/16 Router "C"
10.2.0.0/16 Router "D"
10.3.0.0/16 Router "B"
10.32.0.0/16 Router "B"
10.42.0.0/16 Router "D"

IP load-sharing does not affect routed traffic to different hosts on the same subnet. That is, all traffic for different hosts on the same subnet will go through the same next-hop router. For example, if subnet 10.32.0.0 includes two servers at 10.32.0.11 and 10.32.0.22, all traffic from router "A" to these servers will go through router "B".