napalm-automation / napalm-junos Goto Github PK

I get a TypeError when I do a get_facts() on a virtual JUNOS router. I included the get_interfaces() call to show that NAPALM is able to talk to the router. It's just that get_facts() fails.

$ python
Python 2.7.11+ (default, Apr 17 2016, 14:00:29)
[GCC 5.3.1 20160413] on linux2
Type "help", "copyright", "credits" or "license" for more information.

from napalm import get_network_driver
driver = get_network_driver('junos')
device = driver('10.1.1.99', 'config_pusher', 'xxxxxxxxx')
device.open()
for i in device.get_interfaces():
... i
...
'demux0'
'pime'
...
'em0'
'pp0'
'dsc'
device.get_facts()
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/napalm_junos/junos.py", line 163, in get_facts
'uptime': string_parsers.convert_uptime_string_seconds(uptime),
File "/usr/local/lib/python2.7/dist-packages/napalm_base/utils/string_parsers.py", line 75, in convert_uptime_string_seconds
uptime_dict = regex.search(uptime)
TypeError: expected string or buffer

NAPALM:

$ pip show napalm

Metadata-Version: 1.1
Name: napalm
Version: 1.1.0
Summary: Network Automation and Programmability Abstraction Layer with Multivendor support
Home-page: https://github.com/napalm-automation/napalm
Author: David Barroso
Author-email: [email protected]
License: UNKNOWN
Location: /usr/local/lib/python2.7/dist-packages
Requires: napalm-base, napalm-eos, napalm-fortios, napalm-ibm, napalm-ios, napalm-iosxr, napalm-junos, napalm-nxos, napalm-pluribus, napalm-panos
Classifiers:
Topic :: Utilities
Programming Language :: Python
Programming Language :: Python :: 2
Programming Language :: Python :: 2.7
Operating System :: POSIX :: Linux
Operating System :: MacOS

$ uname -a
Linux userver 4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

JUNOS router:
config_pusher@J99> show version
Hostname: J99
Model: olive
JUNOS Base OS boot [12.1R1.9]
JUNOS Base OS Software Suite [12.1R1.9]
JUNOS Kernel Software Suite [12.1R1.9]
JUNOS Crypto Software Suite [12.1R1.9]
JUNOS Packet Forwarding Engine Support (M/T Common) [12.1R1.9]
JUNOS Packet Forwarding Engine Support (M20/M40) [12.1R1.9]
JUNOS Online Documentation [12.1R1.9]
JUNOS Voice Services Container package [12.1R1.9]
JUNOS Border Gateway Function package [12.1R1.9]
JUNOS Services AACL Container package [12.1R1.9]
JUNOS Services LL-PDF Container package [12.1R1.9]
JUNOS Services PTSP Container package [12.1R1.9]
JUNOS Services Stateful Firewall [12.1R1.9]
JUNOS Services NAT [12.1R1.9]
JUNOS Services Application Level Gateways [12.1R1.9]
JUNOS Services Captive Portal and Content Delivery Container package [12.1R1.9]
JUNOS Services RPM [12.1R1.9]
JUNOS Services HTTP Content Management package [12.1R1.9]
JUNOS AppId Services [12.1R1.9]
JUNOS IDP Services [12.1R1.9]
JUNOS Services Crypto [12.1R1.9]
JUNOS Services SSL [12.1R1.9]
JUNOS Services IPSec [12.1R1.9]
JUNOS Runtime Software Suite [12.1R1.9]
JUNOS Routing Software Suite [12.1R1.9]

Error Traceback

(Paste the complete traceback of the exception between quotes below)

>>> j.get_optics()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/state/home/mircea/napalm/local/lib/python2.7/site-packages/napalm_junos/junos.py", line 1421, in get_optics
    if optics['input_power'] != '- Inf'
TypeError: float() argument must be a string or a number

napalm-junos version

(Paste verbatim output from pip freeze | grep napalm-junos between quotes below)

0.6.0

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

14.2R6.5

Must use the helpers ip and mac from napalm-base: napalm-automation/napalm-base#55 resp napalm-automation/napalm-base#54

See details in the parent issue napalm-automation/napalm#327

Description of Issue/Question

Ref: napalm-automation/napalm-base#106

Description of Issue/Question

Cannot close and reopen session with a device because the config object cu is already binded.

napalm-junos version

napalm-junos==0.2.1

JunOS version

any

Steps to Reproduce the Issue

• Open connection with the device
• Close the conection
• Open it again

Error Traceback

>>> j.open()
>>> j.close()
>>> j.open()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/state/home/mircea/napalm-junos/napalm_junos/junos.py", line 73, in open
    self.device.bind(cu=Config)
  File "/state/home/mircea/napalm-test/local/lib/python2.7/site-packages/junos_eznc-1.3.1-py2.7.egg/jnpr/junos/device.py", line 756, in bind
    name)
ValueError: requested attribute name cu already exists

Solution

Must remove the binding during close.

Description of Issue/Question

Junos has a concept of physical and logical interfaces.
Physical: xe-0/0/0
Logical xe-0/0/0.0

In practice this means xe-0/0/0 will hold physical properties of a port e.g. speed. xe-0/0/0.0 will hold logical properties such as IP addresses etc.

On Napalm-EOS this already seems to be supported, as subinterfaces:

marty@box01:~$ sudo salt edge01.xxx01 net.interfaces
edge01.xxx01:
    ----------
    comment:
    out:
        ---
[SNIP]
        Ethernet45:
            ----------
            description:
                IXP
            is_enabled:
                True
            is_up:
                True
            last_flapped:
                1487297742.56
            mac_address:
                11:22:33:44:55:66
            speed:
                10000
        Ethernet45.11:
            ----------
            description:
                IXP Primary
            is_enabled:
                True
            is_up:
                True
            last_flapped:
                1487297742.66
            mac_address:
                11:22:33:44:55:66
            speed:
                10000
        Ethernet45.12:
            ----------
            description:
                IXP Secondary
            is_enabled:
                True
            is_up:
                True
            last_flapped:
                1487297742.66
            mac_address:
                11:22:33:44:55:66
            speed:
                10000
[SNIP]

It would be great to have this same functionality on Juniper

See details in the parent issue napalm-automation/napalm-base#71

Description of Issue/Question

Ref: napalm-automation/napalm-base#105

Load the config in the format specified in this field - if not specified, will default to text.
Ref: napalm-automation/napalm-base#111

Description of Issue/Question

Ref: napalm-automation/napalm-base#174

See details in the parent issue napalm-automation/napalm-base#214

Description of Issue/Question

get_lldp_neighors{_details} fails if lldp is not supported.

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)

napalm-junos==0.4.4

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

ntc@vsrx1> show version and haiku
Hostname: vsrx1
Model: vSRX
Junos: 15.1X49-D15.4
JUNOS Software Release [15.1X49-D15.4]


        gdb and me
        joyfully watching bugs flee
        working happily

Steps to Reproduce the Issue

Will fill out later :)

Error Traceback

(Paste the complete traceback of the exception between quotes below)

TASK [get facts from device] ***************************************************
fatal: [ntt-vsrx]: FAILED! => {"changed": false, "failed": true, "msg": "[environment] cannot retrieve device data: RpcError(severity: error, bad_element: None, message: command is not valid on the vsrx)"}
...ignoring

Since the JUNOS API supports SSH keys it would be nice if naplm_junos could support it too.

Instead of specifying username and password one would just specify the username and SSH key file as an optional argument.

For example:

driver(host, username='my_ssh_key_enabled_user', optional_args={'ssh_keyfile': my_key})

Verbatim copy from napalm-automation/napalm-base#227

According to the documentation both get_bgp_neighbors() and get_bgp_neighbors_detail() should: "Returns a dictionary of dictionaries. The keys for the first dictionary will be the vrf (global if no vrf)." However different values seem to be returned for the outer keys of each calls. (i.e. one is the vrf the other the routing instance?)

get_bgp_neighbors_detail() appears to return a dictionary of routing instances and not a dictionary containing the VRF as returned in get_bgp_neighbors(); it would seem that the get_bgp_neighbors_detail method should also return 'global' vrf as outer key. (only default/global VRF configured)

neighbor_facts = device.get_bgp_neighbors()
print("get_bgp_neighbors():")

for vrf in neighbor_facts:
print("Outer key values: " + vrf)

detail_facts = device.get_bgp_neighbors_detail()
print("get_bgp_neighbors_detail():")

for vrf in detail_facts:
print("Outer key values: " + vrf)
Results -

Cisco (ASR9010 - 5.3.3):

get_bgp_neighbors():

Outer key values: global

get_bgp_neighbors_detail():

Outer key values: default

JunOS (15.1F5-S4.6)

get_bgp_neighbors():

Outer key values: global

get_bgp_neighbors_detail():

Outer key values: inet6.0

Outer key values: inet.0

Outer key values: inetflow.0

JunOS (12.3R9.4)

get_bgp_neighbors():

Outer key values: global

get_bgp_neighbors_detail():

Outer key values: inet6.0

Outer key values: inet.0

Outer key values: inetflow.0

In examples above outer dict isn't returning the same value for both calls.

Description of Issue/Question

$ sudo salt edge01.sfo04 route.show 0.0.0.0/0
edge01.sfo04:
    ----------
    comment:
        Cannot execute "get_route_to" on edge01.sfo04: 'NoneType' object has no attribute 'lower'!
    out:
        ----------
    result:
        False
    traceback:
        Traceback (most recent call last):
          File "/state/home/mircea/salt/salt/utils/napalm.py", line 119, in call
            out = getattr(napalm_device.get('DRIVER'), method)(*args, **kwargs)
          File "/usr/local/salt/virtualenv/local/lib/python2.7/site-packages/napalm_junos/junos.py", line 975, in get_route_to
            protocol = protocol.lower()
        AttributeError: 'NoneType' object has no attribute 'lower'

See details in the parent issue napalm-automation/napalm-base#107

Description of Issue/Question

In #132 we're trying to detect the format of the config. I'm curious how someone might go about using "set" syntax w/o a line that begins with set. E.g. deactivating or deleting a bit of config w/o hacking in a superfluous command that starts with set first.

I'd be happy to submit a PR that made _detect_config_format more robust. Also was curious what you all think about explicitly exposing a format argument (that defaults to text) to the relevant methods that's passed to pyEZ's load()? Maybe in addition to a _detect_config_format refactor?

When calling method load_merge_candidate using the argument filename should consider the extension to determine the format type.
Ref: napalm-automation/napalm-base#111

See details in the parent issue napalm-automation/napalm-base#99

Description of Issue/Question

Executing get_bgp_neighbors_detail will return -1 for accepted_prefix_count,
advertised_prefix_count etc.

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

• Yes
• No

Setup

napalm-junos version

(Paste verbatim output from pip freeze | grep napalm-junos between quotes below)

napalm-junos==0.4.1

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

any

Steps to Reproduce the Issue

Execute get_bgp_neighbors_detail

See details in the parent issue napalm-automation/napalm-base#65

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)

napalm-junos==0.6.3

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

