[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: [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/
