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

[PhillSimonds]

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

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.

[jeremystretch]

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).

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.

[steffann]

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.

[stale[bot]]

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.

[jeremystretch]

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

[jeremystretch]

This has been addressed under #4900.