Closed jeffgallagher closed 7 years ago
Just noticed I wasn't at current napalm-junos release - upgraded to 0.6.6 and the issue is still present.
Hi @jeffgallagher - thanks for reporting. I've been able to reproduce this, but I'm not sure what's the best way to fix. In certain circumstances we may transform the list to a certain string format. But this field has to be int.
At the same time, looking at this together with https://github.com/napalm-automation/napalm-junos/issues/139, I think we should group inet.0
, inet6.0
and inetflow.0
into default
and aggregate messages_queued_out
as the sum.
Does this make sense?
Agreed. I think that approach makes the most sense.
I will see if I can solve it this week and release a major version, as this changes many things (but they are changing for the better, ofc).
Description of Issue/Question
Did you follow the steps from https://github.com/napalm-automation/napalm#faq
[X] Yes [ ] No
Setup
napalm-junos version
(Paste verbatim output from
pip freeze | grep napalm-junos
between quotes below)JunOS version
(Paste verbatim output from
show version and haiku
between quotes below)Steps to Reproduce the Issue
Error Traceback
(Paste the complete traceback of the exception between quotes below)
Details:
When a BGP peer ASN has a neighbor in multiple route instances (inet0, inet6 and in this example the peer also happens to be a netflow sink - inetflow.0) the value of key ['messages_queued_out'] will return a non int value. (It returns a list) The documentation suggests the value will always be an int. This appears to be less of a NAPALM bug but in fact a corner case under some circumstances - it can be viewed in the way JUNOS reports in show bgp neighbor - see below:
Code for test:
Note: The traceback error can be reproduced by explicitly casting the ['messages_queued_out'] to an int - I have left this off to print the following for debug purposes...
The results iterating through the peers:
Notice the last two peers - two different route instances but they are reporting a LIST value and not an INT. These are iBGP sessions internal to the network.
show bgp neighbor on the box reveals more details; first a peer that is correctly returning an int value: (First an external peer / with ipv4 only to remote AS)
Note the "Output Queue" value - single entry
Second - the peer (which happens to be an internal iBGP in this case) - the peer sessions establish v4 and v6 iBGP with the remote IP and this particular corner case, the remote node also happens to sink netflow.
Note the bottom output - three queues!! the same peer that is returning a list value for ['messages_queued_out'] (presumably each queue representing a value for each routing instance (inet0, inet6 and inetflow)