Re: [FRnOG] Quagga : limites ?
[...] Une alternative a quagga / zebra serait openbgpd D'ailleurs tant qu'on y est et pour fixer les idées, exemple d'occupation mémoire d'un quagga sous FreeBSD avec une table BGP complète (3 peerings dont 1 avec toute la table, les 2 autres avec très peu de routes) : PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 243 root1 960 86824K 84228K select 0 20.4H 0.88% bgpd 237 root1 960 65232K 57340K select 0 24:19 0.00% zebra bgpd a consommé 20h de CPU (bi-Xeon 2GHz) sur 26 jours d'uptime. Qui est moins consomateur en ram que Quagga et un peu plus véloce : # bgpctl sh rib mem RDE memory statistics 184036 IPv4 network entries using 5.6M of memory 371059 prefix entries using 11.3M of memory 67469 BGP path attribute entries using 4.9M of memory 30141 BGP AS-PATH attribute entries using 905K of memory, and holding 67469 references 3749 BGP attributes entries using 87.9K of memory and holding 46960 references 3748 BGP attributes using 28.3K of memory RIB using 22.8M of memory PID USERNAME PRI NICE SIZE RES STATEWAIT TIMECPU COMMAND 6566 _bgpd 20 46M 46M sleep/0 poll24:50 0.00% bgpd 27595 _bgpd 20 3484K 3880K sleep/0 poll13:15 0.00% bgpd 13138 root 20 6692K 7140K sleep/0 poll12:59 0.00% bgpd OpenBGPd a consommé 24h de temps CPU pour une machine bi PIII 933 Mhz qui a 3 full view (4 normalement, mais un de mes fournisseur de transit a un second routeur qui est hors service), et 36 sessions BGP avec quelques routes ( 1000). Je dis pas que OpenBGPd est meilleurs mais c'est un bon compromis quand on peux pas se payer des Xeon :) En ce qui concerne la facon dont les routes sont injectées OpenBSD a un kroute (comme kqueue sur freebsd) qui permet de changer la table de routage rapidement Voir doc sur openbgd.org :) Bon ca change pas qu'il y a des bugs et des fois des choses tricky mais claudio le developpeur est en général rapide a corriger des bugs et ajouter des features :) /Xavier PS: qui cherche un sponsor pour notre assoce pour virer les pc routeurs ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Neil Bobstone wrote: Bonjour, On derive un peu du sujet ! Perso ma conclusion serait : [...] Ce sont des dérives intéressantes (en tout cas pour moi), merci à tous pour vos réponses ! Laurent --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Christophe Casalegno wrote: Le Mercredi 12 Avril 2006 19:45, Laurent Bauer a écrit : Que signifie une charge peu élevée ? Si on prend le cas (hypothétique bien sûr ;-)) de 2 petites machines avec quagga et freevrrpd, qui annoncent 2 ou 3 classes C à 2 opérateurs, jusqu'à quel traffic (transit) peut-on espérer ne pas avoir trop de problème ? J'imagine que ça dépend un peu de la mémoire et du CPU, mais j'aimerais avoir simplement un ordre d'idée si vous avez des expériences plus précises là-dessus. Concrètement pour un petit hébergeur qui grossit doucement mais sûrement, a-t-on intérêt à investir dans du gros matos ou peut on continuer en soft ? Comment dimensionner ça sachant que pour l'instant ça tient bien mais que ce n'est probablement pas linéaire... Pour Quagga en particulier je ne sais pas, mais pour du routeur soft sur os linux, tu peux router environ 250 Mb/s sur un 32 bits, et un peu plus de 400 Mb/s sur une machine 64 bits sans trop trop de problèmes. amicalement, Je pense qu'il faudrait aussi voir de quel genre de traffic il s'agit, surtout en terme de paquets par secondes. Un quagga routant 250 mbits/sec de traffic web, ftp ou autre ne routera peut être pas 250 mbits/sec de jeu -- Pierre-Yves Maunier [EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Le Mercredi 12 Avril 2006 20:47, Pierre-Yves Maunier a écrit : Je pense qu'il faudrait aussi voir de quel genre de traffic il s'agit, surtout en terme de paquets par secondes. Un quagga routant 250 mbits/sec de traffic web, ftp ou autre ne routera peut être pas 250 mbits/sec de jeu pour les tests que nous avons réalisé il s'agissait de trafic web/ftp/mail/ssh/stream. On a pas testé sur les serveurs de jeux (ou les switches aussi, de basse qualité peuvent poser problème). amicalement, -- Christophe Casalegno | Groupe Digital Network | UIN : 153305055 http://www.digital-network.net | http://www.intelink.info TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX Technical director | Security Intrusion techniques infowar specialist. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Je pense qu'il faudrait aussi voir de quel genre de traffic il s'agit, surtout en terme de paquets par secondes. Un quagga routant 250 mbits/sec de traffic web, ftp ou autre ne routera peut être pas 250 mbits/sec de jeu J'ajouterai aussi le nombre de connexions simultanées. Plusieurs bittorents, qui utilisent chacun plusieurs dizaines (si ce n'est plus) de sessions TCP actives, remplissent très vite la table de connection tracking... Si on ajoute à cela de la classification de paquet et de la QoS, on a plus vite fait d'atteindre les limites du noyau linux. -- Raphaël Marichez [EMAIL PROTECTED] pgpkKjNjFnBfG.pgp Description: PGP signature
Re: [FRnOG] Quagga : limites ?
Bonjour, On Wed, Apr 12, 2006 at 07:45:06PM +0200, Laurent Bauer wrote: Que signifie une charge peu élevée ? Si on prend le cas (hypothétique bien sûr ;-)) de 2 petites machines avec quagga et freevrrpd, qui annoncent 2 ou 3 classes C à 2 opérateurs, jusqu'à quel traffic (transit) peut-on espérer ne pas avoir trop de problème ? J'imagine que ça dépend un peu de la mémoire et du CPU, mais j'aimerais avoir simplement un ordre d'idée si vous avez des expériences plus précises là-dessus. Il faut faire attention à bien distinguer : - le routage de paquets proprement dit, assuré par le noyau en fonction de la table de routage. - la tenue à jour de la table de routage, assurée soit manuellement (cas le plus simple, routes statiques) soit par un processus utilisateur (routed, zebra, quagga, etc). La performance pure en débit ne dépend pratiquement que du premier point. Il faut s'intéresser non seulement au débit en bps, mais aussi au nombre de paquets par seconde (le coût CPU du routage d'un paquet dépend peu de sa taille). Sur un PC un peu ancien (Pentium 350MHz) on peut facilement atteindre les 35 à 50k paquets par seconde soit 40 - 60Mbps sur du trafic non pathologique. Le débit atteignable ne dépend que de la vitesse du CPU et de la qualité des cartes réseau et de leurs drivers. Les machines récentes dépassent largement ces chiffres mais atteignent encore difficilement 1 Gbps soutenu. La mémoire n'intervient que pour le stockage de la table de routage. 512Mo permet largement de faire tenir la table de routage BGP complète (185.000 routes actuellement). Enfin, le CPU peut aussi avoir de l'importance dans la gestion de grosses tables de routage (par exemple en BGP nombreux peerings, règles de filtrages d'annonces, etc). -- A: Yes. Pierre Beyssac [EMAIL PROTECTED] Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
On Wed, Apr 12, 2006 at 10:58:27PM +0200, Christophe Casalegno wrote: Le Mercredi 12 Avril 2006 22:51, Pierre Beyssac a écrit : réseau et de leurs drivers. Les machines récentes dépassent largement ces chiffres mais atteignent encore difficilement 1 Gbps soutenu. Je voudrais souligner que dans bien des cas, le problème de limitation sur le trafic réseau se pose à cause de la largeur du bus de données pci (d'ou la différence entre du 32 ou du 64 bits). Quelque soit la puissance de la machine, cela reste une limite difficilement franchissable. J'aimerais bien des précisions : sur un bus PCI à 100MHz, en 32 bits, il me semble qu'on peut tirer 3,2Gbps... et le double en 64 bits ? Mon calcul est peut-être foireux (ça m'apprendra à croire les commerciaux en réseau), mais sinon il me semble que ça reste au delà des capacités actuelles des CPU. Idem pour la mémoire en ce qui concerne les sessions (exemple nombreux peering), chaque session occupe de la ram, il faut le prendre en compte. Oui effectivement. D'ailleurs tant qu'on y est et pour fixer les idées, exemple d'occupation mémoire d'un quagga sous FreeBSD avec une table BGP complète (3 peerings dont 1 avec toute la table, les 2 autres avec très peu de routes) : PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 243 root1 960 86824K 84228K select 0 20.4H 0.88% bgpd 237 root1 960 65232K 57340K select 0 24:19 0.00% zebra bgpd a consommé 20h de CPU (bi-Xeon 2GHz) sur 26 jours d'uptime. -- A: Yes. Pierre Beyssac [EMAIL PROTECTED] Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
On Wed Apr 12 2006 at 23:14, Pierre Beyssac wrote: J'aimerais bien des précisions : sur un bus PCI à 100MHz, en 32 bits, il me semble qu'on peut tirer 3,2Gbps... et le double en 64 bits ? Mon calcul est peut-être foireux (ça m'apprendra à croire les commerciaux en réseau), Le calcul est juste mais 100 MHz, c'est du PCI-X, pas du PCI. Je ne crois pas que le PCI-X soit très courant. J'avoue n'en avoir jamais vu. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Le Mercredi 12 Avril 2006 23:14, Pierre Beyssac a écrit : J'aimerais bien des précisions : sur un bus PCI à 100MHz, en 32 bits, il me semble qu'on peut tirer 3,2Gbps... et le double en 64 bits ? Mon calcul est peut-être foireux (ça m'apprendra à croire les commerciaux en réseau), mais sinon il me semble que ça reste au delà des capacités actuelles des CPU. Il faut également distinguer 2 autres choses (sur le hard comme le soft), les limites théoriques, et les limites pratiques. Par exemple, un bus large, c'est bien, si la carte mère est dimensionnée pour l'alimenter électriquement : c'est mieux. + des tas d'autres petits paramètres qui font que malheureusement, on est souvient bien loin de la théorie, et utiliser 2 cartes Gb/s standard entre 2 pc, essayer de tirer 950 Mb/s dessus relève plus de l'exploit que de la norme. amicalement, -- Christophe Casalegno | Groupe Digital Network | UIN : 153305055 http://www.digital-network.net | http://www.intelink.info TISTC | OFREMHI | IIHEC | IICRAI | CIRET-AVT | KESAC | TIIX Technical director | Security Intrusion techniques infowar specialist. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Le 12 avr. 06 à 23:40, Christophe Baegert a écrit : Bonjour, Le Mercredi 12 Avril 2006 23:30, Michel Arboi a écrit : Le calcul est juste mais 100 MHz, c'est du PCI-X, pas du PCI. Je ne crois pas que le PCI-X soit très courant. J'avoue n'en avoir jamais vu. C'est quasi-généralisé sur les cartes Tyan ou Supermicro. On a les perfs du PCI Express, avec la compatibilité PCI, que demander de plus ? Oui surement dans la mesure ou la majorité des nics pci-e utilisent en réalité des bridges pci-e - pci-x il n'est dès lors pas surprenant d'obtenir les memes perfs :-) -- Olivier Warin - http://xview.net Stay connected ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Quagga : limites ?
Le 12 avr. 06 à 22:51, Pierre Beyssac a écrit : Bonjour, On Wed, Apr 12, 2006 at 07:45:06PM +0200, Laurent Bauer wrote: Que signifie une charge peu élevée ? Si on prend le cas (hypothétique bien sûr ;-)) de 2 petites machines avec quagga et freevrrpd, qui annoncent 2 ou 3 classes C à 2 opérateurs, jusqu'à quel traffic (transit) peut-on espérer ne pas avoir trop de problème ? J'imagine que ça dépend un peu de la mémoire et du CPU, mais j'aimerais avoir simplement un ordre d'idée si vous avez des expériences plus précises là-dessus. Il faut faire attention à bien distinguer : - le routage de paquets proprement dit, assuré par le noyau en fonction de la table de routage. - la tenue à jour de la table de routage, assurée soit manuellement (cas le plus simple, routes statiques) soit par un processus utilisateur (routed, zebra, quagga, etc). La performance pure en débit ne dépend pratiquement que du premier point. Il faut s'intéresser non seulement au débit en bps, mais aussi au nombre de paquets par seconde (le coût CPU du routage d'un paquet dépend peu de sa taille). Sur un PC un peu ancien (Pentium 350MHz) on peut facilement atteindre les 35 à 50k paquets par seconde soit 40 - 60Mbps sur du trafic non pathologique. Le débit atteignable ne dépend que de la vitesse du CPU et de la qualité des cartes réseau et de leurs drivers. Les machines récentes dépassent largement ces chiffres mais atteignent encore difficilement 1 Gbps soutenu. En forwarding j'ai atteint sans pbm 2Gbps sur un FreeBSD 6.1- PRERELEASE (ie les limites de ma plateforme de tests) puisque composé de 4 em(4) http://xview.net/papers/jumbo_freebsd6.1/ D'autres, plus complet, sont en cours de préparation, je dois valider la méthodologie mais franchement dépasser 1Gbps à notre époque n'est pas chose rare. Dépasser le 1 Mpps ca devient plus rare et effectivement ca depend beaucoup de la nic (cache), du driver, e la stack tcp/ip de l'os que tu souhaites valider etc... -- Olivier Warin - http://xview.net Stay connected ! --- Liste de diffusion du FRnOG http://www.frnog.org/
