Virtual chassis, duplicate interfaces and filtering

[rodvand]

Scenario:

• Device 1 with interface Te1/0/1
• Device 2 with interface Te1/0/1
• Device 1 and device 2 in virtual chassis Test-stack
• Device 1 is master

Now, if I want to find the interface on Device 1, I thought I could use the filtering under /dcim/interfaces with:

• Name: Te1/0/1
• Device: Device 1
• Virtual chassis: Test-stack

This returns interfaces on both Device 1 and Device 2. If I set Device 2 in the filter, I only get the one interface.

Is this expected behaviour?

[DanSheps]

• Device 1 with interface Te1/0/1
• Device 2 with interface Te1/0/1

Cisco seems like, you shouldn't have Te1/0/1 on two different devices that are part of a stack. Likewise with VSS/Virtual Stackwise.

Is this expected behaviour?

It is, because of the way the "master" behaves. On the master device, it returns all interfaces using vc_interfaces, whereas on a member, using vc_interfaces, it only returns the member interfaces.

[jcollie]

Yes, this is the way Netbox works. I work around it by adding interfaces on modules 2+ with the name te{module}/0/1 instead of what it would be if the switch wasn't stacked with the others. Netbox has mass-rename tools that make this less tedious. Jeff

…

On Thu, Feb 17, 2022 at 4:52 PM Martin Rødvand ***@***.***> wrote: Scenario: - Device 1 with interface Te1/0/1 - Device 2 with interface Te1/0/1 - Device 1 and device 2 in virtual chassis Test-stack - Device 1 is master Now, if I want to find the interface on Device 1, I thought I could use the filtering under /dcim/interfaces with: - Name: Te1/0/1 - Device: Device 1 - Virtual chassis: Test-stack This returns interfaces on both Device 1 and Device 2. If I set Device 2 in the filter, I only get its interface. Is this expected behaviour? — Reply to this email directly, view it on GitHub <#8679>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFUVNUQRUGMB62RNMDMSRTU3V32VANCNFSM5OWDHM2A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- Jeff Ollie The majestik møøse is one of the mäni interesting furry animals in Sweden.

[travisjohnsonga]

Can you use module in the interface adds? If so, that's super helpful to know

[rodvand]

When I filter on the virtual chassis AND the device I think it's strange that it returns all the interfaces. And yes, it's because the device I filter on is also defined as the master of the VC. But then the filtering on device does nothing...

It's a strange scenario, and I have myself never seen a stack where the interfaces are named the same, so I guess it's not a common occurrence.

[mtinberg]

I think the idea is that administratively the primary stack member is the whole device and controls/contains all the interfaces, so you'd want to see all the interfaces when operating on the device that represents the whole stack. Virtual Chassis records just associate Device records and Device (and VM) records are the primary models for equipment configuration. On the new Module model there is some template replacement to create interface names with the module number as part of the name, eg. "Te{module}/0/1" but that isn't going to quite work for stacks as the Virtual Chassis collects together _existing_ Device records, I don't think you can create a VC then create new Device records that start as members of the VC, so when a Device is created Netbox has no idea it's going to be part of a stack, and interfaces need to be renamed when a Device joins a VC. There are some tools to help bulk-rename interfaces, since this is a common need, and people write small API scripts to help with this (and also help audit differences between Device Type Interfaces and deployed devices), but there is no general, bug-free code to do this automatically within the core Netbox, especially since interface names are just data totally under the control of the admin. Does that seem about right on why it works the way it does? — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-MadisonMessage ID: ***@***.***>

[bluikko]

Would it make sense to have a {vc} usable similarly as {module}? That defaults to 1 if the Device is not in a VC?

[AnythingOverIP]

@bluikko : see #8648 :)
That said, defaulting to "1" is suitable for a Cisco-like environment, but with Juniper, numbering starts at 0... I don't think there's a one-size fit's all scenario here...

[bluikko]

There would be different notations between the different Cisco product lines also. 1 was mostly an example.

[amk1969]

I find the approach of seeing all interfaces in master and only local interfaces at slave a good one. However, today noticed that with Netbox version 3.2.9 the interfaces disappear from slave when updating them via master using pynetbox. This looks like a regression of #1926

Quickly tested on the current version 3.4.6 at demo.netbox.dev and found the interfaces not disappearing (what is good) but also that the slave device shows only local interfaces in GUI but returns all (non-management) interfaces of the chassis via API.
Is this expected? What could be the reason? Sample script attached.
ifupdate.txt

[amk1969]

Almost about to raise a bug found #11478 that is exactly matched. GUI also shows all interfaces when selected using device_id: eg https://demo.netbox.dev/dcim/interfaces/?device_id=110