Wireless Link Bulk Import-Device/interface

[mblumber1]

NetBox version

v4.1.11

Feature type

Change to existing functionality

Proposed functionality

The bulk import functionality for wireless links (https://netbox-demo.netboxlabs.com/wireless/wireless-links/import/) has interface_a and interface_z. What it should have is device_a, interface_a, device_z, interface_z. That would allow us to bulk-import our wireless links.

Use case

I am documenting a wireless ISP where all our radios have the similar interface names (they are unique to the device, not globally unique). I'd like to import our wireless links rather than building them manually. I'm willing to use json / yaml but I cannot figure how to do it even with that. I believe that this functionality would need to be added.

Database changes

None

External dependencies

None

[pheus]

Thanks for the suggestion - I’ve looked into it a bit.

It seems that the current WirelessLink bulk import form expects the interface_a and interface_b fields to be populated with interface IDs, which are unique but not very intuitive to work with, especially in bulk.

If I understand your request correctly, you're proposing the ability to specify devices and interfaces by name instead — e.g., device_a, interface_a, device_b, interface_b. That definitely makes sense for situations where interface names are only unique per device (which is common), and would greatly improve the usability of the import form.

One thought: to ensure device names are uniquely resolved, this might also require including the site (or site_a / site_b) fields, since device names may not be globally unique across sites.

I also need to take a look at the Cable import form to see how it handles device/interface references — it would make sense for these import mechanisms to be consistent.

This sounds like a good quality-of-life improvement.

[mblumber1]

Thanks. First I want to thank you for providing the fact that I can use interface IDs; with some creative cross-referencing and db lookups, I can make this bulk import work as it is.

I also agree that this import should be consistent across similar types. You mention cable, the other similar data type is circuit; today you can do a bulk import of circuit information (site/equipment/port) using yaml or json but not with CSV. All three of these (cable, circuit, wireless link) should have site_a/b, device_a/b and interface_a/b in their CSV import template. Actually, is there a restriction that cables have to be local to one site (making the site_a/b potentially unnecessary)?

[pheus]

Thanks — I didn’t expect that either, so it definitely feels like something that should either be documented more clearly or ideally changed to allow using names instead of IDs.

Regarding circuits:

I assume you're referring to the CircuitTermination bulk import form, which serves a different purpose than the import forms for Cables and WirelessLinks.

I haven’t used circuits extensively, so I might be missing some nuance, but from my understanding, a circuit defines two circuit terminations (A and Z) of a specific type. If the termination is something other than a provider network, it's possible to reference a CableTermination.

So in that case, the circuit doesn't directly reference devices/interfaces — it goes through the CableTermination.

After looking into the CableImportForm, I’ve noticed that there is only a Device field for Side A and B, but it’s missing the Site field. In addition, the import form does not handle the CircuitTermination case. Since this is clearly out of scope for the current issue, I’d suggest we focus on improving the WirelessLink import form for now.

That said, it might be worth opening a separate feature request to allow importing cables that terminate on a CircuitTermination.

As for cables and site limitations:

No, there's no restriction that both ends of a cable must be within the same site. You can definitely create a cable between devices in different sites — though depending on your use case, it might be helpful to make that relationship more explicit during import (e.g., through site_a / site_b), as you suggested.

[pheus]

I'd like to give this a try. Can I be assigned?
Thanks!