Giters

napalm-automation-community / napalm-ros

MikroTik RouterOS NAPALM driver

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Method get_interfaces_counters failed: 'tx-error'

Dacesilian opened this issue · comments

commented

Description of Issue/Question

get_interfaces_counters doesn't work. It reproduces error:

GET /api/dcim/devices/2/napalm/?method=get_interfaces_counters
HTTP 200 OK
Allow: GET, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "get_interfaces_counters": {
        "error": "Method get_interfaces_counters failed: 'tx-error'"
    }
}

Setup

napalm-ros version

Installed first with pip and then also from this github and used: python3 ./setup.py install

napalm-ros==1.0.0

ROS version

"vendor": "MikroTik",
"model": "RB4011iGS+",
"os_version": "6.47.6 (stable)",

Am I using latest version if I installed it from git with setup.py install? Thanks.

commented

Hi.

Napalm as far as I know doesn't expose any HTTP api. Please run the same command from cli / ipython. I need exact exception so I can help.

commented

I believe GET /api/dcim/devices/2/napalm/?method=get_interfaces_counters comes from the Netbox NAPALM integration which just calls napalm via the Netbox API.

I have a device running the latest stable ROS release, 6.47.8 (stable), model is CCR1009-7G-1C-1S+, using napalm-ros==1.0.0 and librouteros==3.0.2 I am unable to reproduce this problem. It seems to me that 'tx-error' is a key error in the api response you get back via librouteros. As far as I can tell the keys that ROS returns have not changed in their API. A small example from my test device:

{'.id': '*1',
 'actual-mtu': 1500,
 'default-name': 'sfp-sfpplus1',
 'disabled': True,
 'fp-rx-byte': 0,
 'fp-rx-packet': 0,
 'fp-tx-byte': 0,
 'fp-tx-packet': 0,
 'l2mtu': 1580,
 'link-downs': 0,
 'mac-address': '74:4D:28:D7:CD:49',
 'max-l2mtu': 10222,
 'mtu': 1500,
 'name': 'sfp-sfpplus1',
 'running': False,
 'rx-byte': 0,
 'rx-drop': 0,
 'rx-error': 0,
 'rx-packet': 0,
 'tx-byte': 0,
 'tx-drop': 0,
 'tx-error': 0,
 'tx-packet': 0,
 'tx-queue-drop': 0,
 'type': 'ether'}

@Dacesilian perhaps you could do something like the following and inspect the api response directly (replacing the user/pass/ip below):

>>> from librouteros import connect
>>> from pprint import pprint
>>> api = connect(
...     username='username',
...     password='password',
...     host='10.0.0.1',
... )
>>> for row in api('/interface/print', stats=True)
...     pprint(row)

Check to see if the tx-error key is something else in the response you get back. As far as I can tell the response has not changed in 6.47.x but I am using an entirely different model than you.

commented

Probably there is a problem, that key (tx-error) is not present in some blocks?

... | grep -e 'tx-error' -e "'.id':"
{'.id': '*1',
{'.id': '*2',
{'.id': '*3',
{'.id': '*4',
{'.id': '*5',
{'.id': '*6',
{'.id': '*7',
{'.id': '*8',
{'.id': '*9',
{'.id': '*A',
{'.id': '*B',
 'tx-error': 0,
{'.id': '*F00006',
 'tx-error': 0,
{'.id': '*F00005',
 'tx-error': 0,
{'.id': '*F',
 'tx-error': 0,
{'.id': '*1A',
 'tx-error': 0,
{'.id': '*11',
 'tx-error': 0,
{'.id': '*10',
 'tx-error': 0,
{'.id': '*C',
 'tx-error': 0,
{'.id': '*19',
 'tx-error': 0,
{'.id': '*12',
 'tx-error': 0,
{'.id': '*13',
 'tx-error': 0,
{'.id': '*1C',
 'tx-error': 0,
{'.id': '*15',
 'tx-error': 0,
{'.id': '*14',
 'tx-error': 0,
{'.id': '*16',
 'tx-error': 0,
{'.id': '*17',
 'tx-error': 0,
{'.id': '*18',
 'tx-error': 0,
{'.id': '*20',
 'tx-error': 0,
{'.id': '*1E',
 'tx-error': 0,
{'.id': '*1F',
 'tx-error': 0,
{'.id': '*1B',
 'tx-error': 0,
commented

Can you share the full output from one of the interfaces that is missing the tx-error key? I suspect there may be other keys missing and that would be helpful to see. Thanks!

commented

Sure, for example:

{'.id': '*1',
 'actual-mtu': 1500,
 'default-name': 'ether1',
 'disabled': False,
 'fp-rx-byte': 0,
 'fp-rx-packet': 0,
 'fp-tx-byte': 0,
 'fp-tx-packet': 0,
 'l2mtu': 1592,
 'link-downs': 0,
 'mac-address': 'AA:BB:CC...',
 'max-l2mtu': 9578,
 'mtu': 1500,
 'name': 'ether1poe',
 'running': False,
 'rx-byte': 0,
 'rx-packet': 0,
 'tx-byte': 0,
 'tx-packet': 0,
 'tx-queue-drop': 0,
 'type': 'ether'}
{'.id': '*2',
 'actual-mtu': 1500,
 'default-name': 'ether2',
 'disabled': True,
 'fp-rx-byte': 0,
 'fp-rx-packet': 0,
 'fp-tx-byte': 0,
 'fp-tx-packet': 0,
 'l2mtu': 1592,
 'link-downs': 0,
 'mac-address': 'AA:BB:CC...',
 'max-l2mtu': 9578,
 'mtu': 1500,
 'name': 'ether2',
 'running': False,
 'rx-byte': 0,
 'rx-packet': 0,
 'tx-byte': 0,
 'tx-packet': 0,
 'tx-queue-drop': 0,
 'type': 'ether'}

{'.id': '*15',
 'actual-mtu': 1500,
 'disabled': False,
 'fp-rx-byte': 50458344126,
 'fp-rx-packet': 249971402,
 'fp-tx-byte': 138768151521,
 'fp-tx-packet': 153418916,
 'l2mtu': 1588,
 'last-link-up-time': 'nov/28/2020 11:25:46',
 'link-downs': 0,
 'mac-address': 'AA:BB:CC...',
 'mtu': 1500,
 'name': 'vm-vlan-108',
 'running': True,
 'rx-byte': 50459989521,
 'rx-drop': 0,
 'rx-error': 0,
 'rx-packet': 249985460,
 'tx-byte': 152312220074,
 'tx-drop': 0,
 'tx-error': 0,
 'tx-packet': 290605951,
 'tx-queue-drop': 0,
 'type': 'vlan'}
{'.id': '*14',
 'actual-mtu': 1500,
 'disabled': False,
 'fp-rx-byte': 0,
 'fp-rx-packet': 0,
 'fp-tx-byte': 0,
 'fp-tx-packet': 0,
 'l2mtu': 1588,
 'last-link-up-time': 'nov/28/2020 11:25:46',
 'link-downs': 0,
 'mac-address': 'AA:BB:CC...',
 'mtu': 1500,
 'name': 'vlan-1',
 'running': True,
 'rx-byte': 0,
 'rx-drop': 0,
 'rx-error': 0,
 'rx-packet': 0,
 'tx-byte': 1214,
 'tx-drop': 0,
 'tx-error': 0,
 'tx-packet': 13,
 'tx-queue-drop': 0,
 'type': 'vlan'}
commented

It looks like drop/error counters are not returned via the mikrotik api when an interface is not running (R). Thank Mikrotik for that consistent behavior. #86 should fix this (I also added a test case for this).