-
Notifications
You must be signed in to change notification settings - Fork 174
Description
I think it's about time to finally add a field in IXP Manager for IPv6 maximum prefix.
I think this was mostly for historical reasons.
- PeeringDB has separate fields for IPv4 and IPv6 maximum prefixes. PeeringDB have also added some help text to this field to clarify what is actually meant. (Networks were entering different numbers here - either the actual number of advertised prefixes, the "maximum" number of prefixes (actual+some number), or some other made-up number. It still needs to be sanity checked, but mostly it's a good starting point.)
- The IX-F JSON export schema supports separate maximum prefix for IPv4 and IPv6. But we fudge it using the IPv4 max prefix.
Many ASNs advertise a vastly different number of prefixes for IPv4/IPv6, for example they may suggest 10000 IPv4 prefixes, but only a very small number of IPv6 prefixes. (only a handful, or < 1000)
Unfortunately this limitation in IXP Manager means we have to set the (usually) higher number for IPv4 maximum prefixes for IPv6. It means the collector/looking glass/max prefix warnings etc for IPv6 do not function as they should, and we are exporting inaccurate data via our ix-f export. Also, with the v7 Member Diagnostics tool, it's helpful if we use the correct numbers. (Avoid "false negative" check on IPv6 max prefix showing all ok, when it may not be ok.)
"vlan_list": [
{
"vlan_id": 1,
"ipv4": {
"address": "5.57.81.xx",
"as_macro": "AS-xxxxxx",
"routeserver": false,
"mac_addresses": [
"xx:xx:xx:xx:xx:xx"
],
"max_prefix": 1000
},
"ipv6": {
"address": "2001:7f8:17::xxx:x",
"as_macro": "AS-xxxxxx",
"routeserver": false,
"mac_addresses": [
"xx:xx:xx:xx:xx:xx"
],
"max_prefix": 1000
}
}
]
},
As a migration path:
-
The number could either be auto-populated from PeeringDB if available for the ASN, and/or if not available, use the number currently set for IPv4.
-
Collector / lg can be used to set "warn" mode on import limit as a soft check, with receive limit used as a "hard" check if the number exceeds some default big number to protect against obvious route leaks/misconfigurations.
I am currently replacing our cisco collector with BIRD, and testing various ideas for max prefix warning/session restart options. (BIRD doesn't have as many options as Cisco for max-prefix warning/shutdown/restart.)