Il vaut mieux suivre les recommandations de l'opérateur réseau.

Oui, mais jusqu'à une certaine limite... à part si on le fait pour le kif, aucun intérêt selon moi à pousser les gens à avoir des scripts de rotation/régénération de chaîne d'auth sur leur routeur.
On ajoute de la complexité (et donc un risque de pannes) pour un gain virtuellement nul, et pour ceux qui sont moins à l'aise, c'est des étapes en plus, qu'il faut configurer en SSH, etc.

Plutôt d'accord avec Julien : Si tu commences à compter l'AS-SET pour AS62000 (AS-SET AS-NETRIX), par exemple, tu va te retrouver avec plusieurs centaines de milliers d'IP, liés à nos sous clients, alors que la vaste majorité ne sont pas annoncés via chez nous.

Le mieux reste de se baser uniquement sur les blocs liés à l'AS directement, et là deux solutions :
A/ Se baser sur ce que les IRR autorisent (via bgpq4 par exemple), mais c'est "théorique", ça ne veut pas dire que les blocs sont réellement annoncés/utilisés en ce moment
B/ Se baser sur ce qu'il y a d'annoncé dans la DFZ, par exemple via BGPtools ou HE (https://bgp.tools/as/62000)

Oui effectivement, il semble plus intéressant d'afficher le nb d'IPv4 annoncé par le peer (soit l'AS + ses clients).

Il y a une commande simple pour l'avoir depuis un Linux ?

Non car ca du coup tu auras ceux qui mettent dans leur cone tout et n'importe qui. Du coup sur le LG de l'IX, soit ma commande qui est valable pour dire ce qu'un réseau à en IP.

Désolé mais moi je trouve que ca veut rien dire sinon de dire qu'un AS c'est X IP si ce sont ses clients, ils peuvent prepend a mort et donc 0 traf, ou meme peut s'enlever après....

@zof @simon :

Il vaut mieux suivre les recommandations de l'opérateur réseau.

@nando11 :

L'application d'un correctif à odhcpd a abouti sur une cascade de modifications : DUID global + IAID. Pour en savoir plus, lire le commentaire de Noltari dans le ticket « 25.12.0-rc3 breaks static DHCP from network ».

dhcp.sh

[ -z "$clientid" ] && clientid="$(proto_dhcp_get_default_clientid "$iface")"
[ -n "$clientid" ] && clientid="-x 0x3d:${clientid//:/}"

Commit e24ac1c (odhcp6c)

diff --git a/src/dhcpv6.c b/src/dhcpv6.c
index fa0c2a1..2075006 100644
--- a/src/dhcpv6.c
+++ b/src/dhcpv6.c
@@ -479,9 +479,11 @@ static void dhcpv6_send(enum dhcpv6_msg type, uint8_t trid[3], uint32_t ecs)
        ia_na_entries /= sizeof(*e);
 
        struct dhcpv6_ia_hdr hdr_ia_na = {
-               htons(DHCPV6_OPT_IA_NA),
-               htons(sizeof(hdr_ia_na) - 4),
-               htonl(1), 0, 0
+               .type = htons(DHCPV6_OPT_IA_NA),
+               .len = htons(sizeof(hdr_ia_na) - 4),
+               .iaid = htonl(ifindex),
+               .t1 = 0,
+               .t2 = 0,
        };
 
        struct dhcpv6_ia_addr pa[ia_na_entries];
@@ -1156,7 +1158,7 @@ static int dhcpv6_handle_reply(enum dhcpv6_msg orig, _unused const int rc,
                                        continue;
 
                                // Test ID
-                               if (ia_hdr->iaid != htonl(1) && otype == DHCPV6_OPT_IA_NA)
+                               if (ia_hdr->iaid != htonl(ifindex) && otype == DHCPV6_OPT_IA_NA)
                                        continue;
 
                                uint16_t code = DHCPV6_Success;


En résumé, il n'y a que le changement de DUID qui est potentiellement impactant. Dans la requête d'intégration, on voit que la modif. correspond à IA_NA et pas à IA_PD.

Édit : D'ailleurs c'est assez curieux que IA_PD ne soit pas traité. Un oubli ?

Vivien semble vouloir les blocs annoncé par l'AS et non ceux de ses clients

Ça n’a pas trop d’intérêt, parce que sinon ça veut dire qu’HE et Zayo (ou même Eurofiber) sont des ASes moins importants que Verixi ou Outscale (no offense), alors que c’est complètement faux. Ils ont juste pas les mêmes rôles.
Surtout qu’en plus de mémoire, c’est quelque chose comme seulement ¼ des AS qui n’ont pas de downstream. Donc de fait ça donne des chiffres à trois quart faux.