search

netbox-community / netbox

The premier source of truth powering network automation. Open source under Apache 2. Try NetBox Cloud free: https://netboxlabs.com/free-netbox-cloud/
http://netboxlabs.com/oss/netbox/
Apache License 2.0
16.01k stars 2.57k forks source link

Expand the maximum length of Cable #5806

Closed proudbro closed 3 years ago

proudbro commented 3 years ago

Environment

Proposed Functionality

We are faced with the limitation of the cable length for any unit (meters, inches etc) The maximum length is 32767. And that's not enough for some of our cables.

Use Case

We are planning to add and store trunk (magistral) fiber cables to Netbox between optical patchpanes in datacenters.

Database Changes

Change field type

External Dependencies

jeremystretch commented 3 years ago

The maximum length is 32767. And that's not enough for some of our cables.

You have cables longer than 32 kilometers? It sounds like you're using cables to represent circuits.

proudbro commented 3 years ago

@jeremystretch, we have optical patch panels between sites (server rooms are located in different cities) which connected directly by fiber cables to each other. I thought the right way to model that connection is to create cable which connected each rear port combining all front ports on every single patch panel. Why it should be circuit? Or it should and I just misunderstood the sense of circuit?

DanSheps commented 3 years ago

Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size.

I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

xkilian commented 3 years ago

This is a valid use-case, think of all the gas, hydro, electrical, mining, public transit, transport and other utilities that have their own WAN or MAN using black fiber networks. They have right of way, so it makes sense for them to run black fiber all over the place, same for being present in places with no fiber to be leased. Sure long runs using 40 or 80KM optics are not common, but they are there.

xkilian commented 3 years ago

Maybe having an intelligent field that can recognize that the length is either in meters or kilometers might be interesting here?

TheNetworkGuy commented 3 years ago

I mean technically you are right. But how niche would this feature be? How many telco providers will use Netbox to:

  1. Document their infrastructure
  2. Use cables longer than 32 kilometers
  3. Actually document the length of those cables in the "length" field in Netbox

In our case we do rely on (ring) circuits which extend over a long distance (far more than 32KM.) But even those circuits are managed by a 3rd party who provides a circuit ID etc.

proudbro commented 3 years ago

@DanSheps , yes, we have our own 60km fiber bulk cables between datacenters and there are not provaded by ISP or any other third party companies. It's easier to represent it as Cable (we have custom field "Magistral" to emphasize importance) between two rear ports that had been created for optical patch panels.

jeremystretch commented 3 years ago

it would be better to, IMO, allow representation in KMs instead of increasing the field size

Agreed, although we also need to consider the absolute length value, which is calculated and stored behind the scenes for ordering.

vk5tu commented 3 years ago

My experience with fiber plant suggests that meters is the correct unit; as that the unit everything else reports (cableloggers, OTDRs, etc). The longest fiber run you're likely to see is around 300Km, but we still want to track that in meters as then a rackmounted OTDR can compare the fiber's current distance against the installed distance recorded in Netbox. For these very long runs a fault near one of the two ends is more likely than a midspan fault, and storing the length in kilometers will disguise faults in the final 500m or so.

jeremystretch commented 3 years ago

It seems that the outstanding question is how best to model a long-distance fiber run (one which spans many kilometers): Is it a cable, or a circuit? The answer seems to determine whether we implement this change or #6122.

Having given this some consideration, I think it's most appropriate to treat these runs as cables, since ultimately that's exactly what they are: very long cables. I see this as distinct from a circuit, which can comprise multiple cables and devices unknown and unimportant to the NetBox user; a circuit is a more abstract end-to-end physical connection between two points.

proudbro commented 3 years ago

@jeremystretch , Yes, that's right. It is easier to model these sections with cables. After all a circuit also requires cables to be connected at both points of connection to devices.

julianze commented 3 years ago

i would like the see those "long-distance fiber´s" as curcuits.

I see the difference between just "cables" and "circuits" in the way who is providing those paths.

Long cables between two buildings on one campus, i would define this as "cable". the ownership of those cables are mostly the company itself, which place an order for road construction or civil engineering companies to lay the cable in the ground.

Circuits which are provided through an external party should be defined as circuit, so you can model the "Provider" with all it´s useful attributes (noc, admin contact, account number) and the circuit itself has required attributes (id, contract number, install date). Okay "commit rate" wouldn´t be required for a physical fiber because it depends on the optics. Those cable´s are paid on a monthly/yearly fee.

We as a german internet service provider buying long-distance fibers from municipal utilities (sorry, i don´t know how "Stadtwerke" are called correctly outside germany), local or global fiber carrier. Some of them are for our backbone to connect network nodes, Partly they are used for connecting customer locations to the next network nodes.

When i model those circuits as cables, i lost the information of the provider an the above described attribtues of an circuit.

But i a agree, that especially those long-distance fiber´s are an special type of circuits, which is very similar to just cables.

@jeremystretch, we have optical patch panels between sites (server rooms are located in different cities) which connected directly by fiber cables to each other. I thought the right way to model that connection is to create cable which connected each rear port combining all front ports on every single patch panel. Why it should be circuit? Or it should and I just misunderstood the sense of circuit?

@proudbro are the cables between the different cities in you ownership or are there laid and provided through a company / ISP / carrier? I think you model this in your use case as cables to have a valid length of the end-to-end path between the patch panels, right?

see also the question from @DanSheps :

Is the direct connect provided by you? Is it provided by a ISP? If it is from a ISP, then you should be using "circuit". If it is your own fiber that you have installed between these two datacenters (unlikely), then perhaps this might be a valid case, however it would be better to, IMO, allow representation in KMs instead of increasing the field size.

I am guessing, but I suspect your use case is you purchased fiber from someone, in which case this should be modelled as a patch going to a circuit.

proudbro commented 3 years ago

@julianze , we have our own cables in use between two cities which roughly 40000 meters long. These optical bulk cables between fiber crosses (optical patch panels) we use ourselves for our purposes and provide individual fibers (dark fiber) to our customers. I've planned to model it as Cables but came across the lengh limitation.

At the same time we rent several wavelengths from an uplink provider between other cities (more than 800000m including many intermediate nodes like amplifiers). It is more correct to model as circuits.

jeremystretch commented 3 years ago

IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable?

If so, this means we:

  1. Support longer lengths for cables
  2. Don't add a length attribute to the Circuit model
BarbarossaTM commented 3 years ago

IMO if you own and operate the fiber itself, you care about the length and should model it as a cable. If not, meaning a provider is responsible for it, you don't care about the length (or the physical path in general), and should model it as a circuit. Does that sound reasonable?

I would argue that when you rent a dark fiber (so not your own physical cable) a circuit would fit better as it has the provider relationship already in place. But as it is a darf fiber knowing the length still is necessary to chose the correct optics/WDM equipment etc. This obviously would mean both length fields are required, which would provide more flexibilty, too.

xkilian commented 3 years ago

As a MAN private entity, we have all three cases, and length should be provided for dark fiber runs that are rented "cables", as stated by BarbarossaTM it helps choose the right optics. The length attribute for circuits should be optional. As 90% of cases do not need it, but dark fiber runs do need it. And I agree with wholelly owned long fiber be modelled as cables.

julianze commented 3 years ago

i think both scenarios are valid and exists out there, So i am in favor implementing both.

May i can volunteer for #6122, but it would be my first time in developing with netbox and will probably need some support.

jeremystretch commented 3 years ago

Reading through this again, it seems that adding kilometer and mile as length units would suffice to address the cited use cases. And #6154 would allow partial units (e.g. 7.25 km). If agreed, we can tag this for v2.12.