Model: mx960
JUNOS Base OS boot [12.3R9.4]
JUNOS Base OS Software Suite [12.3R9.4]
JUNOS Kernel Software Suite [12.3R9.4]
JUNOS Crypto Software Suite [12.3R9.4]
JUNOS Packet Forwarding Engine Support (M/T/EX Common) [12.3R9.4]
JUNOS Packet Forwarding Engine Support (MX Common) [12.3R9.4]
JUNOS Online Documentation [12.3R9.4]
JUNOS Services AACL Container package [12.3R9.4]
JUNOS Services Application Level Gateways [12.3R9.4]
JUNOS AppId Services [12.3R9.4]
JUNOS Border Gateway Function package [12.3R9.4]
JUNOS Services Captive Portal and Content Delivery Container package [12.3R9.4]
JUNOS Services HTTP Content Management package [12.3R9.4]
JUNOS IDP Services [12.3R9.4]
JUNOS Services LL-PDF Container package [12.3R9.4]
JUNOS Services NAT [12.3R9.4]
JUNOS Services PTSP Container package [12.3R9.4]
JUNOS Services RPM [12.3R9.4]
JUNOS Services Stateful Firewall [12.3R9.4]
JUNOS Voice Services Container package [12.3R9.4]
JUNOS Services Example Container package [12.3R9.4]
JUNOS Services Crypto [12.3R9.4]
JUNOS Services SSL [12.3R9.4]
JUNOS Services IPSec [12.3R9.4]
JUNOS Runtime Software Suite [12.3R9.4]
JUNOS platform Software Suite [12.3R9.4]
JUNOS Routing Software Suite [12.3R9.4]


        3am; darkness;
        Maintenance window closing.
        Safety net: rollback.

Steps to Reproduce the Issue

Error Traceback

(Paste the complete traceback of the exception between quotes below)

Traceback (most recent call last):
  File "HighSpeedPoller.py", line 616, in <module>
    main()
  File "HighSpeedPoller.py", line 597, in main
    get_BGPinfo(device, system_info['hostname'], MyInfluxClient, MySQLClient, "bgp_state")
  File "HighSpeedPoller.py", line 304, in get_BGPinfo
    print(int(neighborDetailInfo[vrf][asn][0]['messages_queued_out']))
TypeError: int() argument must be a string, a bytes-like object or a number, not 'list'

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:

neighborDetailInfo = device.get_bgp_neighbors_detail()

for vrf in neighborDetailInfo:
        for asn in neighborDetailInfo[vrf]:
               print("-----")
                print(vrf)
                print(neighborDetailInfo[vrf][asn][0]['remote_address'])
                print(neighborDetailInfo[vrf][asn][0]['local_address'])
                print(neighborDetailInfo[vrf][asn][0]['messages_queued_out'])
                print("-----")

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:

-----
inet.0
207.231.227.42
207.231.227.41
0
----
.
.  ## other peers omitted for clarity
.
inetflow.0
142.166.13.12
207.231.227.2
[0, 0, 0]

-----
inet6.0
142.166.13.12
207.231.227.2
[0, 0, 0]
-----

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)

   Peer: 207.231.227.42+57724 AS 32934 Local: 207.231.227.41 +179 AS 
  Description: 
  Type: External    State: Established    Flags: 
  Last State: EstabSync     Last Event: RecvKeepAlive
  Last Error: Cease

   ## Some detail here omitted for privacy

  Last traffic (seconds): Received 25   Sent 26   Checked 52
  Input messages:  Total 223552 Updates 10      Refreshes 0     Octets 4247976
  Output messages: Total 230840 Updates 1178    Refreshes 0     Octets 4478126
  Output Queue[0]: 0

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.

Peer: 142.166.13.12+21246 Local: 207.231.227.2+179 
  Description: Internal Peer 
  Type: Internal    State: Established  (route reflector client)Flags: 
  Last State: EstabSync     Last Event: RecvKeepAlive
  Last Error: None

  ### some details omitted here for privacy and clarity ### 

 NLRI for restart configured on peer: inet-unicast inet6-unicast inet-flow
  NLRI advertised by peer: inet-unicast inet6-unicast inet-flow
  NLRI for this session: inet-unicast inet6-unicast inet-flow
  Peer does not support Refresh capability
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  Peer does not support Receiver functionality
  Peer does not support Addpath
  Table inet.0 Bit: 10009
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            1
    Accepted prefixes:            1
    Suppressed due to damping:    0
    Advertised prefixes:          631937
  Table inetflow.0 Bit: 20000
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          0
  Table inet6.0 Bit: 30003
    RIB State: BGP restart is complete
    Send state: in sync
    Active prefixes:              0
    Received prefixes:            0
    Accepted prefixes:            0
    Suppressed due to damping:    0
    Advertised prefixes:          36762
  Last traffic (seconds): Received 2    Sent 0    Checked 2
  Input messages:  Total 40898  Updates 32      Refreshes 0     Octets 778410
  Output messages: Total 7774021        Updates 7728428 Refreshes 0     Octets 862558005
  Output Queue[0]: 0
  Output Queue[1]: 0
  Output Queue[2]: 0

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)

Description of Issue/Question

This happens to lo0, irb etc.

See details in the parent issue napalm-automation/napalm-base#217

See details in the parent issue napalm-automation/napalm#297

Description of Issue/Question

Noticed this issue long time ago, opening this bug to fix it at some point

$ sudo salt edge01.bjm01 snmp.config
edge01.bjm01:
    ----------
    comment:
    out:
        ----------
        chassis_id:
        community:
            ----------
            hackme:
                ----------
                acl:
                mode:
                    ro
        contact:
        location:
    result:
        True

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 ?

See details in the parent issue napalm-automation/napalm#199

Description of Issue/Question

get_route_to doesn't let to specify a table. When multiple vpnv4 tables are present the resulting routes can not be parsed to valid ipv4 address:

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)

napalm-junos==0.6.6 (also with current develop branch)

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

