From: Mike H. <mh...@ac...> - 2004-11-24 21:46:38
|
On Nov 23, "Max Baker" wrote: > On Tue, Nov 23, 2004 at 01:49:50PM -0800, Mike Hunter wrote: > > > Ugly, but it works. How many firewalls do you have on campus? > > > > I don't know. In a lot of ways this is a political problem: We want to > > "fire and forget" by carving out the vlan ports and handing the problem > > off to the departmental administrators. > > That's fine, but you probably want to / have to maintain a list of the ports > that are being used in this manner somewhere. How hard is it to import that > list into netdisco-topology.txt? Never underestimate the power of disorganization :) I don't think we have a list of such ports laying around. We have all the switch configs under management, and you can infer those ports from reading the config, but that's not an easy thing to automate. > > How would this code react when there's a root switch with other switches > > dangling off of it and a router upstream, aka more than one vendor mac? > > The detection is _not_ done by vendor (OUI). It's done by devices that are > in the netdisco database. Doh. That makes more sense. > Once you've discovered all the devices on your > network, you have a list of all the MAC addresses that belong to switch > ports and routers. You look at the forwarding tables for a port. If any of > the entries on that table match your list, it's got to be an uplink port and > you ignore it. Leet. > > That's true. I think in our situation that isn't a big concern, because > > we are looking to mold netdisco into more of an inventory management system > > rather than an operational maintenance type of thing. So if some ahole > > started spewing mac addresses I think we'd get an SNMP trap. We're a ways > > away from using netdisco for R/W applications (aka port control/blocking) > > so we wouldn't be using it on the solution side either. > > I was just pointing out that if you use the method of "the port with the > most amount of mac addresses is the uplink port" you will not detect the > uplink port correctly. So assuming you need to / want to find the topology > and uplink ports so that Netdisco will work correctly, another method has to > be used. If you just want to inventory your hardware, then turn off the > macsucks all together. We'd love to have correct topology, but not more than we want to have mac to switchport mappings :) I do understand the two are related though. > > I had always thought about this as a per-device thing, not a L2 subtree > > thing. Now that you've introduced automated the uplink port finder, this > > vision could actually be reality :) Am I seeing it wrong, or would the > > firewall problem be addressed by a per-device switchport multiplicity > > minimization synchronization configuration? > > Uhmmm Mike, a per-device what???? Strictly from a dumb user perspective, when I hit device X with netdisco -D -M X I get blah blah blah blah blah 00:01:1b:2c:3d: -> foo -> bar -> baz 00:23:45:67:89: -> meep -> moop -> maop I had assumed that a given mac address would show up more than once if it was seen on more than one port, and at that point in the code one could build in a filter. But I think I'm mistaken on this point; I just tried it and I don't see macs more than once (on a switch that has evidence of firewall clumping.) When netdisco does the above, is it iterating over mac addresses or over interfaces? I'm not familiar enough with what's going on at the lower levels to know (thanks for not burning my house down in response to my ignorant questions :) ). > I was just thinking about your > algorithm of comparing two ports: 1. the firewall port and 2. the end port > to figure out which is the right one. Assuming there is a switch or two in > between them, that requires you to have the forwarding table entries from > both or all devices to compare, which will require some drastic changes to > macsuck. I haven't even been thinking about intermediate switches. :( > > > So solutions? You have two options .. > > > 1. Identify the firewall from the switch > > > 2. Have the firewall identify itself to Netdisco or the switch > > I guess there is the existing : > 3. Add these ports to the topology file manually > but I know that is not the answer. I definitely understand that it's a messy situation, and messy work will be required on my part to get our network under netdisco's spell. I'm hoping we can find a way to make this work be more exceptional than standard :) Mike |