get_bgp_neighbors_detail() returns 'received_prefix_count' and other prefix related params as a list

[narJH27]

This occurs only if both routing tables, ie, inet.0 and inet6.0 are activated for that peer. The data model suggests that the value should be an int instead of a list. Can someone please fix this ?

[mirceaulinic]

Thanks for reporting this @narJH27!
Due to a design error, get_bgp_neighbors_detail does not have support for multi-VRF. We are planning to make the necessary adjustments ASAP. This issue will be fixed when applying the changes!
Let's keep this open for the time being, and we'll ask you to confirm once everything is prepared!

[dbarrosop]

@narJH27 note that when we fixed the issue, as @mirceaulinic due to a design error, the method response will change. I am sorry for the inconvenience but any code using that method will most likely fail after the change.

[narJH27]

@mirceaulinic thanks for replying and letting me know that this indeed is an issue that is being worked on.

@dbarrosop not sure what you mean by "response will change". can you elaborate a bit more on this if possible?

[narJH27]

@mirceaulinic & @dbarrosop also i wanted to point out that we are seeing a sudden increase in the number of connections and in turn file descriptors, to junos devices, that are probably being caused due to the design problem you guys alluded to. Is this something that you are aware of as well and will this also be rectified as part of the design changes you guys are working on?

[mirceaulinic]

@narJH27 Can you please provide more details? This does not sound OK & from what I can understand this is not related to the fact that get_bgp_neighbors_detail returns list instead of integer.
The changes we referred to are related to the output structure of get_bgp_neighbors_detail (i.e.: in the root of the main dictionary we'll introduce a new key representing the name of the routing table. Doing so, we'll group all data by VRF, similar to get_bgp_neighbors).

[narJH27]

@mirceaulinic will this change in structure be across all the drivers? or just junos? the file descriptor problem might be caused by something else entirely ..... doesn't look to be a napalm issue.

[dbarrosop]

@narJH27 The object returned by get_bgp_neighbors_detail will change for all drivers. The change will not be dramatic, most probably the current dictionary will just be nested inside a key representing the address-family as with get_bgp_neighbors. So your existing code using that method should be super easy to adapt.

[mirceaulinic]

@dbarrosop I think you meant "the current dictionary will be nested inside a key representing the VRF, as with get_bgp_neighbors", didn't you?

The keys for the first dictionary will be the vrf (global if no vrf).

[dbarrosop]

Yes, exactly.

[mirceaulinic]

Good, just wanted to make sure we have the same idea in mind.

[narJH27]

cool thanks guys for the confirmation. do let me know when you have these changes incorporated