napalm-automation / napalm-ansible

Apache License 2.0
245 stars 103 forks source link

napalm_get_facts reports BGP is_up = true when peer is Idle on Cisco IOS #163

Closed Gelob closed 4 years ago

Gelob commented 4 years ago

When running napalm_get_facts against a Cisco CSR1000v 16.06.02 (Everest) if I have a eBGP neighbor that is Idle, it still returns is_up: true when it should be false. NAPALM outside of ansible returns this properly as is_up: false. This means that when I run napalm_validate I get incorrect results.

Example ansible tasks

    - name: Get BGP
      napalm_get_facts:
        dev_os=ios
        hostname={{ inventory_hostname }}
        username={{ ansible_user }}
        password={{ ansible_password }}
        filter='bgp_neighbors'
      register: bgp_peers
      tags: debug_bgp
    - name: Debug BGP neighbors
      debug:
        var: bgp_peers
      tags: debug_bgp

Cisco CLI Output

csr1(config-if)#do sh ip bgp sum
BGP router identifier 1.1.1.1, local AS number 65511
BGP table version is 1, main routing table version 1

Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.12.2      4        65512      51      53        1    0    0 00:45:22        0
10.10.13.3      4        65513       0       0        1    0    0 00:02:19 Idle

Napalm 2.5.0 with Python 3.5.2 on Ubuntu 16.04.1 output

{'global': {'peers': {'10.10.12.2': {'address_family': {'ipv4 unicast': {'accepted_prefixes': 0,
                                                                         'received_prefixes': 0,
                                                                         'sent_prefixes': 0}},
                                     'description': '',
                                     'is_enabled': True,
                                     'is_up': True,
                                     'local_as': 65511,
                                     'remote_as': 65512,
                                     'remote_id': '2.2.2.2',
                                     'uptime': 2728},
                      '10.10.13.3': {'address_family': {'ipv4 unicast': {'accepted_prefixes': -1,
                                                                         'received_prefixes': -1,
                                                                         'sent_prefixes': -1}},
                                     'description': '',
                                     'is_enabled': True,
                                     'is_up': False,
                                     'local_as': 65511,
                                     'remote_as': 65513,
                                     'remote_id': '0.0.0.0',
                                     'uptime': -1}},
            'router_id': '1.1.1.1'}}

Ansible 2.6.1 output on Ubuntu 16.04.1

ok: [csr1] => {
    "bgp_peers": {
        "ansible_facts": {
            "napalm_bgp_neighbors": {
                "global": {
                    "peers": {
                        "10.10.12.2": {
                            "address_family": {
                                "ipv4": {
                                    "accepted_prefixes": 0,
                                    "received_prefixes": 0,
                                    "sent_prefixes": 0
                                }
                            },
                            "description": "",
                            "is_enabled": true,
                            "is_up": true,
                            "local_as": 65511,
                            "remote_as": 65512,
                            "remote_id": "2.2.2.2",
                            "uptime": 3054
                        },
                        "10.10.13.3": {
                            "address_family": {
                                "ipv4": {
                                    "accepted_prefixes": 0,
                                    "received_prefixes": 0,
                                    "sent_prefixes": 0
                                }
                            },
                            "description": "",
                            "is_enabled": true,
                            "is_up": true,
                            "local_as": 65511,
                            "remote_as": 65513,
                            "remote_id": "0.0.0.0",
                            "uptime": 470
                        }
                    },
                    "router_id": "1.1.1.1"
                }
            }
        },
        "changed": false,
        "failed": false
    }
}
ktbyers commented 4 years ago

Closing...this should be reported against the main NAPALM repository if it is still an issue.

Gelob commented 4 years ago

@ktbyers should this still be reported to upstream napalm even if napalm outside of ansible reported it properly?

ktbyers commented 4 years ago

Meaning this already exists as an issue in the main napalm repository? If it is already an issue there, then no worries at all.

I just didn't want it closed here, but then never tracked as an issue in the main napalm repository.

Gelob commented 4 years ago

Meaning, when I tested straight napalm doesn't have this issue but only when running napalm through ansible the issue appeared. So i believe it to be specific to napalm-ansible. I can work on re-creating it again to see if its still a problem

ktbyers commented 4 years ago

I don't really see how that is possible is all napalm-ansible does it call napalm here and return the data structure napalm returns.