Discovering vCMP configuration of F5 BIG IP LTM

danpatino · ‎06-06-2017

I'm working on implementing discovery and have come across a device that is not getting classified correctly. The OID in the classify input tells me it's BIG-IP vCMP Guest. While I could easily add the OID to the SNMP OID Classifications table, I'm not capturing the relationship between the vCMP hosts and guests (more info here). Has anyone implemented a probe/sensor combo to accommodate this?

Dave Ainsworth · ‎06-07-2017

Hi Dan,

I have been meaning to look at this for an existing project but have not got around to it yet.

Ideally the F5 MIB would contain OIDs we can use to find this information and I haven't had chance to check properly to see if there is anything.

We had to change the identifier when discovering the vCMPs because they shared the same serial number as the host so we added a new identifier on the serial number and name which will work as long as F5s never have their name changed.

The next step I think would be to mark these as virtual and as the F5 table extends from the computer class the virtual flag is available on the F5 table.

To set this though I think would need a new classifier for the vCMPs. The classifier (lets call it F5 BIG-IP vCMP) would trigger the exact same probes as the other F5 classifier but in the 'On classification script', we can set the virtual flag:

current.virtual = true;

We can then set the vCMP System OIDs to trigger this new classifier.

Next we need to create the relationship. Ideally, this is where we might get something from the host F5 discovery and it might be possible by querying some F5 OIDs. But in the absence of this, we could use serial number which is not ideal.

The following Business Rule does rely on serial number being the same for both vCMP and host which it has been for the vCMPs I have seen:

Name: F5 vCMP add relationship

Table: cmdb_ci_lb_bigip

When: after

Insert: true

Update: true

Condition: current.virtual == true

(function executeRule(current, previous /*null when async*/) {


       var hostGR = new GlideRecord('cmdb_ci_lb_bigip');

       hostGR.addQuery('virtual', false);

       hostGR.addQuery('serial_number', current.serial_number);

       hostGR.orderByDesc('last_discovered'); // In case of duplicates, find last discovered

       hostGR.query();


       if (hostGR.next()) {

               new DiscoveryFunctions().createRelationshipIfNotExists(current.sys_id, hostGR.sys_id, "Virtualized by::Virtualizes");

       }


})(current, previous);

In the above, the BR will only run for a vCMP (virtual). It will then look for a non-virtual F5 (host) with the same serial number and create the relationship.

I haven't tested any of this apart from the identification and a couple of manual inserts in the F5 table to check the business rule. But if you do try something similar, let me know how you get on. Or even better, if you know any OIDs we could query from the F5 MIB, even better!

Regards,

Dave

View solution in original post

Dave Ainsworth · ‎06-14-2017

Hi Peter,

Just as I was writing a reply, there is an excellent blog post that has been posted that is worth a read and might help so have deleted a lot of what I was going to write because it is described in more detail in here:

Discover multiple CIs with the same serial number - Part II

In summary, it doesn't look like you haven't ticked the independent checkbox on your new rule and so it is falling back to the hardware rule? When independent is ticked, it should not do this.

Regards,

Dave

petertjeerdsma · ‎06-14-2017

Hi David,

Just before I saw your reply I saw the twitter post regarding the subject. As a result I do have the classifiers running now including a modified rule. It is certainly worth reading the blog post. Although I had set the independent flag there was an (self created) error in the pattern which prevented it from setting the serial number so new records kept on being created because a name,serial match could not be made on subsequent discoveries 🙂

However, I still needed the workaround using the serial_number,serial_number_type adding a dependency running only on a dummy CI. For some strange reason I cannot run the rule without the entry because it throws me the error "missing Lookup Rule for 'cmdb_serial_number'" if I disable it.

Next step will be to create a dedicated identifier for the vCMP's an set the virtual flag, and building the relationships towards the physical (i5800) machines.

Thnx a lot for your efforts.

Just out of curiosity because the pattern itself runs quite long (had to modify the execution timeout to 60 minutes to prevent it from running in an error state) I was looking for the cache results option which was present in the probe and sensor configurations setting the cache flag on a per probe/sensor base. Can't seem to find a similar flag for pattern based discovery though. Do you know whether the results are automatically cached starting from Instanbul or should I set it somewhere else?

Regards

Peter

Dave Ainsworth · ‎06-14-2017

Hi Peter,

I remember an issue in Geneva where if the payload sent to the identification engine contained an attribute that the identification engine didn't know what to do with (i.e. wasn't in any identification rules), it would throw this error but it was fixed in Helsinki and as you are using the horizontal pattern, I guess you must be on Istanbul so not sure what the problem could be there.

As far as I am aware, there is no caching with patterns but I have mainly been using Helsinki so haven't used patterns much in discovery. There were some improvements to the F5 probes in the latest Helsinki/Istanbul patches to fix some timeout and instance memory issues though. But often, the amount of data brought back from a F5 device just means it takes time to process.

Regards,

Dave