Model: mx10-t
Junos: 13.3R6-S2
JUNOS Base OS boot [13.3R6-S2]
JUNOS Base OS Software Suite [13.3R6-S2]
JUNOS Kernel Software Suite [13.3R6-S2]
JUNOS Crypto Software Suite [13.3R6-S2]
JUNOS Packet Forwarding Engine Support (MX80) [13.3R6-S2]
JUNOS Online Documentation [13.3R6-S2]
JUNOS Services Application Level Gateways [13.3R6-S2]
JUNOS Services Jflow Container package [13.3R6-S2]
JUNOS Services Stateful Firewall [13.3R6-S2]
JUNOS Services NAT [13.3R6-S2]
JUNOS Services RPM [13.3R6-S2]
JUNOS Services Crypto [13.3R6-S2]
JUNOS Services SSL [13.3R6-S2]
JUNOS Services IPSec [13.3R6-S2]
JUNOS Routing Software Suite [13.3R6-S2]

Steps to Reproduce the Issue

Run the following playbook (using napalm-ansible):

- name: fetch info
  gather_facts: false
  hosts: all
  connection: local
  tasks:
    - name: get facts
      napalm_get_facts:
        hostname: "10.69.0.35"
        username: "******"
        password: "******"
        dev_os: "junos"
        filter:
          - "route_to"
        args:
          route_to:
           destination: 8.8.8.0/24
      register: result
    - name: display results
      debug: var=result

Error Traceback

(Paste the complete traceback of the exception between quotes below)

TASK [get facts] *****************************************************************************************************************************************************************************
fatal: [vsrx01]: FAILED! => {"changed": false, "failed": true, "msg": "[route_to] cannot retrieve device data: failed to detect a valid IP address from u'10.69.0.177:500:8.8.8.0'"}
        to retry, use: --limit @/home/ubuntu/2d-automation/ansible/getdata.retry

Original issue napalm-automation/napalm#191 created by @fooelisa

print device.get_bgp_neighbors()
Traceback (most recent call last):
File "", line 1, in
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/napalm-0.51.0-py2.7.egg/napalm/junos.py", line 307, in get_bgp_neighbors
peer['address_family'] = self._parse_route_stats(neighbor_data)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/napalm-0.51.0-py2.7.egg/napalm/junos.py", line 266, in _parse_route_stats
family = self._get_address_family(table)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/napalm-0.51.0-py2.7.egg/napalm/junos.py", line 258, in _get_address_family
return address_family_mapping[family]
KeyError: 'evpn'

Description of Issue/Question

Ref: napalm-automation/napalm-base#185

See details in the parent issue napalm-automation/napalm-base#137

Description of Issue/Question

Running get_environment against MX240 failed with the following error:

Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.7/dist-packages/napalm_junos/junos.py", line 288, in get_environment
float(structured_object_data['temperature'])
TypeError: float() argument must be a string or a number

Other NAPALM function do work correctly with the device

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

• Yes
• No

Setup

napalm-junos version

(Paste verbatim output from pip freeze | grep napalm-junos between quotes below)

napalm-junos==0.4.1

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

Hostname: MX240_1
Model: mx240
Junos: 14.1R7.4
JUNOS Base OS boot [14.1R7.4]
JUNOS Base OS Software Suite [14.1R7.4]
JUNOS Packet Forwarding Engine Support (M/T/EX Common) [14.1R7.4]
JUNOS Packet Forwarding Engine Support (MX Common) [14.1R7.4]
JUNOS platform Software Suite [14.1R7.4]
JUNOS Runtime Software Suite [14.1R7.4]
JUNOS Online Documentation [14.1R7.4]
JUNOS Services AACL Container package [14.1R7.4]
JUNOS Services Application Level Gateways [14.1R7.4]
JUNOS AppId Services [14.1R7.4]
JUNOS Border Gateway Function package [14.1R7.4]
JUNOS Services Captive Portal and Content Delivery Container package [14.1R7.4]
JUNOS Services HTTP Content Management package [14.1R7.4]
JUNOS Services Jflow Container package [14.1R7.4]
JUNOS IDP Services [14.1R7.4]
JUNOS Services LL-PDF Container package [14.1R7.4]
JUNOS Services MobileNext Software package [14.1R7.4]
JUNOS Services Mobile Subscriber Service Container package [14.1R7.4]
JUNOS Services NAT [14.1R7.4]
JUNOS Services PTSP Container package [14.1R7.4]
JUNOS Services RPM [14.1R7.4]
JUNOS Services Stateful Firewall [14.1R7.4]
JUNOS Voice Services Container package [14.1R7.4]
JUNOS Services Crypto [14.1R7.4]
JUNOS Services SSL [14.1R7.4]
JUNOS Services IPSec [14.1R7.4]
JUNOS py-base-i386 [14.1R7.4]
JUNOS Kernel Software Suite [14.1R7.4]
JUNOS Crypto Software Suite [14.1R7.4]
JUNOS JAM Plugin Software Suite (MPC2E/3E) [14.1R7.4-C1.1]
JUNOS Routing Software Suite [14.1R7.4]


        No icons; no mouse
        No drop down menus or fonts
        CLIs are cool

Steps to Reproduce the Issue

Error Traceback

(Paste the complete traceback of the exception between quotes below)

>>> import napalm
>>> driver = napalm.get_network_driver('junos')
>>> mx = driver(hostname='mx240_1', username='root', password='XXXXXXXX')
>>> mx.open()
>>> mx.get_environment()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/napalm_junos/junos.py", line 288, in get_environment
    float(structured_object_data['temperature'])
TypeError: float() argument must be a string or a number

Confirmed function works fine against QFX:

