starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Bulk cable import does not validate interface types #6503

New Issue
Closed
opened 2025-12-29 19:41:38 +01:00 by adam · 10 comments
adam commented 2025-12-29 19:41:38 +01:00
Owner
Copy Link

Originally created by @klaernie on GitHub (May 23, 2022).

Originally assigned to: @DanSheps on GitHub.

NetBox version

v3.2.3

Python version

3.9

Steps to Reproduce

  1. create device role dummy role
  2. create site demo site
  3. create manufacturer dummy manufacturer
  4. create a device type demo model, using the dummy manufacturer
  5. add an interface template to the demo model device type:
    • name it demo virtual if
    • set the type to Virtual
  6. create two devices using the demo model, thedummy role and the demo site
    • name the first one demo1
    • name the second one demo2
  7. attempt to import the following cable CSV: 
    side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name
demo1,dcim.interface,demo virtual if,demo2,dcim.interface,demo virtual if

Expected Behavior

Either of:

  • The cable gets imported and displayed as usually
  • The import fails with a meaningful error message like Virtual interfaces cannot have a cable attached.

Observed Behavior

The following exception is thrown:

<class 'ValueError'>

'CableCSVForm' has no field named 'termination_a_id'.

Python version: 3.8.10
NetBox version: 3.2.3
Originally created by @klaernie on GitHub (May 23, 2022). Originally assigned to: @DanSheps on GitHub. ### NetBox version v3.2.3 ### Python version 3.9 ### Steps to Reproduce 1. create device role `dummy role` 1. create site `demo site` 1. create manufacturer `dummy manufacturer` 1. create a device type `demo model`, using the `dummy manufacturer` 1. add an interface template to the `demo model` device type: - name it `demo virtual if` - set the type to `Virtual` 1. create two devices using the `demo model`, the`dummy role` and the `demo site` - name the first one `demo1` - name the second one `demo2` 1. attempt to import the following cable CSV: ```csv side_a_device,side_a_type,side_a_name,side_b_device,side_b_type,side_b_name demo1,dcim.interface,demo virtual if,demo2,dcim.interface,demo virtual if ``` ### Expected Behavior Either of: - The cable gets imported and displayed as usually - The import fails with a meaningful error message like ` Virtual interfaces cannot have a cable attached.` ### Observed Behavior The following exception is thrown: ``` <class 'ValueError'> 'CableCSVForm' has no field named 'termination_a_id'. Python version: 3.8.10 NetBox version: 3.2.3 ```
adam added the type: bugstatus: accepted labels 2025-12-29 19:41:38 +01:00
adam closed this issue 2025-12-29 19:41:39 +01:00
adam commented 2025-12-29 19:41:39 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 23, 2022):

This issue was already reported once as #6045, but was missing the concrete reproduction steps.

Additionally I should mention, that as soon as I change the interface type of demo1's demo virtual if interface to other the exception changes to 'CableCSVForm' has no field named 'termination_b_id'.. Following this up with changing the demo virtual if interface on demo2 to other as well leads to a properly imported cable.

@klaernie commented on GitHub (May 23, 2022): This issue was already reported once as #6045, but was missing the concrete reproduction steps. Additionally I should mention, that as soon as I change the interface type of `demo1`'s `demo virtual if` interface to `other` the exception changes to `'CableCSVForm' has no field named 'termination_b_id'.`. Following this up with changing the `demo virtual if` interface on `demo2` to `other` as well leads to a properly imported cable.
adam commented 2025-12-29 19:41:40 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 23, 2022):

Either of:

  • The cable gets imported and displayed as usually
  • The import fails with a meaningful error message like Virtual interfaces cannot have a cable attached.

Virtual interfaces cannot have a cable connected; the second item is correct. The error occurs because the interfaces fields' queryset is being filtered by type to exclude virtual interfaces in the current implementation.

@jeremystretch commented on GitHub (May 23, 2022): > Either of: > * The cable gets imported and displayed as usually > * The import fails with a meaningful error message like Virtual interfaces cannot have a cable attached. Virtual interfaces cannot have a cable connected; the second item is correct. The error occurs because the interfaces fields' queryset is being filtered by type to exclude virtual interfaces in the current implementation.
adam commented 2025-12-29 19:41:40 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 23, 2022):

