Why am I not seeing IPFIX data in NFA from VMware devices?

Document ID : KB000096841
Last Modified Date : 22/05/2018
Show Technical Document Details
Question:
Why am I not seeing IPFIX data in NFA from VMware devices?
Answer:
VMware devices do not use the standard MIB's that NFA relies on to SNMP poll devices, so VMware devices cannot be snmp polled the same way to get interface names, desc, etc.

Also with VMWare devices the  IPFIX data has multiple sysuptime sequences.

In NFA when we detect a new sysuptime sequence, NFA thinks the device rebooted, and puts it into a "RebootRefresh" state in the poller.routers table until a successful SNMP poll can be completed.   

While it is in that state it drops all Netflow to ensure that if ifindex values have shifted on a router, we do not end up mapping data to the wrong interface.  

With devices like VMware that cannot be SNMP polled like a traditional router, this causes all data to be dropped usually before it can be processed.

There is a setting in the Harvester database that can ignore device reboots to allow it to keep collecting data, however it is a global setting for each harvester.  
So by setting this, you would be negatively affecting every other device on that harvester.  Meaning if a device rebooted and something changed on that device, data could potentially be mapped to the wrong interfaces.  For that reason we almost never recommend changing this setting to ignore device reboots.

However if you had a Harvester that was only processing VMware devices or other devices that could not be snmp polled only, you could enable this setting and it should allow you to collect data from VMWare devices. The interfaces would show up in NFA with no name or speed, but you can manually edit them if needed.

Workaround

If you do have a Harvester where none of your devices can be SNMP polled, you can apply this workaround.

**NOTE** If you have other devices that are polling fine, you should not apply this change in a production environment as you will risk data being mapped to the wrong interfaces.
1. Login to mysql on the Harvester server by running the following:
mysql harvester

2. Run the following update statement to set ignoreReboots to true.
update parameter_descriptions set defaultvalue='True' where paramater='IgnoreReboots';

3.  Then recycle the Harvester and new devices should start showing data shortly thereafter.

For devices that were already sending flow and stuck in a RebootRefresh state follow the additional steps below.
 
4. Stop the "CA NFA Harvester" Service.

For 9.3.3 follow the steps below:
5. Delete the device from poller.routers by running
mysql poller 
delete from routers where address='x.x.x.x'; 

6. Then truncated harvester.interfaces and harvester.routers table:
Mysql harvester 
truncate routers; 
truncate interfaces

           7. Start the CA NFA Harvester Service and the device showed up in the GUI soon after.

For 9.3.6 or later:

         
8.  Find the ID for the router by running the query below using the ip address of the device in place of x.x.x.x:
mysql harvester
select id from routers where inet6_ntoa(router)='x.x.x.x';

 
9. Use the ID found in the query above in the query below:
delete from routing_engines where routerid=x;
 
10. Run the following to delete from the routers and interfaces table:
delete from routers where inet6_ntoa(router)='x.x.x.x';
delete from interfaces where inet6_ntoa(router)='x.x.x.x';

11.  Start the Harvester service and the device should show up in NFA shortly after.