How-to: OSP with NetBox

[DanSheps]

Hey all,

I just wanted to share my experiences modelling our OSP in hopes of helping someone else.

First, we use FOSC 400D5, Panduit FC29N-24-10U, and a mix of loose fiber and ribbon (with MPO-12 on one end).

This will mainly focus on the FOSC models.

i started with a FOSC device type, with 5 module bays. Then I created a module type (FOSC-ACC-D-TRAY-36) with 2 rear port and 72 front ports. Both a A and a B side.

I quickly realized 1 rear port would not work and adjusted to 6 rear ports, 12 positions each. As there are sometimes split 12 counts between various trays.

After a little more trial and error, I broke out the A and B sides to separate modules (using a position of "T#-A"). This proved to work in most instances however there were still some corner cases. After trying a few more iterations, I finally settled on 2 module types with 1 module per tray splice group (12 fibers).

• FOSC-ACC-D-TRAY-36 12x1
• FOSC-ACC-D-TRAY-36 12x2

An additional type of "FOSC-ACC-D-TRAY-36 12x12" could be added.

For the device type, the module bay creation string I used is:

T[1-6]-SG[1-3]-[A-B]

This would generate 36 module bays, 18 for both the A and B side. I would slot a tray in each bay. This proved to allow the most flexible deployment.

You basically splice all front-ports 1:1 as the "fusion splice" and then your rear ports are your cables.

All of this is to say that while this works for me, it might not work for everyone but I figured it might save a bunch of time for someone who might have a similar situation.

I have a script to connect all front ports on each device which I will upload tomorrow.

I would love to see what everyone else does.

[DanSheps]

Export to CSV for OSP:

Location,Label A,Buffer Color,Strand Color,Splice Identifier,Status,Strand Color,Buffer Color,Label B
{% for cable in queryset %}{% if cable.a_terminations[0].device == cable.b_terminations[0].device %}{{cable.a_terminations[0].device}},{{cable.a_terminations[0].rear_port.cable}},{{cable.a_terminations[0].rear_port.cable.color}},{{cable.a_terminations[0].color}},{{cable}},{% if cable.status=="connected" %}Splice{% else %}{% endif %},{{cable.b_terminations[0].color}},{{cable.b_terminations[0].rear_port.cable.color}},{{cable.b_terminations[0].rear_port.cable}}
{% endif %}{% endfor %}

Fiber "splice" script: https://gist.github.com/DanSheps/a72b1e9f40dd9d92e48d05bdc3e6d44f

[xkilian]

Buffer Color,Strand Colour, Splice Identifier I would surmise these are custom fields added to the device type or to the device model?
Are there any other gotchas concerning modeling splices.
Context: I am trying to figure out with our fiber engineers, if netbox will be able to model fiber splices for OSP cabling. We currently only use the IPAM portion and plan on using the DCIM, OSP and ISP features.

[DanSheps]

That is an export template, not for importing.

[candlerb]

I have a script to connect all front ports on each device which I will upload tomorrow.

In case it's useful, there's also a generic script which connects one-to-one between a port range on two devices here:
https://github.com/netbox-community/reports/blob/master/scripts/multi_connect.py

[DanSheps]

I don't believe that script has been updated for the latest version of netbox, FYI.

[candlerb]

Ah yes good point. PR is on its way.

BTW, in the process of fixing this I found was an awkward change in Netbox 3.2 to LinkStatusChoices, where they now have three values in each tuple instead of two:

    CHOICES = (
        (STATUS_CONNECTED, 'Connected', 'green'),
        (STATUS_PLANNED, 'Planned', 'blue'),
        (STATUS_DECOMMISSIONING, 'Decommissioning', 'yellow'),
    )

If you try to use this as a ChoiceVar choices in a custom script (as mine did):

class MultiConnect(Script):
    cable_status = ChoiceVar(choices=LinkStatusChoices.CHOICES, default=LinkStatusChoices.STATUS_CONNECTED, label="Cable Status")

you get an exception:

ValueError at /extras/scripts/multi_connect.MultiConnect/
too many values to unpack (expected 2)

But the exception doesn't tell you what line of the custom script is faulty. I had to do a binary chop to find it :-(

[kkthxbye-code]

BTW, in the process of fixing this I found was an awkward change in Netbox 3.2 to LinkStatusChoices, where they now have three values in each tuple instead of two:

The following works as expected here:

cable_status = ChoiceVar(choices=LinkStatusChoices, default=LinkStatusChoices.STATUS_CONNECTED, label="Cable Status")

Is there a specific reason why you are using .CHOICES?

[candlerb]

Only that it wasn't obvious that you could pass the entire class: the documentation says it must be a list of 2-tuples.

EDIT: I see how it works now. ChoiceVar.__init__() calls add_blank_choice(choices); add_blank_choice calls tuple(choices); and there is magic in the ChoiceSet which turns it into an iterable of 2-tuples:

>>> from dcim.choices import LinkStatusChoices
>>> LinkStatusChoices
<class 'dcim.choices.LinkStatusChoices'>
>>> tuple(LinkStatusChoices)
(('connected', 'Connected'), ('planned', 'Planned'), ('decommissioning', 'Decommissioning'))

[kkthxbye-code]

Only that it wasn't obvious that you could pass the entire class: the documentation says it must be a list of 2-tuples.

It gets automagically turned into exactly such tuple as it is a ChoiceSet.

>>> tuple(LinkStatusChoices)
(('connected', 'Connected'), ('planned', 'Planned'), ('decommissioning', 'Decommissioning'))

I see how that might not be obvious though.

[salvadorb]

Hi @DanSheps interesting approach, it's good to see others also trying to use Netbox for OSP (Outside Plant) management. IMHO, Netbox really revolutionized inside cable management, unfortunately there's nothing similar for outside plant. I understand that Netbox has been designed mainly for in-building use, but it would be amazing to have a OSP module in Netbox, @jeremystretch, I don't see it as a FTTH-focused solution, in mainly focused on point to point and xWDM ptmp fiber links.

That Netbox module could handle ODF as cable termination points in the DC, Splice boxes, outdoor cables, MUXes). And if all that information is connected it would really simplify troubleshooting of fiber links, since you would be able to trace a fiber strain from the device in one DC to another device in a different DC or building

Best regards,

Salvador

[jeremystretch]

This would make a great plugin idea!

[salvadorb]

Just added the idea, open to comments and suggestions: https://plugin-ideas.netbox.dev/ideas/PLUGINS-I-35