v3.3-beta1 - 2022-07-14

[jeremystretch]

Breaking Changes

• Device position and rack unit values are now reported as decimals (e.g. 1.0 or 1.5) to support modeling half-height rack units.
• The nat_outside relation on the IP address model now returns a list of zero or more related IP addresses, rather than a single instance (or None).
• Several fields on the cable API serializers have been altered or removed to support multiple-object cable terminations:

Old Name	Old Type	New Name	New Type
termination_a_type	string	Removed	-
termination_b_type	string	Removed	-
termination_a_id	integer	Removed	-
termination_b_id	integer	Removed	-
termination_a	object	a_terminations	list
termination_b	object	b_terminations	list

• As with the cable model, several API fields on all objects to which cables can be connected (interfaces, circuit terminations, etc.) have been changed:

Old Name	Old Type	New Name	New Type
link_peer	object	link_peers	list
link_peer_type	string	link_peers_type	string
connected_endpoint	object	connected_endpoints	list
connected_endpoint_type	string	connected_endpoints_type	string
connected_endpoint_reachable	boolean	connected_endpoints_reachable	boolean

• The cable path serialization returned by the /paths/ endpoint for pass-through ports has been simplified, and the following fields removed: origin_type, origin, destination_type, destination. (Additionally, is_complete has been added.)

New Features

