Cisco HSRP in Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-10-2015 09:19 AM
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
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-10-2015 10:58 AM
What if you exclude .1?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-10-2015 12:51 PM
Thanks Tim for the suggestion. The problem is there are hundreds of /24's involved and even more /25's & /26's. The smaller subnets being configured on switches running HSRP so the exclusion list would be massive and not easy to manage.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-10-2015 02:53 PM
Yeah, ok. I tried. Next worse idea, and please forgive my laziness in not trying this out in a busy week...
What if you discover the .2's first such that those IPs get into the CI. Subsequent identification should recognize that the .1 address is the same guy as the .2 and (here's where I'm waving my hands and hoping) stick with the existing IP in the CI?
So, have a limited schedule to get the .2 IPs into the CIs for your HSRP devices, then blaze away at all the subnets thereafter.
Worth a shot?
- Tim.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-11-2015 06:28 AM
Deleted the CIs to start from scratch.
I created a discovery with a single IP address in the address list, the .2 address. The device is discovered correctly.
Then created a discovery with the /24, simulating the weekly global discovery that would cover the subnet in question.
The CI is updated with the .1 address. Seems that the first IP that is found is used, which I see on other CIs as well whereby a Tunnel IP address might be selected and used for the CI.
Is there a way to protect the IP address field so that subsequent discoveries do not update the IP address?
At least I could go through manually correcting the IP addresses and would know they would not change after that.
Many thanks
Mike