Connections via circuits - cable end to end tracing (Brainstorm)

[xkilian]

Reference #5717 Answer provided by Jeremy Stretch: This is expected behavior and is specifically called out in the v2.10 release notes: Circuits are considered endpoints of the cable path. This change was made to fix several bugs which had plagued the cable tracing logic for a long time.

Understanding this, would it be possible to add some logic to identify point-to-point circuits so that these can be handled by the tracing logic. At least this way the original use-case for tracing across point-to-point circuits will become available once more. I agree with Jeremy that it is most important (my interpretation) for Netbox to behave consistently and with integrity.

BUT it does not invalidate the use-case that point-to-point circuits should be handled, even if it requires additional input by the user for it to work correctly, this is a way important feature for installations.

What would be an acceptable means to get this back. Putting a solution hat on!

• Making sure that the circuit ids match up at each end?
• Explicit additional data added to connections? I am not a Netbox expert, but there has to be a clean and concise solution to do this.

Use cases: This is problematic when interfacing with software like GE Smallworld that provide a circuit id for all connections.
Use case: Point-to-point leased circuits, leased black fiber.

[jcralbino]

It could be interesting to create a separate circuit type to address the dark fiber use case . I also have the same scenario where we use dark fibers between sites, and I would be interested in seeing the end to end path terminate in switches and not in the circuit.

[jeremystretch]

BUT it does not invalidate the use-case that point-to-point circuits should be handled

Note that this is an opinionated take. It just as easily argued that circuits should not be followed in a cable trace if undesirable for one's use case.

would it be possible to add some logic to identify point-to-point circuits so that these can be handled by the tracing logic

One of the primary problems with the old implementation was that the tracing logic did not treat circuit terminations consistently: a trace would either follow a circuit termination or not depending on how it was connected at the point in time when the trace was being executed. The v2.10 release fixed this, by ensuring that circuit terminations were always treated as endpoints in a cable path, just like interfaces, etc. (The only cable termination objects which are currently traversed by a trace are front and rear pass-through ports.)

I want to stress that any proposed extension to the current behavior must respect this hard-earned decision: Every object to which a cable may be connected must always be treated either a pass-through node or a termination node, consistently. Any proposal which seeks to compromise this rule is a non-starter.

The problem with treating circuits terminations as pass-through nodes is that any circuit without a far-end termination defined will be considered an incomplete path. For example, say I have an Internet access circuit with an A side termination to a router interface, but no Z side termination because I don't know and/or care about the far end of the circuit. But when viewing interfaces on the router, I want to see that the interface does indeed lead to the circuit.

When the path is traced from the router interface, today NetBox considers this a complete path from the interface to the circuit termination point, so we see the circuit as the endpoint. Altering the logic to consider circuit terminations as pass-through nodes would result in an incomplete path, and the router interface would show as not having a connected endpoint. For this approach to work, there must be something connected to the far end of the circuit.

Currently, either end of a circuit may terminated to one of the following:

1. A device component (or another circuit termination) using a cable
2. A site
3. Nothing

The first case doesn't require much consideration: we can simply treat the circuit as we do a device having ingress and egress pass-through ports.

The second case requires more thought, because the current implementation assumes that a trace will always comprise a list of three-tuples, wherein each tuple is defined as (termination, cable, termination). Following a circuit to a site would result in something like the following:

(
    (interface, cable, front port),
    (rearport, cable, circuit termination),
    (circuit termination, ???, site)
)

Obviously, we cannot connect a circuit termination to a site using a cable, so some solution would need to be devised. This might be supporting the omission of the middle element, or it might be the introduction of some new object to represent an "abstract" link.

Finally, we have to account for the third scenario, wherein there is no far-end circuit termination defined. Because we still want to show the origin point as having a connected endpoint in such case, we would need to "force" the far end connection to some sufficiently representative object. Unrelated discussion around overlay modeling has brought up the idea of a "cloud" object to represent some network unknown to the NetBox user (just as a cloud icon is often used in network topology drawings). It may be reasonable to alter the circuit model to require always specifying both A and Z side terminations, as we do for cables, where one of the terminations could simply be a cloud representing the provider's network or the Internet. However, any such solution must also take care to properly migrate single-ended circuits in existing NetBox installations, which may be nontrivial.

[sdktr]

I do like the circuit to cloud termination idea to close the loop🙂

[jeremystretch]

I like it too, but the migration to get existing installations there might be a little tricky, since open-ended circuits are currently allowed. It might make sense to introduce the "circuit-to-cloud" capability in v2.11, and then make it mandatory to upgrade to v2.12 in the future.

[sdktr]

What are your concerns regarding assigning a 'default cloud' for currently open ended circuits? As a migration in 2.11 for example?

[jeremystretch]

We can't make any assumptions on behalf of the user. For example, it would not make sense for circuits belonging to two different providers' private networks to connect to the same cloud.