Multi-object Cable Terminations (#9102)

When creating a cable in NetBox, each end can now be attached to multiple objects. This allows accurate modeling of duplex fiber connections to individual termination ports and breakout cables, as examples. (Note that all terminations attached to one end of a cable must be the same object type, but do not need to connect to the same parent object.) Additionally, cable terminations can now be modified without needing to delete and recreate the cable.

L2VPN Modeling (#8157)

NetBox can now model a variety of L2 VPN technologies, including VXLAN, VPLS, and others. Each L2VPN can be terminated to multiple device or virtual machine interfaces and/or VLANs to track connectivity across an overlay. Similarly to VRFs, each L2VPN can also have import and export route targets associated with it.

PoE Interface Attributes (#1099)

Two new fields have been added to the device interface model to track power over Ethernet (PoE) capabilities:

• PoE mode: Power supplying equipment (PSE) or powered device (PD)
• PoE type: Applicable IEEE standard or other power type

Half-Height Rack Units (#51)

Device type height can now be specified in 0.5U increments, allowing for the creation of half-height devices. Additionally, a device can be installed at the half-unit mark within a rack (e.g. U2.5). For example, two half-height devices positioned in sequence will consume a single rack unit; two consecutive 1.5U devices will consume 3U of space.

Restrict API Tokens by Client IP (#8233)

API tokens can now be restricted to use by certain client IP addresses or networks. For example, an API token with its allowed_ips list set to [192.0.2.0/24] will only permit authentication from API clients within that network; requests from other sources will fail authentication. This can be very useful for restricting the use of a token to specific clients.

Reference User in Permission Constraints (#9074)

NetBox's permission constraints have been expanded to support referencing the current user associated with a request using the special $user token. As an example, this enables an administrator to efficiently grant each user to edit his or her own journal entries, but not those created by other users.

{
  "created_by": "$user"
}

Custom Field Grouping (#8495)

A group_name field has been added to the custom field model to enable organizing related custom fields by group. Similarly to custom links, custom links which have been assigned to a common group will be rendered within that group when viewing an object in the UI. (Custom field grouping has no effect on API operation.)

Toggle Custom Field Visibility (#9166)

The behavior of each custom field within the NetBox UI can now be controlled individually by toggling its UI visibility. Three settings are available:

• Read/write: The custom field is included when viewing and editing objects (default).
• Read-only: The custom field is displayed when viewing an object, but it cannot be edited via the UI. (It will appear in the form as a read-only field.)
• Hidden: The custom field will never be displayed within the UI. This option is recommended for fields which are not intended for use by human users.

Custom field UI visibility has no impact on API operation.

Enhancements

• #1202 - Support overlapping assignment of NAT IP addresses
• #4350 - Illustrate reservations vertically alongside rack elevations
• #4434 - Enable highlighting devices within rack elevations
• #5303 - A virtual machine may be assigned to a site and/or cluster
• #7120 - Add termination_date field to Circuit
• #7744 - Add status field to Location
• #8171 - Populate next available address when cloning an IP
• #8222 - Enable the assignment of a VM to a specific host device within a cluster
• #8471 - Add status field to Cluster
• #8511 - Enable custom fields and tags for circuit terminations
• #8995 - Enable arbitrary ordering of REST API results
• #9070 - Hide navigation menu items based on user permissions
• #9177 - Add tenant assignment for wireless LANs & links
• #9536 - Track API token usage times
• #9582 - Enable assigning config contexts based on device location

Plugins API

• #9075 - Introduce AbortRequest exception for cleanly interrupting object mutations
• #9092 - Add support for ObjectChildrenView generic view
• #9228 - Subclasses of ChangeLoggingMixin can override serialize_object() to control JSON serialization for change logging
• #9414 - Add clone() method to NetBoxModel for copying instance attributes
• #9647 - Introduce customfield_value template tag

Other Changes

• #9261 - NetBoxTable no longer automatically clears pre-existing calls to prefetch_related() on its queryset
• #9434 - Enabled django-rich test runner for more user-friendly output

---

This discussion was created from the release v3.3-beta1 - 2022-07-14.

[dejantep]

Where would be the best place to leave some feedback if needed?

[DanSheps]

Here, in a new FR/BR, on the issue for the change itself. Here is probably best for now.

[dejantep]

Thanks.
I'm excited about l2vpn feature and have tried it out on beta demo. I ran into one issue straight away. while trying to setup simple EPL with two terminations.
If i choose device as first termination point and port GigabitEthernet 0/0/0 and then another device as second termination point, i cannot choose port GigabitEthernet 0/0/0 on that other device. Netbox throws an error.

[DanSheps]

Open a bug report with detailed recreation steps please, I can look at it today if it is valid.

[DanSheps]

Nevermind, I opened it and resolved: #9844

[iunderwood]

You are on a roll with the innovative features. I can't wait to try out the new cable model!

[Serazio]

I would like to give some feedback to the new features:

Multi-object Cable Terminations (#9102)
I really like the idea to have the option to model breakout cables, but i played a bit with the beta demo and see some usability issues.
Using NetBox as a single source of truth isn't possible with this implementation, as there is no 1:1 binding between 2 cable endpoints.
Lets assume you have a trunk cable, like a 4x LC duplex cable. With the current model you can connect 2 switches together with 4x 10G, but you will not be able to tell which ports are connected together.

Furthermore i'm not sure how the general idea was how to model breakout cables. Having a QSFP+ 40G optic, which is splitted internally into 4x 10G, you have the option to model a loose 1:4 relation with a fixed order. You will never know which lane of the optic is connected to which end device.
Juniper Switches for example will split a single 40g optic into 4 virtual 10g optics on console. This may is possible to model with virtual sub interfaces like:

et-0/0/50 as qsfp+
- xe-0/0/50:0 as virtual sub interface
- xe-0/0/50:1 as virtual sub interface
- xe-0/0/50:2 as virtual sub interface
- xe-0/0/50:3 as virtual sub interface

But in this case you can't tell which sub interface is physically connected to which endpoint.

Half-Height Rack Units (#51)
Like discussed in the initial feature request, i would have preferred the 1/3 RU model, due to the 3 holes per RU in most racks. It would be a more suitable model for creating real rack documentations.

L2VPN Modeling (#8157)
Very good start for modeling l2vpns!
Inside the terminations list, it would be great to have some more related informations.
For example it would be great to see the related device for an interface or the vlan group for a vlan. Currently its just a bunch of same looking interfaces or vlans :)

Maybe it would be helpful to have some more features in the future.
Using the identifier as VNI for VXLAN, you can't use the same VNI one across multiple independent infrastructures. Something like the vlan groups would be helpful.
Like in the api for vlans, a api endpoint for getting the next free identifier in a certain range.

[markkuleinio]

due to the 3 holes per RU in most racks

At least the square holes I've seen in the racks exclusively here in Finland are not evenly spaced or equally sized, so I fail to see the real possibility to install devices in 1/3 steps. But I'm not a DC engineer so feel free to enlighten me if needed.

[Serazio]

I see your point and I know that the holes are not evenly. But in my experience the holes are so big and "worn-out", that you don't need to be a Hulk to fit a screw in it, if you fail to count the right holes.
Maybe doing it in 1/3 steps just fixes the problem of blind DC engineers :)

[markkuleinio]

Maybe doing it in 1/3 steps just fixes the problem of blind DC engineers :)

Yeah I agree with that 😂

[bistraque]

Actually, screws are not distributed by 1/3U (see here). 3 holes instead of one per U allows for a more robust install for heavy 1U equipments.

It is considered a very bad practice to offset position by 1 or 2 holes and I have no example of a 1/3U form factor. However 1/2U form factors do exist (for ex. here). Holes are elongated to accomodate the position (upper or lower half of the RU).

So in my opinion we should stick to the 1/2U increments ...

[candlerb]

0.1U increments won't accomodate 1 2/3U devices...

You'd define the device height as "1.6U", and install them at positions 0.0, 1.7, 3.4. It's not exact, but I think it's close enough. 0.1U is only 4mm.

[Serazio]

I have thought a little about the height of a device and the positioning inside the rack.
Maybe we should differentiate between both.

In a normal 19” rack with 3 holes per ru you can position a device in 3 different ways. 1st, 2nd or 3rd hole of an RU.
But the height of the device itself doesn’t matter. It could be either 1 ru, 1.5 ru, 1.66 ru or an other strange height.

Furthermore having a device with an abnormal height, you will never be able to positioning it starting at RU 1.5 due to holes in the rack. The only problem you will have, is that you will block half of a mounting hole, which will block that 1/3 of an RU anyway.
A properly mounted device starting at a ru of 0.5 is only possible, if you have either not mounted with screws and put it just on top of another device, or the device does have a very freaky chassis where the bottom holes are positioned in an offset to the bottom line of that device(i have never seen such).

Taking that facts, it could be a solution to allow the device height to be anything in steps of 0.1 starting at a minimum of 0.33(minimum to have a propper mounting point).
A 0.5 device would block 2/3 of a regular RU. Having a 0.5 device mounted in RU 1.33 should block the remaining RU up to RU 2, because with 0.17 remaining of an RU you can’t do anything.

Allowing the positioning in side the rack in steps of 1/3 would result into a large liste of available RUs. 0, 0.33, 0.66, 1, 1.33, …
This could be solved with a little checkbox next to the RU list to have the ability to either show sub units or not.

[DanSheps]

Something to consider:

NetBox should be tracking your desired end state, so mis-mounting should not be a consideration driving our model decisions in NetBox.

[mgoetze5]

Something to consider:

NetBox should be tracking your desired end state, so mis-mounting should not be a consideration driving our model decisions in NetBox.

So if I wanted a nice Apollo G10 server but my manager only approved a DL380G9 instead, I should still enter it in NetBox as an Apollo because that is my desired state? At some point NetBox will lose usefulness if it diverges from reality too far for too long.

[jeremystretch]

@mgoetze5 are you genuinely unclear on @DanSheps explanation above? If so, I'm happy to expand on the concept of intended vs operational state, however it seems like you're deliberately misunderstanding his point.

[candlerb]

I am testing the overlay L2VPN stuff with 3.3-beta2. Thanks for adding this - it's going to be extremely useful! I have a few fairly small comments/suggestions.

1. When you're creating an L2VPN Termination, selecting "Create and add another" should keep the existing L2VPN selected, to make it easier to add multiple terminations to the same L2VPN.

2. When showing an L2VPN Termination linked to a device interface, please show both the device name and interface name. Otherwise, what I see is this:

   

   Those are actually two interfaces on two different devices - but you can't tell without clicking through to each interface in turn. (Same applies to VMs / vminterfaces of course)

3. My primary use case is pseudowires, so I'd like to store the pw-id as an attribute. However I cannot currently use the "identifier" field for because, since it has a unique constraint. The pw-id only needs to be unique between a particular pair of endpoints; if I already have a pw with id 1000, I may well re-use id 1000 between this device and another endpoint, or another pair of devices.
   As a workaround, I guess I could create a custom field. But ideally I'd like the unique constraint to be removed. (Netbox already requires me to synthesise a unique name for each L2VPN, so if there are multiple PWs with id 1000, it's still obvious which is which).

4. If you are viewing a P2P L2VPN e.g. /ipam/l2vpns/1/, and it already has 2 terminations, then clicking "Add Termination" still takes you to the Add Termination page. It's only when you try to save it that you're told you can't have more than 2. It would be better to give an error immediately on clicking the Add Termination button (or grey it out, with tooltip saying max 2)

5. When I view the interfaces on a device, and configure the table, there doesn't seem to be an option to show the L2VPN (like there is for FHRP groups, say). I think this is just an oversight.

A separate minor feature request: for pseudowires I find myself creating lots of virtual subinterfaces, and I notice that the "Add" button next to an interface is a dropdown:

It would be really cool if this could also have "Add child interface". This would go to the normal Add Interface page, but pre-select the parent interface to the one just seen, the interface type to Virtual, and pre-fill the name as the previous interface name with a dot appended. This may seem minor, but it would save having to copy/paste the interface name and having to select it as parent.

Once you've created the child interface, having "Add L2VPN termination" as another option in this dropdown would be awesome.

Come to think of it, I'd also like "Add FHRP Group" on this dropdown - with a page with tabs to either create a new FHRP group or assign an existing one. (Actually, just "Assign FHRP Group" is all I really need). It's not related to L2VPN, but maybe could be done easily at the same time.

Cheers!

[DanSheps]

When showing an L2VPN Termination linked to a device interface, please show both the device name and interface name. Otherwise, what I see is this:

Part of the difficulty, is it isn't always a device, and currently display_name for interface only shows the interface name. We could switch it to a template field, but then we will lose sorting.

My primary use case is pseudowires, so I'd like to store the pw-id as an attribute. However I cannot currently use the "identifier" field for because, since it has a unique constraint. The pw-id only needs to be unique between a particular pair of endpoints; if I already have a pw with id 1000, I may well re-use id 1000 between this device and another endpoint, or another pair of devices.
As a workaround, I guess I could create a custom field. But ideally I'd like the unique constraint to be removed. (Netbox already requires me to synthesise a unique name for each L2VPN, so if there are multiple PWs with id 1000, it's still obvious which is which).

Open a issue for this, it likely won't make it into the release but we could look at it at a later date maybe.

If you are viewing a P2P L2VPN e.g. /ipam/l2vpns/1/, and it already has 2 terminations, then clicking "Add Termination" still takes you to the Add Termination page. It's only when you try to save it that you're told you can't have more than 2. It would be better to give an error immediately on clicking the Add Termination button (or grey it out, with tooltip saying max 2)

Could you open a FR for this?

When I view the interfaces on a device, and configure the table, there doesn't seem to be an option to show the L2VPN (like there is for FHRP groups, say). I think this is just an oversight.

Could you open a FR for this as well?

Once you've created the child interface, having "Add L2VPN termination" as another option in this dropdown would be awesome.

Come to think of it, I'd also like "Add FHRP Group" on this dropdown - with a page with tabs to either create a new FHRP group or assign an existing one. (Actually, just "Assign FHRP Group" is all I really need). It's not related to L2VPN, but maybe could be done easily at the same time.

These are all good minor QoL additions that are likely relatively easy for someone new to NetBox to implement so if you want to open them as FR's I say do it.

[candlerb]

YWIMC: FRs 10032 to 10039 inclusive created.