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/
[FRnOG] [TECH] RTP over UDP : combien de pps ?
Bonjour, Je tente de valider sur le papier mon routeur pour un projet de stream live. La bande passante, je sais calculer, merci mais je ne trouve nul part des exemples (à la louche puisque ça dépend du flux) du nombre de packets per second que ça va me générer. La taille moyenne du paquet RTP m'ira aussi, je sais diviser. Est-ce que quelqu'un aurait ces chiffres à partager ou c'est un autre secret industriel ? Merci d'avance, Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Le 18/01/2012 16:25, Julien Escario a écrit : Bonjour, Je tente de valider sur le papier mon routeur pour un projet de stream live. La bande passante, je sais calculer, merci mais je ne trouve nul part des exemples (à la louche puisque ça dépend du flux) du nombre de packets per second que ça va me générer. La taille moyenne du paquet RTP m'ira aussi, je sais diviser. Est-ce que quelqu'un aurait ces chiffres à partager ou c'est un autre secret industriel ? Tu l'as trouvé tout seul ;) totu dépend du payload et ce dernier dépendra du contenu que tu y feras passer ... http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml Après tu calcules :) Renaud --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RTP over UDP : combien de pps ?
On 18.01.2012 16:25, Julien Escario wrote: Est-ce que quelqu'un aurait ces chiffres à partager ou c'est un autre secret industriel ? c'est tout dans http://tools.ietf.org/html/rfc3984 Raphael --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Le 18/01/2012 16:30, Renaud RAKOTOMALALA a écrit : Le 18/01/2012 16:25, Julien Escario a écrit : Bonjour, Je tente de valider sur le papier mon routeur pour un projet de stream live. La bande passante, je sais calculer, merci mais je ne trouve nul part des exemples (à la louche puisque ça dépend du flux) du nombre de packets per second que ça va me générer. La taille moyenne du paquet RTP m'ira aussi, je sais diviser. Est-ce que quelqu'un aurait ces chiffres à partager ou c'est un autre secret industriel ? Tu l'as trouvé tout seul ;) totu dépend du payload et ce dernier dépendra du contenu que tu y feras passer ... http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml Après tu calcules :) Merci mais j'ai dû calculer de travers. Pour la plupart des profils vidéo (je veux du H264), je vois 90k échantillons/seconde. Ce ne fait quand même pas 9pps ? Parce qu'avec un flux dimensionné à 350kbps, ça fait des paquets de 4 bits. Je veux bien payer un lien giga mais si je peux y faire passer autre chose que de l'overhead ... Sérieusement, il se fait comment ce calcul ? Julien --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Merci mais j'ai dû calculer de travers. Pour la plupart des profils vidéo (je veux du H264), je vois 90k échantillons/seconde. Ce ne fait quand même pas 9pps ? Parce qu'avec un flux dimensionné à 350kbps, ça fait des paquets de 4 bits. Je veux bien payer un lien giga mais si je peux y faire passer autre chose que de l'overhead ... Sérieusement, il se fait comment ce calcul ? Julien le paquet de données Mpeg* fait 188 octets... Si tu fais du MPEGTS... et dans ce cas la norme c'est 7*188. Là personne n'a dit que c'était du MPEG-TS. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Bonjour, Cela ferait donc 135 Mbit/s. Soit, avec un coefficient de foisonnement de 40 %, 190 Mbit/s à prévoir sur une liaison Ethernet de 1 Gbit/s. Sans être un grand expert, il faudrait faire attention à la CoS Ethernet. Cordialement, Michel Hostettler - Mail original - De: sxpert sxp...@sxpert.org À: frnog@frnog.org Envoyé: Mercredi 18 Janvier 2012 17:07:27 Objet: Re: [FRnOG] [TECH] RTP over UDP : combien de pps ? On 18.01.2012 16:46, Julien Escario wrote: Merci mais j'ai dû calculer de travers. Pour la plupart des profils vidéo (je veux du H264), je vois 90k échantillons/seconde. Ce ne fait quand même pas 9pps ? Parce qu'avec un flux dimensionné à 350kbps, ça fait des paquets de 4 bits. Je veux bien payer un lien giga mais si je peux y faire passer autre chose que de l'overhead ... Sérieusement, il se fait comment ce calcul ? Julien le paquet de données Mpeg* fait 188 octets... --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Bonjour, Là personne n'a dit que c'était du MPEG-TS. Il est possible qu'il fasse en réalité H.264 sur H.222 sur UDP, sans le savoir ! Sur du streaming audio/video, sans MPEGTS, sans H.222 sur du rtp/udp... je vois pas ce qu'il reste de possible en fait. Y. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RTP over UDP : combien de pps ?
Il est possible qu'il fasse en réalité H.264 sur H.222 sur UDP, sans le savoir ! Sur du streaming audio/video, sans MPEGTS, sans H.222 sur du rtp/udp... je vois pas ce qu'il reste de possible en fait. Pardon, j'ai oublié H.222 sur RTP sur UDP (H.222 = MPEG-TS). Cordialement, 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: 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/
