junos: get_interfaces returns list instead of bool for an svi that is admin down

[amylieb]

Description of Issue/Question

On a non-ELS juniper (12.3R12.4) there appears to be a bug in the response to get-interfaces-information when a logical port (or at least an svi) is admin down. Here is the relevant config on my old EX4200:

set vlans VLAN0005 vlan-id 5
set vlans VLAN0005 l3-interface vlan.5

set interfaces vlan unit 5 disable
set interfaces vlan unit 5 description amytest
set interfaces vlan unit 5 family inet address 10.255.0.1/32

Here is the resulting state of the port - as expected it is down.

amylieb@d-BLDGG-1# run show interfaces descriptions vlan.5
Interface       Admin Link Description
vlan.5          down  down amytest

{master:0}[edit]

The problem seems to be weirdness with the device's RPC response to get-interfaces-information. It reports <iff-down/> twice. I don't see this behavior anywhere else - SVIs that aren't admin down on this device look fine, and SVIs on a QFX5110 running 18.4R2-S5.4 that are admin-down are also fine.

Here's the relevant snippet of the RPC response when I run get-interfaces-information:

    <logical-interface>
      <name>vlan.5</name>
      <local-index>68</local-index>
      <snmp-index>0</snmp-index>
      <description>amytest</description>
      <if-config-flags>
        <iff-down/>
        <iff-down/>
        <iff-link-down/>
        <iff-snmp-traps/>
        <internal-flags>0x0</internal-flags>
      </if-config-flags>
      <encapsulation>ENET2</encapsulation>
      <traffic-statistics>
        <input-packets>0</input-packets>
        <output-packets>0</output-packets>
      </traffic-statistics>
      <filter-information/>
      <address-family>
        <address-family-name>inet</address-family-name>
        <mtu>1500</mtu>
        <address-family-flags>
          <ifff-none/>
        </address-family-flags>
      </address-family>
    </logical-interface>

And here is the relevant output from napalm's get_interfaces_information for this interface when run against this device:

 {'is_up': True, 'is_enabled': [False, False], 'description': 'amytest', 'last_flapped': -1.0, 'mac_address': '40:B4:F0:7C:23:81', 'speed': 1000.0, 'mtu': 1518}

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

(Place an x between the square brackets where applicable)

• Yes
• [] No

Setup

napalm version

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

root@304d55f4aef7:/usr/src/app# pip freeze | grep napalm
napalm==4.1.0

Network operating system version

(Paste verbatim output from show version - or equivalent - between quotes below)

amylieb@d-BLDGG-1# run show version
fpc0:
--------------------------------------------------------------------------
Hostname: d-BLDGG-1
Model: ex4200-24t
JUNOS Base OS boot [12.3R12.4]
JUNOS Base OS Software Suite [12.3R12.4]
JUNOS Kernel Software Suite [12.3R12.4]
JUNOS Crypto Software Suite [12.3R12.4]
JUNOS Online Documentation [12.3R12.4]
JUNOS Enterprise Software Suite [12.3R12.4]
JUNOS Packet Forwarding Engine Enterprise Software Suite [12.3R12.4]
JUNOS Routing Software Suite [12.3R12.4]
JUNOS Web Management [12.3R12.4]
JUNOS FIPS mode utilities [12.3R12.4]

{master:0}[edit]

Steps to Reproduce the Issue

See above.

Error Traceback

N/A

[amylieb]

Note that assuming this is a Junos problem, I think a response of "open a case with Juniper" is totally valid. But I figure creating an issue here is warranted just to raise awareness.

[mirceaulinic]

Unfortunately, the way PyEZ (which NAPALM uses under the hood) works, I don't think it's fixable and indeed Juniper would need to fix their bash script that produces that XML output. What we could do however is to verify that the output is a list before get_interfaces returns and work around that. @amylieb