Moving SFP Modeling from Inventory Items to Modules in NetBox

The Big Change Everyone’s Talking About

Organizations have been tracking SFPs in NetBox using Inventory Items for a long time now, and recently there have been discussions about them being deprecated in a future release. The actual deprecation timeframe hasn’t been announced, but rather than resisting this change we strongly suggest embracing it, as this change represents a significant upgrade to NetBox’s capabilities.

The previous Inventory Items approach for SFPs always felt like working against the system. While functional, it was cumbersome. Manual association of SFPs with interfaces using naming conventions, limited tracking of spare modules, and minimal automation possibilities meant everything required manual intervention.

The new Modules and Module Types system represents a fundamental shift in how NetBox handles modular hardware.

The Previous Approach: Inventory Items

The traditional workflow was straightforward but limited:

1. Create an Inventory Item on the device
2. Fill in manufacturer, model, serial number
3. Provide a name similar to the interface it corresponds to, something like “SFP-Gi0/1”
4. Rely on manual processes to keep the data accurate when hardware changes
5. Manage the interface separately with no automatic relationship

This approach worked, but it was fundamentally a workaround. The biggest limitation was the lack of automatic relationship between the SFP and its interface. Everything relied on manual association through naming conventions or descriptions.

The New Approach: Modules and Module Types

The new Modules system treats SFPs as what they actually are – modular components that create interfaces when installed.

Consider this scenario: Create a module type for standard SFP+ modules with an interface template named GigabitEthernet{module}. When that module gets installed into module bay position 3 on a switch, NetBox automatically creates interface GigabitEthernet3 and properly associates it with the module.

This represents true automation of the relationship between hardware and configuration.

What Makes This Significantly Better?

Automatic Interface Creation: No more manually creating interfaces and trying to remember which SFP corresponds to which port. Install the module, and the interface appears automatically.

Proper Relationships: NetBox now understands that the SFP and interface are connected. Change the module, and the interface updates accordingly.

Hierarchical Support: Complex equipment with line cards that accept SFPs can now be modeled properly with nested modules.

Future-Proof Architecture: This aligns with NetBox’s development direction. Inventory Items are being phased out, while Modules continue to receive enhancements.

Example: 48-Port Switch with SFP+ Modules

Let’s examine a real-world scenario with a 48-port switch that has SFP+ capabilities and how we would model that using Modules and Module Types.

Step 1: Module Type Profile Create a Module Type Profile to organize and standardize SFP modules:

• Name: “SFP Transceiver”
• Description: “Profile for SFP and SFP+ optical and copper transceivers”
• Schema:

(This is a simplified schema used for illustration purposes and to keep things simple. A proper production schema would probably include additional information such as data rate, reach distance, fiber type, etc.)

Step 2: Module Types Create reusable SFP module types:

1. Create “SFP-10G-SR” Module Type:

• Manufacturer: (select appropriate manufacturer)
• Model: “SFP-10G-SR”
• Part Number: (enter manufacturer part number)
• Profile: select “SFP Transceiver”
• Connector_type: select “LC”
• Wavelength: select “850nm”

1. Add Components > Interfaces:
   • Name: “port{module}”
   • Type: select “SFP+ (10GE)”
   • Description: “10G SFP+ Interface”

Repeat for “SFP-10G-LR” and “SFP-1G-T” Module Types

Step 3: Device Type Create device type for a 48-port switch:

1. Create “48-port SFP switch” Device Type:

• Manufacturer: (select appropriate manufacturer)
• Model: “48-port SFP switch”

1. Add Components > Module Bays:

• Name: “SFP-[1-48]”
• Position: “[1-48]”

Step 4: Device Create a device instance:

• Device Type: select “48-port SFP switch”
• Device will have 48 empty module bays, no interfaces initially
• Only interfaces for installed SFPs will be created

Step 5: SFP Installation

• Install SFP-10G-SR module in module bay position 1:
  • Under “Module Bays” tab for the device, press “Install module” button for module “SFP-1”
  • Module Type: select “SFP-10G-SR”
  • Interface “port1” is created and properly associated with the SFP-10G-SR module
  • All module details (manufacturer, model, serial) are linked to the interface

Repeat for all SFPs installed in the device

Step 6: Operational Benefits

• Cable connections to interface port1 automatically reference the SFP module
• NetBox maintains the relationship between cables, interfaces, and specific SFP types
• Module removal can optionally remove the interface
• No manual naming conventions or procedural dependencies

Best Practices and Considerations

As you plan out your migration from Inventory Items to Modules and Module Types, here are some best practices to consider:

Template Naming: Invest time in getting the {module} templates correct. They must match existing interface names for automation compatibility.

Position Mapping: The module bay position becomes part of the interface name. Ensure positions correspond to physical equipment layout.

Incremental Approach: Avoid migrating everything simultaneously. Refine the process on a few devices before scaling.

Documentation: Document the mapping between previous inventory items and new module types for future reference. See our In-Depth Guide to Writing Network Documentation for more resources.  

Nested Modules: For complex equipment (line cards with SFPs), the new system supports nested modules. While more complex to configure, this provides powerful modeling capabilities.

Final Thoughts

Change is challenging, particularly when current systems are functional. However, this represents a fundamental improvement in how NetBox handles modular hardware rather than change for its own sake.

Once NetBox begins automatically creating interfaces upon module installation, the previous manual approach will seem unnecessarily complex. The future of network infrastructure management emphasizes modular design, and NetBox is leading this evolution.