custom field referencing an interface object - how do I filter on parent device

[Kludge-As-A-Service]

Hello,
In the context of a custom field applied to model "Ipam > prefix", of type "object" > "dcim > interface": once I am configuring a prefix I get a list of interfaces for this custom field, but seemingly with no reference to the device they belong to. Which is a problem because of course interface names are only unique within a given device. For example a lot of firewalls have an interface named "port1", so with only the name of the interface being presented there is not much I can do to decide which one to pick. What I would have expected to happen instead is to be shown something like "Firewall1 > port1", "Firewall2 > port1" in the drop down menu for the custom field.

Am I missing something?
Thanks.

[mtinberg]

Yeah, it's not that sophisticated. custom_field Object and Multi-Object references are like just a generic foreign key to another table in the database and the Django ORM, they are not customized specific to the targeted data model such that they join in other tables, like filtering Interface by Device, or VLAN by VLAN Group or whatever. What about making the relationship the other way, have Interface point to Prefix? What is the end result supposed to look like, what is the output template or automation this relationship is intended to serve? There does already exist IP Address to Interface relationship on the IP Address model, but edited from the Interface page in the WebUI to solve exactly this same kind of problem, and IP Address can include a netmask specifically to make it easy to template into configs as-is, since a prefix on an interface usually has a specific IP active on the interface in that prefix. If you get the IP on an interface, you can try and look up the parent Prefix, if there is other custom_fields or data on the Prefix model you need, and may not need the direct relationship. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Kludge-As-A-Service ***@***.***> Sent: Wednesday, November 9, 2022 5:42 AM To: netbox-community/netbox ***@***.***> Cc: Subscribed ***@***.***> Subject: [netbox-community/netbox] custom field referencing an interface object - how do I filter on parent device (Discussion #10870) Hello, In the context of a custom field applied to model "Ipam > prefix", of type "object" > "dcim > interface": once I am configuring a prefix I get a list of interfaces for this custom field, but seemingly with no reference to the device they belong to. Which is a problem because of course interface names are only unique within a given device. For example a lot of firewalls have an interface named "port1", so with only the name of the interface being presented there is not much I can do to decide which one to pick. What I would have expected to happen instead is to be shown something like "Firewall1 > port1", "Firewall2 > port1" in the drop down menu for the custom field. Am I missing something? Thanks. — Reply to this email directly, view it on GitHub<#10870>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZYJTMLZD35BHVZTF3WHOEZTANCNFSM6AAAAAAR3K3IG4>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Kludge-As-A-Service]

Sorry actually my issue is more about the way it's displayed than a need for filtering. Even if the list simply displayed the id of the interface I could deal with it (since it's unique), but with the interface name only it's impossible to distinguish an interface from another, so the feature seems practically unusable as-is in this particular case.
But I understand that this sort of custom field is a rather new feature, so maybe it'll get better in the future.

To expand on my use case: I have a number of similar sites, each one has been attributed a large "container" /16 prefix. Now I want to easily declare new a vlan+prefix for each site (prefix contained within the container for that site), along with a new subinterface+IP on the firewall cluster for that site, to route the new prefix. So the idea was to have the relevant physical interface of both firewalls linked to the container IP prefix, so that the script can start from the container and immediately know under which device/interfaces the new subinterfaces should be created.
I could go the other way and have the prefix referenced as a custom field on the interfaces, I think it makes less sense from a user standpoint, and what I don't like with ths approach is that I end up with a useless/empty/confusing custom field displayed on 99% of my interfaces, whereas with my initial approach it only applies to prefixes which is a smaller a problem. But if it's the best feasible way I'll take it.

[mtinberg]

Did you want to just assign a Site or Site Group to the container prefix which is already a relationship built-in to the model, and maybe figure out where to assign the subinterface on the firewalls by convention in your provisioning script that creates and associates the records. /ipam/prefixes/?status=container&site=foo once you create the new active prefix and vlan and associate those together assigning the vlan to the subinterface allows the trail to be followed. Picking the interface on the firewalls could be a challenge if it isn't just a known convention (eg Eth1/1 is always inside and Eth1/2 is outside or whatever) then a tag or custom field could make the interface searchable (eg custom_field firewall_zone: inside,outside,dmz), so you know how to name and parent the subinterface. I dunno just brainstorming, there is often another way of turning the data around and looking at it that makes things line up neatly, if you are able and willing to adjust the provisioning process to better match. — Mark Tinberg ***@***.***> Division of Information Technology-Network Services University of Wisconsin-Madison

…

________________________________ From: Kludge-As-A-Service ***@***.***> Sent: Wednesday, November 9, 2022 10:26 AM To: netbox-community/netbox ***@***.***> Cc: Mark Tinberg ***@***.***>; Comment ***@***.***> Subject: Re: [netbox-community/netbox] custom field referencing an interface object - how do I filter on parent device (Discussion #10870) Sorry actually my issue is more about the way it's displayed than a need for filtering. Even if the list simply displayed the id of the interface I could deal with it (since it's unique), but with the interface name only it's impossible to distinguish an interface from another, so the feature seems practically unusable as-is in this particular case. But I understand that this sort of custom field is a rather new feature, so maybe it'll get better in the future. To expand on my use case: I have a number of similar sites, each one has been attributed a large "container" /16 prefix. Now I want to easily declare new a vlan+prefix for each site (prefix contained within the container for that site), along with a new subinterface+IP on the firewall cluster for that site, to route the new prefix. So the idea was to have the relevant physical interface of both firewalls linked to the container IP prefix, so that the script can start from the container and immediately know under which device/interfaces the new subinterfaces should be created. I could go the other way and have the prefix referenced as a custom field on the interfaces, I think it makes less sense from a user standpoint but if it's the best feasible way I'll take it. — Reply to this email directly, view it on GitHub<#10870 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5MNC4HU6AQ6V2N7GDWHPGFHANCNFSM6AAAAAAR3K3IG4>. You are receiving this because you commented.Message ID: ***@***.***>

[Kludge-As-A-Service]

Referencing the site is not sufficient (then it would have been simple, but unfortunately some sites have other unrelated firewalls clusters), but I think that I'll reference both firewalls from the IP container, and then have a tag on the specific firewalls interface as you mention (unfortunately the interface to pick doesn't have a consistent name accross all clusters). So that is just one more tag to add on one interface per firewall, should be fine.
Thanks for your help, appreciated!