Closed ndennis-Insight closed 2 years ago
Additionally, this is what is being created right now with the output I sent you:
AUTOCLUSTER::> net route show
(network route show)
Vserver Destination Gateway Metric
------------------- --------------- --------------- ------
AUTOSVM
0.0.0.0/0 10.206.13.1 20
0.0.0.0/0 10.206.50.1 30
With REST, the issue is that we are expecting 0 or 1 route to exist with same gateway IP address and address, but we are seeing 3. Two with same netmask, one different:
'destination': {'address': '0.0.0.0', 'netmask': '24', 'family': 'ipv4'}, 'gateway': '10.206.50.1',
'destination': {'address': '0.0.0.0', 'netmask': '0', 'family': 'ipv4'}, 'gateway': '10.206.50.1',
'destinatio{'address': '0.0.0.0', 'netmask': '0', 'family': 'ipv4'}, 'gateway': '10.206.50.1',
Some characters are missing, but I assume this a copy/paste issue.
This would explain why the loop works for some IP addresses (no duplication) and fails for others (duplication).
Well, this explains 10.206.13.1 and 10.206.50.1. For 10.206.35.1, REST reports 2 routes. I don't see why 10.206.34.1 is not created if no entry is reported.
We have 3 routes for 10.206.50.1 but ONTAP CLI reports only 1, I wonder if there could be something wrong with the system. The behavior would be explained if there are "hidden" routes (2 each for 10.206.13.1, 10.206.35.1, and 10.206.50.1, and one for 10.206.34.1)
With ZAPI, the logic is a bit different, it will take the first entry that it sees. But if there are multiple entries, this could explain the erratic behavior based on which entry comes back first.
I would suggest to open a case with NetApp as REST is reporting extra routes and is not consistent with the CLI. The 'unexpected response' error message contain the UUIDs of each route and they could identify where they are coming from.
Maybe deleting the SVM and recreating would be a way to start with a clean slate.
could you try:
net route show -vserver AUTOSVM -destination * -gateway 10.206.50.1
Hello there!
You hit the nail on the head. During testing it ended up storing one version of the route into the database and then didn't properly remove/overwrite it. So we had a database that would not allow us to delete the route or extra route entries. We ended up wiping the array (it is a test array) and this allowed us to continue without issue. We've run into a similar issue with the database due to some disks being owned by an aggregate that failed to create.
It seems like REST may be causing some unexpected issues with how the database updates tables perhaps. Please feel free to close this since this a known issue with ONTAP.
KB Articles I found on the route issue: https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/Not_all_routes_listed_in_%22route_show%22_for_ONTAP_9.7 https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/%22Error%3A_show_failed%3A_Loop_detected_in_next()_for_table_vifmgr_vs_routes.%22
Thank you for adding the KB links. Yes, I was thinking of BURT 1323123
Summary
When attempting to create a route, using both ZAPI and REST, I am returned different results every time I run the same task. The true outcome of the task can end up removing the routes, not modifying the routes when the output states it does, or not adding the routes when the output states it does.
When using REST I typically get back large errors that state they're getting "unexpected responses" for only some of my loop iterations but not others when they generally all should be the same. Even then, the ones that return "ok" are not actually creating the route.
When using ZAPI, I add in the "metric" parameter as well as "use_rest: never".
Component Name
na_ontap_net_routes
Ansible Version
ONTAP Collection Version
ONTAP Version
Playbook
Steps to Reproduce
Expected Results
I expect to run this command once, and all the routes be created. When I run it a second time, I expect to get back all "ok" output with no changes.
Actual Results