Rework eos.get_bgp_neighbor

[bewing]

Use all JSON output for get_bgp_neighbor to remove any text-parsing and prevent CLI output updates from breaking the code. Supercedes #2112

Since I'm touching the code and the tests, I'd really love some more eyes on this before a merge.

[bewing]

Test cases removed:

• issue1168 - invalid, 4.23 uses different field that is in seconds natively
• issue1356 - invalid, 4.23+ has descriptions in show ip bgp neighbors
• issue1759 - may be valid, will re-add and generate new mock outputs
• issue58 - not sure what the test was here, can't find a doc

[ktbyers]

One other question, what is the difference between when "global" VRF vs "default" is used on Arista?

[bewing]

One other question, what is the difference between when "global" VRF vs "default" is used on Arista?

global is specifically called out in the base driver as the "no vrf" key: https://github.com/napalm-automation/napalm/blob/develop/napalm/base/base.py#L446-L447

VRF-aware Arista output uses the the key default for the "no vrf" key, so I do a quick rename via pop

[ktbyers]

Everything looks good to me (after fixing the uptime to be -1 for BGP peers that are down/admin down).

One other thing I saw that was odd in the test data was the remote_id of 0.0.0.0.

      "10.0.0.3": {
        "local_as": 65001,
        "remote_as": 65003,
        "remote_id": "0.0.0.0",

Is that just a config error in the BGP setup?

[bewing]

Is that just a config error in the BGP setup?

If a peer is down, you don't know his router ID. Same logic from before this change: https://github.com/napalm-automation/napalm/pull/2116/files#diff-c33f60453329944c74a7bdfb2416f90a5fe0debffbe70a7aefb83a07dc6c81d0L771

Same behavior in other drivers:

napalm/test/ios/mocked_data/test_get_bgp_neighbors/normal/expected_result.json

Line 68 in f0efc0b

"remote_id": "0.0.0.0",

[ktbyers]

@bewing Ooops, missed that the BGP peer was down...

[ktbyers]

LGTM.