1

Hi All,

I’m having an issue with the iLO of my Proliant DL360 Gen 10 which has been there since purchasing it around 12 months ago. This server is the sole server located in a remote office, and unless you’re physically in that office, I can’t connect or even ping iLO. It has a static IP and all network settings are correct.

I can connect to all my iLO’s in my main office from that remote office fine. Strange thing is that when I restart iLO from the web interface, I can ping and connect to it for a few minutes once it come back online. But it soon drops out again.

I’m thinking it’s more iLO related than network issues, does anyone have any ideas?

7 Spice ups
2

If it pings after restarting then you probably have all the network settings in iLo correct. Sounds like maybe the port on the switch closing down. Check STP on the switch.

3

I can check, but like I said, you can get to it whilst in that office. If it was closing down, surely I wouldn’t be able to do that?

4

Does it continue to respond on ssh/http/https when ping stops responding?

I’m usually having https go down with my ilo’s and have to ssh in and restart the ilo to get https back up.

5

No nothing, no SSH, HTTP or HTTPS between sites, but all ok when in that office.

6

Are you sure gateway is set right on the ilo and firewall isn’t preventing access? Do you have any logs from the firewall showing the ping coming from source to ilo and back as allowed or dropped?

7

The gateway is 100% correct. The domain field is populated correctly, the time zone is correct, I’ve gone through every setting to make sure there’s nothing wrong.

I’ve compared trace routes from the actual server and it takes 3 hops to get to it over our VPN, hop 2 is the public facing interface of our firewall, and then hop 3 goes to the server. When tracing to the iLO, it times out on hop 3.

I don’t have access to our firewall logs, but I have been in contact with our ISP who has said they can’t see any entries on the firewall for me pinging it to even show an error. They’re cofident it’s not a firewall issue, but surely it has to be if the trace route shows it’s reaching the firewall?

8

I’ve been looking at this at bit more - I’ve updated iLO to 2.81, it was around 2.5 and it’s still the same. I’m pinging it during an iLO restart, and it came back to life and responds to pings anywhere between 250 and 350 packets before it times out, I sort of expected it to be more cosistent each time so who knows.

Our ISP is saying that they can now see traffic over the VPN when I try to access it, but the iLO isn’t responding back. Again surely it is a firewall issue? If we take the firewall out of the equation, it’s fine.

9

How are you accessing the iLO at the remote site, VPN or over the web?

10

Hey OP!

Wanted to check in and see if you’ve made any progress on this issue? I found this guide for remote iLO troubleshooting in case it has some helpful info in the meantime - Feel free to drop me a line if I can help assist further or do more digging on the HPE end! Best of luck!

@HPE

@jonathanbyron2

11

Hi All,

We’ve had this problem for a while now, but recently I’ve decided to troubleshoot this properly. To make a long story short - you seem to have a device in your network, most probably a Cisco SG-series switch or its Linksys analog, that periodically sends out ICMP Type 9 (IPv4 Router Advertisement for Mobile IP).
For God knows why iLO honors these Advertisements and silently changes static IPv4 default gateway to the value provided in RA. It looks like all iLO revisions available to me (3/4/5) behave the same way with latest firmware from HPE.
Unfortunately, there seems to be no way to disable this stupid behavior neither in iLO config, nor within Cisco SG-series switches - other than converting them to L2 only with set system mode switch losing all the configuration in the process. So the only way to fix this is to make sure that device that sends these advertisements can route your iLO traffic accordingly.
You can find more gory details about this issue in my blog post.

2 Spice ups
12

Hi,

I’d pretty much given up on this, but have decided to revisit it and came across my own post when Googling and noticed this response. I’m trying to confirm this to be the case, but it seems like this is my exact issue.

As mentioned, this server is in a remote office but they have multiple Cisco managed switches all setup as layer 3. Unsure why because there’s no VLAN’s setup, but assume there were previously.

I started going through every option to find a configuration that was wrong. I did find on these switches references to our old IP address range of 192.168../24 before we changed over to 10.20../22. It seems like the guy in charge of that office at the time changed the IP of the management interface of the switches, and nothing else. Some of them have the old IP for DHCP relay, although some switches have the relay enabled and some don’t. All had the old DNS entries. I’ve updated everything I can find and iLO is still the same.

I’m struggling to find where this configuration is set on the switch that is advertising the wrong gateway. From what I’ve read, Layer 3 switches don’t have a gateway, only when set to Layer 2. When L3, they use routes. That’s fine, but no routes have been setup on any switch.

As mentioned, the symptoms are exactly as you’ve documented. iLO pings from outside the subnet for a random amount of time after a reset and then nothing, only local access. Any further guidance on this would be much appreciated.

13

Hi,

On my SGs the ipv4 gateway is configured under IP Configuration → IPv4 Management Interface → IPv4 Static Routes when accessed via Web management or with ip default-gateway a.b.c.d when accessing CLI via SSH or console.

A proper way to find the culprit that I have used is to mirror the iLO port on the switch to another port where you can capture the traffic, reset the iLO and wait until pings cease. Then, at the end of this capture you’ll find ICMP to 224.0.0.1 and a source of this packet is the IP address of the switch that generated RA.