08-04-2023 05:14 AM
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?
08-23-2023 11:24 PM
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.
08-23-2023 11:38 PM
Hi Praveen,
we did this comparison, if there are no restriction on this API, and data is missing. We should raise TAC, right?
Michael
09-06-2023 02:22 PM
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
09-06-2023 09:21 PM
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
09-07-2023 02:23 PM - edited 09-07-2023 02:24 PM
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.
09-07-2023 01:27 PM
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>
10-03-2023 05:36 AM
Dan, thank you for your reply. So this is some internal API restriction which cannot be overcome without change of vManage API server, right?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide