And fix #149.
For each neighbor, Junos returns the prefix stats within the RIBs
the neighbor is configured. But in our case we can only have the
routing table as the top-level key, not the RIB (there can be
multiple RIBs under a routing instance).
The only change that would really make sense would be an API change
and provide the prefixes per RIB. But we need to check if we can
retrieve this information disaggregated from other platforms.
However, we will replace the getters with the napalm-yang parsers
sooner or later so I will leave this aside for the moment. Also,
an API change would take very long.
The current approach is going to provide more useful information,
but it will be slower as we retrieve the information for old Junos.
For newer Junos (>= 14), it will not change anything in terms of
performance.
And fix #149. For each neighbor, Junos returns the prefix stats within the RIBs the neighbor is configured. But in our case we can only have the routing table as the top-level key, not the RIB (there can be multiple RIBs under a routing instance). The only change that would really make sense would be an API change and provide the prefixes per RIB. But we need to check if we can retrieve this information disaggregated from other platforms. However, we will replace the getters with the napalm-yang parsers sooner or later so I will leave this aside for the moment. Also, an API change would take very long.
The current approach is going to provide more useful information, but it will be slower as we retrieve the information for old Junos. For newer Junos (>= 14), it will not change anything in terms of performance.