Improving the host <parents> logic

[Shane Stixrud]

On Thu, 15 Dec 2005, Andreas Ericsson wrote:

> Shane Stixrud wrote:
>> Sure you can define layer 2 devices as parents of a child device, but so 
>> what??  If you are using the parent definition for layer 2 it cannot also 
>> be used for layer 3 parents (for that same device) without unexpected 
>> behavior as far as I can tell.
>> 
>
> Yes it can, although the layer 3 node becomes the parent of the layer 2 node 
> which is the Right Thing to do.

Note the "for that same device",  I am not arguing that layer 2 
defined cannot have a layer3 inheritance.  I am arguing that this 
method is kludgey and inflexible.


> Oh, now I understand what you're talking about. You're still wrong though.

It does not appear you do.

>
> The only difference (packet-wise) between a layer 2 device and a layer 3 
> device is that the layer 3 device modifies the TTL of the packets it sends 
> on. It has to do this whenever it sends a packet to a new subnet (read RFC 
> 791 for more info). Thus, when home users access their internal network over 
> their multi-port router the TTL won't be decremented. When they access the 
> outside world it will be.

What does this have to do with anything being discussed here?  I am 
talking about how best to monitor a large campus network where layer3 
network boundaries have little to do with layer2 boundaries.  Where a single 
switch may have 20 vlans on it, some of which are routed on a device 
directly connected to that switch while other vlans are routed 5 switches 
away.


>> Sure this works fine when the switch is isolated to one layer 3 network 
>> (i.e. no vlans).  Care to share the magic tricks you use to tie vlan 
>> assigned switch ports to the correct layer3 devices/interfaces??
>
>
> Sure. Give the switch an IP in each network and make it switch2-vlan23 or, if 
> the route goes through the same physical devices no matter the VLAN, use 
> whatever IP you already have on it. Obviously, this doesn't work if you can't 
> set an IP on the switch and it can't respond to ICMP or some such (in which 
> case you almost certainly won't have VLAN's on them).

Are you serious?  You consider this the Right Thing (TM) compared to 
having the ability of defining the layer2 and layer 3 parent for each 
device?  Please be serious, the amount of extra work here is absurd, 
especially considering the only benefit is an accurate 3d map and 
notification suppression in Nagios. I dunno what switches you are 
using but Cisco switches have a management interface that is normally 
attached to the management VLAN.  Even if you could define a switch IP 
address for every vlan it may be a member of it would be stupid and 
wasteful not to mention a security risk.

It sounds like you are defending the current implementation not because 
its the best solution but because thats what exists.  Even if these issues 
didn't exist with your "approach" it would still be worth changing to 
cut down the configuration complexity and management overhead required. My 
suggestion is just that a suggestion, if nagios as a project is not 
interested in it thats fine, but your dismissal of this real issue is 
unwarranted IMO.

>
> You're thinking "one device, one host" when you should be thinking "one IP, 
> one host" (this is btw also what I was referring to in the acidity concluding 
> my last email on this topic). You can add the same physical device as a 
> separate host a million times if you want to. If you have VLAN's this is 
> almost always the right thing to do because you will then notice when one 
> VLAN is incorrectly configured.

This is a red Herring, my suggestion does not limit either approach in any 
way.  It merely better reflects the TRUE relationship between a 
network device and its network connectivity (both layer 2 and layer 3).

> So each host would have parents, l2parents and l3parents??

Every inter-network device has at least one layer 2 connection and at 
least one layer3 interface.

>
> It works fairly well for all conditions I've encountered during the roughly 
> 120 installations I've seen (ranging from large international corporations 
> monitoring +5000 nodes) to ISP's (monitoring very non-catenet-ish equipment, 
> some of which doesn't even have an IP), to small but mission-critical 
> manufacturing process controller networks.

Again, I am not saying nagios doesn't "work fairly well" that should of 
been clear from the first two sentences in my initial post.  I am saying it 
could be improved in this respect.

Cheers,
Shane


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click