As I didn't find it yet: where is described, why virtual interfaces cannot be cabled? From my point of view there is merit in having cables between virtual interfaces, for example to clearly document multiple network interfaces belonging to VMs, or to represent hypervisors nested in VMs.

@klaernie commented on GitHub (May 23, 2022): As I didn't find it yet: where is described, why virtual interfaces cannot be cabled? From my point of view there is merit in having cables between virtual interfaces, for example to clearly document multiple network interfaces belonging to VMs, or to represent hypervisors nested in VMs.
adam commented 2025-12-29 19:41:40 +01:00
Author
Owner
Copy Link

@TheNetworkGuy commented on GitHub (May 23, 2022):

Why not model the VM infrastructure with your prefixes and Virtualisation options in Netbox? Cables are a physical (Layer 1) part. VM's are at least application level code.

@TheNetworkGuy commented on GitHub (May 23, 2022): Why not model the VM infrastructure with your prefixes and Virtualisation options in Netbox? Cables are a physical (Layer 1) part. VM's are at least application level code.
adam commented 2025-12-29 19:41:40 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 23, 2022):

Why not model the VM infrastructure with your prefixes and Virtualisation options in Netbox?

VMs cannot be members of virtualization clusters. IP address management is totally separate from managing connections.

Cables are a physical (Layer 1) part.

If you talk about bare metal: yes. But for a virtual machine the "cable" is not made of copper, but it still plugs into a switch, be it a vSwitch in VMware, be it a Linux bridge for libvirt/KVM/Proxmox. But a VM's "cable" can also be directly attached to a hypervisor host's physical interface, by taking the entire control of the NIC away from the hypervisor and handing it to the VM. And lastly you can build entire network environments in software inside of a single host - take a typical virtualized lab environment for testing weird edge cases or non-typical routing.

It all boils down to:
Allows netbox to model reality, or does it prescribe some concepts?

And taking a look at certain design decisions (like for example the possibility to attach a wifi ssid to an 100BASE-TX typed interface on the create screen) I interpret the intentions more as "encourages best practises, but allows to model reality"

@klaernie commented on GitHub (May 23, 2022): > Why not model the VM infrastructure with your prefixes and Virtualisation options in Netbox? VMs cannot be members of virtualization clusters. IP address management is totally separate from managing connections. > Cables are a physical (Layer 1) part. If you talk about bare metal: yes. But for a virtual machine the "cable" is not made of copper, but it still plugs into a switch, be it a vSwitch in VMware, be it a Linux bridge for libvirt/KVM/Proxmox. But a VM's "cable" can also be directly attached to a hypervisor host's physical interface, by taking the entire control of the NIC away from the hypervisor and handing it to the VM. And lastly you can build entire network environments in software inside of a single host - take a typical virtualized lab environment for testing weird edge cases or non-typical routing. It all boils down to: Allows netbox to model reality, or does it prescribe some concepts? And taking a look at certain design decisions (like for example the possibility to attach a wifi ssid to an 100BASE-TX typed interface on the create screen) I interpret the intentions more as "encourages best practises, but allows to model reality"
adam commented 2025-12-29 19:41:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 23, 2022):

@klaernie The cable model in Netbox is used to model physical cables only. This will not change.

@jeremystretch commented on GitHub (May 23, 2022): @klaernie The cable model in Netbox is used to model physical cables only. This will not change.
adam commented 2025-12-29 19:41:41 +01:00
Author
Owner
Copy Link

@klaernie commented on GitHub (May 23, 2022):

@klaernie The cable model in Netbox is used to model physical cables only. This will not change.

Totally fair point. I'll be fine pretending my first virtualization layer exists physically and use the "other" interface type to make my connections able to be modelled.

The only point for opening this issue is to have this constraint clearly communicated to future users, so they don't have to spend an hour figuring it out.

@klaernie commented on GitHub (May 23, 2022): > @klaernie The cable model in Netbox is used to model physical cables only. This will not change. Totally fair point. I'll be fine pretending my first virtualization layer exists physically and use the "other" interface type to make my connections able to be modelled. The only point for opening this issue is to have this constraint clearly communicated to future users, so they don't have to spend an hour figuring it out.
adam commented 2025-12-29 19:41:41 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (May 24, 2022):

I have to agree that virtual interfaces shouldn't be cabled.

For virtual systems, I could see adding a "virtual switch" system where interfaces are attached to virtual switches either on the host(s) they belong to or on the cluster itself. This might be something to consider as a FR. Perhaps open a discussion regarding this as a FR and see if you can gain some traction.

