NetBox?

[heath]

Does anyone use NetBox?  I have some questions about how other people are using it and I just can't find a user community for it.  I can find quite a few pages and videos explaining how to install it, but nothing on actually using it. 

[Otanx]

I run it here. What questions do you have?

-Otanx

[Dieselboy]

When Otanx mentioned it the other week I played with it that weekend. I found that there is a google community for it where you can ask stuff https://groups.google.com/group/netbox-discuss
but please ask your question

[heath]

I think I figured out some of my initial questions.  Like whether "Site" would be a campus or an individual building on a campus or a closet within a building.  I guess that's up to the user, so I'm treating a "Region" as a campus and a "Site" as a building.

Now I've fallen down the Linux rabbit hole of dependencies trying to get Napalm working.  I'm reminded why I hate Linux. 

[Otanx]

For the Organization section we define a Region as a building, then Site is a room. There is a little overlap in our names. So a building may be G7, and a room name is G7.212. Because the building is coded into the room name we considered going to our campus names for the Region, but we only have one campus, and everything else is just a building so it didn't buy us much. Racks go in Sites. We are just starting to play with the Tenants stuff. When we started using it we were the only ones with stuff in our spaces, but that changed and we are now co-locating other departments stuff.

One thing I wish we did not do was link the IPAM and DCIM parts. The IPAM part works pretty well on its own, and the DCIM stuff works pretty well. The integration of associating IPs with interface on devices in DCIM could use some work. We are several versions behind so that may be better now.

I have not done the NAPALM part yet. That will come in the future. If it makes it easier there is a container version of Netbox that is easy to install if you have some container service already.

-Otanx

[heath]

I do have a question for now.  How do you handle switch stacks?  How I've done it so far is define each switch in the stack, then add interfaces to each switch 1/0/[1-48] for the first one, 2/0/[1-48] for the second, 3/0/[1-48] for the third, etc.  Then add stack port interfaces and define the connections between them.  But what about a SVI that doesn't really belong to an individual switch but the stack as a whole?  I've just been adding it to the 1st switch in the stack, but that's not accurate.  I just wonder what the "best practice" for that is.

The process of getting data into it seems so circular that I feel like I must be doing it wrong.  There just doesn't seem to be a logical flow to it.  Setting up one thing depends on something else being set up first, but setting that up requires a 3rd thing to have been set up which requires the first thing exist first.  And it's so much manual entry, I'm just not sure if it's worth it in the end.  Our documentation in OneNote is pretty extensive and always updated so this may be more work than it's worth.  I was hoping for some automation to help cut down on the manual updates to OneNote.

[mmcgurty]

Does anyone here know if you can run NetBox on a Raspberry Pi?  I didn't want to host something on the Internet on a VPS or something and I don't want to ask my Platforms and Storage guys for something that isn't officially supported in our organization?  I was thinking of loading NetBox on my Raspberry Pi 4 with 4GB RAM and trying it out before I go down that road with official requests at the office.  We have InfoBlox as our IPAM but I would really like a good freeware DCIM.

[heath]

I did finally get Napalm working.  It needed to be installed with the -H flag on sudo which I overlooked before. 

It does seem to have a lot of overlap with LibreNMS which I also use.  If the two could be integrated, with feeding data into NetBox and duplicate functionality reduced, that might be perfect.

I don't know about a Pi supporting it.  Give it a try! 

[Otanx]

Switch stacks: See this issue in Github - https://github.com/netbox-community/netbox/issues/99 I think dberube1 option is probably the best, which sounds like what you are doing. However as you note it does not address SVIs. For that see https://github.com/netbox-community/netbox/issues/906  Basically disable the option that prevents duplicate IPs, and then just duplicate the IP. This other issue https://github.com/netbox-community/netbox/issues/1405 was for being able to assign a single IP to multiple interfaces, and was closed as a not going to do this right now.

As for the amount of data I had the same issue when we started. It does get better as you go. Basically setup all our Regions, Sites, Racks. I don't use the Rack Groups, or Roles. Then setup Manufacturers, and Device Types. Depending on your environment this could take a while. You will want all the different models in here. The better you make the device types the easier deploying a device is. Depending on what you are doing in Netbox you can cheat and use generic device types. However, it makes building each device longer. Once you have all that done then add each device, and assign to a rack, and U. That gets you through all the DCIM side of Netbox. All your physical infrastructure should now be in there.

