No, you are right. Let me try once more - maybe I can get this right, and clear enough...
ntop is designed as a hybrid packet analyzer, not a pure Ethernet analyzer (layer 2) nor a pure TCP/IP analyzer (layer 3). Most of ntop's displayed counts are at the TCP/IP level, and that's what confuses people. Internally, however, ntop works both at the level of the Ethernet frame and the TCP/IP packet. A single MAC address can be associated with multiple TCP/IP addresses. For many reports, ntop displays information ntop uses the MAC address to separate physical devices for accumulation. Other data is accumulated and displayed at the TCP/IP (level 3) layer. -m tells ntop something it can't determine by itself. And that is to treat that range of addresses EXACTLY like it was local. For example, on my Cable Modem, I see broadcasts for a number of subnets that AT&T has assigned to this area (I don't see the traffic, but you get the picture). If you have VLANs or simply network overlays (two or more networks on the same wire, but with separate address spaces). etc. Those are where you use -m -m relates to the traffic you see on the wire at the TCP/IP level. -j basically tells ntop something different, but also something it can't determine. That is, the MAC address can not be relied upon to separate among physical hosts. This is often the case with switches, but can also occur with other fancy network devices (caches, load balancers, etc. come to mind). Understand how a switch works. A classic switch operates at layer 2, BELOW the TCP/IP protocol. A packet arrives on a port, call it A. The switch records the MAC address in it's table. It then looks up the destination MAC address and finds either it knows it (and it's on port B) or it doesn't. If the switch knows the port, it sends the packet out on that port, and only that port. So it's created - for the instant - a network that consists JUST of port A and B. The switch may issue an ARP request to find out which port the destination is on. If it does, and gets a response, it learns that and continues as above. If the switch does NOT know the port, it sends it to all of the ports EXCEPT A. So for that packet, it's just like the normal Ethernet bus. In this case, the MAC address isn't touched, so you don't need -j. Switches work in other ways: Some work at other layers of the protocol stack (a "layer 3" switch) - where they really act more like a router. Others exchange information among a set of switches so that the switch understands more of the network and can make better decisions (e.g. sending a packet out an uplink port to another switch vs. broadcasting it). Finally, some switches have a "mirroring" function, where all packets are sent out one particular port, in addition to the normal switching. Nothing REQUIRES the switch (or other layer devices such as bridges and routers) to re-write the packet with the MAC address of the switch, but some do for various reasons. We've found this is especially prevalent with "mirroring". My best guess (and that's all it is) is that the vendors have had customers who have used mirroring not just to a single monitoring host, but injecting into a live network segment. If that happens, and you don't rewrite the MAC address showing the packet came from the switch, you get loops. When this re-write happens, however, the MAC address isn't reliable and you have to use -j. -j is a bit of a chainsaw, lopping off large amounts of functionality. And there are places where ntop uses the MAC address where it could use the TCP/IP address. I will say that I've asked people to help collect packet traces to show what's going on and gotten nothing but arguments about why *my* code (which I didn't write) is wrong. So, while we'll admit that the code isn't as finely tuned as it could be... The code is basically tuned to run successfully on the U of Pisa network (remember, that's what Luca is supposed to be doing - everything else ntop does is gravy). Luca plans to split -j into a number of switches allowing the user to determine what's on and what's off... but that's not how it works in 2.0+ -> 2.1... -----Burton -----Original Message----- From: Olivier Castan - CERTA [mailto:[EMAIL PROTECTED]] Sent: Friday, July 12, 2002 6:40 AM To: [EMAIL PROTECTED] Subject: RE: [Ntop] RC21BUG corrections and remarks >Interesting idea. I'm not sure you're right, however... Note that >the whole idea behind pseudo-local is that you have told ntop (via >the -m parameter) to treat that range of addresses EXACTLY like it >was local. > >In the case where you simply have multiple networks on the same wire >- with their host and destination, then the MAC addresses are unique. > >In the case where you actually have a gateway handling the traffic >(and thus re-writing the packet's MAC addresses, but leaving the >higher level protocols alone), then I think you have the situation >where you're getting multiple (remote) IPs collapsed into one MAC >address. > >It may be that you have to use -j | --border-sniffer-mode for this, >but then (at present) you lose a number of other MAC sensitive >capabilities... Fixing that is on the list post 2.1... > >I'm going to leave the isPseudoLocal stuff to Luca - he's much more >intimately familiar with that area of the code than I am. I'll look >at the URL stuff when I get upstairs after my breakfast and shower... Maybe I'm using the option -m the wrong way : my aim was to define some subnets as local to include them as local in pages like "Local to Remote IP Traffic" _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
