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

API call shows termination_z["connected_endpoint"] of null when the connected endpoint exists. #3921

New Issue
Closed
opened 2025-12-29 18:32:05 +01:00 by adam · 5 comments
adam commented 2025-12-29 18:32:05 +01:00
Owner
Copy Link

Originally created by @PhillSimonds on GitHub (Jul 29, 2020).

Environment

  • Python version: 3.7.8
  • NetBox version: 2.8.8

Steps to Reproduce

  1. Create a site ATL01 from NetBox Web UI
  2. Create a site DEN01 from NetBox Web UI
  3. Create a manufacturer "cisco" from NetBox Web UI
  4. Create a device type "csr1000v" with a Manufacturer of cisco. Leave all other values as default
  1. Create a device role of "WAN Router"
  2. Create a Device "ATL-RT01" with manufacturer of "cisco", Device Type of "csr1000v", and site of "ATL01" -- Leave all other settings as default
  3. Create a Device "DEN-RT01" with manufacturer of "cisco", Device Type of "csr1000v", and site of "DEN01" -- leave all other settings default
  4. Add an Interface component to ATL-RT01 with the name "TenGigabitEthernet1/1/1", a Type of "SFP+ (10GE)", and an MTU of 1500.
  5. Repeat step number 8, but for DEN-RT01
  6. Create a circuit Provider named "bogus-provider" with an ASN of "65001" -- leave all other settings as default
  7. Create a Circuit Type called "Private WAN"
  8. Create a circuit with Provider "bogus-provider", Circuit ID "bogus-1", Type "Private WAN", Status "Active", Date Installed "2020-07-29", Commit Rate "10000000", and Description "ATL01 <-> DEN01"
  9. To this bogus-1 circuit, add a Termination - A Side with Site "ATL01", Port speed (Kbps) of "10000000", Upstream speed of "10000000", and all other fields default.
  10. Click "Connect" next to "Termination", and select "Interface" from the drop down.
  11. Under the "B Side" Panel select a Site of "ATL01, a Device of "ATL-RT01", and a Name of "TenGigabitEthernet1/1/1"
  12. Under the "Cable" Panel, select a Status of "Connected", a Type of "Multimode Fiber (OM4), a color of "Cyan", a Length of "1" and "Meters" from the dropdown next to the Length unit field, then click "Connect"
  13. To this bogus-1 circuit, add a Termination - Z Side with Site "DEN01", Port speed (Kbps) of "10000000", Upstream speed of "10000000", and all other fields default.
  14. Click "Connect" next to "Termination" under Termination - Z Side, and select "Interface" from the drop down.
  15. Under the "B Side" Panel select a Site of "DEN01, a Device of "DEN-RT01", and a Name of "TenGigabitEthernet1/1/1"
  16. Under the "Cable" Panel, select a Status of "Connected", a Type of "Multimode Fiber (OM4), a color of "Cyan", a Length of "1" and "Meters" from the dropdown next to the Length unit field, then click "Connect".
  17. Note the URL which contains the cid of the circuit in it's query. For my instance this is http://localhost:8000/circuits/circuits/1/
  18. Insert "/api" before /circuits/circuits in the URL and load the page
  19. Note that the termination_z["connected_endpoint"] key has a value of null.
  20. Depending on creation/deletion order, termination_a["connected_endpoint"] will either show the connected cable or as null. termination_z["connected_endpoint"] persistently shows with a value of null, so I thought it the best way to describe the bug in this report.

Expected Behavior

The UI shows a connected cable on the termination - Z side of the connection. I expected the API to also show this connected endpoint in the structure of a dictionary as the value of termination_z["connected_endpoint"] for the circuit returned from an API call.

Observed Behavior

The value of termination_z["connected_endpoint"] from the API call for the circuit in question has a value of "null" rather than a dictionary describing the connected endpoint.

Screen Shot 2020-07-29 at 12 03 57 PM

Screen Shot 2020-07-29 at 12 03 11 PM