>>> qfx = driver(hostname='qfx5100_1', username='root', password='XXXXXXXXXXX')
>>> qfx.get_environment()
>>> qfx.open()
>>> qfx.get_environment()
{'fans': {'FPC 0 Fan Tray 0': {'status': True}}, 'memory': {'available_ram': 1953, 'used_ram': 741}, 'temperature': {'FPC 0 Sensor CPULeft E': {'is_alert': False, 'temperature': 28.0, 'is_critical': False}, 'FPC 0 Sensor TopMiddle C': {'is_alert': False, 'temperature': 29.0, 'is_critical': False}, 'FPC 0 Sensor CPURight C': {'is_alert': False, 'temperature': 32.0, 'is_critical': False}, 'FPC 0 Sensor TopRight C': {'is_alert': False, 'temperature': 25.0, 'is_critical': False}, 'FPC 0 Sensor CPU Die Temp': {'is_alert': False, 'temperature': 44.0, 'is_critical': False}, 'FPC 0 Sensor TopRight I': {'is_alert': False, 'temperature': 32.0, 'is_critical': False}, 'FPC 0 Sensor TopLeft I': {'is_alert': False, 'temperature': 29.0, 'is_critical': False}}, 'power': {'FPC 0 Power Supply 0': {'status': True, 'output': -1.0, 'capacity': -1.0}}, 'cpu': {'0': {'%usage': 7.0}}}

Description of Issue/Question

Starting with JunOS 14 the datatype has been changed for loss_percentage from int to float.
PyEz does not seem to like this.

Error traceback

>>> e.get_probes_results()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "napalm_junos/junos.py", line 1146, in get_probes_results
    probes_results_items = probes_results_table.items()
  File "/state/home/mircea/hack2016/local/lib/python2.7/site-packages/jnpr/junos/factory/table.py", line 172, in items
    return list(zip(self.keys(), self.values()))
  File "/state/home/mircea/hack2016/local/lib/python2.7/site-packages/jnpr/junos/factory/table.py", line 164, in values
    return [list(this.items()) for this in self]
  File "/state/home/mircea/hack2016/local/lib/python2.7/site-packages/jnpr/junos/factory/view.py", line 121, in items
    return zip(self.keys(), self.values())
  File "/state/home/mircea/hack2016/local/lib/python2.7/site-packages/jnpr/junos/factory/view.py", line 117, in values
    return [getattr(self, field) for field in self.keys()]
  File "/state/home/mircea/hack2016/local/lib/python2.7/site-packages/jnpr/junos/factory/view.py", line 268, in __getattr__
    raise RuntimeError("Unable to handle field:'%s'" % name)
RuntimeError: Unable to handle field:'last_test_loss'

This is because by default python fails when converting a string like 0.0000 to int:

>>> int('0.0000')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for int() with base 10: '0.0000'

This error is then propagated into the transformations of the PyEz view builder.

Can we add commit confirmed option to optional_args ? It may be useful in some cases and it is easy to implement. I think only junos supports real commit confirmed functionality so I assume it would be better to implement it as local optional argument.

Example implementation:

Two optional arguments added to driver's init function:

        self.junos_commit_confirmed = optional_args.get('junos_commit_confirmed', 0)
        self.junos_commit_wait = optional_args.get('junos_commit_wait', 0)

and little change in commit method:

       if self.junos_commit_confirmed:
            self.device.cu.commit(confirm=self.confirm)
            if self.junos_commit_wait:
                sleep(int(self.junos_commit_wait))
        self.device.cu.commit()

Does it make sense? :)

Description of Issue/Question

When using salt-stack to grab a static route from a junos router, I get an error about it being a NoneType

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

• Yes
• No

Setup

napalm-junos version

(Paste verbatim output from pip freeze | grep napalm-junos between quotes below)

napalm-junos==0.4.3

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

Hostname: myrouter
Model: mx5-t
Junos: 13.3R6.5
JUNOS Base OS boot [13.3R6.5]
JUNOS Base OS Software Suite [13.3R6.5]
JUNOS Kernel Software Suite [13.3R6.5]
JUNOS Crypto Software Suite [13.3R6.5]
JUNOS Packet Forwarding Engine Support (MX80) [13.3R6.5]
JUNOS Online Documentation [13.3R6.5]
JUNOS Services Application Level Gateways [13.3R6.5]
JUNOS Services Jflow Container package [13.3R6.5]
JUNOS Services Stateful Firewall [13.3R6.5]
JUNOS Services NAT [13.3R6.5]
JUNOS Services RPM [13.3R6.5]
JUNOS Services Crypto [13.3R6.5]
JUNOS Services SSL [13.3R6.5]
JUNOS Services IPSec [13.3R6.5]
JUNOS Routing Software Suite [13.3R6.5]


        Help me, Obi-Wan
        I just saw Episode Two
        You're my only hope

Steps to Reproduce the Issue

Error Traceback

(Paste the complete traceback of the exception between quotes below)

salt myrouter route.show 10.0.0.0/8 static
myrouter:
    ----------
    comment:
        Cannot execute "get_route_to" on myrouter as user. Reason: argument of type 'NoneType' is not iterable!
    out:
        ----------
    result:
        False
    traceback:
        Traceback (most recent call last):
          File "/var/cache/salt/minion/extmods/proxy/napalm.py", line 284, in call
            out = getattr(NETWORK_DEVICE.get('DRIVER'), method)(**params)  # calls the method with the specified parameters
          File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/napalm_junos/junos.py", line 1061, in get_route_to
            key: value for key, value in all_protocol_attributes.iteritems()
          File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/napalm_junos/junos.py", line 1062, in <dictcomp>
            if key in _PROTOCOL_SPECIFIC_FIELDS_.get(protocol)
        TypeError: argument of type 'NoneType' is not iterable

