Your points are well taken. Thanks! I'll reply to just one of the issues, and maybe return to the others later.
On Aug 14, 2013, at 7:33 PM, Alan Robertson <[email protected]> wrote: >>> This can lead to some circumstances that don't seem to make sense at first >>> because the various discovery agents aren't all run at the same time. For >>> example, if there is no NIC, then offering a service that uses an IP that >>> doesn't seem to use any NIC seems odd - but it can happen because we may >>> not have discovered that that service is no longer running - or has >>> migrated to another machine. >> >> It's not odd. There are IPs that don't have NICs. How about 127.0.0.1? >> >> The NIC and the IP address are not connected. When you pull the NIC, the IP >> address doesn't remain in the NIC. The connection between the NIC and the >> IP address in the OS. What's missing in the model is interfaces. When you >> pull the NIC out, the interface disappears from the machine. The IP address >> is connected to the interface. So: machines have interfaces. Some >> interfaces have IP addresses. Some interfaces have NICs, but some don't, >> like lo0. >> >> Loopback interfaces can have IP addresses that can be reached from outside >> the machine. Our switches and routers do. > If you have a route established, that's certainly true. There are some HA > techniques (particularly used with LVSs) that rely on this. Not being a > network expert, I never fully understood them the way you no doubt do ;-). I think you should treat switches, routers and hosts (Linux PCs, Macs, Windows PCs) as the same basic things in the database. Here's why. Take a Linux box with two NICs. Connect it to two IP subnets. No problem - it's a multi-homed server. Now reconfigure it slightly to make it forward packets from one subnet to the other. Now it's a switch or router. Do you want the database to struggle to replace a "host" with a "switch" when a software change happens in a device? Modern devices like Cisco 6509s are optimized to switch packets, but they are just devices with a lot of interfaces. The concepts of routers and switches have merged - many "switches" can route, and many "routers" can switch. Our switches do both on different sets of interfaces, depending on how you configure them. Likewise "hosts" can route or switch. These devices are just optimized to do some functions better than others. Some cases to consider: 1. I once worked at a company where it made sense to put multiple IP addresses on router interfaces. 2. On a host running IPv6, it's actually hard to have only one IPv6 address on an interface. IPv6 assumes that you'll have several. 3. On routers running BGP, it's often the case that the BGP sessions terminate on an IP address configured on the loopback interface. That way, the BGP session can survive even if some interfaces go down. When I ssh to our routers, I ssh to the IP address that is configured on the router's loopback interface. This works even when some of the router's interfaces are down. The ssh traffic flows across physical NICs, but there is no NIC associated with the loopback interface. I think the database should allow the representation of the above cases. Devices should have interfaces, including lo0. Interfaces should have names, and zero or more IP addresses, and zero or one NIC. The Common Information Model encapsulates this thinking. Everything is a ManagedSystem. A router is a subclass of a ManagedSystem. Anyway, I'm just rambling, but it would a great thing if the database is designed to allow these cases, even if the code doesn't initially "need" them, so that the application can later grow to do more things. -- Pete
_______________________________________________ Assimilation mailing list - Discovery-Driven Monitoring [email protected] http://lists.community.tummy.com/cgi-bin/mailman/listinfo/assimilation http://assimmon.org/
