Mark an interface as connected without connecting it to anything

[millijuna]

Environment

• Python version: 3.7.3
• NetBox version: 2.6.6

Proposed Functionality

It would be very useful to me if I could mark interfaces as "Connected" and have them show as such, including both the text and the interface colour, without actually connecting them to anything.

Use Case

The main use case here is on access switches, where the device at the other end of the wire is beyond the scope of the networking team. It would be great if we could put in an interface description (for example "Accounting Office J12" and simply mark the interface as connected.

In our environment, this description would then match the description found on the interface in the switch configuration itself. These are just access ports, nothing more.

There are workarounds that can be done (creating a patch panel with interfaces and connecting to that) but that seems hacky, and not as clean as simply being able to mark an interface as "connected"

Database Changes

Unknown, but may require changes to permit an interface showing as connected with a null link to a cable.

External Dependencies

None.

[ljb2of3]

I'd find this one useful! I'd love to be able to track what switch ports are connected in our IDFs where we don't keep track of anything beyond the patch panel.

[kobayashi]

Thank you for this issue.
I understand your situation because I have same issue. However, connection state should be 'connected' when connecting 2 ports between devices which are registered in netbox IMO.
As my workaround, I am adding 'unmanaged devices/ports' which are managed by others in netbox, then connect from my side to them. I hope this may be a solution for you.

[millijuna]

I’d respectfully disagree with that... the very fact that you’re creating unmanaged devices/ports in your database means that you are tracking/creating/working on them.

If you’re just putting them in there and not looking after them, that means you’re polluting the database with all sorts of devices that don’t actually exist (or at least aren’t representative). For something that’s supposed to be a “source of truth”, filling it with bogus information seems like a bad idea. I mean, I could just create my patch panels with interfaces rather than front/rear ports, and satisfy things, but then my system is containing bogus data just to make things look pretty.

IMHO, being able to simply pick “unmanaged device” or something without creating the requisite cable/model/device would be the best option.

[DanSheps]

The main use case here is on access switches, where the device at the other end of the wire is beyond the scope of the networking team.

You should have your switch connected to a patch panel or some other termination using front/rear ports. This will result in a "proper" connection state on the switch, but the termination front/rear port just won't be connected to anything, which would be valid.

For something that’s supposed to be a “source of truth”, filling it with bogus information seems like a bad idea.

It would be an even bigger faux pas in my opinion, to have it connected but not at least try and describe the connection. There will always be a cable. It also isn't that the information is bogus, it is that it is outside of the scope of the team. You could create a unnamed device and say "Desktop Device" and that would be completely accurate.

As an example, in our own instance for access layer switches we are doing the following:

Switch <> Panel Front Port // Panel Rear Port <> Termination Rear Port // Termination Front Port

Switch to Panel Front Port is connected, Panel Rear Port to Termination Rear Port is connected, Termination Front Port is out of scope (normally) and is left as-is. This also gives you a cable trace up to the device that should be plugged in.

[robweber]

I'm mirroring the setup you describe (using front/rear termination points) but it still seems like not the best solution to me. I concur it would be nice if there was some option on the far end of a connection to flag it as connected to "something" that was unmanaged; be it desktop, IP phone, etc. This would complete the connection path and allow it to be shown as connected.

The situation you describe allows for a good cable trace but makes Netbox think the connection is still unfinished. I'm curious what others are doing in this area. I tried using patch panels with interfaces instead of front/rear ports for a while and didn't like that either. Seemed hacky. This is my one big issue when trying to mirror the physical layout of my datacenter, trying to illustrate connections beyond the datacenter that are in fact connected but not managed through a solution like this. For devices all connected within the purview of Netbox the connection status and tracing work flawless.

[millijuna]

I'm mirroring the setup you describe (using front/rear termination points) but it still seems like not the best solution to me. I concur it would be nice if there was some option on the far end of a connection to flag it as connected to "something" that was unmanaged; be it desktop, IP phone, etc. This would complete the connection path and allow it to be shown as connected.

I’ve continued my usual updating and population of netbox, and realized that Netbox already supports a subset of this... When you create a virtual device (Loopback interface, VLAN interface, etc...) they automatically show up as connected, which makes sense (heck, that’s the whole point of virtual interfaces such as loopbacks, they’re always up). To me, that makes for a decent precedent that there are connected interfaces that do not have an associated cable connection.

[ljb2of3]

The main use case here is on access switches, where the device at the other end of the wire is beyond the scope of the networking team.

You should have your switch connected to a patch panel or some other termination using front/rear ports. This will result in a "proper" connection state on the switch, but the termination front/rear port just won't be connected to anything, which would be valid.

For something that’s supposed to be a “source of truth”, filling it with bogus information seems like a bad idea.

It would be an even bigger faux pas in my opinion, to have it connected but not at least try and describe the connection. There will always be a cable. It also isn't that the information is bogus, it is that it is outside of the scope of the team. You could create a unnamed device and say "Desktop Device" and that would be completely accurate.

As an example, in our own instance for access layer switches we are doing the following:

Switch <> Panel Front Port // Panel Rear Port <> Termination Rear Port // Termination Front Port

Switch to Panel Front Port is connected, Panel Rear Port to Termination Rear Port is connected, Termination Front Port is out of scope (normally) and is left as-is. This also gives you a cable trace up to the device that should be plugged in.

After thinking about it, I agree. We should be tracking switch to patch panel connections, even if that panel represents some far off offices and we don't connect the Rear Ports on that panel to anything.

Of course, this means a lot of work creating all the front/rear interfaces for all of our hundreds of access layer patch panels, and the work of actually "connecting" the cables, which is a very time-consuming process. Wasn't there some sort of bulk connect option? Or am I crazy?

[ljb2of3]

This probably belongs in a new issue, but on the note of "connected via a cable" but not "connected to anything on the far end". Netbox is showing the port in green to represent something plugged in, but still says "not connected".

In this case, perhaps it would be useful to say "Incomplete connection" instead, and maybe have mouseover text that tells you what patch panel and port the local cable is connected to. I don't mind clicking the trace cable button to see the entire path, but a quick way to see the first hop without reloading the page would be nice.

The interface is too cluttered to add that information as visible by default, but a mouseover or hover text feature would be nice. What are your thoughts?

[DanSheps]

Of course, this means a lot of work creating all the front/rear interfaces for all of our hundreds of access layer patch panels, and the work of actually "connecting" the cables, which is a very time-consuming process. Wasn't there some sort of bulk connect option? Or am I crazy?

Just to note, I was able to write up a crude script to automate the creation, connection of a patch panel for my own work. Once I refine it, it might upload it to a repo.

This can be done within Netbox, using the "scripts" feature.

[ljb2of3]

Of course, this means a lot of work creating all the front/rear interfaces for all of our hundreds of access layer patch panels, and the work of actually "connecting" the cables, which is a very time-consuming process. Wasn't there some sort of bulk connect option? Or am I crazy?

Just to note, I was able to write up a crude script to automate the creation, connection of a patch panel for my own work. Once I refine it, it might upload it to a repo.

This can be done within Netbox, using the "scripts" feature.

Interesting. I'll have to look into the scripts feature. I ended up creating a standalone flask application to aid me in mapping ports between switches and patch panels in bulk. I posted it over at https://gitlab.com/landy/port-mapper if anyone is interested in using it.

[nomaster]

I'm currently involved with creating a network for an event, where the proposed feature could also be useful.

We place access switches in public areas, with some of them using another access switch as uplink (trunk interfaces). The interfaces are otherwise free to use by the visitors. Obviously, these two configurations are different.

When planning a connection to serve as an uplink from one access switch to another, the view on NetBox presents the user with a drop-down list of available interfaces on the other switch - regardless of its connection. The user will likely use any of these interfaces for the trunk connection.

We would like to mark these interfaces as "unmanaged connected", i.e. without a specific device. With a feature like this, we could simply say that all interfaces in connected state are reserved for access and all others available for trunks.

[darcynz]

2nd this FR. We have many ports connected that we do not manage as the network team. Whilst we. could create devices and interfaces for each, we don't manage these so wont know the relevant information other than something generic. We thought about using circuits as a substitute but the suggestion here would be a much better fit.

[bert-heylen]

+1 for this request. We have many devices out of our scope using our fiber plant. It would be very helpful if we could just mark patch panel ports as "in use" without actually connecting it. We already use the description field to provide some info.

The similar functionality could be used to mark ports as "reserved" for future projects, to make sure nobody uses the port in the meantime.

[avermeer-tc]

I've actually fixed this in the past by creating a Circuit and connecting the A side to the port that is in use.

That way it shows up as connected.

[yarnocobussen]

I've actually fixed this in the past by creating a Circuit and connecting the A side to the port that is in use.

That way it shows up as connected.

Not to go to far off-topic, but for any colocation providers out there: combine this hack with assigning tenants to circuits, and you can track which tenant uses which interface on your fan-out switches, without relying on outside data or customizations to Netbox.

We did this after #3059 got rejected and it's easy to consume this information for things like monitoring and billing automation.

[jeremystretch]

This might be related to #4900 but probably not.

[jeremystretch]

For context, this is likely going to be limited to an occupied boolean (or something to that effect) on the interface model, and possibly others.

[jeremystretch]

I ended up naming the boolean field mark_connected as it was the best name I could think of. I've also included a read-only boolean field in the REST API serializers named _occupied to indicate whether a termination is available to connect a new cable.