Here are the statics configured on the routers default instance
user@myrouter> show configuration routing-options
static {
    route 10.0.0.0/8 next-hop 192.168.1.1;
    route 192.168.0.0/16 next-hop 192.168.1.1;
    route 172.16.0.0/12 next-hop 192.168.1.1;
}

Description of Issue/Question

It looks like our unicode literals together with recent changes in the junos-eznc library, triggered a bug.
This has been raised during my tutorial at RIPE 74 (although unfortunately not recorded):

Setup

As in https://ripe74.ripe.net/presentations/18-RIPE-74-Network-automation-at-scale-up-and-running-in-60-minutes.pdf

napalm-junos version

$ pip freeze | grep napalm-junos
napalm-junos==0.6.6

JunOS version

$ sudo salt device1 grains.get version
device1:
    15.1F6-S1.4

Steps to Reproduce the Issue

Error Traceback

(Paste the complete traceback of the exception between quotes below)

$ sudo salt device1 ntp.stats
device1:
    ----------
    comment:
        Cannot execute "get_ntp_stats" on ip-172-31-9-153.us-east-2.compute.internal as napalm. Reason: 'unicode' object has no attribute 'tag'!
    out:
        ----------
    result:
        False
    traceback:
        Traceback (most recent call last):
          File "/usr/lib/python2.7/dist-packages/salt/proxy/napalm.py", line 294, in call
            out = getattr(NETWORK_DEVICE.get('DRIVER'), method)(**params)  # calls the method with the specified parameters
          File "/usr/local/lib/python2.7/dist-packages/napalm_junos/junos.py", line 888, in get_ntp_stats
            ntp_assoc_output = self.device.cli('show ntp associations no-resolve')
          File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/device.py", line 600, in cli
            rpc_string = self.cli_to_rpc_string(command)
          File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/device.py", line 548, in cli_to_rpc_string
            rpc_string = "rpc.%s(" % (rpc.tag.replace('-', '_'))
        AttributeError: 'unicode' object has no attribute 'tag'

get_mac_address_table doesn't seem to work with JunOS 12.3R6.6 while get_facts for example is working well:

>>> from napalm import get_network_driver
>>> driver = get_network_driver('junos')
>>> device = driver('10.0.0.1', '<username_removed>', '<password_removed>')
>>> device.open()
>>> print device.get_facts()
{'os_version': u'12.3R6.6', 'uptime': 56577120, 'interface_list': ['ge-0/0/0', 'ge-0/0/20', 'ge-0/0/21', 'ge-0/0/22', 'ge-0/0/23', 'xe-0/1/0', 'xe-0/1/1', 'ge-1/0/0', 'ge-1/0/1', 'ge-1/0/2', 'ge-1/0/3', 'ge-1/0/4', 'ge-1/0/5', 'ge-1/0/6', 'ge-1/0/7', 'ge-1/0/8', 'ge-1/0/9', 'ge-1/0/10', 'ge-1/0/11', 'ge-1/0/12', 'ge-1/0/13', 'ge-1/0/14', 'ge-1/0/15', 'ge-1/0/16', 'ge-1/0/17', 'ge-1/0/18', 'ge-1/0/19', 'ge-1/0/20', 'ge-1/0/21', 'ge-1/0/22', 'ge-1/0/23', 'xe-1/1/0', 'xe-1/1/1', '.local.', 'vcp-0', 'vcp-1', 'ae0', 'ae1', 'ae2', 'bme0', 'dsc', 'gre', 'ipip', 'lo0', 'lsi', 'me0', 'mtun', 'pimd', 'pime', 'tap', 'vlan', 'vme'], 'vendor': u'Juniper', 'serial_number': u'CL0201230451', 'model': u'Virtual Chassis', 'hostname': u'labcorertr01', 'fqdn': u'labcorertr01.company.com'}
>>> print device.get_mac_address_table()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python2.7/dist-packages/napalm_junos/junos.py", line 860, in get_mac_address_table
    mac_table.get()
  File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/factory/optable.py", line 63, in get
    self.xml = getattr(self.RPC, self.GET_RPC)(**rpc_args)
  File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/rpcmeta.py", line 143, in _exec_rpc
    return self._junos.execute(rpc, **dec_args)
  File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/decorators.py", line 58, in wrapper
    result = function(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/decorators.py", line 26, in wrapper
    return function(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/jnpr/junos/device.py", line 570, in execute
    raise e(cmd=rpc_cmd_e, rsp=rsp, errs=err)
jnpr.junos.exception.RpcError: RpcError(severity: error, bad_element: get-bridge-mac-table, message: error: syntax error
error: syntax error)

.get_route_to() does not support connected/direct routes

In order to implement testing of routes with no next-hops for napalm-automation/napalm-base#157, direct or connected routes must be a supported protocol.

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)

pip freeze | grep napalm
napalm-base==0.20.3
napalm-junos==0.4.4

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

show version and haiku
Hostname: router
Model: mx80
JUNOS Base OS boot [11.4R7.5]
JUNOS Base OS Software Suite [11.4R7.5]
JUNOS Kernel Software Suite [11.4R7.5]
JUNOS Crypto Software Suite [11.4R7.5]
JUNOS Packet Forwarding Engine Support (MX80) [11.4R7.5]
JUNOS Online Documentation [11.4R7.5]
JUNOS Routing Software Suite [11.4R7.5]


        Just like mosquitoes
        Bugs pepper all my source code
        Keeps me off the streets

Steps to Reproduce the Issue

Attempt to call get_route_to

Error Traceback

(Paste the complete traceback of the exception between quotes below)

Python 2.7.5 (default, Jun 25 2014, 10:19:55)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import napalm_junos,getpass
>>> password = getpass.getpass()
Password:
>>> device = napalm_junos.JunOSDriver('router', 'bewing', password)
>>> device.open()
>>> device.get_route_to('192.0.2.1', 'direct')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/bewing/virtualenv/lib/python2.7/site-packages/napalm_junos/junos.py", line 964, in get_route_to
    protocol=protocol
TypeError: Protocol not supported: direct.

Description of Issue/Question

get_mac_address_table() fails when JUNOS return '*' as the MAC address.

XXXXX@XXXXX> show ethernet-switching table
Ethernet-switching table: 3 entries, 1 learned, 0 persistent entries
VLAN MAC address Type Age Interfaces
client201 * Flood - All-members
client201 b8:27:eb:04:ff:a2 Learn 0 ge-0/0/0.0
default 54:e0:32:30:87:01 Static - Router

from napalm import get_network_driver

driver = get_network_driver('junos')

device = driver('XXXXX', 'XXXXX', 'XXXXX')
device.open()
print device.get_facts()
print device.get_mac_address_table()

{u'os_version': u'14.1X53-D40.8', u'uptime': 7862760, u'interface_list': ['ge-0/0/0', 'ge-0/0/1', 'ge-0/0/2', 'ge-0/0/3', 'ge-0/0/4', 'ge-0/0/5', 'ge-0/0/6', 'ge-0/0/7', 'ge-0/0/8', 'ge-0/0/9', 'ge-0/0/10', 'ge-0/0/11', 'ge-0/0/12', 'ge-0/0/13', 'ge-0/0/14', 'ge-0/0/15', 'ge-0/0/16', 'ge-0/0/17', 'ge-0/0/18', 'ge-0/0/19', 'ge-0/0/20', 'ge-0/0/21', 'ge-0/0/22', 'ge-0/0/23', 'ge-0/0/24', 'ge-0/0/25', 'ge-0/0/26', 'ge-0/0/27', 'ge-0/0/28', 'ge-0/0/29', 'ge-0/0/30', 'ge-0/0/31', 'ge-0/0/32', 'ge-0/0/33', 'ge-0/0/34', 'ge-0/0/35', 'ge-0/0/36', 'ge-0/0/37', 'ge-0/0/38', 'ge-0/0/39', 'ge-0/0/40', 'ge-0/0/41', 'ge-0/0/42', 'ge-0/0/43', 'ge-0/0/44', 'ge-0/0/45', 'ge-0/0/46', 'ge-0/0/47', 'xe-0/1/0', '.local.', 'vcp-0', 'vcp-1', 'bme0', 'dsc', 'gre', 'ipip', 'jsrv', 'lo0', 'lsi', 'me0', 'mtun', 'pimd', 'pime', 'tap', 'vlan', 'vme'], u'vendor': u'Juniper', u'serial_number': u'XXXXX', u'model': u'EX4200-48T', u'hostname': u'XXXXX', u'fqdn': u'XXXXX'}
Traceback (most recent call last):
File "./test2.py", line 12, in
pprint(device.get_mac_address_table())
File "/usr/lib/python2.7/site-packages/napalm_junos/junos.py", line 988, in get_mac_address_table
mac_entry['mac'] = napalm_base.helpers.mac(mac)
File "/usr/lib/python2.7/site-packages/napalm_base/helpers.py", line 219, in mac
return py23_compat.text_type(EUI(raw, dialect=_MACFormat))
File "/usr/lib/python2.7/site-packages/netaddr/eui/init.py", line 387, in init
self.value = addr
File "/usr/lib/python2.7/site-packages/netaddr/eui/init.py", line 437, in _set_value
% value)
netaddr.core.AddrFormatError: failed to detect EUI version: u'*'
Segmentation fault

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)

