Add ability to connect "virtual" interfaces

[ggidofalvy-tc]

Environment

• Python version: 3.7.3
• Nautobot version: 1.0.0b2

Proposed Functionality

I'd like to propose relaxing the current requirements on connecting two interfaces within Nautobot, allowing connecting two virtual interfaces to each other.

Currently, this can be achieved with this one-line diff, we haven't experienced any negative side-effects after we applied this patch (we've tested this in NetBox, up to version 2.9.0).

diff --git a/nautobot/dcim/constants.py b/nautobot/dcim/constants.py
index dce0b060..a6af02a0 100644
--- a/nautobot/dcim/constants.py
+++ b/nautobot/dcim/constants.py
@@ -41,7 +41,7 @@ WIRELESS_IFACE_TYPES = [
     InterfaceTypeChoices.TYPE_80211AD,
 ]

-NONCONNECTABLE_IFACE_TYPES = VIRTUAL_IFACE_TYPES + WIRELESS_IFACE_TYPES
+NONCONNECTABLE_IFACE_TYPES = WIRELESS_IFACE_TYPES


 #

Just thinking a bit ahead here, but I'd also like to throw in the suggestion to abstract connections away from cables to simply be what they are, connections, and to, at some point, support point-to-multipoint (or 1-to-N, perhaps N-to-N) connections. Please let me know if I should create a separate issue for the discussion on this.

Use Case

This would enable connecting logical interfaces to each other, which would help in modelling different services, such as logical tunnels (thinking GRE, IPsec), pseudowires, etc. Additionally, having the ability to connect two LAG interfaces would also help in modelling logical connectivity between devices.

Database Changes

No database changes required, this can be modelled as a regular connection/cable (perhaps the addition of a 'virtual'/'logical' cable type, or further abstracting 'cables' away).

External Dependencies

None.

[jathanism]

Thanks for the suggestion @ggidofalvy-tc.

At a glance this seems like a logical change, but we also have to consider deliberately augmenting the automated testing if we were to do this. This vibes with some other conversations that have been ongoing about modeling logical circuits (like IPSec as you mentioned).

Just thinking a bit ahead here, but I'd also like to throw in the suggestion to abstract connections away from cables to simply be what they are, connections, and to, at some point, support point-to-multipoint (or 1-to-N, perhaps N-to-N) connections. Please let me know if I should create a separate issue for the discussion on this.

You stated you've tested on NetBox 2.9.0, and Nautobot was forked from NetBox 2.10.4. There was a massive overhaul of the cable and path tracing in NetBox 2.10 that addressed pretty much all of your suggestions, and so that's the data model we have in Nautobot. I think it would be good for you to start there before we ventured into any discussions on what to change.

So my suggestion would be

• Upgrade a copy of your NetBox 2.9.0 instance to NetBox 2.10 and compare your notes against the current cable path modeling
• Create a new test instance of Nautobot 1.0.0b3 and compare the functionality

We just dropped Nautobot 1.0.0b3 yesterday that includes a ton of updates, but you'll need to use our nautobot-netbox-importer plugin to migrate anything from NetBox 2.10.x over to Nautobot 1.0.0b3.

[ggidofalvy-tc]

For now, I'd like to keep the topic on easy pickings, that is, enabling virtual interfaces and LAGs to be logically connected in Nautobot. Perhaps my other suggestion should be a separate issue.

I've applied the patch to NetBox v2.10.5 and to the latest commit on the develop branch of Nautobot (c96b3d0); I could create connections between circuits in both, haven't experienced any issues in either. Furthermore, I was able to import the data with connected virtual interfaces from NetBox via the importer plugin after I applied the patch to Nautobot.

[jathanism]

Circling back to this, I wanted to reiterate that this is a great idea, but it's also not as easy as just removing VIRTUAL_IFACE_TYPES from the list of NONCONNECTABLE_IFACE_TYPES, because that opens the door to connect virtual interfaces to any other interface type, and it is overloading the use of models designed for physical objects (like cables and circuits).

As I mentioned, we've had ongoing discussions about how to model logical objects like virtual/tunnel interfaces, pseudo-cables, and tunnels, but have not yet gotten to that.

As for easy pickings, if we were to add some guardrails around asserting that only virtual interfaces can connect to virtual interfaces, this would be acceptable, but it's not something we can commit to right now.