Open jmbredal opened 7 years ago
(by mbrekkevold) Some comments from DeiC, the Danish research network (these are not verbatim, but transcribed by Vidar):
This does not apply to equipment monitored with SNMP as ipdevpoll in that case derives all IP addresses for the IP device in questions. So this primarily applies to the category SRV.
In "seed database" if the IP device is of category SRV the second registration form should have an additional field "Additional IP address". Perhaps in plural, so a list of IP addresses can be added, both IPv4 and IPv6 (some servers have two network cards and then possibly two IPv4 and two IPv6 addresses).
The feature request Monitor all IP addresses" should take care of status monitoring of the additional IP addresses. The Box down event should still be based on the primary registered IP address.
A challenge is how the service monitor should behave. Perhaps the "seed database" service monitoring configuration should include a check box "monitor all registered IP addresses".
Preliminary battleplan:
{% crispy form %}
?through
-table.This can be split over several releases: one for recording the addresses, then others for experimenting with monitoring.
Sounds like you need to create GitHub project for your battle plan, @hmpf . As discussed in other channels, working on number 1 in your list is probably a good idea, regardless of the design path we choose to take on the rest of this.
NAV already has a data model to store a router's router port IP addresses in the gwip
table. These are automatically collected. I'm not sure I would want to duplicate these into another table. There should also probably be a distinction between manually added IP addresses, and ones that were automatically detected by NAV.
Sounds like ManyToMany, and a flag on gwip for whether manual or not.
Sounds like ManyToMany, and a flag on gwip for whether manual or not.
Not really. gwip
is there to reference directly the interface
table, since it exists to build a relation between a router port and an IP-address / prefix combo. The table is, per definition, a registry of automatically collected router addresses.
What we're discussing is a more general mechanism. We might want to do a deep-dive into the NAV data model to bring you up to speed :-)
For a dual-stack host with both IPv4 and IPv6 connectivity, it would be nice to have provisions in NAV for monitoring both.
The challenge is to figure out how NAV would do alerting and topology analysis when only one of the addresses stop responding to ping/echo requests.
Imported from Launchpad using lp2gh.