SDN: IPAM NetBox: "create sdn subnet object failed: error add subnet ip to ipam: ip 10.0.0.1 already exist"

M

MathieuMD

Member
Jun 2, 2022
3
0
6
While trying to add a subnet to a VNet, PVE fails because the subnet's gateway is already existing in NetBox. The error popup says:
create sdn subnet object failed: error add subnet ip to ipam: ip 10.0.0.1 already exist: at /usr/share/perl5/PVE/Network/SDN/Ipams/NetboxPlugin.pm line 109. (500)
Click to expand...
I could create subnets whose gateway was not yet existing in NetBox, though.
Is it normal behavior? I guess it should silently ignore already existing IPs.
 
Same Problem here. But the gateway is not available in Netbox. Clear new Subnet without an entry in Netbox. Is it a bug in „NetboxPlugin.pm line 80. (500)“?
 
f931dc8a6b said:
Same Problem here. But the gateway is not available in Netbox. Clear new Subnet without an entry in Netbox. Is it a bug in „NetboxPlugin.pm line 80. (500)“?
Click to expand...
Are you using PVE 8.4? Are you sure that there is not an entry for that prefix in Netbox? (API endpoint /ipam/prefixes/)
 
shanreich said:
Are you using PVE 8.4? Are you sure that there is not an entry for that prefix in Netbox? (API endpoint /ipam/prefixes/)
Click to expand...
Hello shanreich
have the same issue in 8.4.1.
Deleted the entry in Netbox - Error is still shown. (even after several minutes)

BUT - i dont like to delete something in Netbox!
Maybe its an oversight from Proxmox, that Netbox is a planning and SoT Tool?
Have already planned nearly 80 prefixes and 40 IPs in Netbox - which i will for sure not delete ;)
 
MrNobody_ said:
BUT - i dont like to delete something in Netbox!
Maybe its an oversight from Proxmox, that Netbox is a planning and SoT Tool?
Have already planned nearly 80 prefixes and 40 IPs in Netbox - which i will for sure not delete ;)
Click to expand...
Same case here, our network team manages thousands of subnets and also has many if not most already pre-provisioned with extra information in Netbox.
If not silently/with warning ignored, it would be nice if it just tells you that the prefix already exists and asks if you really want to use that subnet.
 
  • Like
Reactions: MrNobody_
lumarel said:
Same case here, our network team manages thousands of subnets and also has many if not most already pre-provisioned with extra information in Netbox.
If not silently/with warning ignored, it would be nice if it just tells you that the prefix already exists and asks if you really want to use that subnet.
Click to expand...
my first intention was to give an prefix the ..
  • state "planned" (custom state)
    • allowed to use
    • using it in the SDN/other automation - the state will change to "active"
  • state "reserved"
    • should block any use in SDN (or similar automation)
  • state "active"
    • should block any use in SDN (or similar automation)
  • state "deprecated"
    • should also block any use - because its actual in use and needs deprovision first
  • state "Container"
    • can be ignored
  • no match
    • free to use (eventually)
AND .. BUT
des ganze geht dann noch auf wie ein Germteig..
The actual implementation from the IPAM Netbox plugin in Proxmox has no possibility to limit (scope it) it to an Site, Tenant, Role and/or VRF.
 
Last edited:
  • Like
Reactions: lumarel
@MrNobody_ Already see you have a very good idea how this has to work, and I can only agree.
One more thing, on SDN deletion, just deleting the Netbox object might not always be the best idea, setting it to deprecated would be a better idea (or having the option in the settings to either always delete, deprecate or ask) (uh.. the thing you said above I guess)
 
Last edited:
Hi!
not a netbox expert, so please bear with me :)
The actual implementation from the IPAM Netbox plugin in Proxmox has no possibility to limit (scope it) it to an Site, Tenant, Role and/or VRF.
Click to expand...
This shouldn't be too hard, we could add a optional vrf, tenant and role properties to the netbox ipam plugin and then just throw them into the api requests. I can't add a prefix to a Site AFAICT, so that wouldn't apply to us.
MrNobody_ said:
  • state "planned" (custom state)
    • allowed to use
    • using it in the SDN/other automation - the state will change to "active"
  • state "reserved"
    • should block any use in SDN (or similar automation)
  • state "active"
    • should block any use in SDN (or similar automation)
  • state "deprecated"
    • should also block any use - because its actual in use and needs deprovision first
  • state "Container"
    • can be ignored
  • no match
    • free to use (eventually)
Click to expand...

Do you mean that PVE should verify the state of the prefix before assigning an IP? If the prefix is marked as "deprecated," should it prevent IP allocations?
Among the built-in status states, the only one that would IMO deny IP allocation is "reserved," but I don't think we should restrict the user in this case.
 
Last edited:
  • Like
Reactions: lumarel
ggoller said:
Do you mean that PVE should verify the state of the prefix before assigning an IP? If the prefix is marked as "deprecated," should it prevent IP allocations?
Among the built-in status states, the only one that would IMO deny IP allocation is "reserved," but I don't think we should restrict the user in this case.
Click to expand...
That's actually mostly for the prefix creation, so the check that it's already doing just with more checks,
if the prefix is marked as deprecated, it shouldn't be able to use it, because it's marked for tearing down by (most likely) the network team and they might not be done with the cleanup in the campus network. (routing, vlan, ...)

though also makes sense for ip-addresses, like planned could be, you already told the network team what IP it will have so they can prepare firewall exclusions (to internet, inter network rules, client access rules, ...) (and the other way around on deprecated)
while active is maybe used by a network component or other device that is not managed by the SDN integration.
 
Last edited:
ggoller said:
Hi!
not a netbox expert, so please bear with me :)

This shouldn't be too hard, we could add a optional vrf, tenant and role properties to the netbox ipam plugin and then just throw them into the api requests. I can't add a prefix to a Site AFAICT, so that wouldn't apply to us.


Do you mean that PVE should verify the state of the prefix before assigning an IP? If the prefix is marked as "deprecated," should it prevent IP allocations?
Among the built-in status states, the only one that would IMO deny IP allocation is "reserved," but I don't think we should restrict the user in this case.
Click to expand...

Hello Gabriel,

me to .. have just experience.
Netbox is quite flexible in use and allows even some customising.
You can use it for a Homelab or an Enterprise or even Service Provider (i think).

Let's split it in separate parts..

Scoping:
it depends on the Usecase
  • Site
  • Tenant
  • Tenant Group
  • VLan
  • VLan Group
  • Role
  • VRF
  • Tags
--> It can be just 1 of them or even up to all together.

States:
It depends - think some will use an IPAM as:
  • Holy Grail / SSoT (Single Source of Truth) / Source for Ansible or some other IaC
    • very restrictive
    • "what's not in the book, will not exist in real"
or use it more like an:
  • SoT (Source of Truth) / Documentation
    • less restrictive
      • restrict what is already in IPAM (based on the state codes)
        • block: used, deprecated, reserved, ..
        • allow: planed and non existent
    • non restrictive
      • add freely
      • update existing
--> an "Mode selection" could solve it.
  • IPAM is "God/King/Joker"
  • IPAM gives "Guidelines"
  • IPAM? who the f**k is IPAM?
--> possibility to customise states in the plugin, so that someone can easy fit it to the requirements


just my "5 cents"
 
  • Like
Reactions: lumarel
You must log in or register to reply here.
Top Bottom