Aligning Discovery with Asset Management
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2025 05:51 PM
I'd like to get the communities thoughts on challenges I am facing aligning Discovery of CIs created by Asset Management.
I am quite experienced with Discovery, having worked with it for a few years. But I am new to Asset Management.
My challenge is that Asset Management creates a number of types of CIs that I can't discover Out of the Box (OOB). This generally relates to network gear; I see less of an issue with other device types. But it's all common stuff, Cisco Firewalls, Cisco Wireless LAN Controllers (WLC), F5 Big-IPs, etc. - these aren't niche devices.
Examples of the challenges I am facing:
F5 VIPRION Platform. These devices consist of a chassis and multiple blades. Our Asset Management team create an asset for the chassis and each blade. Asset Management automatically creates a CI for each of these. But the F5 Load Balancer pattern only discovers and updates the CI for the chassis, not the blades. This results in the CIs for the blades becoming stale and the Asset Management Team questioning why Discovery isn't working?
Cisco Nexus 2000 Fabric Extenders. There's a KB article that explains why these aren't discovered (KB0830746) and an Idea for a future enhancement, but that Idea is 5 years old. Again, our Asset Management Team create assets for these, which automatically creates CI. The CIs don't get discovered, they become stale, more questions why Discovery doesn't work.
Various Cisco Catalysts configured as High Availability pairs. These might be firewalls, WLCs or other. Each device in the HA pair has the same name and same configuration, one being Active, the other Standby. Asset Management Team create an asset for each device, which creates a CI for each device. But Discovery only discovers the active device, never the standby. The Standby CI becomes stale, more questions why Discovery doesn't work.
In each of these examples, one resolution may be to customise the pattern. But these are common devices in what I am told by our Networks Team, very common configurations. I can understand having to customise a pattern if we have something niche, or a requirement to collect a niche attribute. We shouldn't have to customise multiple OOB Cisco and F5 patterns. If it's not working OOB for these market leading players, then it's the wrong Discovery product.
The other resolution that I'm coming to prefer, is do we need to track the CIs? Do we need to track the blade components of the F5 Big-IP as CIs, or can we just have a CI for the chassis? Do we need to have CIs for the Nexus 2000 FEXs, or are we OK with just a CI for the switch they are extending? Do we need a CI for each chassis in the Catalyst HA pair, or do we just have a CI for the pair itself?
This latter solution makes more sense to me, but my research tells me that Asset Management is always going to create a CI. Do we just live with this and manually delete the CIs, or ignore the fact they'll become stale?
I'm curious how others deal with these kinds of situations and what best practise looks like.
Thanks
Tony
- Labels:
-
Discovery

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-06-2025 07:49 PM
Hey Tony,
Your questions are something I've come across a fair few times. "Why doesn't this work as I expect" questions from stakeholders often cause a slight smirk on my face.
Firstly to point out - CI creation is configurable. The model reference has a 'asset_tracking_strategy' which defaults to 'leave to category'. If this field is set to one of the other values, a CI won't be create. Likewise if a CI is created, an asset won't be created. The other option is for the model category to not have a CI class specified.
Some other options:
- For the cluster devices in standby, you can use the state/status fields (depending on CI Class and whether you've migrated to CSDM Life Cycles) to set to a state which you exclude from CMDB Health.
- Modify the model record's asset tracking strategy as I mentioned above.
- Create new model categories with no CI class defined. As part of asset creation, the model and model category are chosen. Because a model can relate to multiple categories, your asset management team could have the option between a category that allows CI creation, and a category that doesn't. Note - this does come with the risk that a model category isn't changeable afterwards.