Cisco SD-WAN vManage API - OMP route not in OMP RECEIVED API response

[michaelwaligora]

Hi,

Route which is visible in routing table (GET /device/ip/ipRoutes) with protocol omp, isn't visible in omp received routes (GET /device/omp/routes/received). I got response but some routes are missing.
When I wan't to get details about OMP route with filter for particular prefix (GET /dataservice/device/omp/routes/received?deviceId=<id>&prefix=<prefix>). I got empty response. 

When I check route via cli, it is present in both show ip route and show sdwan omp routes.

Device has around 2.5k OMP routes. Version 17.09.02.0.48.

Do you know what can cause that issue?

[Praveen Anand]

Hi Michael,

"IP route" on a cEdge device shows the underlay routes and "omp routes" shows the overlay routes. you can try with "show ip route vrf 'VRF NAME'" to compare with the received omp routes

There is no restriction on displaying the routes\ for this API.

[michaelwaligora]

Hi Praveen,

we did this comparison, if there are no restriction on this API, and data is missing. We should raise TAC, right?

Michael 

[stephli2]

Hi,

The vManage 20.9 version may experience challenges handling large numbers of routes via those APIs. However, from vManage 20.11 onwards, a pagination feature has been implemented to address such issues, effectively displaying OMP routes across all cEdge devices.

If upgrading isn't immediately feasible and this remains a concern, I recommend opening a TAC case for specialized assistance.

Stephen

[michaelwaligora]

Hi Stephen,

can you point me to some documentation? I found just https://developer.cisco.com/docs/sdwan/#!browsing-returned-results-sorting-results-filtering-results-and-rate-limits - "For API queries on a device, the pagination behavior is determined by the device."

Thanks

Michael

[stephli2]

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/configuration/Monitor-And-Maintain/monitor-maintain-book/m-network.html#c_View_OMP_Information.xml

Sorry for the confusion, The feature is actually "Download Output of OMP Routes" in which you can download the output of up to 1 million OMP routes in JSON or CSV format.

[Dan Frey]

Appears the max number of returned objects is 3999.   There are 2 vsmarts and 3 transports so each prefix consumes 6 objects.

https://192.168.0.156:443/dataservice/device/omp/routes/received?deviceId=11.1.42.1
+--------+----------------+-----------+-----------------+------------+------+----------------+------------+
| object |     color      |  vdevice  |     prefix      | from-peer  | site |     color      |     ip     |
|        |                |   name    |                 |            |  id  |                |            |
+--------+----------------+-----------+-----------------+------------+------+----------------+------------+
|   1    |      mpls      | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.4 |  41  |      mpls      | 11.1.41.1  |
|   2    | metro-ethernet | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.4 |  41  | metro-ethernet | 11.1.41.1  |
|   3    |  biz-internet  | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.4 |  41  |  biz-internet  | 11.1.41.1  |
|   4    |      mpls      | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.5 |  41  |      mpls      | 11.1.41.1  |
|   5    | metro-ethernet | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.5 |  41  | metro-ethernet | 11.1.41.1  |
|   6    |  biz-internet  | 11.1.42.1 |  10.0.41.0/24   | 11.1.251.5 |  41  |  biz-internet  | 11.1.41.1  |
...
|  3994  |      mpls      | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.4 |  41  |      mpls      | 11.1.41.1  |
|  3995  | metro-ethernet | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.4 |  41  | metro-ethernet | 11.1.41.1  |
|  3996  |  biz-internet  | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.4 |  41  |  biz-internet  | 11.1.41.1  |
|  3997  |      mpls      | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.5 |  41  |      mpls      | 11.1.41.1  |
|  3998  | metro-ethernet | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.5 |  41  | metro-ethernet | 11.1.41.1  |
|  3999  |  biz-internet  | 11.1.42.1 | 10.89.91.153/32 | 11.1.251.5 |  41  |  biz-internet  | 11.1.41.1  |
+--------+----------------+-----------+-----------------+------------+------+----------------+------------+

raw netconf is also enforced as it also ends on the same prefix.

# netconf-console.py --host=10.1.44.42 -u dafrey -p XXXXXXX --port 830 --get --x omp | grep prefix
            <prefix>10.0.41.0/24</prefix>
            <prefix>10.0.42.0/24</prefix>
            <prefix>10.0.43.0/24</prefix>
            <prefix>10.0.44.0/24</prefix>
...
            <prefix>10.89.91.149/32</prefix>
            <prefix>10.89.91.150/32</prefix>
            <prefix>10.89.91.151/32</prefix>
            <prefix>10.89.91.152/32</prefix>
            <prefix>10.89.91.153/32</prefix>
[root@CrashCart 17.12beta]# 

Changing the xpath refpoint so each prefix is its own object returns all routes (removing vsmart and transport info).   I believe this is why you see all the routes in the ip routetable since each prefix only takes 1 line rather than many lines per prefix.   

# netconf-console.py --host=10.1.44.42 -u dafrey -p XXXXXX --port 830 --get --x omp/routes-table/family/entries/prefix | grep prefix 
            <prefix>10.0.41.0/24</prefix>
            <prefix>10.0.42.0/24</prefix>
            <prefix>10.0.43.0/24</prefix>
            <prefix>10.0.44.0/24</prefix>
...
            <prefix>10.89.92.250/32</prefix>
            <prefix>10.89.92.251/32</prefix>
            <prefix>10.89.92.252/32</prefix>
            <prefix>10.89.92.253/32</prefix>
            <prefix>10.89.92.254/32</prefix>

[michaelwaligora]

Dan, thank you for your reply. So this is some internal API restriction which cannot be overcome without change of vManage API server, right?