Re: [FRnOG] [MISC] cas d'utilisation 5G
Bonjour,
On Tue, Sep 29, 2020 at 02:03:02PM +0200, Richard Klein wrote:
> Bonjour,
>
> >La 5g me semble être surtout un bon moyen pour les >opérateurs de
> désengorger de manière durable les >réseaux 4g saturés en zone dense et à
> terme de >répondre aux enjeux du Thd en France.
> Faux !!!
> Il paraît que dans les pays nordiques l'exposition aux ondes est moins
> forte car la densité des antennes mobile est plus importante... Donc charge
> ,débit et communications voix sont mieux répartis . CQFD.
> En combien de temps un opérateur a les autorisations pour déployer un site
> ? Avoir les fibres pour éviter les FH? En France et dans des pays
> nordiques histoire de comparer?
D'après Alexandre Archambault sur Twitter : France 36 mois, scandinavie
6 mois.
Pas mal d'opposition aux antennes en France.
(Alex est sur cette liste sauf erreur)
https://twitter.com/AlexArchambault/status/1309101107436752902
Car voyez-vous, entre l’identification d’un site et son
activation afin d répondre aux besoins des habitants, il
s’écoule en moyenne 36 mois compte tenu des recours à purger.
Contre 6 en Scandinavie
--
Pierre Beyssac p...@eriomem.net
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] Re: [MISC] La sobriété numérique, oui mais pour quoi faire ?
Bonjour, On Mon, Jul 20, 2020 at 04:02:43AM +0200, frnog.kap...@antichef.net wrote: > Désolé de te contredire Stéphane mais ce n'est pas ce que dit l'article. > Le passage dont tu parles est une petite note de 4 lignes qui arrive en toute > fin d'un billet de près de 250 lignes qui sont consacrées à démontrer que la > réduction des volumes transportés n'entraine pas de réduction significative > de > la consommation énergétique pour amener à l'idée que la sobriété numérique > serait un effort inutile. Stéphane a très bien compris le sens du billet. J'en suis l'auteur et j'ai mis un certain nombre d'avertissements (dont en tête du billet) pour expliciter que ce n'est pas la demande de sobriété numérique en tant que telle que je critique, mais 1) la "sobriété pour la sobriété" si elle n'a aucun sens énergétique (il s'agit d'une démarche monastique, non pragmatique) et 2) en particulier, combattre l'idée fausse et malheureusement répandue que notre impact énergétique est proportionnel à notre consommation de données, ce qu'aucune donnée factuelle ne montre, au contraire. Si le billet n'est pas suffisamment clair malgré les multiples avertissements, je peux le corriger, mais on ne m'expliquera pas ce que j'ai voulu dire car j'en ai une assez précise idée :) Il s'agit donc juste de déconstruire une idée particulièrement fausse. Ce n'est pas une thèse générale sur l'impact du numérique, qui en effet est un sujet bien plus large, et il ne me viendrait pas à l'esprit de nier que cet impact existe. On voit fleurir les articles du style "le numérique a un impact de x % des GES mondiaux" suivi de (handwaving) "60 % du volume consommé concerne la vidéo en ligne, il faut donc réduire notre consommation de données". Le lecteur en tire bien évidemment une conclusion fausse, et appliquera des efforts vains (au lieu de penser à éviter de changer d'ordiphone pour un oui ou pour un non). > Le fait que l'auteur ait été amené à ajouter un avertissement en introduction > pour préciser que son objet n'est pas de nier l'impact environnemental du > numérique indique qu'un certain nombre de lecteurs ont pensé que c'était le > cas à la lecture du billet. Soit qu'une partie du lectorat ait mal interprété > les propos peut-être à cause d'une formulation hasardeuse, mais peut-être > aussi qu'une partie du lectorat a correctement interprété le propos du billet > et l'auteur se trouve obligé de s'en défendre. J'essaie de sérier les problèmes. Qu'on s'attaque aux vrais plutôt qu'aux problèmes fantasmés, en chiffrant correctement les impacts, sans dogmatisme. Vouloir tout aglomérer dans un gros blob "le numérique c'est mal" n'est pas une méthode d'analyse suffisamment fine, elle permet d'affirmer un peu n'importe quoi sans chiffre. > Ici l'objectif est bien de ramener la consommation totale en dessous du seuil > de capacité de charge de la planète. La planète a une limite en terme de volume d'échange de données numériques ? > Dans les faits, la consommation totale augmente de plus en plus vite, la > consommation du numérique augmente aussi de plus en plus tandis que la > consommation des autres secteurs que le numérique pourraient compenser ne > diminue pas. Ça semble indiquer que la consommation du numérique vient > s'additionner à celle des autres secteurs au lieu de s'y substituer. Il ne faut pas confondre consommation énergétique et consommation en volume de données. Donc soyons précis dans ce que nous disons. Sinon, beaucoup de gens vont croire que diminuer leur consommation de données par 2 va diviser leur impact énergétique numérique par 2... et c'est totalement faux. Une autre question serait : veut-on vraiment réduire l'impact en tapant là où il faut, ou veut-on se faire plaisir (et tester son influence sur la population générale) en leur donnant l'impression qu'ils font un effort en nous obéissant ? -- Pierre Beyssac p...@eriomem.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [SMTP] Free :: des mails qui n'arrivent pas.
Bonjour à tous, On Tue, Apr 28, 2020 at 01:53:09PM +0200, Nico CARTRON wrote: > A priori tu as des soucis au niveau DNSSEC, d'après DNSviz: > https://dnsviz.net/d/melusine.eu.org/dnssec/ > > "RRSIG eu.org/DNSKEY alg 8, id 21363: The Signature Expiration field of > the RRSIG RR (2020-04-23 17:29:35+00:00) is 4 days in the past." > > Depuis chez moi (PowerDNS Recursor avec validation DNSSEC activée), j'ai > effectivement du SERVFAIL quand je demande le MX pour ce domaine: Merci Nicolas de m'avoir prévenu ce matin. Un des serveurs secondaires eu.org a une copie ancienne de la zone, donc distribue des signatures expirées. J'ai prévenu la personne qui s'occupe du serveur et aussitôt enlevé ce serveur de la liste des serveurs de noms EU.ORG à 12h02 UTC, mais il peut encore être sollicité jusqu'à demain 12h UTC environ suivant ce que vous avez dans vos caches (24h = TTL des enregistrements NS dans la zone .ORG et dans la zone EU.ORG). -- Pierre Beyssac p...@eriomem.net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
On Mon, Jun 29, 2015 at 12:30:26PM +0200, Damien Fleuriot wrote: Avoir une vision technique c'est bien, avoir également la vision financière ça permet de relativiser les différents sujets. Bingo, c'est exactement ça. Pour petit rappel, la vision financière, jusqu'en 1995 en gros, c'est que tout était prévu par les telcos avec ATM puis OSI avec des vrais réseaux pro facturés au plus près des usages. TCP/IP c'était une blague pour que quelques universitaires s'amusent entre eux temporairement. Malheureusement, les geeks dans un garage ont toujours eu une aussi désagréable que répétée tendance à découper en confettis les vrais professionnels de la profession. :-P Ce n'est peut-être pas une coïncidence complète si 2 des plus grosses boites Internet (Google et Facebook) se sont déjà mises à IPv6 sans nous faire des cacas nerveux. Il leur manque manifestement la vision financière :-P -- Sent from my FreeBSD server on its IPv6 connection Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées
Je rejoins la team papy et me permets de venir mettre mon grain de sel... sur la pointe des pieds, car je me suis retenu d'écrire jusque-là, mais il y a des choses qui me gratouillent un peu. Je voudrais juste comprendre. Car je ne comprends rien à cet attachement touchant et, je j'en doute pas, intellectuellement reposant, mais objectivement pas très rationnel, pour papy v4. On Sun, Jun 28, 2015 at 10:58:27PM +0200, Pierre Lagoutte wrote: Mais non, mais non, ce n'est pas un pb d'apprentissage, mais de la bonne adaptation de v6 aux problèmes rencontrés en pratique (immaturité). On est plusieurs vieux cons ici, qui n'en sont pas à un nouveau protocole près. mais on pouvait légitiment espérer que v6 constituerait un progrès (notamment en simplicité d'usage), en gagnant en maturité (15 ans quand même...) Sur la simplicité, il suffit de jouer un tantinet à l'autohébergement : on voit tout de suite la différence entre 1 IPv4 sévèrement NATté en entrée et un /56 ou /64 IPv6. Beaucoup moins de galères en configuration HTTP ou firewall, en logs, etc. et pas un emm... supplémentaire en mal d'outillage approprié: que nenni, rien n'existe, On peut préciser de quel outillage on parle ? Les outils basiques classiques ont été portés à v6. Bon, je ne sais pas si certaines vieilleries propriétaires hors de prix ont été adaptées (coucou OpenView). Les éditeurs ont peut être l'œil rivé sur leur bilan comptable, tough (vive le libre). Et les présupposés du design de v6 ayant été très pauvres à l'époque (ce n'est pas forcément ici le lieu pour en discuter), ses implémentations et son écosystème s'avèrent malheureusement à la hauteur du désastre. Là encore, on peut préciser plutôt que de la jouer FUD ? Quand tout fonctionne au mieux: tout va bien, mais dépanner facilement c'est (et ça restera) autre chose. Je redoute la dissémination des déploiements, l'opacité et les difficultés de communication/échange technique autour de v6 (moins de personnes réellement qualifiées). Il y a moins de personnes qualifiées, donc il faut absolument éviter d'en augmenter le nombre ? Là non plus je ne pige pas le raisonnement. ... et je supporte les conseils visant à les limiter (en l'état) à la périphérie du réseau: il vaudrait mieux que v6 reste un protocole interne aux telcos. Là aussi... ça veut dire quoi techniquement concrètement ? IPv6 étant prioritairement fait pour délivrer massivement de l'espace adressage aux utilisateurs finaux, je ne vois vraiment pas le sens de le limiter aux telcos. C'est plutôt l'inverse qui est logique, et sans surprise c'est ce qui existe en déploiement (coucou le 6rd Free ou le L2TP SFR). Bon -- je comprends que ça fasse mal aux fesses des telcos à l'ancienne d'ouvrir l'abondance (truc dont ils ont horreur) sur un truc qu'ils monétisent chèrement (l'IPv4 publique et en particulier fixe). C'est le seul argument concret réel et business derrière le refus d'IPv6, mais forcément c'est plus difficile à vendre au client... -- Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Free vs Google (doubleclick)
On Tue, Nov 06, 2012 at 12:00:00PM +0100, Stephane Bortzmeyer wrote: On Tue, Nov 06, 2012 at 11:40:32AM +0100, Benjamin Sonntag benja...@octopuce.com wrote a message of 39 lines which said: De là à penser que le problème d'avec Free viendrait de ce pb IPv6, il n'y a qu'un pas que je ne franchis pas mais bon ... Un collègue me fait remarquer que le peering v4 Google-Free semble coupé. Ça sort via Cogent. Mais ledit peering est toujours activé en IPv6 : C'est pas de jeu de balancer des traceroute, on va être obligés de parler de factuel. Pour ceux qui sont sur twitter, j'en parlais hier après midi et hier soir aussi : https://twitter.com/pbeyssac/status/265457028007342080 -- Sent from my FreeBSD server Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 12:23:06PM +0100, Kavé Salamatian wrote: N'étant pas sur Facebook, je n'avais pas vu cela. Par contre, pour aller sur facebook.com, le discours à la mode « le DNS ne sert plus » me laisse froid. (Oui, j'ai testé http://69.171.234.21/ et il redirige vers www.facebook.com. Sans DNS, rien ne marche.) Quand ai je dis le DNS ne sert plus? je recopie ce que j'ai dit Des univers entiers, comme Facebook, échappent au DNS. Google pourrait très bien court-circuiter le nommage s’il y voyait un intérêt. Ce n'est pas gagné car, même si Google Search renvoyait vers des adresses IP, il faut encore que le serveur HTTP destination soit configuré pour servir les bonnes pages. Or avec l'épuisement des adresses IPv4, il n'est plus possible d'avoir 1 IP par host virtuel HTTP comme on le faisait autrefois. Donc... même si Google voulait tuer le DNS, on a encore au moins besoin des FQDN pour le web. Comme je l'ai indique facebook retourne dans certains cas des adresses IP au lieu d'URL, et Google pourrait faire de meme et cela serait pourrait court-circuiter une grande partie du DNS. Non, donc. Cela réclamerait la collaboration de l'ensemble des serveurs web qui attendent du trafic de la part de Google. Contrairement à ce que veulent croire les experts SEO et autres vendeurs d'astrologie numérique, Google ce n'est donc toujours pas l'Internet. -- Sent from my FreeBSD server Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 12:54:30PM +0100, Kavé Salamatian wrote: Ce n'est pas gagné car, même si Google Search renvoyait vers des adresses IP, il faut encore que le serveur HTTP destination soit configuré pour servir les bonnes pages. L'adresse canonique est envoye dans l'echange HTTP pour ceci. il suffit pour google de renvoyer les deux: adresse IP et adresse canonique. Ainsi il n' y a plus besoin de requete au DNS. Je ne dis pas que google va le faire, mais techniquement parlant on peut l'imaginer Non. Car le navigateur non plus n'invente pas l'adresse IP. Quoi que fasse Google. URL présentée avec FQDN : 1) le navigateur résout l'adresse IP via DNS 2) il se connecte à l'adresse IP 3) il fournit un entête Host: FQDN au serveur HTTP URL présentée avec adresse IP : 1) le navigateur se connecte à l'adresse IP 2) a priori il me semble qu'il fournit un entête Host: IP mais je n'ai pas sous la main de quoi le vérifier. Je ne crois pas que ce comportement soit modifiable avec du Jajascript côté Google (pas spécialiste de jajascript, désolé) pour squeezer le DNS. S'il l'est, cela constituerait un énorme trou de sécurité dans les navigateurs, donc bug susceptible d'être corrigé. Donc en plus de l'intention de Google et de la collaboration de l'ensemble des serveurs HTTP souhaitant être accessibles, il faut que tous les éditeurs de navigateurs modifient ce comportement. Totalement d'accord Google n'est pas l'Internet. La preuve il n'a rien a voir dans le routage :-) Non, que dans le peering (ou pas) :-) -- Sent from my FreeBSD server Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Le routage, enjeu de cyberstratégie
On Tue, Nov 06, 2012 at 12:05:23PM +0100, Kavé Salamatian wrote: Oui. Mais un defaut de protectionn ne justifie pas une attaque. Suppose que quelqu'un trouve un moyen astucieux pour s'attaquer au DNS .fr. Que faut il faire : 1- lui decerner une medaille d'astuce et le le congratuler pour son intelligence 2- dire que c'est pas sa faute si les ingenieurs de l'AFNIC ne sont pas aussi intelligent/prevoyant, etc... que lui 3- dire que c'est un delit que de s'attaquer a l'infrastructure d'autrui avec objectif d'y nuire. Un certain Lawrence Lessig a relativement bien résumé la question, à la base : code is law C'est plus profond qu'il n'y parait. Ça rend les discussions de souveraineté, d'extraterritorialité et de gouvernance assez largement oiseuses et dépassées. La tech du XXIe siècle d'un côté, les schémas politiques hérités du XVIIIe de l'autre. (je ne prends pas là position pour dire que c'est bien ou mal, je dis juste que c'est comme ça) -- Sent from my FreeBSD server Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Le troll du lundi par Michel
On Tue, Jun 21, 2011 at 10:30:40AM +0200, Clement Cavadore wrote: PURe, j'irai peut être pas jusque là, un seul troll dans la journée s'il vous plait... :-) Néanmoins, à l'époque, voir un nom de domaine en .fr était gage d'un minimum de sérieux. Une boite, avec un nom enregistré (INPI, etc), c'était pas le plus compliqué à faire, mais pas à la portée de n'importe quel neuneu en mal de grosses merdes. L'Internet civilisé, quoi. Ayant eu à en souffrir dès le début des années 90 : bof bof. Blague à part, pour ma part je n'ai pas d'avis très tranché sur ces ouvertures de gTLD ICANN, on verra, ça peut être une bonne comme une mauvaise chose, un peu des deux à la fois probablement. Mais critiquer ça sur les bases du .fr anciennes règles qui étaient -- désolé -- indéfendables, c'est un anachronisme complet et une analogie plus que douteuse, car ça n'est absolument pas comparable. -- Sent from my FreeBSD server Pierre Beyssac p...@fasterix.frmug.org --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Multicast monitoring ,
Bonjour, On Mon, Oct 01, 2007 at 02:04:31PM +0200, Xavier Beaudouin wrote: J'essaye en vain de trouver un outil si possible opensource (ou a la limite freeware) qui tournerais sous linux pour monitorer du Multicast... [...] Ce que je cherches c'est un ensemble qui pourrais m'indiquer la disponibilité des groupe multicast a coup de snmp... Eg quels groupe ais-je a l'instant T (demande page web par exemple), et eventuelleemnt un graphe dans le temps me permettant de savoir de quelle heure a quelle heure tel groupe multicast est arrivé sur mon réseau... Pas de réponse sur ça, il faudrait interroger les tables de routage multicast du routeur... ça doit être possible, je n'en sais pas plus. L'autre solution (réclamer un flux, voir s'il arrive, retourner un code d'erreur en rapport dans Nagios ou équivalent) est impraticable sur des flux à haut débit qu'on ne souhaite pas recevoir en permanence car il provoque évidemment une grosse surconsommation. Question supervision j'utilise une petite application appelée dbeacon qui présente une matrice de connectivité avec les sites partenaires : http://fivebits.net/proj/dbeacon/ C'est très utile pour débugguer les problèmes de connectivité (y compris sur un réseau interne), mais ça ne dit rien sur le trafic, les groupes reçus ou les pertes de paquets. -- 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] Content Deliver y Network (CDN) à la francaise
On Fri, Dec 01, 2006 at 10:55:38AM +0100, [EMAIL PROTECTED] wrote: a aucun probleme pourqu'un client puisse faire 100Mbps. d'ailleurs on en a plein qui le font. d'aileurs j'ai aucun client qui puisse me dire j'arrive pas faire mes 100Mbps. [...] les offres qu'on propose n'ont pas été prevues pour ce type de clients. ces clients là doivent construire leur backbone qui doit repondre à leur besoins, pas squater un reseau d'un tient qui Donc si je suis bien : - n*100Mbps de n clients perso, c'est bien et tu sais gérer ; - n*100Mbps de client pro c'est mal et tu ne sais pas gérer et il faut qu'ils aillent voir ailleurs, ouh les méchants qui tondent la laine sur le dos d'OVH. Et moi qui aurais juré que 1Mbps = 1Mbps. Marketing, quand tu nous tiens ! C'est une chose d'orienter son discours à destination des utilisateurs individuels, mais il ne faudrait peut-être pas les prendre pour des idiots. -- Pierre Beyssac [EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] Con tent Delivery Network (CDN) à la francaise
On Fri, Dec 01, 2006 at 11:21:55AM +0100, Jean-Francois Cousi wrote: En faisant exploser la Bande Passante moyenne par abonné, les services de vidéo (ajouté au P2P) remettent en cause tout le modele économique des FAI basé sur la mutualisation de la BP (mais c'est pareil pour les hébergeurs qui fournissent 100Mb par serveur). En tant que site utilisateur averti, je voudrais apporter un point de vue différent : 1) le développement de la bande passante consommée/fournie par utilisateur était -- et est encore -- prévisible. Tous ces discours d'opérateurs/FAI se plaignant de l'explosion de la consommation oublient que celle-ci suit tout simplement l'offre disponible, LA LEUR... et réciproquement. C'est certain qu'il serait beaucoup plus rentable pour les FAI de vendre des millions de liaisons 20 Mbps ADSL si personne ne les utilisait, mais la nature a horreur du vide. 2) sur le P2P qui sature les réseaux. Même refrain, je rappelle que le P2P a longtemps été un produit d'appel quasiment explicite dans les pubs de FAI ADSL ! 3) sur la distribution de vidéo. Les technologies type multicast (voire anycast), sont sous développées et sous exploitées au niveau Internet, elles servent uniquement en interne chez les FAI pour les bouquets vidéo sur ADSL. C'est dommage et les FAI, qui ne proposent pas d'offre multicast, en sont très largement responsables. Le routage multicast ne passe pas bien à l'échelle d'Internet ? C'est vrai, mais si personne ne s'en sert, qui va travailler dessus ? Quelles solutions ? -Augmenter le prix de l'abonnement -Diminuer les débits des clients -Faire financer le réseau par les éditeurs de contenu haut débit = Brider la BP sortant du réseau: 20Mb non bridé en interne chez le FAI = Brider la BP vers certains ports ou certains contenu: Rate limiting pour Il y en a deux non citées : - Ne rien faire, suivant le principe du Best effort (bienvenue chez IP). Les premiers contenus impactés sont ceux qui sont les plus consommateurs et malcommodes à gérer, la VoD d'abord, les téléchargements de vidéo ensuite. Si les sites de distribution de vidéo abusent autant que les FAI essaient de nous l'expliquer, ils seront les premiers pénalisés. Si des FAI meilleurs que les autres arrivent à gérer, tant mieux pour eux. C'est un problème de gestion de croissance de l'activité, certains sont bons, d'autres mauvais, et que les meilleurs gagnent. - Optimiser les méthodes de distribution de vidéo : goto 3) ci-dessus. Pour les FAI c'est pareil, si le P2P et la video font exploser le cout et par conséquent soit augmente le prix soit dégrade la qualité de service, pourquoi ceux qui ne les utilisent pas devraient payer pour ceux qui en abuse ? C'est tout le problème de la facturation liée à la consommation réelle. Soit ça s'appelle le Minitel et ça se casse la gueule parce que le système de tarification empêche l'évolution des débits et des technos, soit ça coûte très cher à mettre en oeuvre pour un résultat plus qu'incertain (cf Noos). C'est plus de la gestion de la pénurie qu'une solution à terme. -- Pierre Beyssac [EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
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/