$ pip freeze | grep napalm-junos
napalm-junos==0.6.6

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

root@XXXXX> show version and haiku 
Hostname: XXXXX
Model: ex4200-48t
Junos: 14.1X53-D40.8
JUNOS EX  Software Suite [14.1X53-D40.8]
JUNOS FIPS mode utilities [14.1X53-D40.8]
JUNOS Online Documentation [14.1X53-D40.8]
JUNOS EX 4200 Software Suite [14.1X53-D40.8]
JUNOS Web Management Platform Package [14.1X53-D40.8]


        TTL down one
        the end nearer with each hop
        little packet, poof.

{master:0}

Steps to Reproduce the Issue

Error Traceback

(Paste the complete traceback of the exception between quotes below)

{u'os_version': u'14.1X53-D40.8', u'uptime': 7862760, u'interface_list': ['ge-0/0/0', 'ge-0/0/1', 'ge-0/0/2', 'ge-0/0/3', 'ge-0/0/4', 'ge-0/0/5', 'ge-0/0/6', 'ge-0/0/7', 'ge-0/0/8', 'ge-0/0/9', 'ge-0/0/10', 'ge-0/0/11', 'ge-0/0/12', 'ge-0/0/13', 'ge-0/0/14', 'ge-0/0/15', 'ge-0/0/16', 'ge-0/0/17', 'ge-0/0/18', 'ge-0/0/19', 'ge-0/0/20', 'ge-0/0/21', 'ge-0/0/22', 'ge-0/0/23', 'ge-0/0/24', 'ge-0/0/25', 'ge-0/0/26', 'ge-0/0/27', 'ge-0/0/28', 'ge-0/0/29', 'ge-0/0/30', 'ge-0/0/31', 'ge-0/0/32', 'ge-0/0/33', 'ge-0/0/34', 'ge-0/0/35', 'ge-0/0/36', 'ge-0/0/37', 'ge-0/0/38', 'ge-0/0/39', 'ge-0/0/40', 'ge-0/0/41', 'ge-0/0/42', 'ge-0/0/43', 'ge-0/0/44', 'ge-0/0/45', 'ge-0/0/46', 'ge-0/0/47', 'xe-0/1/0', '.local.', 'vcp-0', 'vcp-1', 'bme0', 'dsc', 'gre', 'ipip', 'jsrv', 'lo0', 'lsi', 'me0', 'mtun', 'pimd', 'pime', 'tap', 'vlan', 'vme'], u'vendor': u'Juniper', u'serial_number': u'XXXXX', u'model': u'EX4200-48T', u'hostname': u'XXXXX', u'fqdn': u'XXXXX'}
Traceback (most recent call last):
  File "./test2.py", line 12, in <module>
    pprint(device.get_mac_address_table())
  File "/usr/lib/python2.7/site-packages/napalm_junos/junos.py", line 988, in get_mac_address_table
    mac_entry['mac'] = napalm_base.helpers.mac(mac)
  File "/usr/lib/python2.7/site-packages/napalm_base/helpers.py", line 219, in mac
    return py23_compat.text_type(EUI(raw, dialect=_MACFormat))
  File "/usr/lib/python2.7/site-packages/netaddr/eui/__init__.py", line 387, in __init__
    self.value = addr
  File "/usr/lib/python2.7/site-packages/netaddr/eui/__init__.py", line 437, in _set_value
    % value)
