On Sat, 2012-08-18 at 01:14 +0200, Olivier Benghozi wrote: Hello, > Ça va du "faut filtrer tout ce qui est plus petit qu'un /21" à "voilà les > allocations selon les pools IANA, faut prévoir 250 lignes de prefixlist", et > bien sûr on peut tenir compte de peering/je garde, transit/je filtre et je > default au moins partiellement.
Le filtrage sur le minimum allocation size des RIR n'est plus possible malheureusement car l'ARIN et le RIPE ont réduit leur minimum allocation size à /24 pour leur blocs IANA. ARIN: Tous leurs blocs IANA sont à /24. http://www.apnic.net/db/min-alloc.html ARIN: 7 blocs IANA sont à /24 actuellement, ils réduisent progressivement le minimum allocation size des autres blocs IANA en fonction des allocations/PI assigment qui se libèrent et des demandes. http://www.arin.net/reference/ip_blocks.html RIPE: "The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29." https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html LACNIC: Pour le moment seul 1 bloc IANA est à /24, les autres sont toujours à /22 comme initialement. http://lacnic.net/en/registro/index.html AFRINIC: La page retourne un 404. http://www.afrinic.net/Registration/resources.htm Le problème sur le filtrage est l'importance du prefix ou de l'AS. Il peut y a avoir des /24 très critiques (comme les root DNS server) ou des sites de contenu très important qui ont un /24 PI. Personnellement, je réfléchi plus à la construction de prefix-list basées sur la criticité que par rapport à la taille du prefix. Après une prefix-list de 250 lignes, c'est rien. Pour rappel de nombreux réseaux générent des prefix-lists automatiquement depuis les AS-MACRO pour tous leurs peerings. Un concept qui serait efficace pour plusieurs choses (filtrage de route, QoS,...), c'est que chaque réseau déclare les adresses IP/prefixes utilisés pour des services critiques dans la base du RIR pour pouvoir construire des prefix-lists automatiquement. Cela permettrai aussi d'aider dans la décision de mise en place de peering, car malheureusement beaucoup de décision sont prise sur un niveau de traffic et non pas sur la criticité d'un service ou sur l'intérêt du service proposé (exemple1: un content provider qui refuse de peerer avec un eye balls provider car il n'y a pas beaucoup de traffic, sauf que cet eye balls provider à que des clients professionnel qui font peu de surf et que du mail - exemple2: les contents providers et les eye balls provider qui refusent de peerer avec les DNS root server (F ISC, M WIDE,...) car le traffic est trop faible (c'est normal que le traffic soit faible car c'est que du traffic DNS mais ce dernier est hautement critique)). > Ceux qui ont vraiment tout plein beaucoup de routes ont dû lâcher les archis > à base de TCAM. Indépendamment du nombre de routes, ce qui s'est vendu comme > des ptits pains après l'époque du 6500, ce sont les MX de Juniper. Pas de > TCAM là-dedans pour la FIB, plusieurs millions de routes supportées. > D'ailleurs en matière de VPNv4, sur les 6500 dans la TCAM, par défaut (et > jusqu'à ce que le Per-VRF Label soit disponible -quoique expérimental- sur > 6500), une route VPNv4 compte double (une entrée dans la partie IPv4, une > dans la partie MPLS), tout comme une route IPv6 (et une route VPNv6 compte > triple). La plate-forme Cisco 6500/7600 est utilise par énormément de réseaux (quelque soit la taille, y compris des gros) comme routeur edge pour livrer leur clients. Je ne les voit pas changer du jour au lendemain tous leurs routeurs car la DFZ ne rentre plus dans la TCAM de leur routeur edge. Beaucoup vont déployer des route-servers et ils vont donc monter les sessions BGP en multi-hop avec leur client. -- Nicolas DEFFAYET --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
