If the router is getting it's address via dhcp, then it can't happen that way - the dhcp server will hand out the address to only one customer at a time.
However, if the router is using a static address in your dhcp range, well, it's all doing exactly what you told it to do. Remember, the dhcp conflict messages are broadcasts and won't cross collision domains. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of pc Sent: Tuesday, September 02, 2003 9:52 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop-dev] IP - MAC mapping changes (was: Issues w/ ntop 2.2.93) I may have run across the cause of this issue. After watching things for a while I noticed that the transformation did not usually occur very soon after ntop was restarted; usually it was hours later. But after tracking it a bit closer I noticed that it would always occur at least daily. After thinking about what could possibly be taking place on the network with long durations between events, it dawned on me that it could be DHCP. It seems there may be a bug with the RedHat installation process. My normal method is to place a reservation on the DHCP server and let the processes do what they are designed to do. I looked at /etc/dhclient-eth0.conf and suddenly things came together. The one line config item states: send host-name "172.22.22.254"; # temporary RHL ifup addition This IP address is for my default router! Then I found the same thing in /etc/sysconfig/ifcfg-eth0 (DHCP_HOSTMANE=172.22.22.254). This would cause the DHCP client to get a lease for the wrong hostname and in this case it was my default router. So the long and short of it is that ntop was probably acting strange due to this misconfiguration. It's one of those things where there were no other symptoms. The machine was otherwise coming up fine with the assigned hostname and the correct IP address. I'm thinking that I may have screwed up during the initial install, but I sort of doubt it where I have not any issues with the hostname otherwise. I certainly would have noticed if the machine had shown me somewhere else that its hostname is the default router's IP address. Maybe it's a new 'feature' in RH 9. I will continue to watch this for a while to make sure the condition is corrected, but I suspect this an issue we can put to bed. Tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Burton M. Strauss III Sent: Sunday, August 31, 2003 6:42 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop-dev] IP - MAC mapping changes (was: Issues w/ ntop 2.2.93) Well, without seeing the traffic, there's not much I can say. I don't have even a ghost of a beginning towards explaining what you're seeing. You *might* try enabling the -q | --create-suspicious-packets switch. It will put out some additional warnings and dump the offending packets to a tcpdump formatted file (unfortunately, it can't go back in time to grab the original packet). Most of them you won't care about, but some might be relevant - stuff like this: **WARNING** Two MAC addresses found for the same IP address %s: [%s/%s] (spoofing detected?) The other thing you might do is see if there's a light usage host that does the switching and try to grab only it's packets. If you can come up with a trace file of a few packets or even a few dozen, it's something to look at. Otherwise, you will need to instrument the logic where ntop stores these things and see what the log messages tell you. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of pc Sent: Thursday, August 28, 2003 8:43 PM To: [EMAIL PROTECTED] Subject: RE: [Ntop-dev] IP - MAC mapping changes (was: Issues w/ ntop 2.2.93) I don't want to bore you with how I got to where I am again. I didn't report it initially where it could just as easily be an environmental thing going on. But maybe not. The web page output I sent you definitely shows host '172.22.22.254' (my default router) owning ip address 172.22.22.55 (my linux box). And the data presented on that page is definitely from my linux box as well. There is no other line listed on any of the upper level web pages with 'pc5.localnet' at the time when I view the '172.22.22.254' host but there WAS when I started ntop and for several hours afterward. I don't understand why ntop would re-resolve things either, but there is clearly something in there doing just that. It's not just this one host either, I see host designations change within the application all the time, but in this specific situation the host designation is definitely rong. --sticky-hosts is also active. My Cabletron switch has vlan capabilities, but none of this is currently configured. The spanning tree has nothing to span either. My Cisco router is configured very vanilla these days too and ntop doesn't see anything strange coming out of it. A lot of my development efforts recently have been involved with testing configurations between Windows 2k and linux. Much of it to get linux based utilities to handle active directory associated functions; particularly with DNS and DHCP with Samba and NFS in use also. Might be a part of it? Don't know... To me the real challenge is getting everybody's application happily talking to each other and still have choices with whose OS it is running on top of. One of reasons for using ntop in the first place was to get a better handle on what our good friends at Micro$oft are doing these days from a networking perspective. There is a lot they bury deep in some tech note or not at all. It seems everybody these days is using yet another port for something. tcpdump or ethereal would tell me more per se, but I don't want to analyze mountains of data either. OK, enough blabber... Tim -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Burton M. Strauss III Sent: Thursday, August 28, 2003 9:51 AM To: Ntop-Dev Subject: [Ntop-dev] IP - MAC mapping changes (was: Issues w/ ntop 2.2.93) Never seen it. Would have been nice to have reported this earlier, instead of hoping it would magically get fixed. Days before the planned release is very late in the game. Gang: Anyone else having this problem? I haven't seen it, but I have a very simple network. ntop doesn't use the ARP data. If the gethostbyname() and other functions use it under the covers, that could cause issues, but once ntop resolves an name, it doesn't re-resolve it. IIRC - without diging into the code - the name in the "info about" line is the 'resolved' name, which is a char[] represention of the ip address as a last resort. Thoughts - is this a complex, switched environment? Some switches re-write packets with their own MAC addresses, this causes all sorts of pain. If you have multiple redundant links and the switches are reconfiguring the spanning tree, then I could see how packets would 'change' their MAC-IP address connection. That would confuse the heck out of ntop. Try the -o | --no-mac switch and let us know... that should disable the MAC stuff, making ntop a pure layer 3 monitoring tool, vs. the hybrid. -----Burton > -----Original Message----- > From: pc [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 26, 2003 9:07 PM > To: [EMAIL PROTECTED] > Subject: Issues w/ ntop 2.2.93 <snip/> > ntop confuses default router and linux box & known host names change > > If I startup ntop and then go and ping everything in my network, all of the hosts are displayed nice and pretty by ntop. But after a while this seems to fall apart. Some things revert back to their manufacturer/MAC address and some others become a simple host name without the domain suffix and sometimes they become an IP address. The one very problematic one is that my box that I run ntop on becomes displayed as the IP address of the default router???? When I look at the host in the ntop web page it in fact displays both the IP addresses in the output. The record for the default router may or may not exist at the time. THIS IS NOT NEW TO v2.2.93! I was having this same issue with 2.2c (and was hoping it might be somehow corrected in the new version). In some of my debugging efforts I've noticed that ntop seems to be very sensitive to the contents of the arp cache at the time the web page is displayed. But once the data for the default route and local machine seemingly merge, nothing corrects it without a restart of ntop. I've attached a web page example of this. Note that the host name that ntop has named it is 172.22.22.254 but the actual IP address is 172.22.22.55. The initial name that ntop named it was pc5.localnet which is in line with it's actual host name. (see: > ntopIPmismatch.zip) _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
