2

Question for someone who knows a lot more about networking than I do...

So, long story shortish, I had an issue with a remote server tonight that I couldn't get corrected over ILO (HP's out-of-band management technology), even after doing a complete RTFM. I noticed that the ILO firmware version on this server was over 5 years old, and figured that might be the cause of my difficulties, so I went to upgrade it, and couldn't. (The ILO web management console provides a mechanism to do firmware updates.) In a mistake I'll regret for a long time, I decided I could call tech support and ask how I could get the firmware updated. Upon actually listening to their advice and doing a soft reset of the interface (also through the ILO web management console), it became non-responsive.

Expected behavior, and I started a ping -t to the ip address of the ILO interface so I'd know when it came back up. Except that the pings were all coming back as Reply from 0.0.0.0: ... I decided to give it a few minutes anyway, in the event that the reset was doing something weird. Well, half an hour later, it was still replying from 0.0.0.0, so I had someone unplug the server. This changed the ping replies to Request timed out. As soon as it was plugged back in, the ping responses from 0.0.0.0 started up again. Even now, 6 hours later, a ping to the "actual" IP address of that ILO interface responds with a reply from 0.0.0.0.

For what it's worth, we do not have a separate VLAN or subnet for our ILO (I'm working on it), and pinging addresses in the subnet with nothing on them does return a Request timed out. A tracert to the address goes through our switches, out the link at our main office, to the other side of T1 at the remote site... and then shows 0.0.0.0. A ping request from over the remote VPN (which is a separate VLAN and subnet) comes back Request timed out.

From everything I know about networking, which is apparently less than I thought I knew as recently as yesterday, it's not possible to get a reply from 0.0.0.0. That's the "any" address. So even if the ILO interface had its address reset to 0.0.0.0, it shouldn't be able to send a reply as 0.0.0.0, so... well, does anyone know why this is happening? Or how this even could happen, for that matter?

UPDATE: Got someone on site to check the settings on ILO, and sure enough, the IP address of the interface got reset to 0.0.0.0.

Zeros

Improve this question
8
  • I would try power cycling the machine. It looks like it's in a confused state.
    – David Schwartz
    Aug 9, 2012 at 5:28
  • @DavidSchwartz Will definitely end up doing that in the morning, but I already did it once to no avail. Second time's the charm, maybe. (I'd do it now, but... well, it's kinda hard to remotely power cycle a machine after your OOB management has been wrecked. :D )
    – HopelessN00b
    Aug 9, 2012 at 5:31
  • What does example 2-5 show us in the pic that the first doesn't?
    – gWaldo
    Aug 9, 2012 at 19:22
  • @gWaldo ...um... average time != 74ms? I have no idea, but is it something really obvious I should be embarrassed for noticing sooner? That's usually what it is.
    – HopelessN00b
    Aug 9, 2012 at 19:53
  • I've had remote sites before, so that didn't bother me.
    – gWaldo
    Aug 9, 2012 at 20:03

2 Answers 2

Reset to default
3

This is most likely a firmware bug, but the only situation I've heard of that -sources- packets from 0.0.0.0 is RARP (reverse ARP) which sends out requests from an all zero MAC to find its IP address. This used to be a component of diskless boot once upon a time but hasn't been seen in quite a while.

It may be that the pinging station still held the ILO's MAC address in cache - and, of course, the intermediary switch. If the ILO had lost its address it could have been going through a RARP / BOOTP process. Or it just lost its mind.

Improve this answer
4
  • Interesting. I'll TS into something else to test the arp cache idea. But in the other instance (RARP/firmware bug), how would the packets even be traversing the network if they're from 0.0.0.0? Wouldn't that be like trying to send a packet from a loopback address through the network? (In that it's not possible.)
    – HopelessN00b
    Aug 9, 2012 at 5:11
  • Not much actually looks at source IP's unless there's some kind of ACL, RPF checking, etc. If the two hosts are in the same subnet and there's an appropriate destination MAC address on the packet then the switch will deliver the frame. I guess in theory the same could be true if the default router were also retained, but this is a bit more of a stretch.
    – rnxrx
    Aug 9, 2012 at 5:14
  • So, given that the IP address the ILO interface had assigned for itself was 0.0.0.0, that would definitely point at arp caching, right? Machines that had connected to it and cached the MAC address would be able to get a reply back, which would say it was from 0.0.0.0, but other machines would be unable to connect because the ILO interface wasn't listening for traffic at its "real"/previous IP. Right? ish?
    – HopelessN00b
    Aug 10, 2012 at 5:24
  • The ILO interface may simply listen for any frame bound for its MAC address and then pass said frame up the stack to the (likely crashed) IP stack. There are still a few other low-level firmware drivers that require a host to statically define an IP->MAC mapping to initiate contact - which is similar to your case. The initiating host would have to have a cached mapping. The intervening communication, however, would require either something held in cache on a switch or flooding of unicast packets.
    – rnxrx
    Aug 16, 2012 at 3:09
2

This is less about the 0.0.0.0 and more about the recovery of your ILO...

I can't determine if the server that houses the ILO is running Windows or Linux, but assuming you can get into the server, my suggestion is to reset the ILO to a sane IP address from the host operating system. This can be accomplished quickly with the hponcfg utility (Linux, Windows).

If you don't know by now, firmware is very important in the HP ProLiant world. Run the updates from the host and avoid updating through the ILO web interface on older firmware revisions.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .