Mark interface as DHCP #13465
Replies: 7 comments 5 replies
-
|
I would flag the interface should not have the IP templated (which you probably still want to track, right?) using a tag or custom field on the interface and have a separate {% if blah %} foo {% elif blahblah %} {% endif %} stanza for each way you are templating this line
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Robert Main ***@***.***>
Sent: Monday, August 14, 2023 10:53 AM
To: netbox-community/netbox ***@***.***>
Cc: Subscribed ***@***.***>
Subject: [netbox-community/netbox] Mark interface as DHCP (Discussion #13465)
For each interface, I can assign a static IP to an interface. This is great and I can then go ahead and pull this into a configuration template. However, I start to run into problems for interfaces that get their IP from DHCP (be that from an ISP's DHCP server or even from an internal one). The specific use case for my is my WAN interface (eth0). I can't seem to find a way to mark that as "This interface has an IP but it gets it from DHCP". This means that I can do something akin to the following for most of my interfaces:
{%- for interface in physical -%}
{%- if interface.ip_addresses.first() %}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addresses.first().address }}
{%- endif %}
{%- endfor %}
but my WAN interface expects to be configured thusly:
set interfaces ethernet eth0 address dhcp
I suppose I could simply write an if statement to say that "if an interface has no IP address, then assume DHCP", but that's not entirely accurate for things like trunk interfaces for which I've assigned no IP to the physical interface itself, but it has child interfaces in the form of tagged VLANs which do have IP addresses.
—
Reply to this email directly, view it on GitHub<#13465>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMYALQKEP34YYFX57TLXVJCXHANCNFSM6AAAAAA3P4K2RE>.
You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Not sure what you mean?
My issue with using custom fields is that it feels very brittle and tied to that custom field and this instance of netbox. I don't realistically see myself migrating things between netbox instances, but you see what I'm getting at right? Where the behavior of my templating is dependant on a particular custom attribute rather than some part of netbox that I can always depend on to be there. Either way I ended up adding an IP to the interface, then setting "Status = DHCP" on that IP then in my template, doing this: {%- if interface.ip_addresses.first().status == 'dhcp' %}
set interfaces ethernet {{ interface.name }} address dhcp
{%- else -%}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addresses.first().address }}
{%- endif %} |
Beta Was this translation helpful? Give feedback.
-
This is what I would do. Re: trunk interfaces, those should be set as "mode" tagged anyways, so that shouldn't be an issue to decern whether it is a trunk or routed port. The only issue is when you get into something where you have subinterfaces for example. |
Beta Was this translation helpful? Give feedback.
-
|
Well, it's an issue because I'm using this info to generate config files, so I don't want to end up generating garbage that (at best) won't be accepted by the router or (at worst) will configure it incorrectly. I did check and it looks like I can actually add an IP to the interface (I just picked 1.2.3.4/24) and then "Status = DHCP" in the dropdown. Also - re: "Re: trunk interfaces, those should be set as "mode" tagged anyways, so that shouldn't be an issue to decern whether it is a trunk or routed port." Does that mean I set "802.1q tagging mode" to "Trunked (All)" (or Trunked VLANs) on the parent interface that the vlans hang off? |
Beta Was this translation helpful? Give feedback.
-
|
My issue with using custom fields is that it feels very brittle and tied to that custom field and this instance of netbox. I don't realistically see myself migrating things between netbox instances, but you see what I'm getting at right? Where the behavior of my templating is dependant on a particular custom attribute rather than some part of netbox that I can always depend on to be there.
You are very much intended to use custom fields (and tags) and develop your own naming convention, policies and procedures around them. Netbox provides a framework and a minimal set of fields, the built-in schema is not intended to be exhaustive as that burdens development to make sensible UI and validation rules for each field, when only a subset of the installs need each possible field. You end up where MS went with Word, trying to add every possible feature for every customer that asked, leading to some real strain in the UI and maintenance/development long term. Better for each site to manage their own custom fields and for plugin developers to manage their own db schemas outside the core, with robust tools for both.
The custom field mechanisms are very robust, are carried through on upgrade and can be queried and created using the REST API if you need to sync different installs (eg. QA vs Prod) or just back up the definitions outside of the full DB backups you already have. The Netbox support in Ansible can also create custom fields over the API, so you can manage configuration in playbooks in a git repo. You should not be afraid to use them, any maintenance burden you foresee would be the same if they were part of the base schema. Your templates are not expected to be drop-in reusable outside of your organization anyway because every organization has custom rules and custom fields and differing standards.
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Robert Main ***@***.***>
Sent: Monday, August 14, 2023 9:19 PM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] Mark interface as DHCP (Discussion #13465)
I would flag the interface should not have the IP templated (which you probably still want to track, right?)
Not sure what you mean?
using a tag or custom field on the interface and have a separate {% if blah %} foo {% elif blahblah %} {% endif %} stanza for each way you are templating this line
My issue with using custom fields is that it feels very brittle and tied to that custom field and this instance of netbox. I don't realistically see myself migrating things between netbox instances, but you see what I'm getting at right? Where the behavior of my templating is dependant on a particular custom attribute rather than some part of netbox that I can always depend on to be there.
Either way I ended up adding an IP to the interface, then setting "Status = DHCP" on that IP then in my template, doing this:
{%- if interface.ip_addresses.first().status == 'dhcp' %}
set interfaces ethernet {{ interface.name }} address dhcp
{%- else -%}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addresses.first().address }}
{%- endif %}
—
Reply to this email directly, view it on GitHub<#13465 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UMZO5ZN33LCCNM6MULLXVLMEXANCNFSM6AAAAAA3P4K2RE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I'm facing a similar problem right now. We have various devices, that either receive an dynamic or static/reserved IP lease from DHCP. The handling of static leases works well:
This clearly marks the assignment of a static lease for us. However for dynamic leases, I do not want to set an IP address but rather a prefix or ip-range. Such DHCP interfaces should count towards the utilization of the prefix/range. If you have a dynamic range 192.168.0.10 - 20, and you have assigned 10 interfaces to that range, the range should be treated as "100% used". This should also be possible for SLAAC, i think. As a workaround, I've assigned the network address (192.168.0.0/24) to all of my DHCP Clients but that doesn't feel right (as is does not reflect the prefix usage and generates a lot of duplicate ip addresses). How would you guys handle this? |
Beta Was this translation helpful? Give feedback.
-
|
I don't see the purpose in tracking the dynamic DHCP assignments in Netbox at all, if you need a specific address, statically assign it, if they are dynamic then the specific address doesn't matter and you already have some other mechanism for communicating with the host, like Dynamic DNS records managed by DHCP or the host management agents phone home to a well-known service.
In a dynamic IP case setting the primary_ip in Netbox doesn't make sense because Netbox isn't managing which IP is being used, Netbox works best when its used to manage authoritative data that is pushed down into other tools, and it is very fiddly to try and make Netbox a dashboard of data that is synched from other tools, it adds overhead, complexity and administrivia for little gain except for the data looks more complete, but the data isn't necessarily more usefuL and you have to invest more effort in keeping it up to date.
In your case, if you are trying to manage how full your dynamic DHCP pools are, then you should monitor your DHCP service to alert and trend that, not try and track dynamic assignments in the Netbox IPAM
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Daniel Tücks ***@***.***>
Sent: Tuesday, August 29, 2023 2:44 AM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] Mark interface as DHCP (Discussion #13465)
I'm facing a similar problem right now. We have various devices, that either receive an dynamic or static/reserved IP lease from DHCP.
The handling of static leases works well:
* Assign an IP to the interface
* Assign a MAC address
* Set it to DHCP
This clearly marks the assignment of a static lease for us.
However for dynamic leases, I do not want to set an IP address but rather a prefix or ip-range. Such DHCP interfaces should count towards the utilization of the prefix/range. If you have a dynamic range 192.168.0.10 - 20, and you have assigned 10 interfaces to that range, the range should be treated as "100% used". This should also be possible for SLAAC, i think.
As a workaround, I've assigned the network address (192.168.0.0/24) to all of my DHCP Clients but that doesn't feel right (as is does not reflect the prefix usage and generates a lot of duplicate ip addresses).
How would you guys handle this?
—
Reply to this email directly, view it on GitHub<#13465 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5J77OAXBWRYK6LG2DXXWMXBANCNFSM6AAAAAA3P4K2RE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
The point isn't to manage DHCP assignments as a way to mark the interface as one whose address is assigned via DHCP. I can't immediately see a way to do this without assigning the interface an address. |
Beta Was this translation helpful? Give feedback.
-
|
In that case I'd create a Boolean custom field or a tag and apply that to the interface to indicate it's a DHCP client and not worry about the address. You can still record the access VLAN for the device to associate it with its network if you like.
Get Outlook for Android<https://aka.ms/AAb9ysg>
…________________________________
From: Robert Main ***@***.***>
Sent: Tuesday, August 29, 2023 4:34:59 PM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] Mark interface as DHCP (Discussion #13465)
The point isn't to manage DHCP assignments as a way to mark the interface as one whose address is assigned via DHCP. I can't immediately see a way to do this without assigning the interface an address.
—
Reply to this email directly, view it on GitHub<#13465 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM2NU72FMR4VOTDMB3DXXZN77ANCNFSM6AAAAAA3P4K2RE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I did think about that but the issue then becomes "How does one use that info to generate the relevant config template?" |
Beta Was this translation helpful? Give feedback.
-
|
I'm sorry that I'm not keeping mental state over the days and weeks of this discussion. Looking back at the history per your comment on 2023-08-14 we talked about using a tag or custom_field to indicate a boolean status (eg. enable_dhcp) that you could use in your template, shown here both ways.
{%- if 'enable_dhcp' in interface.tags.names() or interface.custom_field_data['enable_dhcp'] is True %}
set interfaces ethernet {{ interface.name }} address dhcp
{%- else -%}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addresses.first().address }}
{%- endif %}
you could also make the default state dhcp if you wanted and only check if interface.ip_addresses is populated in a couple of ways like
{# if ip_address not populated then default to dhcp #}
{{ interface.ip_addresses.first().address | default("dhcp") }}
or
{% if interface.ip_addresses is defined %}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addreses.first().address }}
{% elif 'enable_dhcp' in interface.tags.names() %}
set interfaces ethernet {{ interface.name }} address dhcp
{% else %}
{# some third option if nothing is specified #}
{% endif %}
—
Mark Tinberg ***@***.***>
Division of Information Technology-Network Services
University of Wisconsin-Madison
…________________________________
From: Robert Main ***@***.***>
Sent: Wednesday, August 30, 2023 8:57 AM
To: netbox-community/netbox ***@***.***>
Cc: Mark Tinberg ***@***.***>; Comment ***@***.***>
Subject: Re: [netbox-community/netbox] Mark interface as DHCP (Discussion #13465)
I did think about that but the issue then becomes "How does one use that info to generate the relevant config template?"
—
Reply to this email directly, view it on GitHub<#13465 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAS7UM5ZEO7JKL6EDAO4N6DXX5BFDANCNFSM6AAAAAA3P4K2RE>.
You are receiving this because you commented.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Ah that makes a ton of sense. {%- if 'enable_dhcp' in interface.tags.names() or interface.custom_field_data['enable_dhcp'] is True %}
set interfaces ethernet {{ interface.name }} address dhcp
{%- else -%}
set interfaces ethernet {{ interface.name }} address {{ interface.ip_addresses.first().address }}
{%- endif %}ended up being what I needed. Thank you! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
For each interface, I can assign a static IP to an interface. This is great and I can then go ahead and pull this into a configuration template. However, I start to run into problems for interfaces that get their IP from DHCP (be that from an ISP's DHCP server or even from an internal one). The specific use case for my is my WAN interface (eth0). I can't seem to find a way to mark that as "This interface has an IP but it gets it from DHCP". This means that I can do something akin to the following for most of my interfaces:
but my WAN interface expects to be configured thusly:
I suppose I could simply write an
ifstatement to say that "if an interface has no IP address, then assume DHCP", but that's not entirely accurate for things like trunk interfaces for which I've assigned no IP to the physical interface itself, but it has child interfaces in the form of tagged VLANs which do have IP addresses.Beta Was this translation helpful? Give feedback.
All reactions