Monitor more than one ip-address per device, incl. dual stack

[jmbredal]

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.

• date created: 2012-10-08T11:26:29Z
• owner: mbrekkevold
• the launchpad url was https://bugs.launchpad.net/bugs/1063699

[jmbredal]

(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".

[hmpf]

Preliminary battleplan:

1. [ ] Rework the forms/views for Netbox in seeddb to make further work easier. #2134
   • Control display in template by not doing {% crispy form %}?
   • Multiple forms? One per logical block in that case maybe.
   • Full-on CBV?
2. [ ] Add the table #2135
   • OneToOne or ManyToMany? Round robin, anycast etc.
   • Additional fields?
   • How to auditlog changes to this table.
     • One entry per ip address? Or one per netbox? When removing an ip address should auditlog that separately probably.
   • Javascript to show/hide the "additional ip addresses" form. Or we could have an "add ip address" button.
3. [ ] Have a way to get all ip addresses of a netbox #2136
   • Instead of one ip-field on netbox and an aditional table with additional ip-addresses, have all ip addresses in the table and a "primary/default" flag? With NULL as default this would work with a UNIQUE constraint on (netbox, address, flag) for ForeignKey/OneToOne. In a ManyToMany, have the constraint and flag in the through-table.
   • Search on all ips.
4. [ ] Monitoring
   • Trivial case: If all ip-addreses down, then netbox down.
   • Other cases?

[hmpf]

This can be split over several releases: one for recording the addresses, then others for experimenting with monitoring.

[lunkwill42]

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.

[hmpf]

Sounds like ManyToMany, and a flag on gwip for whether manual or not.

[lunkwill42]

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 :-)