I would skip IPAM, and go to Virtualization. Build out cluster types. There are a few ways to do that. You could do types as ESXi, Nutanix, Openstack, or as Dev, Test, Prod. Then build the cluster. If you have standalone hypervisors then you build a cluster with only one device. Once you create the cluster you can add the hypervisors to the cluster. Once the clusters are done create all the VMs, and assign to clusters.

Now everything should be defined except IP Addresses. Now under IPAM create VRFs if you need them. Create VLANs. You can have multiple VLANs using the same VLAN ID. So if you do something like Vlan 50 is voice vlan at every site you can create vlan50 multiple times, and assign each one to a site. Now setup RIR, we just did an RIR called RFC1918, and one called ARIN. Then create Aggregates to cover the address space you use. Sizing your aggregates is more art than science. Our public space we did as /24s. Then for our internal space we broke it up based on location. As an example 10.10.0.0/16 is for our primary DC. So we made that an aggregate. Then 10.20.0.0/16 is our HQ building so that is an aggregate. Both RIR and Aggregates are optional, and can be done later, but it is the easiest way to identify available address blocks when setting up new VLANs etc. Once those are done create prefixes. These will be the actaually used space. So you have a VLAN of 10.10.15.0/24 you create a Prefix for that. Assign it to the VLAN if that is the use case.

You are now at the point to setup IPs. You can do this in IP Addresses under IPAM, or under each device. If you do it under IPAM you can't assign it to a device. Same with VMs.

At this point everything should be in Netbox. You just have to keep it up to date.

Some tricks: Use the import buttons. The import is super easy to use. You just copy paste a CSV into the text box with a header to ID each field. This makes setting up Netbox much easier. Also the IP Address import under IPAM allows you to assign a device/interface where the manual add does not. The search at the top works really well.

Raspberry Pi: I don't know, but may try this weekend. I just setup a Pi4 at home, and am using it for Ansible stuff. As I mentioned before there is a container option on docker hub. If you have docker in your environment it can be spun up pretty quick. If you don't AWS has ECS which is pretty cheap. Quick math is less than $3 a day to run it 24 hours (assuming 2vCPUs and 4GB RAM).

[heath]

That post was extremely helpful, Otanx!  Thanks a ton!

[Otanx]

No problem. It has its faults, but I really like Netbox. Much better than spreadsheets. One thing that did not work for us was the idea that Netbox should be the source of truth, and the desired state, not the current state. You manually enter the data into Netbox to describe the desired state. If a device configuration does not match Netbox then the device is wrong, and should be updated to match Netbox. Our infrastructure, documentation, and automation isn't quite up to that yet, and I feel there are some items missing from Netbox (i.e. VIPs) that would cause pain. So we are going against the recommendation, and automating the addition of entries to Netbox based on system configurations. That way Netbox describes the current state of the network. At some point we could flip this, but that would be a major shift on how we do things.

-Otanx

[heath]

In your racks, how do you handle patch panels, PDUs, etc?

I did find the "virtual chassis" which seems to be one way to handle switch stacks.  The virtual chassis itself holds no information other than the devices that make up the virtual chassis.  It doesn't even have a name, just takes the name from the master device.  But, it does show all of the interfaces for all switches in the stack in one view.  It would just be nice if the SVIs and other information could be assigned to the virtual chassis.

[dlots]

Network to Code is big on netbox, I don't have much XP on it though.   They just hired the guy who wrote it.

You might ask in their slack channel though
https://networktocode.herokuapp.com/

[Otanx]

In your racks, how do you handle patch panels, PDUs, etc?

I did find the "virtual chassis" which seems to be one way to handle switch stacks.  The virtual chassis itself holds no information other than the devices that make up the virtual chassis.  It doesn't even have a name, just takes the name from the master device.  But, it does show all of the interfaces for all switches in the stack in one view.  It would just be nice if the SVIs and other information could be assigned to the virtual chassis.

My understanding is patch panels are now supported in Netbox. See - https://github.com/netbox-community/netbox/issues/20 We started with an older version so we did not have this. What we did is just use generic items to put the panels in the rack, but we didn't try to map out cable plant using them. I need to go and look at that, and see if it is worth changing how we do that.

PDUs we defined just like anything else. There is a connector type for power. You can also add 0U devices to your racks. The only issue we ran into was how to number the power outlets. If you are using manageable PDUs I would use the same name as the software. That way you can turn items on/off without having to figure out what outlet it is connected to. While we added the equipment I don't think we ever mapped out our power connections. We have plenty of outlets and usable power in our racks so it isn't a concern for us.

I saw the Virtual Chassis thing too, but as you said without being able to define the interfaces on the virtual chassis you still need to figure out SVIs.

-Otanx