Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On 18 Jan 2012, at 05:59, Michel Py wrote: Michel Py a écrit : Je crois que j'ai saisi maintenant; tu sépares control-plane et forwarding-plane, tu fais ta control-plane et ta moulinette dans un PC avec de la RAM et c'est le switch qui fait la forwarding plane et qui pousse les paquets. C'est suffisamment tordu comme idée pour être intéressant :P C'est le principe d'OpenFlow, ce n'est pas tordu. http://en.wikipedia.org/wiki/OpenFlow http://www.openflow.org/ En théorie, ça peut marcher. Ceci dit, Le RR et le switch n'ont pas la même IP, donc va falloir changer le next-hop des routes que tu annonces et remplacer l'IP du RR par l'IP du switch, mais bon c'est pour ça que route-map a été inventé. Au niveau codage, je ne vois pas quelle autre solution tu as que de modifier un des bgpd opensource. Sinon BIRD est le daemon BGP utilisé par les IX pour leurs route servers, donc le code est bien testé. Mais c'est le genre de magouille pour lesquelles ExaBGP a reçu tant de petits soins récemment : regarde la dernière version pour prendre conscience de toutes clownerie possibles : ton code, tes magouilles. Tu peux lire les routes (forme textuelle) reçues des peers en STDIN, faire ce que tu veux et diffuser le résultat au même (au d'autres peers) via STDOUT. http://code.google.com/p/exabgp/source/browse/#hg%2Fetc%2Fexabgp%2Fprocesses Au niveau pratique, ça fait quand même un peu usine à gaz sur les bords. 2 boites, 2 fois le risque de panne, 3 fois la complexité... Plutot, usine nucléaire en zone sismique :D Va falloir avoir un budget Stroh important Il va vraiment falloir que je découvre le Stroh, il semble que j'ai toutes le prédispositions pour aimer :p J'ai plus confiance en un speaker BGP opensource que dans les implémentations de cisco et juniper, en tout cas pour des choses simples comme ça. Pas moi, surtout quand c'est un clown de mon genre qui pisse du code de porc qui modifie un opensource. C'est clairement le cas, mais on trouve les même codeurs chez Juniper/Cisco/... :D Plus tu as de next-hop *en transit*, car les routes des peers sont peu ou pas modifiées finalement. Oui, les routes des peers on essaie de ne pas toucher, merci pour la précision. Centraliser BGP avec des serveurs qui ne font que route reflector est un design assez déployé. C'est pour cela que les operateurs poussent http://tools.ietf.org/html/draft-ietf-idr-bgp-multisession-06 Afin qu'un bug sur une session BGP IPv6 (par exemple) ne fassent pas tomber leur réseau MPLS avec SLA. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Bonjour, Tu construis ton propre DIY Juniper-like avec le control-plane (PC avec une cargaison d'el-cheapo DDR) et le forwarding-plane (L3 switch avec pas trop de TCAM) que tu peux acheter à pas cher et, tu utilises iBGP comme protocole de transmission de la RIB. En théorie, ça peut marcher. Ceci dit, Le RR et le switch n'ont pas la même IP, donc va falloir changer le next-hop des routes que tu annonces et remplacer l'IP du RR par l'IP du switch, mais bon c'est pour ça que route-map a été inventé. Au niveau codage, je ne vois pas quelle autre solution tu as que de modifier un des bgpd opensource. A moins que tu n'aies envie de réinventer la roue, il te faut au minimum une session BGP solide entre le RR et le switch, ce qui implique entre autres de bien comprendre comment fonctionne la FSM BGP et autres concepts importants. La solution à court terme est que ta moulinette tagges les préfixes de la RIB réduite à l'intérieur de la RIB complète dans le RR et d'avoir une route-map en sortie vers le switch qui n'annonce que celles-là. N'est-ce pas possible d'ajouter les routes directement sur le switch (j'entends, sans passer par BGP) ? On pourrait arriver à une vraie isolation du control plane et du forwarding plane: - Le PC s'occupe de BGP, génère les routes, les charge dans le routeur - On désactive tout le control plane sur le switch (y compris BGP, contrairement à ce que tu proposes), lequel ne s'occupe *que* de routage Question dans le même esprit: N'y a-t-il pas des moyens de charger ses propres routes dans les switchs Cisco, Juniper, ..., sans utiliser l'interface cli ? SNMP ne sait pas faire ça ? Bref, je ne comprends pas la nécessité de maintenir une session BGP si tout cela est possible. Au niveau pratique, ça fait quand même un peu usine à gaz sur les bords. 2 boites, 2 fois le risque de panne, 3 fois la complexité... Va falloir avoir un budget Stroh important pour que les gens mettent ça en prod au lieu d'une prefix-list ou de quelques malheureux milliers de galacticredits pour acheter une PFC3BXL toute neuve qui te donne 1 million de routes. Pas nécessairement. Après tout dans un routeur tu as déjà cette archi: un système pour le control plane, un système pour le forwarding plane. C'est juste qu'ils le cachent et ils vendent un bouzin tout intégré. Je ne suis pas admin réseau, mais ce monde gagnerait peut être en flexibilité à permettre l'utilisation de composants de constructeurs différents ? (On prend le forwarding plane chez X parce qu'il est plus rapide, et le control plane chez Y qui a les fonctionnalités que l'on veut (par exemple, IPv6 dans la version de base de l'OS ! ;) ) ) Faut avoir vraiment confiance dans le PC et dans le système entier; j'avais dans l'idée de recevoir le feed sur le switch, en le filtrant. J'ai plus confiance en un speaker BGP opensource que dans les implémentations de cisco et juniper, en tout cas pour des choses simples comme ça. Pas moi, surtout quand c'est un clown de mon genre qui pisse du code de porc qui modifie un opensource. C'est le principe de l'opensource. Ton code de porc, s'il est intéressant, il sera testé et débuggé (si tant est que tu aies implémenté des bugs :) ). --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
N'est-ce pas possible d'ajouter les routes directement sur le switch (j'entends, sans passer par BGP) ? La presentation est demain :D http://www.uknof.org.uk/uknof21/King-SDN.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le 18/01/12 10:22, Emmanuel Thierry a écrit : N'est-ce pas possible d'ajouter les routes directement sur le switch (j'entends, sans passer par BGP) ? dans le cas présent, on ne se sert de BGP que pour une session et pour un nombre limité de routes. C'est le cas d'utilisation le plus simple possible de BGP, donc ça ne pose pas de problème. Si FORCES était implémenté sur ce genre d'équipements on aurait pu l'utiliser à la place mais c'est trop rare pour être considéré pour l'instant. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le seul inconvénient de ce montage, c'est qu'il n'est pas simple d'être transparent pour les peers. Il n'y a pas de proxy BGP sur les GroSwitchs, au mieux une capacité limitée de faire du NAPT. C'est suffisant, mais c'est moche :( J'ai pas percuté sur cette partie-là, èsseupliques? Michel. Je pense qu'il pointe le fait qu'un setup pareil oblige à monter ses sessions BGP d'une manière particulière avec tes peers/transitaires, ie vers ton RR en multihop, avec route vers le RR nécessaire sur le border router de ton peer/transitaire. C'est un des petits inconvénients en tout cas que je vois à l'idée. Sinon, vue la taille des tables possibles sur les switches actuels, il faut quand même que statistiquement, le gain soit gros. On est pas dans les 20k routes possibles max sur des switches 10G? Bastien Pilat --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le 18/01/12 11:48, PILAT Bastien a écrit : Je pense qu'il pointe le fait qu'un setup pareil oblige à monter ses sessions BGP d'une manière particulière avec tes peers/transitaires, ie vers ton RR en multihop, avec route vers le RR nécessaire sur le border router de ton peer/transitaire. C'est un des petits inconvénients en tout cas que je vois à l'idée. Dans une optique de transparence vis à vis des peers, j'ai envisagé une méthode très crade de NAT statique du 179/TCP de l'IP d'interco du switch vers le RR, sur le papier ça marche pour le v4. Pour le v6, les subnets d'intercos sont plus souvent des /64 que des /126, mais je n'ai pas trouvé de feedback sur un fonctionnement à la fois L2 et L3 sur la plupart des switchs L3, donc je vais encore me gratter la tête un moment : le suport du NAPT 66 sur du vieux matos risque d'être problématique. Sinon, vue la taille des tables possibles sur les switches actuels, il faut quand même que statistiquement, le gain soit gros. On est pas dans les 20k routes possibles max sur des switches 10G? Je n'ai pas considéré les limites de matos récents vu que j'avais plus dans l'idée de faciliter la survie de petits réseaux fauchés que de faire faire des économies de bout de chandelles à quelques grosses infras. C'est plus les 256k routes de quelques papy-routers ou les 32 à 128k routes de quelques switchs gigabit L3 faciles à trouver en broke qui m'intéresse en premier lieu. Après tu as une notion de résolution de la table qui peut être défini comme parametre de l'algorithme de factorisation. C'est surtout valable dans le cas d'un load-balancing relativement naïf entre plusieurs transitaires. Tu peux vouloir tout splitter au /24 pour répartir de façon aussi homogène que possible, dans quel cas tu vas te retrouver avec quelques millions de routes, ou au contraire splitter au /8 et avoir une base de 200 routes à laquelle tu rajoutes les prefixes de peers reçus par certaines sessions, façon guirlande dans un sapin de noel. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Jérôme Nicolle a écrit: Dans une optique de transparence vis à vis des peers, j'ai envisagé une méthode très crade de NAT statique du 179/TCP de l'IP d'interco du switch vers le RR, sur le papier ça marche pour le v4. C'est plus que crade, c'est innommable. En général je suis plutôt pro-NAT, mais faire passer un full-feed à travers NAT pour le mouliner et réinjecter les routes dans le même routeur qui fait NAT, sur ce coup-là tu vas au bûcher direct. Est-ce que ça marche, en plus? Faudrait pas un ALG BGP pour NAT des fois? vu que j'avais plus dans l'idée de faciliter la survie de petits réseaux fauchés que de faire faire des économies de bout de chandelles à quelques grosses infras. C'est plus les 256k routes de quelques papy-routers ou les 32 à 128k routes de quelques switchs gigabit L3 faciles à trouver en broke qui m'intéresse en premier lieu. J'avais bien saisi cette part-là, je suis d'accord. Après tu as une notion de résolution de la table qui peut être défini comme parametre de l'algorithme de factorisation. C'est surtout valable dans le cas d'un load-balancing relativement naïf entre plusieurs transitaires. Tu peux vouloir tout splitter au /24 pour répartir de façon aussi homogène que possible, dans quel cas tu vas te retrouver avec quelques millions de routes, ou au contraire splitter au /8 et avoir une base de 200 routes à laquelle tu rajoutes les prefixes de peers reçus par certaines sessions, façon guirlande dans un sapin de noel. Gardes tes yeux sur le ballon, et attention à ne pas succomber au syndrome IETF et à créer une usine à gaz simplement parce que c'est possible. Revenons à l'objectif: la survie du routeur de papy dans un petit réseau. Explique moi en quoi ton système est supérieur à la prefix-list classique telle que décrite par Clément ou Radu. Faut au moins 1 avantage, et le trafic sortant est un peu moins sous-optimisé ça pèse rien comparé à la complexité, aux emmerdes consistant à avoir un /29 sur les liens au lieu d'un /30, ou aux bidouilles goret genre NAT. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Michel Py a écrit : Je crois que j'ai saisi maintenant; tu sépares control-plane et forwarding-plane, tu fais ta control-plane et ta moulinette dans un PC avec de la RAM et c'est le switch qui fait la forwarding plane et qui pousse les paquets. Donc le switch n'a même pas de session BGP avec les transits, c'est le PC qui lui donne directement la RIB réduite. Jérôme Nicolle a écrit: C'est ça, et c'est pourquoi j'étais en train de me grater la tête en comprenant pourquoi tu parlais de prefix-list. C'est suffisamment tordu comme idée pour être intéressant :P Tu construis ton propre DIY Juniper-like avec le control-plane (PC avec une cargaison d'el-cheapo DDR) et le forwarding-plane (L3 switch avec pas trop de TCAM) que tu peux acheter à pas cher et, tu utilises iBGP comme protocole de transmission de la RIB. En théorie, ça peut marcher. Ceci dit, Le RR et le switch n'ont pas la même IP, donc va falloir changer le next-hop des routes que tu annonces et remplacer l'IP du RR par l'IP du switch, mais bon c'est pour ça que route-map a été inventé. Au niveau codage, je ne vois pas quelle autre solution tu as que de modifier un des bgpd opensource. A moins que tu n'aies envie de réinventer la roue, il te faut au minimum une session BGP solide entre le RR et le switch, ce qui implique entre autres de bien comprendre comment fonctionne la FSM BGP et autres concepts importants. La solution à court terme est que ta moulinette tagges les préfixes de la RIB réduite à l'intérieur de la RIB complète dans le RR et d'avoir une route-map en sortie vers le switch qui n'annonce que celles-là. Au niveau pratique, ça fait quand même un peu usine à gaz sur les bords. 2 boites, 2 fois le risque de panne, 3 fois la complexité... Va falloir avoir un budget Stroh important pour que les gens mettent ça en prod au lieu d'une prefix-list ou de quelques malheureux milliers de galacticredits pour acheter une PFC3BXL toute neuve qui te donne 1 million de routes. http://www.router-switch.com/ws-f6k-pfc3bxl=-p-2085.html La vérité dans la pub: c'est une config que je n'ai pas encore faite, d'ailleurs. Est-ce que quelqu'un ici a déjà remplacé une PFC3B par une PFC3BXL sur un SUP720? En théorie c'est field-upgradable. Faut avoir vraiment confiance dans le PC et dans le système entier; j'avais dans l'idée de recevoir le feed sur le switch, en le filtrant. J'ai plus confiance en un speaker BGP opensource que dans les implémentations de cisco et juniper, en tout cas pour des choses simples comme ça. Pas moi, surtout quand c'est un clown de mon genre qui pisse du code de porc qui modifie un opensource. Pour du MPLS ou du LISP, ils sont surement plus avancés. Pour ce que tu veux faire ça n'a pas vraiment d'importance. Même si ton transit est MPLS, c'est transparent pour toi. Quand au PC, qu'il soit dans le route-processour ou dans le rack d'à coté, c'est bien la même chose, non ? Oui, surtout avec une carte réseau dédiée à ça. Bertrand Yvain a écrit: J'imagine que le gain dépend largement du nombre de peers eBGP (de next-hops en fait). En partie seulement; c'est clair que plus tu as de next-hops moins de gain, ceci dit. Plus tu as de next-hop *en transit*, car les routes des peers sont peu ou pas modifiées finalement. Oui, les routes des peers on essaie de ne pas toucher, merci pour la précision. Ca ne me semble pas être une bonne idée de n'avoir qu'une seule route par défaut. Si tu ne fais pas comme Clement (avoir chaque transit qui te l'annonce) il faut au moins avoir une ou plusieurs floating-static, AMHA. Pas grave, puisqu'elle est crée par le RR ; Pas convaincu. La fullbogons sur un PE, bof, plutot sur un RR qui distribue entre tes upstream et tes PE. Je ne vois pas ce que ça change? Ou alors j'ai pas bien compris ce que tu suggères. Je crois que c'est plus clair maintenant, non ? Même dans cette nouvelle lumière, le cas des fulllbogons est spécial: non seulement ils sont déjà complètement agrégés (aucun gain possible) mais en plus l'idée c'est précisément de les mettre dans les PE pour stopper la merde le plus rapidement possible. Les fullbogons ce sont des routes qui servent à envoyer le trafic vérolé dans Null0. troll Evidemment ça serait mieux si tout le monde (et en particulier tes FAI ET celui du PC zombie qui est en train de te DDOSser avec un bogon) avaient une route-map pour dégager les saloperies dans Null0 au lieu que ça soit toi qui le fasse. /troll Le seul inconvénient de ce montage, c'est qu'il n'est pas simple d'être transparent pour les peers. Il n'y a pas de proxy BGP sur les GroSwitchs, au mieux une capacité limitée de faire du NAPT. C'est suffisant, mais c'est moche :( J'ai pas percuté sur cette partie-là, èsseupliques? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le 15 janvier 2012 23:33, Serge Marienon smarie...@gmail.com a écrit : En quoi c'est sale ??? C'est inévitable et nécessaire. Si tu reçoit tous les préfixes désagrégés et que tes policies les font au final toutes passer par le même hop, non, tu n'en as pas besoin. Tu réagrèges et tu met ton upstream en next-hop, et tu gagnes quelques centaines de routes. Le 15 janvier 2012 22:55, Michel Py mic...@arneill-py.sacramento.ca.us a écrit : Pour le faire proprement il faut rajouter 49000 fullbogons, ça fait 56k soit l'équivalent de la consommation TCAM de 112k routes IPv4. La fullbogons sur un PE, bof, plutot sur un RR qui distribue entre tes upstream et tes PE. Question pour tout le monde qui filtre les routes: qu'est ce que vous avez comme routeur? Ces jours-ci pour un Cisco 7600 un SUP720-3BXL qui prend 1 million de routes ça ce trouve pour $25k. Juniper j'ai aucune idée des prix. Un MX80 sort à partir de 8k€, comme un CER2024 à peu près. La partie qui injecte ça dans le routeur je n'ai pas ça en stock, ceci dit. Il y a des gens avec du temps pour se pencher sur ce genre de chose? Ca pourrait être un projet sympa. Ben je me gratte la tête là dessus en ce moment, mais je code trop mal pour l'implémenter, j'ai besoin d'aide. L'idée est de construire une RIB complète puis de la factoriser sous forme d'arbre binaire dont on colorie les branches en fonction du next-hop. A la lecture, on reconstruit une RIB factorisée sur les couleurs (ou next-hops) et ça correspond au strict minimum d'informations dont le control-place a besoin pour que les décisions de forwarding correspondent aux policies du control-plane. Fait en soft sur un route-reflector, ça consomme que de la RAM et ça permet (en rabottant un peu la FIB résultante si nécessaire) de se contenter de switchs L3 en edge (avec des TCAM 200k routes). De quoi faire de sacrés économies sur le hardware pour des petits réseaux... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
L'idée est de construire une RIB complète puis de la factoriser sous forme d'arbre binaire dont on colorie les branches en fonction du next-hop. A la lecture, on reconstruit une RIB factorisée sur les couleurs (ou next-hops) et ça correspond au strict minimum d'informations dont le control-place a besoin pour que les décisions de forwarding correspondent aux policies du control-plane. Si je comprends ce que tu veux dire, ce n'est pas suffisant. Ce que je comprends: à partir de la RIB complète tu construis la RIB réduite en enlevant les préfixes longs qui ont le même next-hop qu'un préfixe plus court (ou en copiant dans la RIB réduite uniquement les préfixes courts qui ont le même next-hop qu'un préfixe plus long). Ce qu'il faut construire, c'est non pas la RIB de taille réduite mais la préfix-list d'une taille raisonnable qui permet de filtrer le full-feed. Si pour réduire ta RIB de 100k routes il te faut une prefix-list de 50k lignes, tu as perdu la bataille. Ceci se complique encore plus quand tu as plusieurs prefix-list en utilisation (une par peer-group); donc dans ta FIB il faut incorporer la notion de catégorie de next-hop et autoriser que le même préfixe long soit filtré sur une catégorie de next-hop et pas sur l'autre. Donc oui la RIB de taille réduite est l'objectif final mais, à moins que le processus soit incorporé dans le code BGP (qu'en disent Cisco et Juniper?), ce que ta moulinette doit produire c'est la configuration de filtrage du full-feed, avec plusieurs peer-groups, et en tenant compte de contraintes du genre taille de la NVRAM et autres. Stephane Bortzmeyer a écrit: L'idée me parait excellente et je ne sais pas pourquoi elle n'a jamais été faite. Ce n'est pas la première fois qu'on a parle. Il y a 10 ans, quand on a commencé à réaliser que les tentatives de garder la table IPv6 agrégée allaient toutes foirer, il y a quelques personnes qui ont discuté cette idée. Quelqu'un a-t-il fait des simulations avec une vraie table de routage d'un vrai routeur pour voir combien exactement on gagnait ? C'est vachement variable en fonction de la topologie, mais on peut espérer une division par 3 comme idée de base; mes chiffres sont démodés, ceci dit. Mais là encore on parle de gain théorique. Jérôme Nicolle a écrit: Sur AS197422, en simulation, je tombe à 70k routes sur le routeur parisien. Mais mon algo est loin d'être optimisé et je n'ai pas testé sur un replay pour l'instant. Avec une préfix-list de combien de long, ou est-ce que c'est le minimum théorique de la RIB requise sans considération de comment tu la construis? Bertrand Yvain a écrit: J'imagine que le gain dépend largement du nombre de peers eBGP (de next-hops en fait). En partie seulement; c'est clair que plus tu as de next-hops moins de gain, ceci dit. Dans le cas trivial d'un AS stub avec un seul upstream, tu devrais tomber à 1 route. Seulement si tu inclus 0.0.0.0/0 dans les calculs, ce qui ne me semble pas être une bonne idée. Jérôme Nicolle a écrit: Le problème, c'est le cas ou on perde le next-hop correspondant à la route par defaut. Ca ne me semble pas être une bonne idée de n'avoir qu'une seule route par défaut. Si tu ne fais pas comme Clement (avoir chaque transit qui te l'annonce) il faut au moins avoir une ou plusieurs floating-static, AMHA. La fullbogons sur un PE, bof, plutot sur un RR qui distribue entre tes upstream et tes PE. Je ne vois pas ce que ça change? Ou alors j'ai pas bien compris ce que tu suggères. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Jérôme Nicolle a écrit: Fait en soft sur un route-reflector, ça consomme que de la RAM et ça permet (en rabottant un peu la FIB résultante si nécessaire) de se contenter de switchs L3 en edge (avec des TCAM 200k routes). Je crois que j'ai saisi maintenant; tu sépares control-plane et forwarding-plane, tu fais ta control-plane et ta moulinette dans un PC avec de la RAM et c'est le switch qui fait la forwarding plane et qui pousse les paquets. Donc le switch n'a même pas de session BGP avec les transits, c'est le PC qui lui donne directement la RIB réduite. Faut avoir vraiment confiance dans le PC et dans le système entier; j'avais dans l'idée de recevoir le feed sur le switch, en le filtrant. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Pascal Rullier a écrit: Friday, December 23, 2011 8:24 AM - Passer en ipv6 :) ~7700 routes ipv6 vs ~38 routes ipv4 Pour le faire proprement il faut rajouter 49000 fullbogons, ça fait 56k soit l'équivalent de la consommation TCAM de 112k routes IPv4. Radu-Adrian Feurdean a écrit: Friday, December 23, 2011 8:52 AM Sinon, filtrer tous les more specifics dans quelques /8 provider-based (4, 8, 12, 38, ...) ca elimine quand-meme una utre paquet de routes. Tu as un exemple de config de çà? Raymond Caracatamatere a écrit: Friday, December 23, 2011 9:18 AM J'aime l'idée du more specifics car cela n'oblige pas l'utilisation d'une default GW Tu pourrais expliquer en détail pourquoi? J'ai écrit le mois dernier que ça ne me semblait pas être une bonne idée, et je ne vois pas de solution pratique pour que ça marche. Question pour tout le monde qui filtre les routes: qu'est ce que vous avez comme routeur? Ces jours-ci pour un Cisco 7600 un SUP720-3BXL qui prend 1 million de routes ça ce trouve pour $25k. Juniper j'ai aucune idée des prix. Xavier Beaudouin a écrit: Dans la série boite à outil, il serait assez intéressant de créer une sorte de moulinette pour filtrer les gens qui ont de grosses allocations genre : Je suis GroTélécom j'ai un a.v.0.0/16 et je suis sale, alors je casse mes prefixes http://www.cidr-report.org/as2.0/ La partie qui injecte ça dans le routeur je n'ai pas ça en stock, ceci dit. Il y a des gens avec du temps pour se pencher sur ce genre de chose? Ca pourrait être un projet sympa. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Xavier Beaudouin a écrit: Dans la série boite à outil, il serait assez intéressant de créer une sorte de moulinette pour filtrer les gens qui ont de grosses allocations genre : Je suis GroTélécom j'ai un a.v.0.0/16 et je suis sale, alors je casse mes prefixes En quoi c'est sale ??? C'est inévitable et nécessaire. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Merci pour vos réponses à tous. A vrai dire, je ne comptais pas upgrader du tout pour le moment (ce n'est pas du tout prévu). Pour vous en dire plus, j'ai plusieurs upstream avec des full-view répartis sur plusieurs routeurs et le nombre de routes commence donc à être trop élevé pour ma configuration. Si je résume vos idées : - filtrer les préfixes plus spécifiques. * Avantages : pas besoin d'utiliser de default GW, je garde mes stats sflow * Inconvénients : compliqué à mettre en place et à maintenir. - filtrer tous les /24 (par exemple) * Avantages : fastoche à mettre en place * Inconvénients : utilisation de default GW et plus de stats sflow Ray Le 24 décembre 2011 07:19, Michel Py mic...@arneill-py.sacramento.ca.us a écrit : Nicolas DEFFAYET a écrit: Si tu filtre et que ton routeur n'a plus de full table BGP, il est impératif que tes transitaires t'annonces 0.0.0.0/0 en BGP. En effet, si tu ne fais pas cela, certaines destinations seront injoignables. Il n'y a aucune relation entre les deux. Quand on achète du transit, une des choses pour lesquelles on paie est que le transitaire achemine le trafic sortant vers l'ensemble de l'Internet, cela n'a rien à voir avec revoir un full-feed BGP, ou seulement 0.0.0.0/0, ou les deux, avoir 1 ou plusieurs transits, et même ne pas recevoir de routes du tout et configurer une route par défaut statique. La seule exception, c'est quand on est T1 ce qui n'est pas le cas de Raymond. Radu-Adrian Feurdean a écrit: Des upstreams qui annoncent la full-table *ET* le 0.0.0.0/0 (en meme temps), je ne connais pas des masses. Parce que c'est bien souvent un cas de figure inutile, mais c'est quelque chose qui ne pose aucun problème si tu le demandes. Par contre, le 0.0.0.0/0 en statique marche tout aussi bien. Je suis d'accord. D'ailleurs, je ne crois pas qu'il y ait une solution universelle pour reduire la table de routage, applicable a tout le monde sans impact. Il faut toujours trouver la bonne composition des solutions deja decrites. +1 J'allais écrire quelque chose de similaire. Raymond, sans plus de détails on peut pas te dire grand-chose. Il faut aussi rappeler que toutes ces solutions s'addressent uniquement aux stub AS, qui ne vit pas de la vente de transit. Pour ceux qui vendent du transit : upgradez ! Sans empiéter sur les plates-bandes du troll en court que je nourrirai demain, force est de constater que l'échec d'IPv6 dans le domaine du multihoming va finir par déboucher par une sélection par le pognon pour opérer dans la DFZ. Pognon pour acheter le routeur monstrueux, tu continues à jouer; pas de pognon, tu deviens stub AS. Raymond Caracatamatere a écrit: Le père Noël ne veut pas que j'upgrade encore... C'est ennuyeux, car la meilleure solution que j'avais à te proposer était justement de lui écrire. J'aime l'idée du more specifics car cela n'oblige pas l'utilisation d'une default GW, mais comment je peux gérer simplement une telle ACL sur mes équipements sans que cela soit une usine ? C'est pas tellement l'aspect usine à gaz qui me ferait peur, mais plutôt le temps que tu vas y perdre. Combien de mois il faut que tu délaies l'upgrade? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Sans empiéter sur les plates-bandes du troll en court que je nourrirai demain, force est de constater que l'échec d'IPv6 dans le domaine du multihoming va finir par déboucher par une sélection par le pognon pour opérer dans la DFZ. Pognon pour acheter le routeur monstrueux, tu continues à jouer; pas de pognon, tu deviens stub AS. Quel problème de multihoming ? Il y a seulement un problème de mulithoming si tu appliques les pratiques v4 a v6 ! IPv6 est conçu pour que les machines aient plusieurs IPs. La solution simple pour le multi-homing est d'avoir un réseau local en IP site-global (je devrais dire adresse locale unique - ULA ...) ET plusieurs addresses globales (une par fournisseur). Tu addresses tes services internes (messagerie, serveur de docuementation, etc. ) en ULA, pour être indépendant de tes fournisseurs et tu ajoutes ensuite des IP globales a tes machines pour la connectivite externe. Evidement le controle de la politique de routage n'est plus la même qu'avec du NAT, et il ne faut pas avoir peur de le perdre (soupir) et avoir une configuration de pare-feu saine. Ceci dit, pour les gens qui VEULENT du NAT, Il n'est pas impossible de concevoir un mapping 1-1 entre des IP ULA et globale mais en me demandez pas la recette. Le problème est que la définition de site-local a change entre les premières RFC et maintenant, et que beaucoup de gens pensent que le concept n'est plus valide. Je vous invide a lire la RFC 4193 et pour la version plus digeste de wikipedia en ces temps de fetes : http://en.wikipedia.org/wiki/Unique_local_address Cela me rappelle que je dois moi-meme relire ces deux RFC avant de poster quoi que ce soit de plus :p http://tools.ietf.org/html/rfc4864 - Local Network Protection for IPv6 http://tools.ietf.org/html/rfc3484 - Default Address Selection for Internet Protocol version 6 (IPv6) Bonne fêtes, Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le Mon, Dec 26, 2011 at 01:30:57PM +, Thomas Mangin [thomas.man...@exa-networks.co.uk] a écrit: [...] IPv6 est conçu pour que les machines aient plusieurs IPs. Zut. Je ne savais pas qu'on ne pouvait avoir plusieurs ip que en IPv6, du coup j'en mets en IPv4. La solution simple pour le multi-homing est d'avoir un réseau local en IP site-global (je devrais dire adresse locale unique - ULA ...) ET plusieurs addresses globales (une par fournisseur). Tu addresses tes services internes (messagerie, serveur de docuementation, etc. ) en ULA, pour être indépendant de tes fournisseurs et tu ajoutes ensuite des IP globales a tes machines pour la connectivite externe. Tu ne résous, partiellement, que l'utilisation en « accès », et pas du tout le problème du hosting, pour lequel je ne vois pas de solution immédiate, équivalente au multihoming tel qu'il est fait en IPv4 pour que tes services soient encore globalement accessibles quand tu perds l'un de tes transits. -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
IPv6 est conçu pour que les machines aient plusieurs IPs. Zut. Je ne savais pas qu'on ne pouvait avoir plusieurs ip que en IPv6, du coup j'en mets en IPv4. :D La solution simple pour le multi-homing est d'avoir un réseau local en IP site-global (je devrais dire adresse locale unique - ULA ...) ET plusieurs addresses globales (une par fournisseur). Tu addresses tes services internes (messagerie, serveur de docuementation, etc. ) en ULA, pour être indépendant de tes fournisseurs et tu ajoutes ensuite des IP globales a tes machines pour la connectivite externe. Tu ne résous, partiellement, que l'utilisation en « accès », et pas du tout le problème du hosting, pour lequel je ne vois pas de solution immédiate, équivalente au multihoming tel qu'il est fait en IPv4 pour que tes services soient encore globalement accessibles quand tu perds l'un de tes transits. Le multihoming BGP est bien sur possible en IPv6 .. Donc je ne vois pas ce qu'IPv6 n'a pas qu'IPv4 a. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On 26 déc. 2011, at 16:34, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Le multihoming BGP est bien sur possible en IPv6 .. Donc je ne vois pas ce qu'IPv6 n'a pas qu'IPv4 a. Une possibilité d'avoir une fragmentation de la DFZ beaucoup plus importante, et du coup avoir du PA only aurait pu permettre de limiter ça... Bon, il faudra qu' IPv6 décolle bien avant, on est d'accord. D'ailleurs, ça se filtre à quelle longueur, les annonces v6 ? :) Cordialement, -- Aurélien Guillaume Envoyé depuis mon fax satellitaire --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
J'ai 2 autres commentaires: 1. Sur filtrer les préfixes plus spécifiques, je ne serais pas chaud à ne pas avoir de route par défaut. En théorie tu n'en as pas besoin, mais en théorie la théorie et la pratique sont identiques, alors qu'en pratique elles ne le sont pas. Si ton système d'agrégation est parfait et qu'il marche en temps réel, pas de problème mais dès que tu dévies tu cours le risque d'une adresse inroutable. Vérité dans la pub: je n'ai jamais fait cette méthode en prod, mais ma politique est que dès que tu commences à filtrer les routes que tu reçois (donc dès que tu n'acceptes plus le full-feed) il faut la route par défaut comme roue de secours. 2. Sur filtrer les /24: Tu peux filtrer les /24 en provenance de certaines zones, par /8. Exemple: tu filtres les /24 qui sont dans un /8 alloué à APNIC, AfriNIC, LACNIC, ARIN ou LEGACY mais tu ne filtres pas les 24 qui sont dans un /8 alloué à RIPE NCC. C'est pas parfait comme méthode (rien ne vaut un full-feed non filtré) mais ça te permet de garder une certaine granularité pour les préfixes Européens au prix de ne pas supprimer autant de routes que si tu supprimais tous les /24 sans discrimination. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Le 23 décembre 2011 17:08, Raymond Caracatamatere raymond.caracatamat...@gmail.com a écrit : Bonjour, Depuis la pénurie d'IPv4, la table BGP augmente chaque jours plus vite qu'avant, aujourd'hui à 38 routes les routeurs nous rappellent à l'ordre. Hormis la solution de filtrer les annoncent /24 et de poser une default gw vers les transitaires, avez-vous d'autres solutions ? - faire que les routeurs supportent + de routes, = + de mémoire, ressources hard++ - ré agréger des préfixes au lieu d'annoncer du /24 à tire larigot... et pourquoi pas du /32 :) - Passer en ipv6 :) ~7700 routes ipv6 vs ~38 routes ipv4 Merci pour votre aide et bonne fêtes. pareillement. Cdlt, -- PR --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Fri, 23 Dec 2011 17:08:20 +0100, Raymond Caracatamatere raymond.caracatamat...@gmail.com said: Depuis la pénurie d'IPv4, la table BGP augmente chaque jours plus vite qu'avant, aujourd'hui à 38 routes les routeurs nous rappellent à l'ordre. Hormis la solution de filtrer les annoncent /24 et de poser une default gw vers les transitaires, avez-vous d'autres solutions ? Ce n'est pas forcement les /24 qu'il faut filtrer sauvagement. Il y a quelque-part des listes avec les minimum allocation sizes, qui peut etre un tres bon critere. Malhereusement, APNIC, la region avec les pires des-aggregateurs est passe a une allocation minimal de /24 recemment. Sinon, filtrer tous les more specifics dans quelques /8 provider-based (4, 8, 12, 38, ...) ca elimine quand-meme una utre paquet de routes. Sinon, changer le cam-profile peut te faire gagner encore 6-9 moins avant upgrade. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Fri, 2011-12-23 at 17:08 +0100, Raymond Caracatamatere wrote: Bonsoir Raymond, Depuis la pénurie d'IPv4, la table BGP augmente chaque jours plus vite qu'avant, aujourd'hui à 38 routes les routeurs nous rappellent à l'ordre. Hormis la solution de filtrer les annoncent /24 et de poser une default gw vers les transitaires, avez-vous d'autres solutions ? Si tu filtre et que ton routeur n'a plus de full table BGP, il est impératif que tes transitaires t'annonces 0.0.0.0/0 en BGP. En effet, si tu ne fais pas cela, certaines destinations seront injoignables. Il faut garder à l'esprit qu'en filtrant, tu n'aura plus d'information sur les AS dans les statistiques Netflow sur tes transitaires. Tu as plusieurs possibilités de filtrage sur tes transits: Option 1: Filtrer sur le minimum allocation size Il ne faut pas oublier également que certains LIR annoncent leur allocation uniquement de manière désagrégée (ex: /23) sans annoncer l'allocation tel quel a été attribuée (ex: /19). Inconvénients: - Les RIR vont a terme mettre leur minimum allocation size à /24 ce qui limitera l'efficacité de cette méthode. L'APNIC le fait depuis plus d'un an déjà. - Cette méthode ne permet pas de descendre en dessous de 200 000 routes donc à oublier pour les SUP2, SUP32, SUP720(non XL),... - prefix-list longue Option 2: Filtrer sur /19 et accepter les prefixes critiques Inconvénients: - Les réseaux qui ont un bloc d'adresses IP de taille inférieur à /19 passe à la trappe. Les réseaux ne sont donc pas tous égaux car il peut y avoir des petits réseaux très important mais qui ont uniquement un /23. - La définition de prefixes critiques est sujet à de long débats: est-ce uniquement les prefix des DNS root ? inclus-t-on les serveurs gérant les CCTLD ? - Il faut mettre en place un process pour mettre à jour la liste des prefix critiques pour faire les choses proprement même si au pire des cas, cela passe par la default-route. Option 3: Accepter uniquement les prefixes critiques Avantages: - Tous les réseaux sont égaux, chacun est visible par une default route. Inconvénients: - Impossible de faire du traffic engineering et de répartir le traffic sur différents transitaires. Il ne faut pas oublier que pour gérer un grand nombre de routes, un routeur n'a pas besoin uniquement de mémoire (RAM / TCAM) mais il a besoin aussi de beaucoup de CPU pour que la convergence des routes soit la plus rapide possible sans impacter les autres services du routeur. Je ne connais pas beaucoup de réseaux prêt à investir dans des routeurs haut de gamme pour supporter une full table de 1-2 millions de routes IPv4 (en plus des 100 000 routes IPv6 quand chaque ASN annoncera son bloc IPv6) avec un temps de convergence correct qui n'impacte pas les autres services du routeur juste pour avoir le luxe d'avoir une full table. De nombreux réseaux vont devoir se priver de full table pour des raisons économiques. La taille de la table de routage de Internet IPv4 peut être un long débat. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
On Fri, 23 Dec 2011 21:55:23 +0100, Nicolas DEFFAYET nicolas...@deffayet.com said: Si tu filtre et que ton routeur n'a plus de full table BGP, il est impératif que tes transitaires t'annonces 0.0.0.0/0 en BGP. En effet, si tu ne fais pas cela, certaines destinations seront injoignables. Des upstreams qui annoncent la full-table *ET* le 0.0.0.0/0 (en meme temps), je ne connais pas des masses. Par contre, le 0.0.0.0/0 en statique marche tout aussi bien. - La définition de prefixes critiques est sujet à de long débats: est-ce Chacun a ses propres prefixes critiques. Pour moi, presque moitie de mon trafic externe va vers ~20 prefixes (pour empirer les choses, ce meme 50% de trafic va vers moins de 100 IPs). Pour savoir ce qu'on peut filtrer (et evacuer via 0/0) il faut faire une analyse de son trafic. D'ailleurs, je ne crois pas qu'il y ait une solution universelle pour reduire la table de routage, applicable a tout le monde sans impact. Il faut toujours trouver la bonne composition des solutions deja decrites. Il faut aussi rappeler que toutes ces solutions s'addressent uniquement aux stub AS, qui ne vit pas de la vente de transit. Pour ceux qui vendent du transit : upgradez ! --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs
Nicolas DEFFAYET a écrit: Si tu filtre et que ton routeur n'a plus de full table BGP, il est impératif que tes transitaires t'annonces 0.0.0.0/0 en BGP. En effet, si tu ne fais pas cela, certaines destinations seront injoignables. Il n'y a aucune relation entre les deux. Quand on achète du transit, une des choses pour lesquelles on paie est que le transitaire achemine le trafic sortant vers l'ensemble de l'Internet, cela n'a rien à voir avec revoir un full-feed BGP, ou seulement 0.0.0.0/0, ou les deux, avoir 1 ou plusieurs transits, et même ne pas recevoir de routes du tout et configurer une route par défaut statique. La seule exception, c'est quand on est T1 ce qui n'est pas le cas de Raymond. Radu-Adrian Feurdean a écrit: Des upstreams qui annoncent la full-table *ET* le 0.0.0.0/0 (en meme temps), je ne connais pas des masses. Parce que c'est bien souvent un cas de figure inutile, mais c'est quelque chose qui ne pose aucun problème si tu le demandes. Par contre, le 0.0.0.0/0 en statique marche tout aussi bien. Je suis d'accord. D'ailleurs, je ne crois pas qu'il y ait une solution universelle pour reduire la table de routage, applicable a tout le monde sans impact. Il faut toujours trouver la bonne composition des solutions deja decrites. +1 J'allais écrire quelque chose de similaire. Raymond, sans plus de détails on peut pas te dire grand-chose. Il faut aussi rappeler que toutes ces solutions s'addressent uniquement aux stub AS, qui ne vit pas de la vente de transit. Pour ceux qui vendent du transit : upgradez ! Sans empiéter sur les plates-bandes du troll en court que je nourrirai demain, force est de constater que l'échec d'IPv6 dans le domaine du multihoming va finir par déboucher par une sélection par le pognon pour opérer dans la DFZ. Pognon pour acheter le routeur monstrueux, tu continues à jouer; pas de pognon, tu deviens stub AS. Raymond Caracatamatere a écrit: Le père Noël ne veut pas que j'upgrade encore... C'est ennuyeux, car la meilleure solution que j'avais à te proposer était justement de lui écrire. J'aime l'idée du more specifics car cela n'oblige pas l'utilisation d'une default GW, mais comment je peux gérer simplement une telle ACL sur mes équipements sans que cela soit une usine ? C'est pas tellement l'aspect usine à gaz qui me ferait peur, mais plutôt le temps que tu vas y perdre. Combien de mois il faut que tu délaies l'upgrade? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
