Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
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/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
On Sat, 2012-08-18 at 03:09 +0200, Jérôme Nicolle wrote: Le 18/08/2012 00:30, Clement Cavadore a écrit : La question à se poser est surtout: pourquoi maintenir une full route, si le coeur de métier n'est pas de vendre du transit BGP derrière ? Ou alors, pourquoi rentrer une full view au chausse pied dans un routeur alors qu'un route server suffit, ou plus simplement de généraliser l'eBGP multihop. Il n'y a malheureusement pas à ma connaissance aujourd'hui de solution clé en main, à très faible coût, avec support, et fiable sur le marché pour déployer des routes-servers ayant une capacité de calcul très rapide pour limiter les temps de convergences. D'ailleurs, l'un d'entre vous pourrait il me dépanner d'un p'tit 6500 avec une SUP720-3B, ou une SUP32, pour faire quelques tests d’agrégateur externe ? Tu peut nous en dire plus sur les tests que tu veut effectuer ? -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
Le 18 août 2012 à 15:51, Nicolas DEFFAYET a écrit : 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. 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. Je voulais dire que ce n'était pas raisonnablement maintenable. Par ailleurs tu soulignes que ce n'est même plus vraiment envisageable, donc bref, sans objet. Bon ensuite je ne vais pas troller sur la validité, l'utilité, la pertinence, la transparence, la fraicheur des informations d'AS-SET (AS-MACRO ayant changé de nom), et sur le risque d'automatiser des mises à jours de prefixlist à grande échelle (cf Level 3) car trolldi c'était hier :) 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 Tout à fait, ça s'est vendu comme des ptits pains dans les années 2000, et de nombreux réseaux y compris internationaux ont été montés avec ces équipements. J'ai pu constater que le MX lui avait grosso modo succédé avec l'évolution des besoins et des débits, par exemple chez les opérateurs de transit. 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. Ceux qui ne peuvent pas faire autrement bricoleront un truc, comme toujours. D'ailleurs la livraison de transit (ou de collecte, ou même de L3VPN) via un switch intermédiaire d'agrégation en L2 (ou comme point de démarcation, façon sucre optique de luxe), pour des petites capa, ça existe déjà. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
Le 18/08/2012 20:31, Olivier Benghozi a écrit : Je voulais dire que ce n'était pas raisonnablement maintenable. Par ailleurs tu soulignes que ce n'est même plus vraiment envisageable, donc bref, sans objet. Bon ensuite je ne vais pas troller sur la validité, l'utilité, la pertinence, la transparence, la fraicheur des informations d'AS-SET (AS-MACRO ayant changé de nom), et sur le risque d'automatiser des mises à jours de prefixlist à grande échelle (cf Level 3) car trolldi c'était hier :) Pour Level3, même si l'automatisation amène des risques, je trouve ça pas mal d'un autre côté de forcer leurs clients à être clean dans la déclaration pour le filtrage. Après la gestion du truc et l'automatisation aveugle c'est un problème potentiel... Tout à fait, ça s'est vendu comme des ptits pains dans les années 2000, et de nombreux réseaux y compris internationaux ont été montés avec ces équipements. J'ai pu constater que le MX lui avait grosso modo succédé avec l'évolution des besoins et des débits, par exemple chez les opérateurs de transit. Quelle est la raison de cette mode globalement ? CLI ? Fonctionnalités ? Prix ? Perfs ? Je n'ai pas encore eu l'occasion d'en tester, Je vois bien les raisons qui amènent à Cisco ou Brocade, je sais à peu près les avantages d'utilisation du Juniper et ce qui plait aux gens qui les utilisent (CLI, commit, souplesse, etc), mais j'imagine qu'il y a quelque chose derrière d'un peu plus business oriented qui explique cette préférence ces dernières années ? (en espérant éviter les discours commerciaux et les avis trop partisans, c'est plus un retour neutre sur la tendance qui m'intéresserait) Ceux qui ne peuvent pas faire autrement bricoleront un truc, comme toujours. D'ailleurs la livraison de transit (ou de collecte, ou même de L3VPN) via un switch intermédiaire d'agrégation en L2 (ou comme point de démarcation, façon sucre optique de luxe), pour des petites capa, ça existe déjà. Surtout quand on multiplie les PoPs et les ports clients. Frederic --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Re: Compte à rebours des 400 000
Bonsoir, Petit retour 7 mois en arrière : Le 11/01/2012 17:35, Jérôme Nicolle a écrit : Bonjour, Si on en croit ce graphe : http://www.cidr-report.org/cgi-bin/plota?file=%2Fvar%2Fdata%2Fbgp%2Fas2.0%2Fbgp-active.txtdescr=Active+BGP+entries+%28FIB%29ylabel=Active+BGP+entries+%28FIB%29range=--OR--StartDate=01%2F06%2F09+00%3A00EndDate=01%2F06%2F12+00%3A00yrange=--OR--ymin=30ymax=40Width=1Height=1with=Stepcolor=autologscale=linear On peut raisonnablement penser que la table de routage dépassera pour de bon les 400k routes d'ici mars ou avril. On l'a bien dépassé, cette limite. L'Internet ne s'est pas écroulé. Mais ça va pas aller en s'arrangeant. bird sh route count 417067 of 417067 routes for 417067 networks Ou, d'après CIDR-report.org : 424954 routes pour 244555 si tout le monde faisait son boulot correctement. Moi, ça va, mon réseau à la maison est en routage software. Mais quid des 3BXL en prod, que va t il se passer quand on dépassera les 512k routes, sur les réseaux qui auront oublié de repartitionner la TCAM ? On a quand même pas mal de mauvais élèves dans la zone FR. Un exemple au TOP20 : AS15557 1215 552 663 54.6% LDCOMNET Societe Francaise du Radiotelephone S.A Un peu moins bon : 3012 AS8218NEO-ASN Neotelecoms Global Backbone 39 10 2 31 8 20.51% Mais il y en a aussi des plutôt bons malgré leur importance : 10425 AS30781 JAGUAR-AS Jaguar Network SAS 16 1 0 15 1 6.25% Alors, quand est ce qu'on fait le ménage sur nos annonces ? Questions : - Est ce que vous envisagez de réduire le nombre de vos annonces dans la mesure du possible, pour repousser un peu l'échéance ? Bon, techniquement, 410k, 450k, 500k routes, ça ne fait pas une grande importance : les vielles brolles de BigIron et SUP720-3B sont déjà hors-ligne, ou hors de la DFZ, mais ça ne doit pas coûter pas grand chose de limiter l'inflation, non ? - Où se situe votre limite, celle au delà de laquelle vous commencerez à ajouter une default route et filtrer certaines annonces ? En fait, la question se pose surtout pour ceuw qui tournent en 3BXL et 2T, et qui ont quelques 100k routes par ci par là en MPLS. Ce serait interessant de savoir qui peut être impacté par la limite des 1M cumulées, sachant qu'au moins 25186 l'a dépassée depuis longtemps. Question subsidiaire : qui tiens le compte des paris sur la date précise de dépassement des 400k routes ? J'ai pas noté la date précise, c'est tombé quand chez vous ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
On Fri, 2012-08-17 at 23:53 +0200, Jérôme Nicolle wrote: Bon, techniquement, 410k, 450k, 500k routes, ça ne fait pas une grande importance : les vielles brolles de BigIron et SUP720-3B sont déjà hors-ligne, ou hors de la DFZ, mais ça ne doit pas coûter pas grand chose de limiter l'inflation, non ? La question à se poser est surtout: pourquoi maintenir une full route, si le coeur de métier n'est pas de vendre du transit BGP derrière ? Soyons réalistes: Si on a deux transitaires sérieux, la longueur de leurs as-path seront (presque) strictement équivalents. Si on se la joue J'ai (n) transitaires équivalents desquels je choppe une fullroute + default (et chez qui je filtre ce qui est longer than /xx) + quelques peerings judicieux pour mon réseau, tu rentres facile a moins de 200k routes. Et ton business va bien sans devoir réinvestir dans ton réseau. PS: Dans la DFZ, sur ~415/420k routes, on a plus de la moitié de /24 (extract pris a l'instant): /0: 0 /8: 19 /9: 14 /10: 29 /11: 84 /12: 236 /13: 475 /14: 848 /15: 1529 /16: 12327 /17: 6358 /18: 10558 /19: 20795 /20: 29807 /21: 31490 /22: 41419 /23: 39357 /24: 218975 ... alors que sur un réseau (34019) avec des bigirons justement, qui filtre les longer than /21 sur les transits (et longer than /24 sur les peerings) /0: 1 /8: 19 /9: 14 /10: 29 /11: 84 /12: 237 /13: 475 /14: 851 /15: 1542 /16: 12438 /17: 6510 /18: 10845 /19: 21354 /20: 30612 /21: 31770 /22: 4074 /23: 4172 /24: 22380 (Total: 150K routes) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
Salut, Le 17 août 2012 à 23:53, Jérôme Nicolle a écrit : Moi, ça va, mon réseau à la maison est en routage software. Mais quid des 3BXL en prod, que va t il se passer quand on dépassera les 512k routes, sur les réseaux qui auront oublié de repartitionner la TCAM ? Bin, comme quand on a dépassé les 192k quand les gens avaient des 3B en prod, c'était en 2005... Certains auront anticipé, d'autres pas; ça ne s'arrête pas forcément de marcher subitement, en principe certains préfixes ne sont juste pas descendus en tcam et ne sont plus joignables. Comme on ne peut pas choisir lesquels, ça peut être rapidement amusant, on verra quels sont les clow^H^H^Hmalchanceux impactés ; mais ça peut aussi bien passer inaperçu quelques temps. On a quand même pas mal de mauvais élèves dans la zone FR. Un exemple au TOP20 : AS15557 1215 552 663 54.6% LDCOMNET Societe Francaise du Radiotelephone S.A Avec tous les rachats, les 150 backbones et l'historique, il est vrai que ce doit être particulier à gérer. Alors, quand est ce qu'on fait le ménage sur nos annonces ? C'est vrai que pour un trolldi, c'était drôlement calme jusqu'à présent :) Bon, techniquement, 410k, 450k, 500k routes, ça ne fait pas une grande importance : les vielles brolles de BigIron et SUP720-3B sont déjà hors-ligne, ou hors de la DFZ, mais ça ne doit pas coûter pas grand chose de limiter l'inflation, non ? J'ai vu pas mal de propositions qui envisageaient grosso modo de filtrer fortement les routes reçues et de rajouter une default. Ç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. Note que ça ne colle pas pour les fournisseurs de transits, très moyennement pour les hébergeurs, et pas trop mal pour les réservoirs d'eyeballs (qui auraient encore des trucs à base de TCAM pour la DFZ). En fait, la question se pose surtout pour ceuw qui tournent en 3BXL et 2T, et qui ont quelques 100k routes par ci par là en MPLS. Ce serait interessant de savoir qui peut être impacté par la limite des 1M cumulées, sachant qu'au moins 25186 l'a dépassée depuis longtemps. 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). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
Alors juste parce que je suis tombé dessus aujourd'hui, mais un ASR1000 avec 16G de RAM (un 1001 par exemple), ça tient selon la datasheet 9 millions de routes. Et encore ça me parait peu. Donc, les routeurs full CPU (les serveurs donc) avec la blinde de RAM, ils n'auront jamais vraiment de soucis. Un ASR1000 avec les dernières SP/RP, ça tient 100G en plus maintenant. Donc c'est faisable un routeur qui tient plein de routes et qui forwarde à la vitesse du paté... Quant aux SUP des 6500 avec leur CPU de machine à laver et leurs 2G de RAM le vent dans le dos ... ouais ben pas de bras, pas de chocolat quoi. Sur une machine qui a fait ses début avant 2000, il fallait s'y attendre. Je compare avec un Nexus 7000, la Sup2 c'est Xeon Quad Core et 12G RAM, une Sup2E c'est BiXeon et 32G de RAM. La encore, c'est pas la Sup qui va pas tenir. Par contre les cartes XL sont toujours limitées à 1 Million de routes (2 fois la DFZ actuelle juste). On peut esperer que des XL++ sortiront un jour prochain avec des vrais ASICs (voire des SOC, c'est surement plus scalables) non limités à 1 Million de routes... De toutes façons, ça doit bien être la même chose chez tout le monde, vu que les constructeurs achetent tous leurs ASIC/SOC chez les mêmes fournisseurs (voire la prez du Nanog 50http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk34.Scholl-Talk34.cheaper.pdf, Slide 5 : Marvel, Broadcom, Fulcrum ... que du développement en interne quoi) En attendant, y a plus qu'à serer les fesses, investir un peu, et faire des filtres à droite à gauche pour limiter la casse. Le routage non optimum sera le prix à payer pour ne pas avoir à upgrader tout son parc ... C'est aussi le prix à payer quand on a pas anticipé, parce que c'est pas comme si on découvrait maintenant que la DFZ explose. Pour les plus motivés, y a plus qu'à acheter des cartes directe chez Marvel/Broadcom/Fulcrum, mettre ça sur un serveur standard, un petit coup de FreeBSD et Bird, et tester combien ça tient. A mon avis, ça sera limité que par les SOC des cartes. Le 18 août 2012 00:30, Clement Cavadore clem...@cavadore.net a écrit : On Fri, 2012-08-17 at 23:53 +0200, Jérôme Nicolle wrote: Bon, techniquement, 410k, 450k, 500k routes, ça ne fait pas une grande importance : les vielles brolles de BigIron et SUP720-3B sont déjà hors-ligne, ou hors de la DFZ, mais ça ne doit pas coûter pas grand chose de limiter l'inflation, non ? La question à se poser est surtout: pourquoi maintenir une full route, si le coeur de métier n'est pas de vendre du transit BGP derrière ? Soyons réalistes: Si on a deux transitaires sérieux, la longueur de leurs as-path seront (presque) strictement équivalents. Si on se la joue J'ai (n) transitaires équivalents desquels je choppe une fullroute + default (et chez qui je filtre ce qui est longer than /xx) + quelques peerings judicieux pour mon réseau, tu rentres facile a moins de 200k routes. Et ton business va bien sans devoir réinvestir dans ton réseau. PS: Dans la DFZ, sur ~415/420k routes, on a plus de la moitié de /24 (extract pris a l'instant): /0: 0 /8: 19 /9: 14 /10: 29 /11: 84 /12: 236 /13: 475 /14: 848 /15: 1529 /16: 12327 /17: 6358 /18: 10558 /19: 20795 /20: 29807 /21: 31490 /22: 41419 /23: 39357 /24: 218975 ... alors que sur un réseau (34019) avec des bigirons justement, qui filtre les longer than /21 sur les transits (et longer than /24 sur les peerings) /0: 1 /8: 19 /9: 14 /10: 29 /11: 84 /12: 237 /13: 475 /14: 851 /15: 1542 /16: 12438 /17: 6510 /18: 10845 /19: 21354 /20: 30612 /21: 31770 /22: 4074 /23: 4172 /24: 22380 (Total: 150K routes) --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
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. A mon avis, chez Google, il tourne plus sur du TCAM. Ils doivent plus avoir des masses de constructeurs non plus. Ils doivent connaitre leurs softs aussi ... http://code.google.com/p/google-quagga/source/browse/ http://code.google.com/p/opensource-lsr/ https://sites.google.com/site/routeflow/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: Compte à rebours des 400 000
Le 18/08/2012 00:30, Clement Cavadore a écrit : La question à se poser est surtout: pourquoi maintenir une full route, si le coeur de métier n'est pas de vendre du transit BGP derrière ? Ou alors, pourquoi rentrer une full view au chausse pied dans un routeur alors qu'un route server suffit, ou plus simplement de généraliser l'eBGP multihop. Après tout, avec RPKI+ROA et OpenFlow, on va déléguer le control-plane à des serveurs pour que les routeurs ne fassent plus que leur boulot... Soyons réalistes: Si on a deux transitaires sérieux, BINGO ! C'est quoi pour toi, un transitaire sérieux ? Un qui applique à la lettre toutes les best-practices ? Qui peere bien partout comme il faut ? Qui va être suffisament bien connecté pour ne pas être facilement hijacké par une Pilosov à Kapella ? la longueur de leurs as-path seront (presque) strictement équivalents. Si on se la joue J'ai (n) transitaires équivalents desquels je choppe une fullroute + default (et chez qui je filtre ce qui est longer than /xx) + quelques peerings judicieux pour mon réseau, tu rentres facile a moins de 200k routes. Et ton business va bien sans devoir réinvestir dans ton réseau. Investir en hardware, je suppose. Parce que le plus gros investissement du réseau, ça reste de l'humain pour gérer la partie administrative et bien tout filtrer comme il faut, non ? PS: Dans la DFZ, sur ~415/420k routes, on a plus de la moitié de /24 (extract pris a l'instant): Ah ben j'ai fais le mien hier : http://dedibox.nicolbolas.org/tmp/prefix-distribution.png sur AS197422.On est en soft sur celui là, donc pas de problème. D'ailleurs, l'un d'entre vous pourrait il me dépanner d'un p'tit 6500 avec une SUP720-3B, ou une SUP32, pour faire quelques tests d’agrégateur externe ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