@DanSheps commented on GitHub (May 24, 2022): I have to agree that virtual interfaces shouldn't be cabled. For virtual systems, I could see adding a "virtual switch" system where interfaces are attached to virtual switches either on the host(s) they belong to or on the cluster itself. This might be something to consider as a FR. Perhaps open a discussion regarding this as a FR and see if you can gain some traction.
adam commented 2025-12-29 19:41:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 24, 2022):

Holding off on this until #9102 has been completed

@jeremystretch commented on GitHub (May 24, 2022): Holding off on this until #9102 has been completed
adam commented 2025-12-29 19:41:42 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Sep 2, 2022):

During import, it now looks like this is checked. However, the following exception is generated:

ValueError at /dcim/cables/import/
'CableCSVForm' has no field named 'termination'.
Request Method:	POST
Request URL:	http://127.0.0.1:8000/dcim/cables/import/
Django Version:	4.0.7
Exception Type:	ValueError
Exception Value:	
'CableCSVForm' has no field named 'termination'.
Exception Location:	C:\Development\netbox\venv\lib\site-packages\django\forms\forms.py, line 400, in add_error
Python Executable:	C:\Development\netbox\venv\Scripts\python.exe
Python Version:	3.10.4
Python Path:	
['C:\\Development\\netbox\\netbox\\netbox',
 'C:\\Program Files\\Python\\3.10\\python310.zip',
 'C:\\Program Files\\Python\\3.10\\DLLs',
 'C:\\Program Files\\Python\\3.10\\lib',
 'C:\\Program Files\\Python\\3.10',
 'C:\\Development\\netbox\\venv',
 'C:\\Development\\netbox\\venv\\lib\\site-packages',
 'c:\\development\\netbox\\netbox-routing',
 'c:\\development\\netbox\\netbox-config-backup',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\pydriller-2.1-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\dulwich-0.20.35-py3.10-win-amd64.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\uuid-1.30-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\lizard-1.17.9-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\types_pytz-2021.3.6-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\gitpython-3.1.27-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\gitdb-4.0.9-py3.10.egg',
 'C:\\Development\\netbox\\venv\\lib\\site-packages\\smmap-5.0.0-py3.10.egg',
 'c:\\development\\netbox\\netbox-sync',
 'c:\\development\\netbox\\netbox-secretstore']
Server time:	Fri, 02 Sep 2022 17:30:30 +0000

Going to close this out and opena new issue.

@DanSheps commented on GitHub (Sep 2, 2022): During import, it now looks like this is checked. However, the following exception is generated: ``` ValueError at /dcim/cables/import/ 'CableCSVForm' has no field named 'termination'. Request Method: POST Request URL: http://127.0.0.1:8000/dcim/cables/import/ Django Version: 4.0.7 Exception Type: ValueError Exception Value: 'CableCSVForm' has no field named 'termination'. Exception Location: C:\Development\netbox\venv\lib\site-packages\django\forms\forms.py, line 400, in add_error Python Executable: C:\Development\netbox\venv\Scripts\python.exe Python Version: 3.10.4 Python Path: ['C:\\Development\\netbox\\netbox\\netbox', 'C:\\Program Files\\Python\\3.10\\python310.zip', 'C:\\Program Files\\Python\\3.10\\DLLs', 'C:\\Program Files\\Python\\3.10\\lib', 'C:\\Program Files\\Python\\3.10', 'C:\\Development\\netbox\\venv', 'C:\\Development\\netbox\\venv\\lib\\site-packages', 'c:\\development\\netbox\\netbox-routing', 'c:\\development\\netbox\\netbox-config-backup', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\pydriller-2.1-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\dulwich-0.20.35-py3.10-win-amd64.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\uuid-1.30-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\lizard-1.17.9-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\types_pytz-2021.3.6-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\gitpython-3.1.27-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\gitdb-4.0.9-py3.10.egg', 'C:\\Development\\netbox\\venv\\lib\\site-packages\\smmap-5.0.0-py3.10.egg', 'c:\\development\\netbox\\netbox-sync', 'c:\\development\\netbox\\netbox-secretstore'] Server time: Fri, 02 Sep 2022 17:30:30 +0000 ``` Going to close this out and opena new issue.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label status: accepted type: bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#6503
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?