Config Templates: Accessing IPAM Information from Device context

[bradley-rose]

I'm trying to create a config template for some switches. Part of the core of the switch configuration is the default gateway:

ip default-gateway {{ default-gateway-for-subnet }}

From within the Config Template context, it looks like I only have access to the device object. Is there any way I can access any IPAM objects like prefixes? Typically I use the first address in the subnet for the default gateway, so I'm wanting to do something like this:

ip default-gateway {% for prefix in ipam.prefixes.filter({{ device.primary_ip4.address }}) %} {%- if prefix.split("/")[1] == {{ device.primary_ip4.address }}.split("/")[1] %} {{ prefix.split("/")[0].split(".")[0] + "." + prefix.split("/")[0].split(".")[1] + "." + prefix.split("/")[0].split(".")[2] + "." + (prefix.split("/")[0].split(".")[3] + 1) }} {%- endif %} {%- endfor %}

The logic:

• For each prefix identified via querying the device's primary IP address:
  • If the prefix's subnet mask matches the subnet mask of the primary IP address of the device, we've got a match.
  • Split the prefix into four pieces (one for each octet).
  • Write the first three octets (w.x.y.), and for the fourth, increment it by a value of 1. This would give me the first address in the subnet.

I'm not sure how to translate this into proper Jinja2 templating for the Config Template. If there's a much simpler way to do this, please, I'm all ears.

[adparis99]

As of NetBox 3.6, you can access models directly from a configuration template. In your example, the for loop should start off like so:
for prefix in ipam.Prefix.objects.filter({some filter here})...

For what it's worth, in my organization we define default gateways in a Config Context associated with a particular site and then reference that config context object in the template. I suppose that's slightly more manual, but it has served us well.

[bradley-rose]

Thanks for the reply! I hadn't realized this was such a recent feature.

• Is that the exact syntax that you provided, or do I still have to wrap it in Jinja2 syntax?
• Is there documentation to support which models are available?

[adparis99]

No problem. To answer your questions,

1. Yes, it should be wrapped up in in Jinja2 syntax. So as an example, {% for prefix in ipam.Prefix.objects.all() %} do stuff {% endfor %}
2. Expose more objects in the configuration rendering feature #12814 is where the request was originally made. It seems like all models are available for reference, but I can't confirm that because it wasn't said explicitly in that thread. Assuming all are there, if you need a list of the models, see this link for documentation on the NetBox Shell.

[brandan-schmitz]

@bradley-rose Did you ever figure this out? I have a similar situation where I am trying to set an ip default-gateway using a custom field I have attached to the Prefix. However I cannot seem to figure out how to find the prefix based on the primary IP of the device.

[bradley-rose]

@brandan-schmitz Unfortunately, I did not. I ended up giving up entirely on the feature as it felt like, in its current state, it was over-complicating the job. It's a really great idea in theory, but in execution it's not excellent. I think you'd be better off performing configuration and orchestration management with a more purpose-built tool like Ansible, and leaving Netbox to do the thing that it does best: IPAM and DCIM.

What I did recently find out was the value of having a centralized, team-oriented Git tool like Gitlab, Github, or otherwise. This immediately removes a lot of the scary pieces to centralized configuration management for those less inclined to change their ways. Even if it's used for housing legacy text-file-based configurations, they're version controlled. If you can centralize your configuration here, and then replace variables with calls to Netbox, I think you're definitely headed somewhere.