Netbox: Add an interfaces list view

[darcynz]

Environment

• Python version:
• NetBox version:

Proposed Functionality

Add a GUI page for interfaces -> https://netbox/api/dcim/interfaces/. Filtering by site/region and tags would allow easier management of interfaces.

Export template functionality would also add.

Use Case

Enable holistic management of interfaces.

We would use this for our Switch port register (currently done in a spreadsheet to keep track of allocated interfaces in the datacenter).

In general Netbox would be ideal for holistic management of interfaces, making it easy to view them and. It can also be leveraged by adding metadata via tags. Eg monitoring groups.

Noted this was raised before ( https://github.com/netbox-community/netbox/issues/291) but wanted to show the relevance with our use case.

Database Changes

None that I'm aware off

External Dependencies

None that I'm aware off

[jeremystretch]

I don't think it would make sense to do this for only interfaces and not for the six other types of device components (console ports, power ports, etc.).

[wols]

I could export all interface _descriptions_ (before the connection) to fill device configuration templates.

[darcynz]

I agree. I can see benefits seeing the the other components holistically eg one use case could be to find devices with only one power port that need another. It would also enable each component type as a source of truth domain, as users able to see the items holistically easily and any mistakes / omissions. Currently this is done via reports.

Perhaps a multi discipline components page could work. The main difficulty would be filtering, I suppose component specific tags could be listed under their own headings. A check box filter could be used to hide/add component types.

Curious to see community thoughts on this...

[darcynz]

We've managed to make a work around via a recent post (Thanks Jeremy!!) that enables exporting associated interfaces via the device model.

Would still be great to see interfaces via the GUI but this helps provide the overview we wanted.

In case any one else is looking to do the same, below is the adjusted the template to give a report like format:

devicename, deviceid, interfacename,  IP Address(es), description, connected device, connected endpoint, formfactor, mtu, lag, enabled?,  tags
{% for device in queryset %}{% for interface in device.interfaces.all %}{{ device.name }},{{ device.id}},{{ interface.name }}, {% for ip in interface.ip_addresses.all %}{{ ip.address }} - {% endfor %}, {{ interface.description}}, {{interface.connected_endpoint.device}}, {{interface.connected_endpoint}},{{interface.form_factor}}, {{interface.mtu}}, {{interface.lag}}, {{ interface.enabled}}, {% for tag in interface.tags.names %}{{tag}}{% if not forloop.last %} - {% endif %}{%endfor %}
{% endfor %}{% endfor %}

[candlerb]

Adding an explicit 'interfaces' view opens the door to importing interfaces as CSV, which was requested as #822 (and #1492 for virtual machines)

[candlerb]

Just found another use case for this: I wanted to view which MAC addresses I have stored in Netbox.

[candlerb]

The example export above doesn't work with virtualmachines.

The admin interface _does_ let you create an export template for dcim > interfaces, so I made this:

name,device,virtual_machine,type,enabled,mac_address,mtu,mgmt_only
{%- for i in queryset %}
{{i.name}},{{i.device}},{{i.virtual_machine}},{{i.type}},{{i.enabled}},{{i.mac_address}},{{i.mtu}},{{i.mgmt_only}}
{%- endfor %}

However, the GUI doesn't appear to have anywhere to run it :-(

If I manually create the URL /dcim/interfaces/?export=foo I get a 404. As was recently mentioned elsewhere, I don't think the API allows you to run an export either.

Workaround is to use nbshell:

>>> print(ExportTemplate.objects.get(name="foo").render(Interface.objects.all()))

[darcynz]

Thanks Brian! Forgot about VM's, That export will be handy!

[hellerve]

We have a working version of interface lists (including filters and so on) in our fork of NetBox.

Did we agree on only doing this for interfaces for now instead of other device components? If so, I’d happily provide the code that we have. If not this should also not be a big problem for us to implement!

EDIT: Oh, I see @DanSheps already volunteered to work on this. Sorry about that!

[DanSheps]

I think we should definitely do all views.

[TheRealBecks]

@hellerve @DanSheps Maybe working together could lead into a faster result?

[steffann]

Looks good! I did notice that for interfaces the "Device" column is empty when an interface belongs to a VM. Might be useful to change that column to "Device/VM".

[steffann]

Also: while playing with it I found the order of the columns a bit confusing. I would suggest the following order (basically moving Device to the front):

• Device/VM
• Name
• Type
• Connection status
• Cable

[candlerb]

I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded.

(Aside: it seems that connection status as an attribute of the interface is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?)

[darcynz]

My initial thought was that the interface list would be similar to what you see on a device (name, description, mtu, mode, cable, connection etc) but that would be too verbose.

Could interface description fit? At a glance this could be quite important as often it shows purpose of the interface.

Also perhaps showing interface 'enabled' could quite helpful.

[steffann]

(Aside: it seems that connection status as an attribute of the _interface_ is weird. It means it could be Planned at one end and Active at the other. Would it be better as an attribute of the cable?)

The attribute on the interface is basically a cache. It's set when any cable in the path is changed, and its value is based on the status of all the cables on the path. It will only show as connected if all cables are connected and there is a remote endpoint. So not as useless as it seems :)

[candlerb]

I think description should be included. This would be consistent with /ipam/ipaddresses and /ipam/prefixes which also include description. /dcim/devices doesn't - but devices and VMs have "comments" rather than "description".

If screen estate is a problem, then one option would be switchable views:

• a regular view with Device/VM, Name, Type, Description (Enabled?) (Mgmt Only?) (Cable?)
• a technical view, with Device/VM, Name, Type, MTU, MAC address, VLAN mode, VLANs

[candlerb]

Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-(

[DanSheps]

I would like to see MAC Address in a column, if only to be able to spot interfaces that haven't had MAC address recorded.

I am trying to keep the view very generic at this point in time. In the future we can look at expanding the columns.

If screen estate is a problem, then one option would be switchable views:

This is going to be beyond the scope of the current issue. This would have to wait, most likely for a major UI revamp.

Oh, and it would be great to see tags. However the other list views don't show tags either, so I guess that should be left out purely for consistency :-(

This is going to maintain consistency with other list views more or less.

[jeremystretch]

Regarding tags: I agree that it would nice to include them, but right now we're constrained by the use of HTML tables for most object lists. Ideally, tags should appear below the standard fields to ensure they don't force excessive wrapping of other fields. This would be best approached by converting to a more flexible rendering mechanism, but obviously that won't be trivial as it likely entails ditching django-tables2.

[DanSheps]

For everything except for interfaces and device bays, the following columns are used: 'pk', 'device', 'name', 'type', 'description', 'cable'

For interfaces: 'pk', 'parent', 'name', 'type', 'description', 'cable'

For device bays: 'pk', 'name', 'device', 'installed_device'

Ports are ordered by either device or parent