netaddr.core.AddrFormatError: failed to detect EUI version: u'*'
Segmentation fault

BGP neighbors down are not returned by the get_bgp_neighbors_detail function.
We need to refactor this method from scratch.

Description of Issue/Question

Unable to retrieve BGP config from vSRX

Did you follow the steps from https://github.com/napalm-automation/napalm#faq

• Yes
• No

Setup

Using the old vSRX box running 12.1, tried to retrieve the BGP config.

napalm-junos version

0.3.0

JunOS version

(Paste verbatim output from show version and haiku between quotes below)

root@vsrx2> show version and haiku
Hostname: vsrx2
Model: firefly-perimeter
JUNOS Software Release [12.1X47-D20.7]


        Just like mosquitoes
        Bugs pepper all my source code
        Keeps me off the streets

Steps to Reproduce the Issue

Just a minimal config for BGP is enough to reproduce:

root@vsrx2> show configuration protocols bgp | display set
set protocols bgp group TEST type external
set protocols bgp group TEST peer-as 1234
set protocols bgp group TEST neighbor 1.2.3.4

root@vsrx2> show configuration protocols bgp | display xml
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/12.1X47/junos">
    <configuration junos:commit-seconds="1476138575" junos:commit-localtime="2016-10-10 22:29:35 UTC" junos:commit-user="root">
            <protocols>
                <bgp>
                    <group>
                        <name>TEST</name>
                        <type>external</type>
                        <peer-as>1234</peer-as>
                        <neighbor>
                            <name>1.2.3.4</name>
                        </neighbor>
                    </group>
                </bgp>
            </protocols>
    </configuration>
    <cli>
        <banner></banner>
    </cli>
</rpc-reply>

Then open the connection using NAPALM and execute get_bgp_config()

Error Traceback

(Paste the complete traceback of the exception between quotes below)

>>> e.get_bgp_config()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/napalm_junos/junos.py", line 598, in get_bgp_config
    peers.get()  # unfortunately cannot add filters for group name of neighbor address
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/jnpr/junos/factory/cfgtable.py", line 546, in get
    self.xml = self.RPC.get_config(get_cmd, options=options)
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/jnpr/junos/rpcmeta.py", line 52, in get_config
    return self._junos.execute(rpc)
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/jnpr/junos/decorators.py", line 71, in wrapper
    return function(*args, **kwargs)
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/jnpr/junos/decorators.py", line 26, in wrapper
    return function(*args, **kwargs)
  File "/Users/mirucha/cfnapalm/lib/python2.7/site-packages/jnpr/junos/device.py", line 529, in execute
    raise e(cmd=rpc_cmd_e, rsp=rsp, errs=err)
jnpr.junos.exception.RpcError: RpcError(severity: error, bad_element: neighbor, message: syntax error)

Description of Issue/Question

For down neighbors, the the address family is an empty dictionary:

u'1.2.3.4': {'is_enabled': True, u'uptime': 3981371, 'remote_as': 65500, 'description': u'', 'remote_id': u'', 'local_as': 65000, 'is_up': False, u'address_family': {}

Description of Issue/Question

Fails when trying to retrieve the BGP neighbors using get_bgp_neighbors.

napalm-junos version

napalm-junos==0.2.1

JunOS version

Junos: 13.3R6.5

Steps to Reproduce the Issue

• Configure BGP to use inet flow: set protocols bgp family inet flow
• Open the connection with the device
• call get_bgp_neighbors

Error Traceback

>>> j.get_bgp_neighbors()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/state/home/mircea/napalm-junos/napalm_junos/junos.py", line 374, in get_bgp_neighbors
    peer['address_family'] = self._parse_route_stats(neighbor_data)
  File "/state/home/mircea/napalm-junos/napalm_junos/junos.py", line 333, in _parse_route_stats
    family = self._get_address_family(table)
  File "/state/home/mircea/napalm-junos/napalm_junos/junos.py", line 325, in _get_address_family
    return address_family_mapping[family]
KeyError: 'inetflow'

As described here: napalm-automation/napalm-base#237

See details in the parent issue napalm-automation/napalm-base#70

Relates to napalm-automation/napalm#280

Add setup.cfg and requirements-dev.txt file with the following content:

• `setup.cfg

[pylama]
linters = mccabe,pep257,pep8,pyflakes,import_order
ignore = D203

[pylama:pep8]
max_line_length = 100

• requirements-dev.txt

pytest
pytest-cov
pytest-json
pytest-pythonpath
pylama
flake8-import-order
-r requirements.txt