Support both IPv4 and IPv6 "Primary IP" for devices #61

New Issue

adam · 2025-12-29T15:31:04+01:00

adam commented

2025-12-29 15:31:04 +01:00

Originally created by @bellwood on GitHub (Jun 29, 2016).

As the subject indicates, you cannot have both a v4 and v6 primary IP for a device.

Would be nice to have both =)

Originally created by @bellwood on GitHub (Jun 29, 2016). As the subject indicates, you cannot have both a v4 and v6 primary IP for a device. Would be nice to have both =)

adam closed this issue

2025-12-29 15:31:04 +01:00

adam commented

2025-12-29 15:31:05 +01:00

@jeremystretch commented on GitHub (Jun 29, 2016):

Currently we use a single primary_ip field on Device to indicate which IP should be used to reach it. As you point out, this can be either IPv4 or IPv6, but not both.

We could replace this with primary_ip4 and primary_ip6, but then we need some way to decide which address family should be used. For instance, when NetBox reaches out to a device to gather inventory data, should it try IPv4 or IPv6 first? Is this answer the same for all devices?

Seems like it would be reasonable to create a PRIMARY_AF configuration variable to indicate whether IPv4 or IPv6 should be preferred, but I'm open to suggestions.

@jeremystretch commented on GitHub (Jun 29, 2016): Currently we use a single `primary_ip` field on Device to indicate which IP should be used to reach it. As you point out, this can be either IPv4 _or_ IPv6, but not both. We could replace this with `primary_ip4` and `primary_ip6`, but then we need some way to decide which address family should be used. For instance, when NetBox reaches out to a device to gather inventory data, should it try IPv4 or IPv6 first? Is this answer the same for _all_ devices? Seems like it would be reasonable to create a `PRIMARY_AF` configuration variable to indicate whether IPv4 or IPv6 should be preferred, but I'm open to suggestions.

adam commented

2025-12-29 15:31:06 +01:00

@x-zeroflux-x commented on GitHub (Jun 29, 2016):

I would suggest as the internet has done it for years.

if ipv6 exist use ipv6 first then followed by ipv4.

@x-zeroflux-x commented on GitHub (Jun 29, 2016): I would suggest as the internet has done it for years. if ipv6 exist use ipv6 first then followed by ipv4.

adam commented

2025-12-29 15:31:07 +01:00

@jeremystretch commented on GitHub (Jul 9, 2016):

Just thinking out loud, I see this as entailing three distinct migrations:

Add fields primary_ip4 and primary_ip6 to the Device model.
Copy the value of primary_ip to one or the other, depending on the address family of primary_ip, for all Devices (this is a data migration as opposed to a schema migration).
Delete the primary_ip field from the Device model.

The primary_ip field would become a property on Device which returns primary_ip6 if set, or falls back to primary_ip4.

@jeremystretch commented on GitHub (Jul 9, 2016): Just thinking out loud, I see this as entailing three distinct migrations: 1. Add fields `primary_ip4` and `primary_ip6` to the Device model. 2. Copy the value of `primary_ip` to one or the other, depending on the address family of `primary_ip`, for all Devices (this is a [data migration](https://docs.djangoproject.com/en/1.9/topics/migrations/#data-migrations) as opposed to a schema migration). 3. Delete the `primary_ip` field from the Device model. The `primary_ip` field would become a property on Device which returns `primary_ip6` if set, or falls back to `primary_ip4`.

adam commented

2025-12-29 15:31:08 +01:00

@MaXFalstein commented on GitHub (Jul 11, 2016):

Your last comment is exactly how this should be.

You could do this by keeping the existing variable and setting it to IPv6 or you could do it by finding out if IPv6 is set to anything and then trying that first or reverting to IPv4, again if set, if IPv6 is not supported on that device.

@MaXFalstein commented on GitHub (Jul 11, 2016): Your last comment is exactly how this should be. You could do this by keeping the existing variable and setting it to IPv6 or you could do it by finding out if IPv6 is set to anything and then trying that first or reverting to IPv4, again if set, if IPv6 is not supported on that device.

adam commented

2025-12-29 15:31:08 +01:00

@LBegnaud commented on GitHub (Aug 23, 2016):

@jeremystretch can you comment on what you mean about "For instance, when NetBox reaches out to a device to gather inventory data"? I didn't think netbox was built for that kind of thing.

@LBegnaud commented on GitHub (Aug 23, 2016): @jeremystretch can you comment on what you mean about "For instance, when NetBox reaches out to a device to gather inventory data"? I didn't think netbox was built for that kind of thing.

adam commented

2025-12-29 15:31:08 +01:00

@bellwood commented on GitHub (Aug 24, 2016):

@LBegnaud please see:

https://github.com/digitalocean/netbox/blob/develop/netbox/extras/management/commands/run_inventory.py

That runs inventory for devices via RPC

@bellwood commented on GitHub (Aug 24, 2016): @LBegnaud please see: https://github.com/digitalocean/netbox/blob/develop/netbox/extras/management/commands/run_inventory.py That runs inventory for devices via RPC

adam commented

2025-12-29 15:31:09 +01:00

@jeremystretch commented on GitHub (Aug 24, 2016):

Yeah, it's still a beta-level undocumented feature. It was a rushed implementation that needs more love and care before it can be deemed part of NetBox proper.

@jeremystretch commented on GitHub (Aug 24, 2016): Yeah, it's still a beta-level undocumented feature. It was a rushed implementation that needs more love and care before it can be deemed part of NetBox proper.

adam commented

2025-12-29 15:31:09 +01:00

@LBegnaud commented on GitHub (Aug 24, 2016):

Neat. Thanks for the info!

@LBegnaud commented on GitHub (Aug 24, 2016): Neat. Thanks for the info!

adam referenced this issue

2025-12-29 15:32:47 +01:00

Rack Groups - not visible in Sites #61 #99

adam referenced this issue

2025-12-29 19:27:38 +01:00

Removing and connecting power outlets causes Server Error #5409

adam referenced this issue