Issue with HP iLO (IPv6) after switch replacement

[robo764]

I have recently replaced a Catalyst 4507 with a 9407.  Since the upgrade, several HP iLO have stopped being accessible from outside their VLAN.  This is resolvable by going to each iLO and disabling the setting that tells it to prefer IPv6.  What I'd like to understand is what default configuration on the 9407 (running Cupertino, 17.9.5) is causing this issue. I've made some configuration adjustments to resolve an issue with NTP (bug CSCwb37650 ), but this was done after the iLO issue was diagnosed and so shouldn't be related (other than obviously not resolving the issue).  I can easily enough resolve the issue by re-configuring the iLOs, but this isn't the only upgrade/replacement I have slated, so I'd like to find out what change is being introduced that's causing this issue, where it previously didn't matter. I'd be lying if I said I'm extremely experienced/comfortable with IPv6, so I'd appreciate any advice.  Aside from the steps outlined in the workaround for the aforementioned bug, I've also disabled IPv6 redirects and verified that "ipv6 unicast-routing" was disabled.

[rayanconnor11]

Your issue with HP iLO (Integrated Lights-Out) IPv6 connectivity after replacing the Catalyst 4507 with a 9407 suggests that the new switch's default IPv6 handling differs from the previous configuration. Here’s a breakdown of possible causes and solutions:

---

Potential Causes & Solutions:

1. HP iLO Preferring IPv6 Over IPv4

• Since iLO defaults to preferring IPv6, it may be attempting to communicate over IPv6 instead of IPv4, but routing changes in the 9407 (Cupertino 17.9.5) are preventing proper external access.
• Workaround (You already found this): Disabling the IPv6 preference on each iLO manually.

2. Changes in IPv6 Behavior in Cisco 9407

• The Catalyst 9407 (running Cupertino 17.9.5) may have different default IPv6 handling compared to the 4507.
• The default behavior of IPv6 unicast-routing may be impacting how IPv6 traffic is forwarded.

Check if IPv6 routing is truly disabled:

show running-config | include ipv6 unicast-routing

 If it is enabled, try disabling it (since your setup may not rely on IPv6 routing).

no ipv6 unicast-routing

3. ND Proxy or RA Issues (IPv6 Neighbor Discovery / Router Advertisements)

• Some Cisco switches send IPv6 Router Advertisements (RA) by default, which could be affecting HP iLO’s decision to prefer IPv6.
• Solution: Try disabling RAs on the VLAN interface:

interface VlanX
 no ipv6 nd ra suppress

or

interface VlanX
 ipv6 nd suppress-ra

• Also, check if your switch is acting as a default gateway for IPv6, which could be impacting reachability.

---

4. IPv6 Redirects or ACL Blocking Traffic

• You mentioned disabling IPv6 redirects—this is a good step.
• Check if any IPv6 ACLs are in place that might be affecting connectivity:

show ipv6 access-list

Check if the iLO is successfully learning its default gateway and neighbors:

show ipv6 neighbors

Conclusion & Next Steps

• The new 9407 switch likely handles IPv6 differently than the 4507, potentially due to IPv6 routing, RA behavior, or ACLs.
• First, verify that ipv6 unicast-routing is truly disabled if you're not using IPv6 routing.
• Check for RA suppression and ACL rules that might be preventing IPv6 traffic.
• Try disabling MLD snooping if IPv6 multicast neighbor discovery seems affected.

Since this issue only impacts external VLAN access but works within the VLAN, it's likely related to routing, RA suppression, or ACLs. Let me know if you need further troubleshooting steps!

[robo764]

Thanks for the response.  I've verified that ipv6 unicast-routing is disabled (as much as I'm able; it's not present in the config, and I've made doubly sure by issuing the "no ipv6 unicast-routing" command).

As it stands, here are the relevant config snips for the VLAN interface, the physical interface connected to the iLO, and the ACL that's referenced.  The ACL was created to resolve an NTP issue (hence the name), and I've only applied it in an attempt to further block any ipv6.

interface Vlanxxx
 ipv6 nd ra suppress
 no ipv6 redirects
 no ipv6 pim
!
interface GigabitEthernetxxx
 switchport access vlan xxx
 ipv6 nd suppress
 ipv6 traffic-filter DENY-NTP-IPV6-BROADCAST in
 ipv6 traffic-filter DENY-NTP-IPV6-BROADCAST out
!
IPv6 access list DENY-NTP-IPV6-BROADCAST
    deny ipv6 any any sequence 10

[robo764 · Accepted solution]

This is just in case anyone is as boneheaded as me and searches for something like this:

So it apparently has nothing to do with IPv6.  Looking through packet captures, I verified that there was, in fact, IPv4 traffic (my ICMP echo/request, combos for one thing) for the device.  There seemed to be nothing IPv6 related that should be causing this, but I found out that we hadn't performed a reset of the iLO devices before changing the IPv6 preference (which came with a reset).  We performed a reset without changing anything and it started working fine.  I removed all of the IPv6 config changes that I'd made attempting to resolve it, performed another reset, and it continued working fine.  I'm not an iLO guy, so I'll see if I can figure out what caused the required reset and the behavior we were seeing, but at the very least this issue wasn't related to IPv6 preference, as I believed.  ¯\_(ツ)_/¯