Description
Deployment Type
Self-hosted
NetBox Version
v3.7.3
Python Version
3.11
Steps to Reproduce
I only was able to identify issue #14200, #14137 (closed/rejected) as a similar problem.
The following steps are made for a clean empty netbox installation.
Initial setup
-
Create a manufacturer (HPE in this case).
-
Create a device type for that one. (ProLiant DL360 Gen11 in this case).
-
Create a device/VM role (Server in this case).
-
Create a site (DC1).
-
Create 2 Servers with that role, site and type. (server001, server002).
-
Assign an interface (eth0 in this case) to both servers.
Create a cable between both
{
"a_terminations": [
{
"object_type": "dcim.interface",
"object_id": 1
}
],
"b_terminations": [
{
"object_type": "dcim.interface",
"object_id": 2
}
],
"status": "connected"
}
curl -X 'POST' \
'http://127.0.0.1:8000/api/dcim/cables/' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"a_terminations": [
{
"object_type": "dcim.interface",
"object_id": 1
}
],
"b_terminations": [
{
"object_type": "dcim.interface",
"object_id": 2
}
],
"status": "connected"
}'
After this POST the interfaces are cabled and you can see the connection and link peers. 2 Terminations with the IDs (1,2) exist after this.
Add more interfaces to servers and change the cable in the GUI.
The old termination is deleted, replaced with a new one, the connection is updated and you can trace the cable.
Now over the API, Delete termination B
- There is a similar issue from december: Path Status "Not Reachable" after edit cable terminaison by API #14137 (got closed, though)
- The person there updated the termination by patching the cable over
api/dcim/cables
. - Both the changelog screenshot from above and @jeremystretch ´s comment show that the correct way is to delete the termination and create a new one.
- So delete the termination for cable 1 (server002 -> eth1) with a DELETE to
/api/dcim/cable-terminations/3/
curl -X 'DELETE' 'http://127.0.0.1:8000/api/dcim/cable-terminations/3/'
Create a new B termination for server002 -> eth0
post data
{
"cable": 1,
"cable_end": "B",
"termination_type": "dcim.interface",
"termination_id": 2
}
curl -X 'POST' \
'http://127.0.0.1:8000/api/dcim/cable-terminations/' \
-H 'accept: application/json' \
-H 'Content-Type: application/json' \
-d '{
"cable": 1,
"cable_end": "B",
"termination_type": "dcim.interface",
"termination_id": 2
}'
Cable and terminations have correct data (Skip this... issue after this one :) )
Data for both terminations and the cable looks correct.... nothing special.
{
"count": 2,
"next": null,
"previous": null,
"results": [
{
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/cable-terminations/1/",
"display": "Cable #1 to eth0",
"cable": 1,
"cable_end": "A",
"termination_type": "dcim.interface",
"termination_id": 1,
"termination": {
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/interfaces/1/",
"display": "eth0",
"device": {
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/devices/1/",
"display": "server001",
"name": "server001"
},
"name": "eth0",
"cable": 1,
"_occupied": true
},
"created": "2024-03-09T18:12:52.063515Z",
"last_updated": "2024-03-09T18:12:52.063527Z"
},
{
"id": 4,
"url": "http://127.0.0.1:8000/api/dcim/cable-terminations/4/",
"display": "Cable #1 to eth0",
"cable": 1,
"cable_end": "B",
"termination_type": "dcim.interface",
"termination_id": 2,
"termination": {
"id": 2,
"url": "http://127.0.0.1:8000/api/dcim/interfaces/2/",
"display": "eth0",
"device": {
"id": 2,
"url": "http://127.0.0.1:8000/api/dcim/devices/2/",
"display": "server002",
"name": "server002"
},
"name": "eth0",
"cable": 1,
"_occupied": true
},
"created": "2024-03-09T18:33:25.250711Z",
"last_updated": "2024-03-09T18:33:25.250729Z"
}
]
}
{
"count": 1,
"next": null,
"previous": null,
"results": [
{
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/cables/1/",
"display": "#1",
"type": "",
"a_terminations": [
{
"object_type": "dcim.interface",
"object_id": 1,
"object": {
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/interfaces/1/",
"display": "eth0",
"device": {
"id": 1,
"url": "http://127.0.0.1:8000/api/dcim/devices/1/",
"display": "server001",
"name": "server001"
},
"name": "eth0",
"cable": 1,
"_occupied": true
}
}
],
"b_terminations": [
{
"object_type": "dcim.interface",
"object_id": 2,
"object": {
"id": 2,
"url": "http://127.0.0.1:8000/api/dcim/interfaces/2/",
"display": "eth0",
"device": {
"id": 2,
"url": "http://127.0.0.1:8000/api/dcim/devices/2/",
"display": "server002",
"name": "server002"
},
"name": "eth0",
"cable": 1,
"_occupied": true
}
}
],
"status": {
"value": "connected",
"label": "Connected"
},
"tenant": null,
"label": "",
"color": "",
"length": null,
"length_unit": null,
"description": "",
"comments": "",
"tags": [],
"custom_fields": {},
"created": "2024-03-09T18:12:52.049438Z",
"last_updated": "2024-03-09T18:19:21.528022Z"
}
]
}
Connection is missing
However, in the server -> interfaces view, the connection is not listed anymore.
And you can no longer trace the cable.
Tracing over the API is also not possible at this point.
Summary
Correct me if I did smth wrong... But GUI actions cause the same actions and you suggested in #14200 to do it like this. Is this the correct way for updating cables?
Expected Behavior
- A cable should have a connection after deleting/creating its terminations over the API. (See the description from above.)
Observed Behavior
- After deleting and creating a new termination for a cable, it does not have a connection anymore.
Both terminations are interfaces. Furthermore, you cannot trace the path anymore.
Activity
Hedius commentedon Mar 9, 2024
Correction, ignore the edit exception part. Duplicate to: #11460
Removed it from the report.
I actually meant to reference #14137 before.
jeffgdotorg commentedon Apr 1, 2024
Thank you for opening a bug report and for taking the time to provide detailed steps to reproduce on a pristine system.
I was unable to reproduce the reported behavior on NetBox v3.7.4. Maybe this means we fixed the problem you're reporting in the course of doing other work. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary.
Hedius commentedon Apr 1, 2024
Hi, thank you for your answer and for looking into it. I will redo my script on stable later this week.
Hedius commentedon Apr 6, 2024
Hello I performed the same steps on NetBox 3.7,5 and I have the same issue again.
I took a cable. Deleted 1 termination over the API, created a new one and ended up with a cable without a connection as described above...
The cable exists with both terminations, but http://127.0.0.1:8000/dcim/interface-connections/ does not show any connections.
The cable path only contains the A-Termination and the cable. The B-Termination is missing.
What I did is:
I looked at the signals of dcim for CablePaths and updates are triggered in different cases (dcim/signals.py):
So from that posting a cable termination to
/api/cable-terminations
will never trigger an update of a cable path. (Therefore, no path in the table.... Also verified that the logic does not get triggered with break points.)Different take. (While in the referenced issue it was said that deleting/creating new cable terminations is the correct way, I gonna try now updating the cable directly with a PATCH to /api/dcim/cables/x/, because updating a termination cannot trigger the trace_path signal?
Before me changing the endpoints the path is documented correctly after creating the cable:
Updated cable the B termination of cable 3 from interface 2 to 3 with a PATCH to /api/dcim/cables/3/
Data:
This clearly seems to be incorrect though:
It does update the terminations now and a Path from A to B is created.
The B-Termination is updated correctly, but old B-Termination shows now 2 paths. (Instead of the new one showing one only to the A-Temrination)
I am lost now...
@jeffgdotorg Can you please explain how you updated the termination over the API? Did you update the cable or did you delete/create the terminations?
Hedius commentedon Apr 6, 2024
For reference: https://github.com/netbox-community/netbox/blob/develop/netbox/dcim/signals.py#L75 is the cable path logic, but I can only see it getting triggered if you use /api/dcim/cables
Jeremy made clear that you should not do this: #14137 (comment)
But posting a termination cannot trigger the trace_path logic. It is only triggered at
netbox/netbox/dcim/models/cables.py
Line 240 in b7668fb
Correct me please if I am wrong here.
I have had the idea to open a PR and insert sending the trace_path signal in the cable termination save method, but this seems incorrect, because then trace paths would be triggered several times per cable modification/creation
2 remaining items
bsampaio commentedon Aug 14, 2024
Hi!
I'm really looking forward to that fix. Thanks @arthanson for the effort.
I'm currently facing the same issue.
github-actions commentedon Apr 24, 2025
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.
#15390 add trace signal if cable terminatiions changed
#15390 add trace signal if cable terminatiions changed
#15390 add trace signal if cable terminatiions changed