Response Time Graph and Dual-Stacked Host

[ipv6_bert]

Does anybody now if and how its possible to get seperate response time and availability graphs for ipv4 and ipv6 in IMC7.2? 

By default, the hosts are discovered with their ipv4 address. And thats what the response time graph monitors. If I add an ipv6 address to a device - no change. 

I added the device a second time by its ipv6 address. Now I also have a graph for ipv6. 

BUT: after some time - when the devices are synchronized again - IMC sends an alert that there are duplicate devices with the same ip addresses. By the way you would need twice the number of licences. 

Any suggestions? 

[LindsayHill]

I don't _think_ it's going to be easy to get what you want. 

IMC uses either IPv4 or IPv6 to monitor a device. But it then collects all status data on all interfaces via that single IPv4 or IPv6 address. As you found out, if it realised they were the same underlying device being polled by both IPv4 & IPv6 addresses, then it gets upset with you.

They don't really want to do multiple polling of a single device, because they see that as either (a) inefficient, or (b) lost revenue :troll:

You could add another device with just the IPv6 address, but no/incorrect SNMP community. Then you'll get ICMP monitoring of that address, but it will use another node license. 

You might also be able to add a service monitor - e.g. if the device has a web interface, you could add HTTP monitoring of that service, using whatever protocol makes sense. But I don't think you'll be able to tell IMC to do dual status polling of v4 & v6, at no cost to you.

[ipv6_bert]

It is clear to me that it makes no sense to monitor the host twice. At some point there must be a switch from IPv4 to IPv6. But then I move the issue to the IPv4 check.  

It would be nice if I could set up an ICMP check which forces to use the IPv6 address (ping6 or ping -6).

I will try the HTTP (or SSH, or DNS) check. But there I cannot use variables an have to hard code the IPv6 address into the URL. Or is there a variable that tells the monitor to use the i.e. $HOST6_ADDRESS? 

Creating every host a second time with wrong credentials only to get an ICMP check for the IPv6 address of a already monitored host is no option. We already have a nagios installation what is able to use '-6' as an argument. But I don't want to use a second monitoring tool just for icmp6. :sosad:

[LindsayHill]

But why would you want to monitor it by both v4 and v6, it should always be the same, right? Right? /ducks

I think it's a fundamental design issue, since IMC is just checking the device status, not really doing path checking (which is what you're doing with both v4 & v6 checks). 

Not sure what the 'best' thing to do here is. I guess it depends what your goals are, and what sorts of faults you're looking to identify.

Another couple of years and we can switch off v4...maybe. The Google IPv6 stats are starting to look promising, but Enterprise is generally lagging badly.

[ipv6_bert]

I solved the nameserver thing with service monitors asking the ipv4 or ipv6 address directly. That works for that service. 

But what is about dual-stacked switches or routers?
On i.e. cisco routers the OSPFv3 process is seperated from ipv4. If I want to check the reachability it makes no sense to only check ipv4. I want to know if ipv6 reachability is also good. 
I also want to know if the response times are good (for both protocols). If IPv6 is much slower within our Campus LAN than there must be some issue. 

And the monitored device is the same. Just another protocol. 

I'm also glad when the end of IPv4 is finally approaching but until then I have to enable dual-stack and I would like to be able to monitor both. 

An example why it is so important to me: 
Our nameservers are dual-stacked for about 2 years with no problems. In February 2017 we did an internet firewall upgrade. That upgrade had a bug we recognized about two months later because of missing ipv6 monitoring. 
The neighbor discovery table (ipv4 = arp) entries of ipv6 hosts behind tagged interfaces were marked as INCMP after some hours. Nobody recognized that the server is not reachable over ipv6 because there was also ipv4 and everbody used FQDN to connect (and happy eyeballs). 

Some registrars then told us that the domains will be parked because the servers are not responsible for that domains anymore (on IPv6!!!). That's why I want to monitor v4 and v6 for the same monitored device. 

So let me answer your question "it should always be the same, right?" with NO. 

[ipv6_bert]

I agree that it looks like a design issue. 

Either the ipv4/v6 addresses are treated as seperate monitoring instances or there must be only one protocol per device (choosen at discovery or device addition) and the possibility to add the same device with different protocols. 

[LindsayHill]

If I want to check the reachability it makes no sense to only check ipv4. I want to know if ipv6 reachability is also good. 

Part of the problem is that for any NMS, it is only checking reachability between the NMS and the node. It's not checking real paths across the network. In environments with proper OOB mgmt networks, it wouldn't be testing any production paths. 

I guess if you want to do more 'real-world' path checking, you'd probably need some sort of IP SLA probes, or equivalent.

[ipv6_bert]

That's what I want. I want to check the reachability of the node. And the node is reachable over two protocols which are already recognized by IMC. 

If it would not be recognized I would be able to add device a second time with the v6 address. 

However, this discussion does not lead to any result.
I'll go and try my luck with a feature request or use Nagios for the reachability checks only.