Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
PhillSimonds opened this issue Jul 29, 2020 · 5 comments
Labels
type: bug A confirmed report of unexpected behavior in the application

Comments

@PhillSimonds
Copy link

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

@jeremystretch
Copy link
Member

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 jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation type: bug A confirmed report of unexpected behavior in the application labels Jul 29, 2020
@steffann
Copy link
Contributor

steffann commented 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.

wmfgerrit pushed a commit to wikimedia/operations-software-homer-deploy that referenced this issue Aug 13, 2020
Hopefully temporary until upstream issues are fixed

see also:
netbox-community/netbox#4812
netbox-community/netbox#4925

Change-Id: I4e5d7d0fcbee3f71e500880c0cfbfc12efe4992a
@stale
Copy link

stale bot commented 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 stale bot added the pending closure Requires immediate attention to avoid being closed for inactivity label Sep 17, 2020
@jeremystretch jeremystretch added status: blocked Another issue or external requirement is preventing implementation and removed pending closure Requires immediate attention to avoid being closed for inactivity status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Sep 29, 2020
@jeremystretch
Copy link
Member

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

@jeremystretch
Copy link
Member

This has been addressed under #4900.

@jeremystretch jeremystretch removed the status: blocked Another issue or external requirement is preventing implementation label Nov 17, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 16, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

No branches or pull requests

3 participants