11-07-2016 07:56 AM
Hello everyone.I want to detect all the routes for a specific device and use that array in my python scripts. I used this API request:
and i have the following result:
That means what NETMRI is detecting only 773 routes, but when in fact when i print Check the routing Table using cisco CLI i have more than 15000 (show ip route vrf *)
Should I use a different query for my need?
Solved! Go to Solution.
11-07-2016 08:14 AM
I have not seen this same issue. Fist I recommend that you change the API version to something higher, such as 2.9.0 or 3.0.0, if you are on a later version. You could just be hitting an old API bug in 2.10.
Second, I would verify that the router you have selected is actually a supported device by NetMRI.
Hope this is of some help.
11-07-2016 08:45 AM
Sorry, one more thing to check would be to open the device viewer => Router => Route Table and look at how many routes have been collected. It should match the API query count.
11-07-2016 09:04 AM
Thank you for the answer Lon.
The device is supported in NETMRI and also Cisco OS version is supported for VRF support in Network Automation 6.9.x and 7.x. Maybe is a bug for 2.10 API version, but i thynk is such a big bug to not be fixed in release Notes (basic functionality of netmri)...
I've checked the device viewer => Router => Route Table and i find the same number of collected routes. And even if i ask NETMRI to detect all the device routes:
I have far less then the real number of total routes .
11-07-2016 10:17 AM
I tried using the same API call with 2.10 on a router with VRF's. It reported the same amount as the device viewer (652). So if your device viewer isn't even picking up all the routes, then something else is wrong someplace. You may want to look at the logs (in the device viewer) and see if something is timing out in retrieving the route tables. If you are using snmp to pull 15000 route entries, it may be timing out before it is completing. We use CLI as the primary method of getting the route tables and snmp is secondary.
This can be changed via Settings => Collection and Groups => Network Polling. At the bottom of the screen is a radio button to change the Route Collection Priority.
If that is not it, sounds like its time to open a new case with Infoblox.
11-07-2016 10:44 AM
I second Lon's suggestion of using CLI for route table collection, especially with that many entries.
Also, check your Advanced Setting for "Route Limit". The admin doc and the built-in tool tip disagree on its effect. The way it used to work matches the tool tip -- it's a hard limit of when to truncate the routing table collection. The admin guide says it's a threshold above which the SNMP method will switch to the CLI method. Of course, there's no way to know before it's collected that many via SNMP, which doesn't make much sense to me.
The default value for Route Limit used to be 3000, and the unit I'm looking at still has that value.
Another tidbit I discovered is that the CLI method is used within a CCS script for route collection in Nexus, ASAs, and IOS-XE devices, regardless of the Collection setting.
11-08-2016 05:46 AM
Thank you guys. I've checked if CLI is used for route table collection and it's the case for our server.
In the same time, that "Route Limit=3000" could be the problem. I tested a route collection with one Device with 2000 routes and it detects everything. And for the Devices with more then 3000 routes, NetMRI will collect all the routes without BGP routes...
.... So, i changed that "Route Limit" value to 20000 and i dont see any changes yet. Should I restart NETMRI or wait until a new database will be created?
11-08-2016 05:56 AM
I dont *think* it should be necessary to restart services to honor the higher limit. Did you wait a sufficient period to make sure the RT collection was performed again? For a given device, check the timestamp for that item in Settings -> Device Support.
If it's not working as you expect, enable SNMP debug for just that router and check the result after a few hours. IIRC, even if the CLI is used to collect the RT, there will be a mention of it being done and the resulting store in the DB.
11-15-2016 07:56 AM
Above the RouteLimit, it starts to prune out routes, starting with BGP routes. I don't know if it prunes *all* BGP routes or just some until it hits the limit.
Setting the route limit too high can have a performance impact, especially if you have hundreds of thousands of BGP routes.
11-15-2016 08:50 AM
It prunes all BGP routes.
Changing RouteLimit doesnt solve the problem anyway. We will upgrade to 7.1 version soon, Maybe route detection will work correctly after that.
11-15-2016 09:22 AM
I checked a few of our route tables and we don't have any above 3000 entries, close to that, but none above. Previously I suggested looking at your logs in the device viewer to possible see where it is choking. Have you done this?
Another suggestion is it possible for you to summerize your routes more, so you don't have as many?
Lastly, I don't recall there being any bugs of this magnatude on routing in 6.9 that were resolved in 7.1, but I could be wrong, I'm not an employee. Could be time to open a support case for this to end your suffering )