Cisco HSRP in Discovery

[mikeanning]

Hi

How are people handling Cisco HSRP in the discovery process?

I have found that discovery picks the first IP address that it finds for a CI and uses that within CMDB. This in itself is a problem as its not necessarily the desired IP. The IP address on the LAN side helps me identify the location of a device...

Aside from that, although if anyone has any ideas how I can force discovery to use a certain IP on a specific SVI/vlan for example that would be very useful, The problem I am trying to address relates to HSRP, (Virtual IPs).

.1 for example could be on Router1 or Router2 depending on the Active/Standby state of those two routers.

.2 & .3 would be configured on R1 & R2 respectively.

When SNOW discovers .1 it uses that for the first CI (R1) but its not necessarily correct as this router may be the Standby router and .1 would be responding on R2 which is the Active router at that point in time.

This becomes a bigger problem as SNOW hands off the CI's to Zenoss for SNMP monitoring meaning that the wrong device could be monitored.

SNOW see's .1 & .2 on the same vlan in the CI so is recording the VIP as well as the real IP address.

Is there a way to stop SNOW from using the HSRP address altogether?

I raised a ticket and the SNOW tech tells me there is no support for HSRP.

Many thanks

[tim_broberg]

Curses - foiled again!!

Script Include, DiscoveryIDSensor, has a method, processIPAddressField which is supposed to address exactly this issue of flip-flopping IP addresses, so

1. Seems like, if it has A - an IP in the CI, B - the CI matches the same identity, and C - the IP changes, it's a bug.
2. I hadn't considered it until now, but perhaps B is the issue rather than A or C. Perhaps the identifiers are failing to match for this same device?
3. If you're feeling moderately ambitions, you could instrument that method to see where he's going astray and/or being misled.

Recommend examining the identifiers to make sure these CIs match in all cases. Failing that, you might play with DiscoveryIDSensor.processIPAddressField to see what's going on in there. Also, consider squinting at the discovery logs for these IPs for clues (if you haven't already).

Hope this at least gives you some angles to attack it from. Looking forward to hearing what you find,

    - Tim.

[tim_broberg]

Ok, I finally got around to trying this. I created two VMs on two subnets with schedules for each subnet and for both.

If I discover them on one subnet, their IPs are populated on that subnet. If I discover them on the other, their IPs move to the other subnet. If I discover both subnets, their IPs remain the same.

So, if A) the identifiers are working correctly, and B) you discover the primary IPs first, and if C) the primary IPs never fail to discover, then D) you should never see it switch to the failover IP.

So, it should work, but I worry about C). If it doesn't work, look carefully at A), the identifiers.

Alternately, you could put a business rule on that table and forbid changing the device IPs to those particular IPs. It's hacky, but it works.

    - Tim.

[mikeanning]

Thanks Tim for your assistance.

A team member who has more priviliges than I do modified the System Property glide.discovery.enforce_ip_sync

This at least allows us to manually change the IP address field and stops Discovery from updating it again.

Thanks

Mike

[tim_broberg]

Ok, thanks for the update.

    - Tim.