Fix for issue #1069 #1346
Fix for issue #1069 #1346
Conversation
| .get("peerEntry", {}) | ||
| .get("peerAddr", "") | ||
| ) | ||
| except AddrFormatError: |
There was a problem hiding this comment.
Perhaps not a biggie, just curious:
For certain BGP related routes, peerEntry is moved up a level, so if it isn't found under routeDetail we catch the error thrown by the IP helper and try again in the other location.
Does this apply to any specific route types, or any pattern we can distinguish at all? I'd be more inclined to a simpler if 'routeDetail' in bgp_route_details but perhaps there's some other context I'm missing.
Either way, thanks for this patch as well @malanovo and it'd be great to add a test case for this scenario here as well.
There was a problem hiding this comment.
Honestly I haven't quite figured out yet all the cases when EOS will return peerEntry in the alternate location. The devices I have been testing against will trigger the issue for seemingly similar configuration sections, and I even have two different switches in the same network that look like they should both cause it, yet one does while the other does not. I'm still trying to figure it out, since the values as returned through the CLI seem identical. I'll circle back on it once the thing I'm building that uses this module is finished.
I fully agree with doing the simpler if based method, and originally started doing it that way, but went with the try/except method instead as it was easier to see what was going on, plus it seemed more consistent with existing code (I'm referring to how that method was used elsewhere in the code for catching other instances of AddrFormatError).
I'll work on getting a test case put together. I should be able to capture something from a device in my network to use as a base for it.
|
Test case has been added to the pull request. |
Fix for issue #1069 . The problem was caused when an empty IP address was passed to one of the helpers due to it not being in the expected location. For certain BGP related routes, peerEntry is moved up a level, so if it isn't found under routeDetail we catch the error thrown by the IP helper and try again in the other location.