[FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 24 mai 2011 23:49, Pascal Rullier pas...@rullier.net a écrit : Bonjour, En voyant les routes entre 2 abonnements orange sur la même plaque AMontpellier-652-1-144-1.w81-251.abo.wanadoo.fr je me dis que l'on aime faire voyager les paquets par Paris... Il n'y aurait pas l'un des 2 accès qui aurait l'honneur d'avoir une IP fixe ?? Quand on était chez Orange, le passage en IP fixe nous faisait géolocaliser à Paris au lieu de Lyon, il semble y avoir une plage d'ip spécifique pour ça, avec un LNS différent et un reverse toujours aubervilliers. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25/05/2011 08:19, Paul Rolland (ポール・ロラン) a écrit : C'est surement ce qui permet a S. Richard d'annoncer 5% de croissance de traffic mobile sur Paris par semaine au cours de la premiere journee de l'e-G8 ! Ils ont du deploye B-3G-P sur les infras ;) Non, vous n'y êtes pas. C'est bien lié au e-G8, mais c'est un passage obligé par Paris afin d'appliquer les futures mesures de DPI qui seront rendues obligatoires par la responsabilisation des FAI en cas de piratage. Bonne journée quand même.. :/ Rémi. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 24 mai 2011 23:49, Pascal Rullier pas...@rullier.net a écrit : Bonjour, En voyant les routes entre 2 abonnements orange sur la même plaque AMontpellier-652-1-144-1.w81-251.abo.wanadoo.fr je me dis que l'on aime faire voyager les paquets par Paris... Oui je sais, ici ce n'est pas le helpdesk des FAI, c'était juste pour montrer une aberration de plus... Et alors ? FT peut avoir plein de raisons de faire passer un paquet par Paris. Le traffic qui doit de toute façon aller à Paris (transit/peering/plates-formes services internes) est probablement infiniment supérieur au traffic qui va directement sur un autre client FT. C'est pas un Business VPN IP/MPLS là, c'est un accès internet, mass market: ça leur simplifie l'architecture et leur donne un point de contrôle pour effectivement remplir les obligation légales (qu'on les aime ou pas elles sont obligatoires), faire de la QoS, du contrôle d'accès (ah vous avez pas payé votre facture ?), et sûrement plein d'autres raisons que je ne connais pas. L'aberration c'est ce genre de réflexions à la va-vite qui manquent de connaissances de fond. Un réseau d'opérateur national avec des millions de clients, c'est n'est pas un LAN avec 3 routeurs. Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 11:48, Guillaume Leclanche guilla...@leclanche.net a écrit : Et alors ? FT peut avoir plein de raisons de faire passer un paquet par Paris. Le traffic qui doit de toute façon aller à Paris (transit/peering/plates-formes services internes) est probablement infiniment supérieur au traffic qui va directement sur un autre client FT. C'est pas tant une raison de passer par Paris que des héritages architecturaux remontant aux premiers déploiements ADSL. Faut pas perdre de vue que la grande majorité des DSLAM encore exploités par FT sont raccordés en ATM, et que toutes les connexions sont terminées sur des LNS après avoir été transportées sur la boucle ATM nationale. La logique chez FT c'est de router une connexion sur tel ou tel LNS en fonction de sa configuration. Une ligne ADSL GP classique ira sur un des nombreux LNS configurés pour ça, attribué à la construction de la ligne, avec un backup prédéfini. Une ligne qui a l'option IPfixe basculera sur un LNS nominal et un secours qui routent uniquement les plages d'IP fixe. C'est pas un Business VPN IP/MPLS là, Boarf, la logique est sensiblement la même sur ces offres là c'est un accès internet, mass market: ça leur simplifie l'architecture et leur donne un point de contrôle pour effectivement remplir les obligation légales (qu'on les aime ou pas elles sont obligatoires), faire de la QoS, du contrôle d'accès (ah vous avez pas payé votre facture ?), et sûrement plein d'autres raisons que je ne connais pas. L'aberration c'est ce genre de réflexions à la va-vite qui manquent de connaissances de fond. Un réseau d'opérateur national avec des millions de clients, c'est n'est pas un LAN avec 3 routeurs. Je me demande d'ailleurs si quelqu'un chez FT connaît le nombre de routeurs en prod sur RBCI / RAIN / 3215 :p -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 11:58, Jérôme Nicolle jer...@ceriz.fr a écrit : Je me demande d'ailleurs si quelqu'un chez FT connaît le nombre de routeurs en prod sur RBCI / RAIN / 3215 :p Ouais, le mec qui paye les taxes de maintenance à Cisco, Juniper, Alcatel co :) Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 11:48, Guillaume Leclanche guilla...@leclanche.net a écrit : Le 24 mai 2011 23:49, Pascal Rullier pas...@rullier.net a écrit : Bonjour, En voyant les routes entre 2 abonnements orange sur la même plaque AMontpellier-652-1-144-1.w81-251.abo.wanadoo.fr je me dis que l'on aime faire voyager les paquets par Paris... Oui je sais, ici ce n'est pas le helpdesk des FAI, c'était juste pour montrer une aberration de plus... Et alors ? FT peut avoir plein de raisons de faire passer un paquet par Paris. Le traffic qui doit de toute façon aller à Paris (transit/peering/plates-formes services internes) est probablement infiniment supérieur au traffic qui va directement sur un autre client FT. Peut être mais quand cela passe par le même routeur (étape 2 et 9), j'ai du mal à comprendre pourquoi ca part par Paris pour revenir sur le même routeur au lieu d'y aller directement L'aberration c'est ce genre de réflexions à la va-vite qui manquent de connaissances de fond. Un réseau d'opérateur national avec des millions de clients, c'est n'est pas un LAN avec 3 routeurs. C'est sur, cela rend la complexité encore plus complexe... Mais à forcer les protocoles de routage qui choisissent toujours par défaut le chemin le plus court, on voit ce genre d'aberration... Cdt, --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 12:08, Pascal Rullier pas...@rullier.net a écrit : Le 25 mai 2011 11:48, Guillaume Leclanche guilla...@leclanche.net a écrit : Le 24 mai 2011 23:49, Pascal Rullier pas...@rullier.net a écrit : j'ai du mal à comprendre pourquoi ca part par Paris pour revenir sur le même routeur au lieu d'y aller directement [...] Mais à forcer les protocoles de routage qui choisissent toujours par défaut le chemin le plus court, on voit ce genre d'aberration... j'ai du mal à comprendre n'implique _jamais_ c'est une aberration. Tu as commencé ce thread directement en attaquant FT en sous-entendant que c'était des gros blaireaux qui connaissent rien à BGP. Si tu voulais savoir pourquoi ils font ça, le plus simple pour obtenir une réponse c'est d'avouer que tu n'en as aucune idée et de demander pourquoi; c'est quand même un des buts de cette liste et la manière dont tu t'y es pris ne risque pas d'inciter quiconque de FT à donner une explication technique. Le incumbent-bashing au niveau technique, ça ne sert à rien et c'est contre-productif. Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 13:04, Guillaume Leclanche guilla...@leclanche.net a écrit : Le 25 mai 2011 12:08, Pascal Rullier pas...@rullier.net a écrit : Le 25 mai 2011 11:48, Guillaume Leclanche guilla...@leclanche.net a écrit : Le 24 mai 2011 23:49, Pascal Rullier pas...@rullier.net a écrit : j'ai du mal à comprendre pourquoi ca part par Paris pour revenir sur le même routeur au lieu d'y aller directement [...] Mais à forcer les protocoles de routage qui choisissent toujours par défaut le chemin le plus court, on voit ce genre d'aberration... j'ai du mal à comprendre n'implique _jamais_ c'est une aberration. Oui j'ai du mal à comprendre, mais coté routage pur, c'est une aberration. Vous conviendrez non ? Tu as commencé ce thread directement en attaquant FT en sous-entendant que c'était des gros blaireaux qui connaissent rien à BGP. Ne pas me faire écrire les soi disants sous entendus. La forme, je l'avoue, était sur un modèle Skudi made in TrollLand. Si tu voulais savoir pourquoi ils font ça, le plus simple pour obtenir une réponse c'est d'avouer que tu n'en as aucune idée et de demander pourquoi; c'est quand même un des buts de cette liste et la manière dont tu t'y es pris ne risque pas d'inciter quiconque de FT à donner une explication technique. Le incumbent-bashing au niveau technique, ça ne sert à rien et c'est contre-productif. J'aimerais bien avoir le pourquoi de cette incompréhension. La chose positive, et contrairement à ce que tu écris, est que l'étude est en cours coté Orange FT group. Merci à ceux de OFTG qui se penchent sur le souci technique. Cdt, --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Le 25 mai 2011 13:41, Pascal Rullier pas...@rullier.net a écrit : Le 25 mai 2011 13:04, Guillaume Leclanche guilla...@leclanche.net a écrit : Mais à forcer les protocoles de routage qui choisissent toujours par défaut le chemin le plus court, on voit ce genre d'aberration... j'ai du mal à comprendre n'implique _jamais_ c'est une aberration. Oui j'ai du mal à comprendre, mais coté routage pur, c'est une aberration. Vous conviendrez non ? Si on le prend hors contexte et uniquement dans le cadre scolaire théorique, oui c'est une aberration. Mais à l'intérieur de son réseau on fait comme on veut, si le L3 forwarding est tweaké de telle sorte que tout le trafic passe par un endroit centralisé, ça ne me choque pas. On ne joue pas avec e-BGP parce que là on parle à d'autres; mais pour tout ce qui est interne, tout est permis tant que ça marche et qu'on fournit le service promis au client. Puisqu'on parle de cas théoriques maintenant, les apparences peuvent être trompeuses: le fait que le premier hop soit le même ne veut pas dire que le traffic peut techniquement être routé entre les deux interfaces, il peut simplement s'agir de l'adresse source ICMPv4 qui est prise de manière identique; l'opérateur mettant par exemple tout le traffic entrant dans un PW quelle qu'en soit la destination, et fait qd même du TTL decrease. J'ai eu un cas en v6 d'un traceroute qui semblait passer par un transit pour un paquet qui devait rester dans notre réseau. Finalement l'IP du transit était celle configurée sur notre routeur et c'est simplement que le ICMPv6 time exceeded prenait comme source une autre adresse que celle de l'interface d'émission (qui était en Link Local). ça prend pas très longtemps à débugger mais ça donne à réfléchir vis-à-vis des interprétations de traceroute. En plus, entre MPLS, IP Fast Reroute, Multi-Chassis Link Aggregation, et autres technos funky, ça fait déjà qqs temps que le traceroute ne veut pas dire grand chose sans connaître en détails l'infrastructure sous-jacente. Et maintenant, chez un certain vendeur, les ICMPv6 sourcés avec une LL pour envoyer à une adresse globale (dans un cas particulier où l'interface d'émission a uniquement une LL configurée). Nous vivons une époque formidable: IPv4 avait à peine commencé à marcher qu'on doit se retaper tout le troubleshooting des stacks IPv6 des vendeurs ;) (mais c'était pas le sujet du thread) Donc mon point était (et est toujours) : ne jamais supposer a priori qu'un opérateur a fait une erreur sur son réseau interne parce qu'on voit quelque chose qui semble bizarre, surtout si cet opérateur a plusieurs millions de clients. Tu as commencé ce thread directement en attaquant FT en sous-entendant que c'était des gros blaireaux qui connaissent rien à BGP. Ne pas me faire écrire les soi disants sous entendus. [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto. Bon cette partie-là je ne débats plus dessus c'est sujet à interprétation. Si tu voulais savoir pourquoi ils font ça, le plus simple pour obtenir une réponse c'est d'avouer que tu n'en as aucune idée et de demander pourquoi; c'est quand même un des buts de cette liste et la manière dont tu t'y es pris ne risque pas d'inciter quiconque de FT à donner une explication technique. Le incumbent-bashing au niveau technique, ça ne sert à rien et c'est contre-productif. J'aimerais bien avoir le pourquoi de cette incompréhension. La chose positive, et contrairement à ce que tu écris, est que l'étude est en cours coté Orange FT group. ça n'est pas contraire à ce que j'écris, mais de toute façon tant mieux si on a une réponse pour comprendre quelle est la raison de ce comportement (qu'il soit voulu ou non), c'est toujours instructif et ça fait avancer le schmilblick :) Guillaume --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] RE: [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
Bonjour, Il me semble y avoir quelques erreurs dans les mails qui circulent sur frnog. Tout d'abord, il ne faut pas confondre LNS et BAS. Une ligne ADSL grand publique classique est raccordée sur un DSLAM, DSLAM lui-même raccordé en GE ou en ATM sur un équipement du réseau France Télécom. Les flux Internet arrivent sur un BAS qui dans les deux cas qui gère l'accès à Internet (au sens Radius). Un outil pédagogique explique ce cheminement sur http://www.francetelecom.com/sirius/reseau/cartes_reseaux/carte.html Cliquer sur accès internet dans l'onglet usage à gauche Pour les clients IP Fixe, le client arrive toujours sur un BAS (LAC) via la collecte GE ou ATM et il est renvoyé vers un LNS à travers le réseau IP FT (AS3215) dans un tunnel L2TP. Les LNS de FT sont répartis sur le territoire (métropole et DOM). Les LNS ne sont pas tous en IDF loin de là. Je n'ai pas trouvé de liens didactiques sur le site de France Télécom, mais vous trouverez des explications sur FrameIP http://www.frameip.com/l2tp-pppoe-ppp-ethernet/ = chapitre 6 Si nous revenons à l'intervention initiale de Pascal Rullier, 1. 192.168.1.10.0% 40.6 0.6 0.5 0.7 0.1 2. AMontpellier-652-1-144-1.w81-251.abo.wanadoo.fr 50.0% 3 33.3 33.3 33.3 33.3 0.0 3. 10.123.82.138 0.0% 3 33.5 33.6 33.5 33.7 0.1 4. xe-2-0-0-0.nrlyo101.Lyon.francetelecom.net 0.0% 3 40.2 40.1 40.0 40.2 0.1 5. tengige0-9-0-4.ntpst101.Paris.francetelecom.net0.0% 3 47.3 47.5 47.3 47.8 0.3 6. tengige0-4-0-5.ntsta301.Paris.francetelecom.net0.0% 3 48.6 48.1 47.6 48.6 0.5 7. xe-2-1-0-0.ncidf301.Aubervilliers.francetelecom.net0.0% 3 47.3 55.4 47.3 71.6 14.0 8. 80.10.215.194 0.0% 3 53.1 50.8 49.3 53.1 2.0 9. AMontpellier-652-1-144-1.w81-251.abo.wanadoo.fr0.0% 3 437.5 431.1 424.6 437.5 9.1 10.123.82.138 10. LAubervilliers-151-11-7-235.w193-251.abo.wanadoo.fr0.0% 3 79.9 84.2 79.3 93.3 7.9 le traceroute montre la chose suivante : 2- Pascal arrive sur son BAS de raccordement à Montpellier 3 à 8- Le BAS connait une route pour joindre le bloc 193.251.48.0/20 qui se trouve annoncée par un LNS IP Fixe situé à Aubervilliers. Le traceroute remonte jusqu'à ce LNS d'Aubervilliers. 8- Le LNS d'Aubervilliers qui porte le bloc 193.251.48.0/20 connait l'adresse 193.251.54.235 à travers un tunnel L2TP qui pointe sur un BAS de Montpellier 8 à 10- Pascal redescent vers le client 193.251.54.235 à travers un tunnel L2TP. Le délais afficher par le traceroute est elevé car il s'agit de refaire les étapes 2 à 8 dans le sens inverse. 10- La résolution DNS de l'étape 10 est trompeuse car à l'étape 10, nous sommes chez le client 193.251.54.235, à Montpellier (et pas à Aubervilliers). Cet aller-retour Montpellier - Aubervilliers est une conséquence de l'architecture historique mise en œuvre pour les clients IP Fixe, architecture qui repose sur quelques LNS situés en province et en IDF. En espérant avoir clarifié la situation, Pascal -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Jérôme Nicolle Envoyé : mercredi 25 mai 2011 11:59 À : Guillaume Leclanche Cc : Pascal Rullier; frnog@FRnOG.org Objet : [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto Le 25 mai 2011 11:48, Guillaume Leclanche guilla...@leclanche.net a écrit : Et alors ? FT peut avoir plein de raisons de faire passer un paquet par Paris. Le traffic qui doit de toute façon aller à Paris (transit/peering/plates-formes services internes) est probablement infiniment supérieur au traffic qui va directement sur un autre client FT. C'est pas tant une raison de passer par Paris que des héritages architecturaux remontant aux premiers déploiements ADSL. Faut pas perdre de vue que la grande majorité des DSLAM encore exploités par FT sont raccordés en ATM, et que toutes les connexions sont terminées sur des LNS après avoir été transportées sur la boucle ATM nationale. La logique chez FT c'est de router une connexion sur tel ou tel LNS en fonction de sa configuration. Une ligne ADSL GP classique ira sur un des nombreux LNS configurés pour ça, attribué à la construction de la ligne, avec un backup prédéfini. Une ligne qui a l'option IPfixe basculera sur un LNS nominal et un secours qui routent uniquement les plages d'IP fixe. C'est pas un Business VPN IP/MPLS là, Boarf, la logique est sensiblement la même sur ces offres là c'est un accès internet, mass market: ça leur simplifie l'architecture et leur donne un point de contrôle pour effectivement remplir les obligation légales (qu'on les aime ou pas elles sont obligatoires), faire de la QoS, du contrôle d'accès (ah vous avez pas payé votre facture ?), et sûrement
[FRnOG] Re: Re: [FRnOG] SORBS, blacklisting
La réponse de Sylvain me semble tout à fait constructive dans son contenu. Histoire de réagir : SORBS est loin d'être marginale en utilisation et c'est bien ce qui peut faire peur. De nombreux constructeurs l'on implémenté de base dans leurs boitiers (firewall, anti-spam) et software de messagerie electronique. C'est aussi ce qui explique que le nom de cette RBL soit aussi connu, aussi connu que son inventeur M.S. La RBL (Realtime BlackList) de TrendMicro nommée MAPS est plutôt une bonne RBL si on s'en tient au contexte global. à l'époque ou Dave Rand (cf : mrtg) était encore de la partie j'ai tjrs considéré qu'il faisait un travail plutôt correct. Les organisme de Blacklist propose souvent de nombreuse déclinaison de leur liste à tolérance graduelle. La liste DUL de MAPS est bien basée sur les IP considérées comme allouées dynamiquement, vue le complexité de la problématique spam (essentiellement basé sur la légèreté du protocole SMTP, Dave Crocker le reconnait lui-même), il me semble que cette pratique s'est révélé simple et efficace pour les admin de domaines lourdement sollicités. Leur algo se base en partie sur la structure du reverse DNS lorsque celui-ci contient des chaîne de caractères type dyn*. Généralement, un reverse DNS avec un terme de type static suffit à en sortir. Cependant, il est vrai que les RBL de ce type demande à ce que l'interlocuteur initiant la demande soit le correspondant au niveau du WHOIS, ce n'est pas si simple ... Pour en revenir à la RFC de base, je citerais plutôt la RFC2142 qui liste en plus du postmaster celui de l'ab...@domain.tld qui est un recours souvent plus efficace que le postmaster. Le message retournée en 5XX ou 4XX donne normalement la raison de ce blocage et pour les plus consciencieux utilisent le champs texte (associé au rejet SMTP) une URL vers le http://postmater.domain.tld/ donnant des infos sur le process à suivre pour s'en sortir (cf : AOL par exemple). Par contre, il est évident que vers un destinataire standard, le service concerné n'est pas toujours ...comment dire ... disponible :) Concernant SPF, si vous posséder votre domaine, le fait de l'annoncer (même avec un TTL très court sur des DynDNS) permet parfois de passer outre un éventuelle blacklistage car les algo des serveur en face autorise parfois en priorité les domaines dont le SPF est clairement annoncé. Outre l'adresse les systèmes liés à l'adresse IP, pour donner un signe de votre bonne foi en tant qu'émetteur il reste aussi la signature DKIM (collaboration de Cisco + Yahoo) des messages avec votre clé privée et clé publique annoncé sur un selecteur de votre domain émetteur. cependant, ce système reste très peu utilisé encore. En résumé : quoique l'on en pense, à ce jour, disposer d'une IP fixe reste pour le moment le moyen le plus sure de distribuer son mail ... 2011-05-25 H De ： Sylvain Leroy Date/heure ： 2011-05-25 01:08:04 A ： frnog Cc ： Sujet ： Re: [FRnOG] SORBS, blacklisting Le 24/05/2011 23:48, Yves-Alexis Perez a écrit : On mar., 2011-05-24 at 14:34 -0700, Michel Py wrote: troll Moi Monsieur, mon serveur de mail c'est Bill Gates qui l'a écrit. En personne. Tout le monde le sait, c'est comme Al Gore qui a inventé l'Internet. Des fois, c'est pratique. C'est qui qui a écrit ton logiciel de mail? Linus quoi? Il est même pas Américain. /troll http://lkml.org/lkml/2010/9/13/342 Avant que le thread ne dérive de trop, j'aimerais jeter un autre pavé dans la mare : Trend Micro Ceux derrière : http://www.mail-abuse.com/cgi-bin/lookup?ip_address=$your_ip; Dans le même style que SORBS, les DUL de Trend Micro appliquent l'algo très simple : toutes les ip (ip dynamiques ou fixes, d'où le D dans DUL...) sauf les smtp FAI... Impossible de discuter avec eux, les solutions étant que mon FAI fasse une demande de whitelisting de mon ip, ce qui n'arrivera jamais. A par eux, en 8 ans de services smtp auto-hébergés, je n'ai jamais eu de gros problèmes. Les admins que j'ai eu par e-mail ou téléphone pour les demandes de whitelisting ont toujours été sensible au reverse DNS correct et au champs SPF valide. Le problème le plus rebutant pour moi a souvent été de trouver un moyen de discussion avec l'admin du serveur smtp filtrant, sachant qu'une bonne partie filtrent postmaster@ alors que d'après la RFC 5321 § 4.5.1 http://tools.ietf.org/html/rfc5321 SMTP systems are expected to make every reasonable effort to accept mail directed to Postmaster from any other system on the Internet. In extreme cases -- such as to contain a denial of service attack or other breach of security -- an SMTP server may block mail directed to Postmaster. However, such arrangements SHOULD be narrowly tailored so as to avoid blocking messages that are not part of such attacks. Sur de gros serveurs smtp, le fait de laisser postmaster@ hors filtrage est-il vraiment gênant ou est-ce simplement une mauvaise implémentation de la RFC? -- Sylvain
[FRnOG] RE: [FRnOG] RE: [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
pascal.nou...@orange-ftgroup.com Cet aller-retour Montpellier - Aubervilliers est une conséquence de l'architecture historique mise en œuvre pour les clients IP Fixe, architecture qui repose sur quelques LNS situés en province et en IDF. Sans apporter mon soutien ouvert à FT, je dirais quand même que c'est facile de critiquer quand on n'a pas la partie historique à traîner comme un boulet. Plus le réseau est ancien, plus on va trouver des momies dans les placards, et souvent (d'après mon expérience) c'est plutôt la faute aux dirigeants qui ont poussé les ingénieurs à faire une migration automatisée qui à force de générations finit par produire des aberrations techniques. Vieux dicton de la Royale: tout ce qui bouge, on le salue; le reste on le peint (en gris). Dicton non militaire mais néanmoins populaire: peinture + merde = propreté. Le problème de FT, c'est qu'il y a trop de couches de peinture. Il n'y a que quand on commence à peindre qu'on se rend compte de l'épaisseur de ce qu'il y a dessous. Pascal Rullier, toi qui a été dans la marine, tu devrais apprécier la peinture mieux que ce que tu ne le fais. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] RE: [FRnOG] RE: [FRnOG] Re: [FRnOG] Re: [FRnOG] c'est pas trolldi mais certains devraient réviser BGP-howto
2011/5/25 Michel Py mic...@arneill-py.sacramento.ca.us: pascal.nou...@orange-ftgroup.com Cet aller-retour Montpellier - Aubervilliers est une conséquence de l'architecture historique mise en œuvre pour les clients IP Fixe, architecture qui repose sur quelques LNS situés en province et en IDF. Sans apporter mon soutien ouvert à FT, je dirais quand même que c'est facile de critiquer quand on n'a pas la partie historique à traîner comme un boulet. Plus le réseau est ancien, plus on va trouver des momies dans les placards, et souvent (d'après mon expérience) c'est plutôt la faute aux dirigeants qui ont poussé les ingénieurs à faire une migration automatisée qui à force de générations finit par produire des aberrations techniques. C'est sur, on traine son passé dans ses placards, cela n'empêche pas de faire évoluer son réseau mais quand ça marche, on y touche plus. Vieux dicton de la Royale: tout ce qui bouge, on le salue; le reste on le peint (en gris). Tout à fait cher Nelson... Dicton non militaire mais néanmoins populaire: peinture + merde = propreté. C'est pas l'inverse ? merde + peinture = propreté :) Le problème de FT, c'est qu'il y a trop de couches de peinture. Il n'y a que quand on commence à peindre qu'on se rend compte de l'épaisseur de ce qu'il y a dessous. On peut prendre la même analogie avec les couches de papiers peints... Ca me rappelle mon dernier décollage dans la chambre de mon fils, on est remonté à 4 couches et découvert des peintures rupestres des enfants des 1ers occupants. :) Pascal Rullier, toi qui a été dans la marine, tu devrais apprécier la peinture mieux que ce que tu ne le fais. Dans le coté marin, la peinture contient de l'antirouille. Il y a de la couche... J'ai pu tater du BULL pour sortir des états de services, mon pinceau fut plutôt un clavier et ça migrait vers de l'unix et du sybase... Comme quoi l'évolution des dinosaures est possible. Cdt, -- Pascal, --- Liste de diffusion du FRnOG http://www.frnog.org/
