Adding functions for get_vlans and get_interface_descriptions()

[icmp-echo]

So today there are the following methods in napalm-base

get_arp_table () get_mac_address_table() get_interfaces_ip() get_interfaces_counters() get_interfaces()

As a network operations center and as an engineer I heavily rely on basic information of vlans and interface description find the right port or right unit, and could use similar functionality. So my proposal is to add:

get_vlans() get_interfaces_descriptions()

which is very basic but could impact very very positively.

Thanks

[dbarrosop]

Hi, regarding get_interfaces_description, do you see something here that might be missing on get_interfaces? You should have the description there already.

Regarding get_vlan, I'd propose a method that returns an openconfig-like object:

vlans:
  vlan:
    1:
      config:
          name: default
          status: active|suspended
    3:
      config:
          name: pre
          status: active|suspended
   4:
      config:
          name: pro
          status: ACTIVE|SUSPENDED
 interfaces:
   interface:
      et1:
        ethernet:
             switched-vlan:
                 config:
                       interface-mode: ACCESS|TRUNK
                       native-vlan: 1
                       access-vlan: 3
                       trunk-vlans: [3,4]

It's not the nicest model but it's similar to how OC looks like and will allow us to reuse code for napalm-yang. And yes, the get_vlans method would return both the vlans and the interfaces keys. Unless we want to have get_vans and get_interfaces_vlan. Thoughts?

@mirceaulinic ^

[mirceaulinic]

Sounds good to me. Maybe we can even start writing a parser & translator pair directly under napalm-yang and use it? I see @dbarrosop already wrote something (https://github.com/napalm-automation/napalm-yang/blob/develop/napalm_yang/mappings/junos/translators/openconfig-vlan/vlan.yaml) and we can easily access them through napalm.

[dbarrosop]

If we want to do that (which I think it's a great idea) I'd suggest abstracting napalm-yang from the driver. Meaning the user still uses get_vlans but then napalm-yang is called under the hoods. The reason is that I still want to be able to change napalm-yang's API if we decide so.

So what I'd suggest for this then would be to implement get_oc_interfaces and get_oc_vlans which happens to use napalm-yang.

[ddevalco]

Curious if what is being proposed here would provide the sort of data I'm looking for myself. I've been looking for ways provide a tool for others that can check switches for a vlan and what ports have it enabled. For instance on Cisco the basics of the "show vlan id xxxx":

7018_1# sh vlan id 32

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
32   TEST_10.80.32.0/24               active    Po850, Eth1/1, Eth1/4, Eth1/5
                                                Eth1/6, Eth1/9, Eth1/11, Eth1/13
                                                Eth1/14, Eth1/17, Eth1/26
                                                Eth1/27, Eth1/30, Eth2/1, Eth2/5
                                                Eth2/9, Eth2/11, Eth2/12
                                                Eth2/17, Eth2/26, Eth2/46
                                                Eth3/31, Eth4/28, Eth5/12
                                                Eth5/19, Eth5/29, Eth5/33
                                                Eth5/45, Eth6/6, Eth6/29
                                                Eth7/24, Eth7/44, Eth8/15
                                                Eth8/19, Eth8/28, Eth8/31
                                                Eth8/34, Eth8/37, Eth8/43
                                                Eth11/5, Eth11/21, Eth11/30
                                                Eth11/36, Eth13/8, Eth13/35
                                                Eth13/45, Eth14/8, Eth15/21
                                                Eth15/29, Eth16/21, Eth16/33
                                                Eth17/1, Eth17/7, Eth17/28
                                                Eth17/30, Eth17/33, Eth17/36
                                                Eth17/39, Eth18/10, Eth18/14
                                                Eth18/18, Eth18/19, Eth18/20
                                                Eth18/29, Eth18/35, Eth18/44

Haven't starting using Napalm yet, it's on the list, and if this is the sort of data one could extract efficiently it would be a great excuse to start leveraging Napalm.

[dbarrosop]

Well, the model is described here:

https://github.com/napalm-automation/napalm-base/issues/252#issuecomment-305963170

The code is not there yet though.

[dbarrosop]

264 integrates napalm-yang into the drivers which means we will only need to implement the parsers/translators and get all the napalm-yang goodies.

[dbarrosop]

@icmp-echo what platforms would you need for the get_vlans method?

[icmp-echo]

@dbarrosop cisco and juniper, please

[dbarrosop]

Ok, will implement at least one of them. However, it might not be released for a while while we iron some details with pyangbind and py3 support.

[dbarrosop]

@icmp-echo could you be more specific? cisco and juniper have at least 10 different ways of configuring vlans depending on platform, phase of the moon and mood of the developer :) It would be great if you could provide platform, operating system and even snippets of valid configuration :)

Thanks!

[dbarrosop]

I implemented this for EOS because I don't know which flavor of IOS/Junos people wanted. You can see the results here:

https://github.com/napalm-automation/napalm-yang/blob/develop/test/integration/test_profiles/eos/openconfig-interfaces/config/l2_ports/expected.json https://github.com/napalm-automation/napalm-yang/blob/develop/test/integration/test_profiles/eos/openconfig-vlan/config/default/expected.json

Theoretically the vlan model has a members attribute where it lists the interface members, however, I didn't bother implementing it as it's redundanty (the info is already on the interfaces model).

[lboue]

Hello,

I managed to get close to the expected result for IOSDriver with a template here. But I still have to split the PORTS rows in an external script. For exemple: ['Fa0/1, Fa0/2, Fa0/3, Fa0/4, Fa0/5, Fa0/6, Fa0/7, Fa0/8, Fa0/9', 'Fa0/10, Fa0/11, Fa0/12']]

I think this can be done in a new method in the IOSDriver class.

What do you think about it?

Regards,

[dbarrosop]

I am not sure what the question is :)

In any case, this discussion should be moved to the napalm repo as this one is deprecated.

Closing.