We are a small ISP - How do you manage customer circuits?

[jlon125]

I'm curious if you create these as virtual circuits, or physical circuits.

We assign a vlan per customer, and at least as far as I can tell there's no way to map a regular circuit to a VLAN, you have to connect it to a physical interface.

We could go either way, but if we use physical circuits we would need to add in the entire transport Network and map it out, and even then I'm unsure how you get the circuit mapped to a VLAN, so you can easily see what vlan that circuit is assigned to.

Just looking for some guidance. Thank you!

[simonzsay]

This is an interesting question. I would even expand it to: “What model/logic for documenting cross-connects, both physical and virtual, can generally be considered the closest to the model/logic intended by the NetBox developers?”

In my opinion, both sections — Circuits and Virtual Circuits — are quite strange, both in terms of understanding and everyday use. They definitely force you to make compromises, making an already complex task even more complicated. I spent a lot of time rereading dozens of issues, manuals, videos, and official documentation just to understand how to map the logic of the provider I work for onto NetBox’s logic. At least somehow.

There is a lot that could be said, but I will try to summarize the conclusions I have reached.

Circuits, as I understand it, are some kind of abstract entity that should cover both physical circuits and, to some extent, “virtual” ones, but not those related to VLANs. Perhaps that is why the section is called Circuits rather than Physical Circuits. Everything related to VLANs belongs under Virtual Circuits.

At first, I created point-to-point connections like this:

Device <-> PP <-> Circuit DC A <-> Circuit Provider, e.g. COLT <-> Circuit DC B <-> PP <-> Device

This allowed trace to work. It was very convenient, because I could quickly see the full path from one point to another.

However, I soon realized that NetBox breaks this model when, for example, in DC A I have an NNI port with a provider, and connections from that port go to two other data centers: DC B and DC C. In other words, I would like to see the trace of the transport line, but unfortunately, in some cases I get a split path error instead.

There were many other attempts, but in the end I came to the conclusion that I had to give up tracing the entire route and start using Circuit Groups. I create one group for DC A & DC B, and another group for DC A & DC C. One cross-connect, the one in DC A, is a member of both groups, while the other two cross-connects each belong to their own group.

This way, I can at least divide thousands of cross-connects into groups in table form and trace each small segment separately. At the same time, for me, a provider cross-connect, for example between continents, always looks like this:

Provider Network <-> Circuit Provider, e.g. COLT <-> Provider Network

Later, I plan to add virtual cross-connects to the same groups, because VLANs run on top of this transport. In any case, in my opinion, this method is very inconvenient and requires a large number of actions and extra effort, not to mention training colleagues and creating custom validation for every form.

I have seen examples where people create dummy devices with a large number of ports, acting as a kind of provider device, and connect circuit terminations to those devices instead of the provider network. This at least makes full trace work. But honestly, I am always afraid of forcing my own custom logic onto NetBox, because nobody knows whether the next update will be fatal for everything that was not intended by design. And reworking an already labor-intensive setup is definitely not something I want to do.

It would be great if someone could explain how these sections were actually intended to be used, and what the correct approach is when you have more than 100 data centers around the world and a network that is as complex as it can possibly get.

[exero44]

I do have same issue, can you please advice solution.

[dmitrylomakin]

I'd also be very interested in to see the implementation examples from some of the developers. Unfortunately, the documentation doesn't provide a clear and precise definition of when we should use physical and virtual circuits

[KaricAllegra]

So, not sure if this helps, but is there a reason you couldn't simply add a custom field to your circuit creation that lets you select which VLAN it's on when you are adding a circuit? Here is what it could look like: