ios: get_interfaces() last_flap - not implemented

bradh11 commented 5 years ago

Description of Issue/Question

Drivers do not have last_flap attribute calculated for get_interfaces(). I believe a good source of this would be the "last input / last output / last output hang" data that is seen via a show interface command typically. In fact it might make better sense to add these 3 values to the dictionary rather than try to leverage the single unimplemented last_flap attribute.

The new attributes could be parsed via a textfsm template with something like this. ^\s+Last\s+input\s+${LAST_INPUT},\s+output\s+${LAST_OUTPUT},\s+output\s+hang\s+${LAST_OUTPUT_HANG}\s*$$

the new proposed attributes could be:

last_input
last_output
last_output_hang

These are valid for Cisco based devices, but i am not sure about non Cisco devices. If they are available, I would recommend this change across all drivers for consistency.

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

(Place an x between the square brackets where applicable)

[x] Yes
[ ] No

Setup

win10 python 3.7.2

napalm version

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

napalm==2.4.0

Network operating system version

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

n/a

Steps to Reproduce the Issue

always reproducible since the library has not implemented this feature yet.

Error Traceback

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

n/a

TheRealBecks commented 5 years ago

I took a look at Cisco and Arista switches. From the 'show interfaces' command I get the following output (shorted): Arista:

Ethernet2 is up, line protocol is up (connected)
  Hardware is Ethernet, address is 7483.efee.a98f (bia 7483.efee.a98f)
  Description: TMP: pw-live-auth02-b rif0 trunk
  Ethernet MTU 9214 bytes , BW 10000000 kbit
  Full-duplex, 10Gb/s, auto negotiation: off, uni-link: n/a
  Up 16 days, 20 hours, 24 seconds
  Loopback Mode : None
  62 link status changes since last clear
  Last clearing of "show interface" counters 138 days, 2:28:56 ago

--> Up 16 days, 20 hours, 24 seconds

Cisco:

GigabitEthernet1/0/1 is up, line protocol is up (connected) 
  Hardware is Gigabit Ethernet, address is 5cfc.66d4.7481 (bia 5cfc.66d4.7481)
  Description: core-b1 fxp0 mgmt_berlin re0
  MTU 9000 bytes, BW 1000000 Kbit/sec, DLY 10 usec, 
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, media type is 10/100/1000BaseTX
  input flow-control is off, output flow-control is unsupported 
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:12, output 00:00:00, output hang never
  Last clearing of "show interface" counters never

--> Last input 00:00:12, output 00:00:00, output hang never

NAPALM processes the output as follows: Arista:

interfaces[interface]["last_flapped"] = values.pop(
    "lastStatusChangeTimestamp", -1.0
)

--> I have no access to the Arista API, but I think Arista returns the lastStatusChangeTimestamp as some kind of datetime, so it's possible to get some useful information out of it.

And here's the code for Cisco:

Get interface details.

last_flapped is not implemented

<-- It's a comment in the code

# default values.
last_flapped = -1.0
[...]
interface_dict[interface] = {
    "is_enabled": is_enabled,
    "is_up": is_up,
    "description": description,
    "mac_address": mac_address,
    "last_flapped": last_flapped,
    "mtu": mtu,
    "speed": speed,
}

Juniper:

"last_flapped": float((iface_data["last_flapped"] or -1)),

The problem is that you won't get any useful output from Cisco last_*. From my perspective as an network engineer that output was never ever useful in any situation... :( Also you can't compare that information with the output from other vendors as it's no uptime from the interface. So default value will be -1.

gnubyte commented 4 years ago

For anyone looking at this, the issue is not just as trivial as adding the detail to ios - I recently tried this in a fork and the unit tests will require updating, as when you update the unit test it will inherently break all model's tests (in my experience) from a quick attempt at this problem. If there is a better way to address a per driver unit test that is easily implemented I'd appreciate any other suggestions of how to implement this.

napalm-automation / napalm