Originally created by @PhillSimonds on GitHub (Jul 29, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for reproducible bugs. If you need assistance with NetBox installation, or if you have a general question, DO NOT open an issue. Instead, post to our mailing list: https://groups.google.com/forum/#!forum/netbox-discuss Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report, and that any plugins have been disabled. --> ### Environment * Python version: 3.7.8 * NetBox version: 2.8.8 <!-- Describe in detail the exact steps that someone else can take to reproduce this bug using the current stable release of NetBox. Begin with the creation of any necessary database objects and call out every operation being performed explicitly. If reporting a bug in the REST API, be sure to reconstruct the raw HTTP request(s) being made: Don't rely on a client library such as pynetbox. --> ### Steps to Reproduce 1. Create a site ATL01 from NetBox Web UI 2. Create a site DEN01 from NetBox Web UI 3. Create a manufacturer "cisco" from NetBox Web UI 4. Create a device type "csr1000v" with a Manufacturer of cisco. Leave all other values as default 5) Create a device role of "WAN Router" 6) Create a Device "ATL-RT01" with manufacturer of "cisco", Device Type of "csr1000v", and site of "ATL01" -- Leave all other settings as default 7) Create a Device "DEN-RT01" with manufacturer of "cisco", Device Type of "csr1000v", and site of "DEN01" -- leave all other settings default 8) Add an Interface component to ATL-RT01 with the name "TenGigabitEthernet1/1/1", a Type of "SFP+ (10GE)", and an MTU of 1500. 9) Repeat step number 8, but for DEN-RT01 10) Create a circuit Provider named "bogus-provider" with an ASN of "65001" -- leave all other settings as default 11) Create a Circuit Type called "Private WAN" 12) Create a circuit with Provider "bogus-provider", Circuit ID "bogus-1", Type "Private WAN", Status "Active", Date Installed "2020-07-29", Commit Rate "10000000", and Description "ATL01 <-> DEN01" 13) To this bogus-1 circuit, add a Termination - A Side with Site "ATL01", Port speed (Kbps) of "10000000", Upstream speed of "10000000", and all other fields default. 14) Click "Connect" next to "Termination", and select "Interface" from the drop down. 15) Under the "B Side" Panel select a Site of "ATL01, a Device of "ATL-RT01", and a Name of "TenGigabitEthernet1/1/1" 16) Under the "Cable" Panel, select a Status of "Connected", a Type of "Multimode Fiber (OM4), a color of "Cyan", a Length of "1" and "Meters" from the dropdown next to the Length unit field, then click "Connect" 17) To this bogus-1 circuit, add a Termination - Z Side with Site "DEN01", Port speed (Kbps) of "10000000", Upstream speed of "10000000", and all other fields default. 18) Click "Connect" next to "Termination" under Termination - Z Side, and select "Interface" from the drop down. 19) Under the "B Side" Panel select a Site of "DEN01, a Device of "DEN-RT01", and a Name of "TenGigabitEthernet1/1/1" 20) Under the "Cable" Panel, select a Status of "Connected", a Type of "Multimode Fiber (OM4), a color of "Cyan", a Length of "1" and "Meters" from the dropdown next to the Length unit field, then click "Connect". 21) Note the URL which contains the cid of the circuit in it's query. For my instance this is `http://localhost:8000/circuits/circuits/1/` 22) Insert "/api" before /circuits/circuits in the URL and load the page 23) Note that the termination_z["connected_endpoint"] key has a value of null. 24) Depending on creation/deletion order, termination_a["connected_endpoint"] will either show the connected cable or as null. termination_z["connected_endpoint"] persistently shows with a value of `null`, so I thought it the best way to describe the bug in this report. <!-- What did you expect to happen? --> ### Expected Behavior The UI shows a connected cable on the termination - Z side of the connection. I expected the API to also show this connected endpoint in the structure of a dictionary as the value of termination_z["connected_endpoint"] for the circuit returned from an API call. <!-- What happened instead? --> ### Observed Behavior The value of termination_z["connected_endpoint"] from the API call for the circuit in question has a value of "null" rather than a dictionary describing the connected endpoint. ![Screen Shot 2020-07-29 at 12 03 57 PM](https://user-images.githubusercontent.com/23535194/88841965-96e1ce80-d193-11ea-8dc5-fed1e804d015.png) ![Screen Shot 2020-07-29 at 12 03 11 PM](https://user-images.githubusercontent.com/23535194/88841910-7b76c380-d193-11ea-8963-b3c01045c4f6.png)
adam added the type: bug label 2025-12-29 18:32:05 +01:00
adam closed this issue 2025-12-29 18:32:05 +01:00
adam commented 2025-12-29 18:32:05 +01:00
Author
Owner
Copy Link

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

Thank you for the thorough bug report! I'm going to use this as an example from now on. 😄

This hits on an issue that I feel like we've been chasing for a long time: When do we consider a circuit part of the path? Here's what's happening:

  1. When termination A is connected to the interface on ATL-RT01, NetBox detects an end-to-end path between that interface and the circuit termination:
           <--------path------->
[ATL-RT01] Te1/1/1 ------ Term A [Circuit]

This is valid in a scenario where a circuit has only one termination defined (e.g. to model an Internet access circuit, where the far end is unknown).

  1. When termination Z is connected to the interface on DEN-RT01, NetBox detects an overlapping path, between both interfaces via the circuit:
           <------------------------path----------------------->
[ATL-RT01] Te1/1/1 ------ Term A [Circuit] Term Z ------ Te1/1/1 [DEN-RT01]

You can confirm this by viewing the interface on ATL-RT01: it shows the opposite interface as its connected endpoint (and vice versa). This is why termination Z doesn't have its connected_endpoint defined. However, termination A erroneously retains its connected_endpoint pointing to the interface on ATL-RT01.

What we end up with is one complete path and one partial path:

           <------------------------path----------------------->
                      ?-------->
[ATL-RT01] Te1/1/1 ------ Term A [Circuit] Term Z ------ Te1/1/1 [DEN-RT01]

So, there are two issues here. First, the one-way end-to-end path above is a bug no matter how you look at it, and needs to be resolved.

The second issue is determining and documenting the expected behavior for this scenario. There are (at least) two choices:

Choice A: Establish two separate paths, each from a circuit termination to its connected interface.

Choice B: Establish a path only across circuit terminations, and never to them. (Essentially, treat them like front/rear pass-through ports.)

I believe this is the root issue for which #4812 was opened (currently a work in progress). #4519 also touches on this issue, though in a different context. All of these will need to be considered in parallel to make a decision.

@jeremystretch commented on GitHub (Jul 30, 2020): Thank you for the thorough bug report! I'm going to use this as an example from now on. :smile: This hits on an issue that I feel like we've been chasing for a long time: When do we consider a circuit part of the path? Here's what's happening: 1. When termination A is connected to the interface on ATL-RT01, NetBox detects an end-to-end path between that interface and the circuit termination: ``` <--------path-------> [ATL-RT01] Te1/1/1 ------ Term A [Circuit] ``` This is valid in a scenario where a circuit has only one termination defined (e.g. to model an Internet access circuit, where the far end is unknown). 2. When termination Z is connected to the interface on DEN-RT01, NetBox detects an overlapping path, between both interfaces _via_ the circuit: ``` <------------------------path-----------------------> [ATL-RT01] Te1/1/1 ------ Term A [Circuit] Term Z ------ Te1/1/1 [DEN-RT01] ``` You can confirm this by viewing the interface on ATL-RT01: it shows the opposite interface as its connected endpoint (and vice versa). This is why termination Z doesn't have its `connected_endpoint` defined. However, termination A erroneously retains its `connected_endpoint` pointing to the interface on ATL-RT01. What we end up with is one complete path and one partial path: ``` <------------------------path-----------------------> ?--------> [ATL-RT01] Te1/1/1 ------ Term A [Circuit] Term Z ------ Te1/1/1 [DEN-RT01] ``` So, there are two issues here. First, the one-way end-to-end path above is a bug no matter how you look at it, and needs to be resolved. The second issue is determining and documenting the expected behavior for this scenario. There are (at least) two choices: **Choice A:** Establish two separate paths, each from a circuit termination to its connected interface. **Choice B:** Establish a path only _across_ circuit terminations, and never to them. (Essentially, treat them like front/rear pass-through ports.) I believe this is the root issue for which #4812 was opened (currently a work in progress). #4519 also touches on this issue, though in a different context. All of these will need to be considered in parallel to make a decision.
adam commented 2025-12-29 18:32:05 +01:00
Author
Owner
Copy Link

@steffann commented on GitHub (Aug 3, 2020):

Choice A isn't currently possible because there may be a rear port with multiple front ports connected to the circuit termination. In that case there may be many interfaces whose path traverses the circuit. The path from the circuit termination can only go as far as the rear port. At that point the paths split.

A possible solution for that scenario is to store the rear port as the connected endpoint for the circuit termination. Something to think about.

@steffann commented on GitHub (Aug 3, 2020): Choice A isn't currently possible because there may be a rear port with multiple front ports connected to the circuit termination. In that case there may be many interfaces whose path traverses the circuit. The path from the circuit termination can only go as far as the rear port. At that point the paths split. A possible solution for that scenario is to store the rear port as the connected endpoint for the circuit termination. Something to think about.
adam commented 2025-12-29 18:32:06 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Sep 17, 2020):

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. Please see our contributing guide.

@stale[bot] commented on GitHub (Sep 17, 2020): 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. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:32:06 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Sep 29, 2020):

Blocked by #4900 (due to be implemented in v2.10)

@jeremystretch commented on GitHub (Sep 29, 2020): Blocked by #4900 (due to be implemented in v2.10)
adam commented 2025-12-29 18:32:06 +01:00
Author
Owner
Copy Link

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

This has been addressed under #4900.

@jeremystretch commented on GitHub (Nov 17, 2020): This has been addressed under #4900.
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 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#3921
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?