Aaron Toponce wrote:
> On 04/28/2010 10:05 PM, Jacob Adams wrote:
>> A little bit off topic, but bear with me here.  Would a packet sniff
>> on the network reveal the rogue dhcp server by inspecting from what
>> IP address the DHCPOFFER packets are coming from?  If you've got two
>> servers, you'll know which one is yours, so the other would have to
>> be the offending server.    
> 
> That's exactly it. You just get the offending IP address of the rogue
> server, find the port on the switch those packets are going through,
> then you have the cable that traces back to the physical box.  

In my relatively little experience (I'd actually refer to them as dabblings)
in network management, I'd say this step is not even necessary.

Due to the way the problem "goes down" it usually starts with a frustrated
user wondering "why the internet doesn't work".  You usually forego your 5
minute speech about why the internet is actually working, the user just
can't see it working, and start by asking them what happens when they open
Google, do an nslookup, etc.  The next thing you ask is what is the output
of ipconfig.  Then you see that even though you're running a 192.x.x.x
network, they've got a 10.x.x.x network.  You mute the caller and release
some frustration in the form of a yell due to what Stuart has previously
described.  Something about your well-tuned machine and someone turning
knobs.

No you KNOW the ip address that's sending out DHCPOFFERs...  It's 99.99999%
of the time none other than the "gateway" from the victim's ipconfig output.
So packet sniffing for DHCPOFFERs is replicating efforts at this point.

The other point is: I am not a CCNA and it's possible there's a command I'm
not aware of, but as far as I know there wasn't a way to show an ip address
list on a layer 3 device, such as a switch.  We usually deal with MACs (the
address, not the crappy computer) when you get farther out on the limbs of
the network.  I could be wrong here though, and I'm always interested in
learning new Cisco commands, so please share.


Brian


--------------------
BYU Unix Users Group 
http://uug.byu.edu/ 

The opinions expressed in this message are the responsibility of their
author.  They are not endorsed by BYU, the BYU CS Department or BYU-UUG. 
___________________________________________________________________
List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list

Reply via email to