[FRnOG] Re: MTU sur les points d'echange
On 14 Oct, Jérôme Nicolle wrote: Quels MTU tiennent nos IX nationaux ? Le problème c'est que sur un point d'échange *tous* les participants doivent avoir la même MTU. Donc la MTU du VLAN par défaut c'est toujours 1500. Pas d'autres solutions. Par contre certains points d'échange (celui de Netnod par ex) proposent un deuxième VLAN avec une MTU plus grande (9k par ex) pour ceux qui veulent jouer dans la cours des grands. Mais comme les deux VLAN ne communiquent pas entre eux, tu ne vas pas jouer avec grand monde ... Pour ces histoires de MTU, est ce qu'il y a déjà eu des expérimentations concrètes pour essayer de les augmenter ? Le seul endroit où tu peux commencer à jouer c'est sur tes liens de transit, car il n'y a que toi et ton copain d'en face. (la plupart des opérateurs ont un backbone avec une grosse MTU) Si tu arrives à faire cela, alors on pourra jouer ensemble ! -- Jean-Philippe --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: Le troll du vendredi par Michel
Michel, Le 15/10/2011 05:32, Michel Py a écrit : Effectivement il y a une grosse différence. La différence c'est que l'hypothétique déploiement d'IPv6 qui sera déployé l'année prochaine depuis 15 ans, plus personne n'y croit, alors que LISP comme c'est nouveau malgré que ça ne soit que du vieux ressassé depuis 15 ou 20 ans comme IPv6 (et j'ai posté des liens) ça a l'air d'être nouveau donc on trouve encore des bleubites pour y croire. En plus, ce n'est pas lié à IPv6. Puisqu'on en est au jeu des différences, que dis tu de cette ressemblance : LISP est promu par les mêmes équipementiers responsables du retard et des coûts dans l'adoption d'IPv6. Un conspirationniste pourrait en conclure que, bien qu'ils s'en défendent, les juniscocade et compagnie auraient pu délibérément nuire à IPv6 pour vendre de l'indiréction plus tard... Ceci-dit les enfants, vous commencez à prendre des risques politiques sérieux en devenant les derniers défenseurs du bastion IPv6. A ce point-là, ça devient un pari, et je ne voudrais pas être dans vos pompes dans 10 ans si IPv6 ne décolle pas, parce qu'il va y avoir quelqu'un qui va ressortir vos contribs d'aujourd'hui et vous allez être promus au nettoyage des chiottes. Tiens, c'est marrant, je vois bien le risque à s'accrocher à IPv4, mais pas celui à s'intéresser et déployer IPv6. Et justement, une des applications possibles de LISP, c'est de maintenir de la connectivité v4 on demand à l'edge, sur un backbone intégralement v6, qui sur des équipements récents pourrait justement avoir des jumboframes de partout, comme ça on a plus aucun inconvénient à LISP. Le Saint Graal c'est super si on le trouve, on a l'air con si on ne le trouve pas. Petit récapitulatif: 1. IPv6, c'est une DFZ petite. Du genre, ID/LOC qui marche. 2. IPv6, c'est le renumbering facile. D'ailleurs, je me demande à quoi ça servirait, si 1 marchait. 3. IPv6, c'est les adresses dont le monde entier à besoin pour que l'Internet ne s'arrête pas. Euh je ne veux pas être méchant, mais il ne vous reste que 1 ou 2 ans pour retourner votre veste ^H^H^H^H^H pantalon. Signé: quelqu'un qui a l'air con. Michel. -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] extension de Vlans
Salut la ML. Je souhaite rebondir sur un point d'un message envoyé hier à propos de l'extension de Vlan (dans le sujet LISP), pourquoi beaucoup de gens haïssent l'extension de VLan ? Perso je suis plutôt (voire même très) en faveur du L2 étendu dans les environnements datacenters pour la souplesse que ça apporte : - en cas de déménagement pas de réadressage des machines - capacité à faire du Vmotion intersite (je dis pas que ce soit forcément intelligent mais beaucoup de gens systèmes le demande, ils préfèrent utiliser ça que VMWare SRM) - abstraction des problèmes DNS liés au GSLB (dans sa version DNS donc) : problème de non respect des TTLs et cache négatif... - clusters étendus divers pour le côté client - la VIP (IBM, HP, Veritas, Oracle RAC, [rajouter ici les 50 fournisseurs de clusters applicatifs qui nécessitent du L2 pour être stateful] même NLB soyons fous) aussi bien que pour les liens privés pour les heartbeats qui parfois nécessitent des adjacences L2 directes car le protocole de heartbeat n'est même pas basé sur IP - arrivée de FCoE en dehors des DCs (sur certaines plateformes FCoE est supporté sur des distances de type MAN), FCoE est par définition non routable Certes à part dans le cas de déménagement, l'extension de Vlans longue distance nécessite l'extension du stockage (pour les clusters / Vmotion), et dans ce cas les distances se réduisent (une centaine de kms max) à cause des contraintes dues au stockage. Pour quoi la plupart des gens détestent-ils l'extension L2 ? À cause de l'extension STP ? Y a plein de technos qui suppriment ce risque : régions MSTP (sauf pour l'instance 0), etherchannel distribué (style Cat6500 VSS ou équivalent en étoile qui supprime toute boucle logique intersite), EoMPLS / VPLS etc... qui permettent de limiter le domaine STP à un site unique sans l'étendre sur ses voisins Associé à ça y a du storm-control pour limiter les soucis, en plus y a pas mal de technos émergentes qui permettent de venir sur des technos routées au niveau 2 :Trill et son TTL, 802.1aq shortest path bridging qui est le concurrent Pas mal de constructeur poussent le L2 suite à la pression des applis. Des idées là dessus ?
Re: [FRnOG] extension de Vlans
Aaaah le niveau 2 étendu... D’expérience l’idée arrive dans une réflexion type PRA/PCI dont le déclencheur serait (au choix) : - l'avion qui s’écrase sur le Datacenter a Roger Gicquel - le tremblement de terre en région Parisienne - la crue centennale de la Seine qui inonderait le Datacenter situe a 50m en dénivelé. bref, on imagine le scénario du pire (probabilité 1/10E beaucoup), et on essaye de trouver LA parade, et la, le VLAN étendu arrive au galop car la finance s'en mêle, et qu'il est toujours plus facile d'avoir un cluster de base de données sur deux sites, que deux clusters avec de la synchro de stockage. Mais la, deux problèmes : - d’expérience encore, la première cause d'outage de Datacenter, c'est l'erreur humaine. Et celle qui fait le plus de dégât sur Ethernet, c'est bien entendu la connerie qui plante le niveau 2 - c'est mignon d'essayer de parer au cas de panne majeur avec un système qui fait qu'un problème sur le site 1 se propage instantanément sur le site 2. Principe de base du coup, avant d'essayer de faire une architecture de Datacenter résiliente au crash d'avion, commencer par faire un Datacenter résilient a l'erreur humaine (le Datacenter exploitation-proof). Sur le second point, ça va plus loin que le simple vlan étendu. Un cluster de base de données, par définition, partage la même donnée car il voit un stockage cohérent ... a un certain temps de synchro prés. Je connais une superbe solution de réplication de données synchrone sur SAN, qui permet d'assurer d'avoir exactement la même donnée sur deux stockage distant, grâce a un jeu d’écriture en cascade. Sur les slides c'est super. Si un avion vient a s’écraser sur mon site 1, mon site 2 reprend directement la main, sans perte de données. Bien entendu, aux latences, ouvertures de flux, bascule DNS près sur le frontal. Par contre si je corromps ma donnée sur le site 1, elle est instantanément corrompu sur le site 2. Et malheureusement, ça arrive beaucoup plus souvent que l'avion sur le parking. Le vlan étendu, c'est le rêve de tout inge système, car finalement il est utilisateur de la couche IP, mais sans forcement bien la comprendre. Quel ingénieur réseau ferait un backbone avec un seul gros vlan de routage ? Pourtant ça marcherait ! Et le problème avec ça, c'est qu'on arrive très vite avec des concepts fumeux de datacenter virtuel, ou datacenter étendu avec la possibilité de cramer deux ou trois sites d'un coup. Maintenant, y a l'existant, et des trucs aussi gros que des clusters de base de données bancaires ne vont pas evoluer pour s'adapter a l'architecture réseau, c'est au réseau de s'adapter. Et la, financièrement, on pourra toujours te prouver qu'un vlan étendu c'est moins cher qu'une refonte de code, ou que d'exploiter du LISP pour bouger des VMs Jusqu'au premier crash. Personnellement, juste l’année dernière, j'ai vu des Datacenters dans le noir a cause de boucle spanningtree, de serveurs pinguant la 224.0.0.2 avec un ttl = 1 (IPMP chez Sun), ou d'interop Cisco = Alcatel qui marche pas aussi bien que sur les slides... Je suis juste content qu'on ait perdu qu'un Datacenter a chaque fois, ce qui est déjà énorme, et qui aurait pu être évité avec un cloisonnement du datacenter en plusieurs zones de niveau 2 (topologie core - distrib - access). Pour VMWare, problème résolu en discutant avec les premiers concernés : long distance VMotion non supporte si tu n'es pas sur LA technologie du partenaire (Cisco). Et après en interne, tu apprends que ca, c'est du politique, et que les inge VMWare te le déconseillent fortement. SRM est un outil de scripting pour du PRA/PCI pour le coup, base sur le principe que lors de la perte d'un datacenter 1, tu redémarres une partie de l'infra a distance, en modifiant les configurations a la volée (ré-écriture du .vmx des VMs par exemple) Bref, si ton besoin est de faire un seul datacenter logique sur deux sites physiques distants, alors bien sur, vlan étendu et autres joyeusetés (VPLS, OTV, TRILL, ce que tu veux, juste après tu essaieras de nous expliquer ou se situe la gateway de ton vlan, et comment tu optimises ton trafic inter-sites, qui en général n'est pas gratuit. A part GLBP en v4, et des annonces nd bien tunees en v6, je ne vois pas comment s'en sortir, et encore c'est pas simple). Maintenant, sois juste bien conscient que tu n'as QU'UN site logique, et que donc si tu veux gérer un PRA/PCI, il t'en faut un deuxième (voire un deuxième couple de sites physiques), et que non, tu ne peux pas gérer une véritable continuité de services avec du vlan étendu. Et pour répondre a la remarque évidente que si le vlan étendu c'est mal, alors pourquoi les constructeurs s'acharnent a sortir des solutions d'extension de niveau 2 ?, je dirai juste : quand y a un con qui est prêt a acheter, moi je vends, c'est un principe. Y a toujours deux solutions a un problème ! (de mémoire, Kaamelott) Le 15 octobre 2011 21:55, Surya ARBY arbysu...@yahoo.fr a écrit : Salut la ML. Je souhaite
