Pra Pra Pra
I've lost a machine.
In the monster setup I'm doing in the 404, I blew a static DHCP setup and directed an IPMI NIC over to an address it couldn't have -- it was taken. After the dust cleared from the resulting fight between it and a photocopier that was squatting on that IP - right in the middle of the range I'd pre-allocated - the IPMI NIC seems to have gone away. It's not at the IP it should be, it's not at the IP I set aside for it during the squabble and to which it never went, and it's not sleuthable at a 169.254.x.y IP as it also could be. I'm all but sunk on that one machine until I can get a human to dump the power on the box (that's why we have IPMI) and bring it back up. It should kick the IPMI back onto the state table and get it networking again. Ugh.
I've since learned two things: arping and inarp.
Arping, here, helps me ensure an IP is really vacant before I allocate it. DHCP should, too, but it wasn't doing so well in this case since I hard-coded it into the config. This, folks, is why we define pools and stick to them. All the problems with "dhcp causing IP conflicts", as some hicks in the 561 claimed, were all through mis-use like I did here. So, do this next time:
The next thing, which I dearly need now, is a linux implementation of Inverse ARP, or inarp. It's different from RARP ("who am I on this MAC") because it solicits for a third party, essentially asking "What IP is on that MAC?"
No inarp.c though. I found one for Windows, but I don't have control of a winbox on that network, where I can inject arps. Argh.
Anyone found a decent Inverse ARP tool for linux? I'll even take one in perl.
In the monster setup I'm doing in the 404, I blew a static DHCP setup and directed an IPMI NIC over to an address it couldn't have -- it was taken. After the dust cleared from the resulting fight between it and a photocopier that was squatting on that IP - right in the middle of the range I'd pre-allocated - the IPMI NIC seems to have gone away. It's not at the IP it should be, it's not at the IP I set aside for it during the squabble and to which it never went, and it's not sleuthable at a 169.254.x.y IP as it also could be. I'm all but sunk on that one machine until I can get a human to dump the power on the box (that's why we have IPMI) and bring it back up. It should kick the IPMI back onto the state table and get it networking again. Ugh.
I've since learned two things: arping and inarp.
Arping, here, helps me ensure an IP is really vacant before I allocate it. DHCP should, too, but it wasn't doing so well in this case since I hard-coded it into the config. This, folks, is why we define pools and stick to them. All the problems with "dhcp causing IP conflicts", as some hicks in the 561 claimed, were all through mis-use like I did here. So, do this next time:
# arping -D 192.168.1.6 -w 5And we can be sure that something's there if it replied within 5 seconds.
ARPING 192.168.1.6 from 0.0.0.0 eth0
Unicast reply from 192.168.1.6 [00:04:01:EF:D8:4C] for 192.168.1.6 [00:04:01:EF:D8:4C] 0.650ms
Sent 1 probes (1 broadcast(s))
Received 1 response(s)
arping -D 192.168.1.112 -w 5
ARPING 192.168.1.112 from 0.0.0.0 eth0
Sent 6 probes (6 broadcast(s))
Received 0 response(s)
The next thing, which I dearly need now, is a linux implementation of Inverse ARP, or inarp. It's different from RARP ("who am I on this MAC") because it solicits for a third party, essentially asking "What IP is on that MAC?"
No inarp.c though. I found one for Windows, but I don't have control of a winbox on that network, where I can inject arps. Argh.
Anyone found a decent Inverse ARP tool for linux? I'll even take one in perl.
<< Home