Describe the bug
Unable to update existing Network object due to existing max-prefix values being out of range
To Reproduce
Click edit on an existing network object with (existing) high max-prefix values.
Change or update any fields.
Click save, receive error blocking save.
Expected behavior
Allow save and bypass range check?
Issue is that the max-prefix values are commonly configured on routers with values copied directly from PeeringDB and many router vendors have a default warning threshold of 75%. This means that for larger networks, setting the max-prefix value to highest value as specified by the current allowed range (725546 for IPv4), we'd be above, or really close to the warning threshold (if set to 75% = 546k)...
Who is affected by the problem?
AS1299
What is the impact?
Unable to update network object.
Are there security concerns?
No.
Are there privacy concerns?
No.
What are the proposed actions?
Short term, allow to bypass range check for IPv4 & IPv6 max-prefix fields.
One solution is for larger networks to deprecate the max-prefix values, using "null" (as requested by AS7018 in #1547).
Another solution could be to implement additional fields, "recommended warning threshold in percent", maybe using 90% for larger networks?
Describe the bug Unable to update existing Network object due to existing max-prefix values being out of range
To Reproduce Click edit on an existing network object with (existing) high max-prefix values. Change or update any fields. Click save, receive error blocking save.
Expected behavior Allow save and bypass range check?
Issue is that the max-prefix values are commonly configured on routers with values copied directly from PeeringDB and many router vendors have a default warning threshold of 75%. This means that for larger networks, setting the max-prefix value to highest value as specified by the current allowed range (725546 for IPv4), we'd be above, or really close to the warning threshold (if set to 75% = 546k)...
Who is affected by the problem? AS1299
What is the impact? Unable to update network object.
Are there security concerns? No.
Are there privacy concerns? No.
What are the proposed actions? Short term, allow to bypass range check for IPv4 & IPv6 max-prefix fields.
One solution is for larger networks to deprecate the max-prefix values, using "null" (as requested by AS7018 in #1547).
Another solution could be to implement additional fields, "recommended warning threshold in percent", maybe using 90% for larger networks?
What is the proposed priority? Not super urgent.