Mark an interface as connected without connecting it to anything #2981

@kobayashi commented on GitHub (Nov 2, 2019):

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.

@kobayashi commented on GitHub (Nov 2, 2019): 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.

adam commented

@millijuna commented on GitHub (Nov 2, 2019):

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.

@millijuna commented on GitHub (Nov 2, 2019): 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.

adam commented

@DanSheps commented on GitHub (Nov 4, 2019):

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.

@DanSheps commented on GitHub (Nov 4, 2019): > 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.

adam commented

@robweber commented on GitHub (Nov 4, 2019):

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.

@robweber commented on GitHub (Nov 4, 2019): 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.

adam commented

@millijuna commented on GitHub (Nov 8, 2019):

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.

@millijuna commented on GitHub (Nov 8, 2019): > 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.

adam commented

@ljb2of3 commented on GitHub (Nov 8, 2019):

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 commented on GitHub (Nov 8, 2019): > > 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?

adam commented

@ljb2of3 commented on GitHub (Nov 8, 2019):

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?

@ljb2of3 commented on GitHub (Nov 8, 2019): 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?

adam commented

@DanSheps commented on GitHub (Nov 12, 2019):

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.

@DanSheps commented on GitHub (Nov 12, 2019): > 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.

adam commented

@ljb2of3 commented on GitHub (Nov 12, 2019):

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.

@ljb2of3 commented on GitHub (Nov 12, 2019): > > 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.

adam commented

@nomaster commented on GitHub (Dec 24, 2019):

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.

@nomaster commented on GitHub (Dec 24, 2019): 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.

adam commented

@darcynz commented on GitHub (Jan 30, 2020):

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.

@darcynz commented on GitHub (Jan 30, 2020): 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.

adam commented

@bert-heylen commented on GitHub (Apr 2, 2020):

+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.

@bert-heylen commented on GitHub (Apr 2, 2020): +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.

adam commented

@avermeer-tc commented on GitHub (May 25, 2020):

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.

@avermeer-tc commented on GitHub (May 25, 2020): 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.

adam commented

@yarnocobussen commented on GitHub (May 25, 2020):

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.

@yarnocobussen commented on GitHub (May 25, 2020): > 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.

adam commented

@jeremystretch commented on GitHub (Jul 24, 2020):

This might be related to #4900 but probably not.

@jeremystretch commented on GitHub (Jul 24, 2020): This _might_ be related to #4900 but probably not.

adam commented

@jeremystretch commented on GitHub (Nov 18, 2020):

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 commented on GitHub (Nov 18, 2020): 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.

adam commented