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.15k stars 2.58k forks source link

Virtual Chassis interface dynamic naming #8648

Closed thefreakquency closed 2 years ago

thefreakquency commented 2 years ago

NetBox version

3.1.7

Feature type

New functionality

Proposed functionality

Similar to what has been brilliantly implemented in https://github.com/netbox-community/netbox/issues/7844 for interface names assigned to a module, it would be beneficial to be able to do the same with VC, based on the VC ID.

Switch ID 0: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-0/0/0 @ ge-0/0/48 Switch ID 1: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-1/0/0 @ ge-1/0/48 Switch ID 2: ge-{MemberID}/0/0 @ ge-{MemberID}/0/48 : would then results in interfaces ge-2/0/0 @ ge-2/0/48

Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore.

Having a "default position ID" defined in the device type (i.e: if switch not a member of a VC, assign a value to {MemberID}, so interfaces templates are not to be maintained twice would be a great plus, but this would potentially be harder to maintain or model (i.e: Cisco devices would have a default value of 1, and Juniper a default value of 0).

To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment (one being a stand-alone switch and the other a stack member). This would minimize the logic needed to have different naming schemes whether a switch is used in a VC or not.

Similar issues were previously raised in https://github.com/netbox-community/netbox/issues/5918 , https://github.com/netbox-community/netbox/issues/4177, but hopefully Netbox 3.x would now be able to accommodate this using what's implemented in #7844

Use case

That new module concept is huge and will simplify our Netbox inventory. My understanding is that it could almost replace VC in most cases, but rack elevations would not be represented properly. Also, multi-site or multi rack VC member locations would not be properly addressed by that. I'd like to see in the Virtual Chassis model some of the flexibility the module model is bringing. Switch stacks would then be easier to create/maintain.

Database changes

None AFAIK

External dependencies

No response

empusas commented 2 years ago

I would keep the virtual chassis feature. If you replace it with module you might loose a lot of functionality. As I understand it the module model, it assumes that the "module" is inside of the chassis of the main device. But your stack members, fabric extenders etc. might be at a different place and you want to capture that information. Only problem I see is that you would like to have the interface in the master device, for example if you have an automation. But then it might be misleading if you use the cabling feature as the cables might end at a different location as the master device. Not an easy problem I guess.

thefreakquency commented 2 years ago

I would keep the virtual chassis feature.

Definitely! My request is not to get rid of Virtual Chassis. Just to do some mileage on what has been done with Modules.

steele-ntwrk commented 2 years ago

This is a great request 👍🏼 ! Great work!

I was about to open a similar one after watching the youtube video about Modules in Netbox 3.2 but thought I would have a search first.

I think two new fields can be added to the data model of the device type that will be assessed when creating a Virtual Chassis and update interfaces.

Example virtual chassis capable: True vcname: GigabitEthernet{VC}/0/1

There also seems to be some logic already there that when a device is marked as Master it imports all the interfaces, could renames the interfaces in the same process based on the above data model?

Cheers, Steele

wwerther commented 2 years ago

Already tested in Version 3.2 with Modules. It's working nice, to use interfaces names in module-type like: TenGigabitEthernet1/{module}/1 so the addition would be to use TenGigabitEthernet{vcid}/{module}/1 instead with the vcid replacd with the number in vc or a default value as stated in top request.

The question that will pop-up is what will happen if the VCID changes at a later time. So will deployed modules get permanent names or will the name be "replaced" dynamically when the position in VC would change.

jeremystretch commented 2 years ago

The major distinction between modules and virtual chassis members (devices) is that device components are populated before assignment to a VC, whereas module components are populated at the same time. So you can't use the same approach of defining a placeholder value in the component name.

To simplify the feasibility of this FR, I wouldn't mind maintaining two device types for the same piece of equipment

I suspect you're going to be in the minority there.

Currently, when adding switches to a Stack, we have to go and delete, then recreate interfaces as they the interface name is not what's in the device type anymore.

It's recommended to just rename the interfaces in bulk rather than deleting & recreating them all.

DanSheps commented 2 years ago

Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience.

Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought.

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

thefreakquency commented 2 years ago

@DanSheps , do you think it's worth keeping this FR opened? (pretty please! :) )

steele-ntwrk commented 2 years ago

Could we do something like {vcid:1} where anything after the ":" is the default, and have it check when a device is attached to a VC? I know it is a bit hacky but I do think it would greatly improve peoples UX experience.

Nevermind, I see that we can't relocate a module after the fact. Could we perhaps have a _unresolved_name cached on the object that we can check against and perhaps rename. This would also facilitate moving module slots without losing the interface state. Just a thought.

I think this is a good idea, but I'm also not very well versed in programming.

DanSheps commented 2 years ago

I think for now we have more pressing issues to work on and this can be manually achieved by bulk rename currently

thefreakquency commented 2 years ago

OK then! Thanks!

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

github-actions[bot] commented 2 years ago

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.