[vox-tech] Another Round of eth0 Problemas - Fixed, now how t o prevent?

Jeff Newmiller jdnewmil at dcn.davis.ca.us
Thu Mar 3 10:47:44 PST 2005


On Thu, 3 Mar 2005, Karalius, Joseph wrote:

> Ken Herron wrote:
> > It sounds like you might have another computer on your LAN using the 
> > same IP address.
> 
> Ken wins!
> The problem turned out to be someone else in IT was bringing a new printer
> online with the same IP address. Doh!

... 20/20....

> I discovered this when I entered http://mmagdb/ for the 122nd time, and
> instead of serving up the redirect from Apache, the Plone site, or nothing
> at all, an HP printer status page from the offending piece of equipment came
> up with confirmation of the duplicate IP.  The printer was promptly brought
> down and everything seems to be working as expected.  Our WAN guy maintains
> that he checked for duplicate IP addresses.

He "checked"? Since the switch responds to whichever device sent a packet
last, and the printer won't be emitting as many packets as an intranet
server, the switch is likely to point to the server most of the
time.

> Why do the little things cause the biggest headaches?
> 
> This is the second time I've run into duplicate IP address problems on this
> network.  The static IPs are mixed into the same host range with the DHCP
> licensed IPs and IT's system for organizing them or notifying all personnel
> of IP assignments has failed.  It like they just hijack a number and don't
> even ping for a response.  I heard there's an Excel file somewhere that has
> the reserved static IP addresses on it but changes to the file are not
> propagated to everyone in the IT group.  Huh? There's gotta be a better
> way...

Yes and no.  If someone who thinks they know what is going on hijacks a
number, you can't stop them.  You have to have the cooperation of people
using the network.

> I spent the better part of the last 5 days fretting about this problem which
> turned out to be because of lack of communication by IT.  (Of course, if I
> knew better, I should have explored that possibility further.)  I plan to
> address this with the parties involved, but instead of just ripping into
> them I want to bring suggestions to the table.  It's not my job to do either
> of those but it's for their own good, since the next time they knock this
> server out, the downtime will be far more expensive and they will get kicked
> with a bigger boot from management.
> 
> So, if I may redirect the discussion, I'd like to hear about how the network
> admins on the list organize IP assignments.  More specifically, is it wise
> to put static IPs shuffled within the DHCP licensed host range and simply
> blacklist the statics from the DHCP server?

Unwise... and unusual.

>  Why not put the static IPs in a
> different network, that way the address itself would tell you the address
> type (static vs. dynamic) and if partitioned out even further, printers
> could be in one host range on the network ,and servers could be in another.

Not a different network, since that would imply different broadcast
addresses... but you can use convention to subdivide the network.  DHCP
servers are specifically configurable to allow the administrator to set
aside a range for allocating dynamic ip addresses.

I setup a range for statics (usually near the bottom of the network
address range), then a range for dynamic leases (near the top) and a third
range for MAC-allocated DHCP addresses in the middle somewhere.

> Is it common to just ping addresses to find an unused one and then grab it?

Common? depends which idiot is handing out the advice.

> Or is this a non-issue and only newbies and hacks are affected by it?

It is always an issue as an organization grows larger.  I don't manage a
large network so I don't speak from experience, but I would advocate a
visible, public (within the organization) document like a web page for
making the policy clear and providing instructions for who to talk to
about adding equipment that doesn't use DHCP.  I think it is important to
enlist people's cooperation, because failing to do so leads to these
problems.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil at dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...1k
---------------------------------------------------------------------------




More information about the vox-tech mailing list