Re: [FRnOG] [TECH] Linux, Multicast et VXLAN
Hello Vincent, J'ai déjà lu ta page en fait, pas plus tard qu'hier. J'étais parti pour utiliser pimd (de manière assez arbitraire) à l'étape d'après, mais je te confirme que je n'ai aucun démon configuré pour router. ip mroute ne retourne rien de rien. En revanche, ton idée m'a permis de voir une erreur dans mon setup, et oui j'ai bien quelque chose d'autre qui réinjecte la trame multicast ... comme quoi il était nécessaire par principe que je pose la question, pour me faire lever le nez. Je vais attaquer la partie router. Donc, merci ! PS : toutes mes confuses pour les yeux qui piquent avec les fautes de mon premier mél (s/trop/troll/, etc). Le 2 décembre 2016 à 15:45, Vincent Bernat <ber...@luffy.cx> a écrit : > ❦ 2 décembre 2016 14:53 +0100, Baptiste Malguy <bapti...@malguy.net> : > > > Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis > > 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. > > Perso, je trouve cela fort suprenant si tu n'as pas encore mis de démon > de routage multicast. Linux route le multicast comme l'unicast et > consulte la table de routage classique. Es-tu sûr que tu ne vois pas > simplement les trames émises sur eth0 revenir sur eth1 ? ip mroute > est-il vide ? > > Sur le VXLAN Linux, j'avais fait un peu de doc ici quand ça avait été > développé. J'ai retesté récemment et ça fonctionnait toujours : > https://vincent.bernat.im/en/blog/2012-multicast-vxlan.html > > Note que dans ton cas, faire de l'ECMP multicast ne marchera pas sans > démon de routage (genre du PIM-SM). Je compte faire ça très > prochainement, donc tout retour de ta part m'intéresse. > -- > Keep it right when you make it faster. > - The Elements of Programming Style (Kernighan & Plauger) > -- Baptiste Malguy --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Linux, Multicast et VXLAN
Bonjour, C'est vendredi, et pourtant je n'ai pas de trop à proposer :) Il était une fois Linux, le multicast et VXLAN (et un chouia de BGP). Mon cas de figure est peut-être simplissime à résoudre et je n'ai pas encore lu la bonne page de manuel à ce propos, donc si au final j'obtiens un RTFM avec la référence qui va bien, je suis preneur ! Je teste le setup décrit plus bas, et c'est sur la partie multicast que c'est drôle. La version courte : avec VXLAN (au moins), il semble que quoique je fasse, le noyau semble envoyer les trames multicast sur toutes les interfaces réseau, peu importe que j'ai cherché à le désactiver ou pas. Le trafic étant généré par le noyau et non par un processus qui puisse être influencé, je sèche après avoir testé quelques pistes. Je cherche à réduire au maximum la couche L2 au minimum du setup. Deux machines (et une gw qui n'a pas d'importance), chacune avec eth0 et eth1, et Bird : - host1 : eth0 / 192.168.50.5/28, eth1 / 192.168.50.20/28, lo:1 / 192.168.100.2/32 - host2 : eth0 / 192.168.50.6/28, eth1 / 192.168.50.21/28, lo:1 / 192.168.100.3/32 - gw : 192.168.50.1/28, 192.168.50.17/28 et 192.168.100.1/32 et ses propres uplinks - du BGP entre tout ce petite monde (Bird sur host1 et host2). gw annonce la default route, chacun annonce sa loopback et plus tard d'autres routes - plutôt qu'avoir une redondance en L2 au travers d'un trunk/LAG/portgroup, ça se passe en L3, rien de transcendant jusque là. - Ubuntu Xenial (16.04), avec un noyau 4.4.0-47 A présent je veux ajouter du VXLAN sans mettre (pour le moment) de contrôleur. Avant même de vouloir faire annoncer le VXLAN sur un groupe multicast depuis la loopback (et profiter de la redondance L3), je commence par tester le fonctionnement plus simple. Et déjà là, ça coince : Lorsque je fais ceci : # ip link add vxlan10 type vxlan id 10 group 239.0.0.10 ttl 4 dstport 4789 dev eth0 # ip link set vxlan10 up Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul. Idem en configurant vers eth1 plutôt qu'eth0. Idem en ayant préalablement saisi ces commandes avant l'ajout de vxlan10 : # ip link set eth1 multicast off # ip link set eth1 allmulticast off # route add -net 224.0.0.0 netmask 224.0.0.0 dev eth0 A noter qu'utiliser "ip link add ... local 192.168.255.2" fonctionne comme je le le souhaite (ce qui est mon objectif au départ) mais malgré, le trafic multicast part partout, que je puisse le maîtriser sur une évolution "d'archi". Suis-je en mode neuneu ou bien c'est plus subtile ? -- Baptiste Malguy --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Plusieurs postes d'administrateur système et/ou réseau
Bonjour, Diabolocom recrute plusieurs administrateurs expérimentés en système et/ou réseau sur Levallois-Perret (au pied de la station de métro Anatole France, ligne 3). Plus bas vous trouverez le lien vers l'annonce sur le site. Diabolocom développe et opère des plateformes de services en cloud permettant aux entreprises de gérer la relation avec leurs clients via tous les canaux de communication (voix / email / réseaux sociaux / live chat). Les infrastructures sont en propre dans plusieurs datacenters franciliens. L'annonce sur le site parle assez logiquement de plusieurs compétences parfois pointues (SIP-I, BGP, ... et il en manque d'autres orientées systèmes : Salt, Foreman, ...). Contrairement à certains qui cherchent "l'admin à 5 pattes", l'objectif pour Diabolocom est bien de faire progresser une équipe dont la somme de ses talents maitrise l'ensemble de ces points. Dit autrement, il n'est pas attendu qu'une personne seule maitrise toutes ces compétences. Et c'est aussi pour ça qu'on recherche plusieurs personnes. Il y a de l'IP, du telco (SS7, SIP-I), du système, du stockage (NetApp tout juste sorti des cartons), du Cisco et du Juniper (aussi fraichement sorti des cartons) et pleins de choses à faire avec. Si vous avez envie de participer à la façon dont on va s'amuser avec tout ceci, vous pouvez m'envoyer un mél afin qu'on en discute ensemble. Voici le lien vers l'annonce plus formelle : http://www.diabolocom.com/offre/administrateur-systeme-2/ Bonne fin de journée, -- Baptiste MALGUY --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [BIZ] Recherche presta clim pour petite salle info
Bonjour, Je recherche un prestataire de clim. Pas pour un DC, mais pour une petite salle info (au sein des bureaux sur Levallois). On parle d'environ 15kW à refroidir, pas le bout du monde. Notre installation fonctionne normalement, mais on ne souhaite pas continuer avec le prestataire actuel. Et bonnes vacances ! :) -- Baptiste MALGUY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau
J'avoue que ces micro-switchs semblent bien foutus en terme d'intégration, en effet un retour deux ceux qui ont expérimentés serait appréciable. Les deux points que je relève juste à la vue des photos : - comment les rebooter avec l'alim planquée dans la goulotte ? - pas de branchement à la terre ? Etant en inter en DC, j'ai pas RTFM si la réponse est dedans :) Le 20 août 2014 00:07, Hugues Brunel hugues.bru...@fullsave.com a écrit : Merci Philippe pour le topo! Ce design me rappelle une présentation que j'ai eu (c'était en juin 2008!!) des solutions microsens et leurs micro-switches: http://www.microsens.com/products/category/micro-switches/ Les switchs sont directement intégrés dans les goulottes et le reste du cablage est en fibre. Cerise sur le gateau dans les goulottes, il y a souvent le courant qui n'est pas loin pour alimenter le micro-switch (poe ou non)... Je n'ai jamais testé (quelqu'un a un retour d'xp là dessus?), mais j'avais trouvé l'idée intéressante... Avec la baisse du prix du cablage fibre (et l'augmentation du cuivre), il y a fort à parier que ce genre de solution se développe. Seul problème: on n'a pas encore de C2960 au format goulotte legrand :-D ++ Hugues. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Baptiste MALGUY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : [FRnOG] [TECH] Cisco2960 ip source binding avec plusieurs IP sur une MAC
Bonjour, Le 16 juillet 2014 09:00, Clément Michel michel.clemen...@gmail.com a écrit : Et puis, à moins que je me trompe, en IPv4 une MAC ne peut se référer qu'à une seule IP (sans compter la boucle locale en 127.0.0.1). Depuis quand ? L'inverse ooui (1 @IP - 1 @MAC à un instant T), mais on peut parfaitement avoir plusieurs @IP pour une même @MAC, c'est même un usage fréquent. Sous Linux : les sous-interfaces ethX:X (je n'ai _pas_ écrit ethX.X qui est pour les VLAN / tags 802.1q) Sous *BSD : les @IP alias sur une même interface Ceci n'a rien d'incompatible avec l'usage de couples Virtual IP / Virtual MAC au travers d'HSRP, VRRP, CARP and co. Et même là, on peut avoir plusieurs VIP pour une même VMAC. Mes 0,01 cents du mercredi. -- Baptiste MALGUY --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Interco BGP sur subnet RFC1918 : on en est arrivé là ?
En 2005, pour de l'accès simple par fibre, lors d'un déménagement, un opérateur dont le nom commence par C m'avait imposé un /30 d'interco similaire sur le nouveau site. Il y a combien de lettres dans le nom de ton opérateur ? :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] OVH - incident de sécurité
Hello, Je suis aussi enclin à saluer l'effort de communication d'OVH face à cet incident, face au lot de critiques qu'on a pu voir. Suffisamment rare pour le mettre en valeur et inciter les autres à suivre cette attitude. Le 24/07/13 10:34, Pierre-Yves Maunier a écrit : Avant j'utilisais un keypass stocké dans un conteneur truecrypt sur dropbox pour le côté dispo mais c'est quand même contraignant, pas d'accès mobile etc. Pareil, sauf que ... jamais stocké ailleurs que sur des postes dits sécurisés (selon les règles définies au sein de l'entreprise). Autant pour du pro, que du perso. Penser à augmenter le nombre de rounds pour le chiffrement du fichier. Ca tend à fortement réduire les risques liés aux attaques par force brute. Pour l'accès mobile, je n'ai pas suffisamment confiance (mot-clé) dans les smartphones/tablettes, y compris ceux avec chiffrement intégral du stockage, donc je ne fais pas. Je ne suis pas prêt d'utiliser un Lastpass ou autre, bien que je comprenne le raisonnement de Pierre-Yves. Et les solutions existantes ne sont pas toutes pour l'ensemble _des_ publics visés. -- Baptiste MALGUY signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Re: Re: [MISC] Un cas d'utilisation d'un préfixe AfriNIC en dehors de l'Afrique
Qand les technologies actuelles remettent au goût du jour l'archéologie (numérique). Le 20/02/13 16:17, Stephane Bortzmeyer a écrit : outils whois partant de la racine IANA sont donc redirigés à Afrinic... qui s'arrête là. En demandant à ARIN, ça marche. Bref, quand on cherche des infos sur un préfixe, il faut connaître son histoire. Connaître le RIR actuel ne suffit pas. -- Baptiste MALGUY signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Carrier Grade NAT, nous y voilà
Je n'ai pas vu le mot NAT dans le message d'Alain, en dehors du sujet... Le 22/01/13 10:39, Frédéric GANDER a écrit : euh car le nat c'est de la securite ? et bientot on va me dire qu'un firewall regle les pb de securite ? nb : un des premier but d'ipv6 c'était de garantir une connectivite end to end sans passer par des machines qui triturent les paquets et la tout le monde veux remettre du statefull firewall ? bon ba on va faire du nat alors ;) -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] se passer des box FAI : technique, juridique (Was : Mieux que l'HADOPI, Free !)
Hello, Le 06/01/2013 13:02, Ben Carrier a écrit : 1) y-a-t-il une obligation d'utiliser cet équipement ? Non n'importe qui peut passer la TrucBox en mode bridge. La Freebox v3 et v5 oui (pas eu les autres) La Livebox v2 apparemment non, ou bien je veux bien le manuel. Du coup, vive la double NAT ... 3) tous les services sont ils disponibles dans le cas d'utilisation d'un autre équipement ? Non, pas de TV. La VoIP reste disponible il me semble (peut être pas tout les FAI) Chez Free, la VoIP en SIP fonctionne à priori ? Chez Orange, j'essaierai le jour où je retirerai la Livebox pour coller directement mon routeur derrière le boitier ONT. Au nez, je pressens que : - la TV fonctionnera (je m'avance ...) - la téléphonie uniquement avec l'appli Livephone sur Smartphone, vu que les specs SIP sont gardées secrètes (je n'ai peut-être pas assez cherché) -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] [MICHU] Trolldi / phénomène étrange Orange end-user
Si j'ai bien suivi, le troll de ce vendredi, c'est pas si Orange fait du NAT44(4), mais si FrNOG devient la chatroom de Smartjog / Yacast ? -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] [MICHU][BRUIT] Trolldi / phénomène étrange Orange end-user
Alors là, grande forme, grande classe, j'avoue, clap clap clap. 1. Défoncer un de ses gars en public 2. Balancer du flan sur les peerings montés Aller, je tends une perche, c'est quoi la troisième ? PS : pour ceux qui cherche l'info utile du jour, allez directement au mél de Sarah. Le 16/11/12 15:44, Ludovic LACOSTE a écrit : Yacast est mort essai plutot TDF, d'ailleurs, c'est une honte de conerver les peerings Yacast alors que l'AS a été revendu, faites comme vous voulez mais c'est pas du tout dans la norme ... -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Coupure électrique sur le premier étage de TH2 ?
On va pas se contenter de leur demander une idée précise cette fois ... Le 10/08/12 10:54, Julien Follenfant a écrit : Bonjour, Rien à signaler, le mieux étant de téléphoner au PCS pour avoir une idée précise :) Cordialement, -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cohabition HSRP + VRRP
Hello, Par contre, avec uCARP, point de vMAC. C'est la MAC native de l'interface qui est utilisée, donc changement dans les tables ARP IP/MAC des équipements L3 concernés. J'ai fait mettre en place du uCARP, et finalement, je le regrette. C'est super bien fait dans un contexte BSD (du vrai CARP), j'adhère totalement (surtout avec son intégration dans OpenOSPFD et compères), mais c'est pas terrible sur Linux : 1. Comme dit plus haut, pas de vMAC 2. La décorrélation noyau/userland : un daemon ucarp qui fait les annonces, indépendamment de la bonne ou mauvaise configuration avec ip addr. On ne peut pas facilement faire de ifconfig carp -carpdemote and co. Il faut d'une part tuer le démon ucarp (que je sache) et déconfigurer l'interface avec ip addr d'autre part. Dans la pratique, c'est truc à se ficher dedans, à avoir des états pas homogènes lors de bascules. Et FreeVRRP j'ai pas adhéré non plus (et plus maintenu depuis longtemps je crois). Mes 2 cents ... Le 21/06/12 16:59, Surya ARBY a écrit : La Mac virtuelle est là pour ça. S'il y a des Garp éventuels c'est pour forcer la convergence L2 des switchs adjacents et en aucun cas pour mettre à jour de force une association IP/Mac puisque celle-ci ne change pas. Que les équipements L3 adjacents interprêtent les Garp ou pas ne change rien sur le bon fonctionnement de la haute dispo fournie par le protocole. Le 21/06/2012 17:53, Olivier Benghozi a écrit : Bonjour, L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et La RFC dit exactement le contraire. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Cohabition HSRP + VRRP
Velu le troll ! Il a hiberné jusqu'en juin ? Parce que là, même pas envie de relever ... Le 21/06/12 23:10, Damien Fleuriot a écrit : Sans troller, sérieux. CARP sous freebsd, c'est géré direct niveau kernel, ça a rien à voir avec un vieux ucarp moisi. Mais bon voilà après faut savoir ce qu'on veut. Un pseudo UNIX réécrit de merde, ou un vrai OS réputé pour sa stabilité et pas forcément sa facilité d'administration. -- Baptiste MALGUY NEW PGP fingerprint: 70A9 37BB 59F3 481D 190B 3B71 96D8 6328 0B2F 0EA1 OLD PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] MegaUpload
Le 11/03/2012 05:38, Michel Py a écrit : Rémi Bouhl a écrit: Je ne suis pas d'accord avec toi. Je fais plus confiance aux opérateurs qu'aux législateurs incompétents qui pondent les lois et aux gendarmes qui pètent plus haut que leur cul parce que les législateurs leur ont donné un uniforme, un képi et un flingue. Dans un tout autre domaine que les télécoms ou l'informatique, j'ai passé ma journée avec un groupe dont un gendarme en service. Je n'ai pas remarqué qu'il se la jouait, alors que ça aurait pu être l'occasion de faire le coboye (gyro, sirène, flingue, etc). Généraliser, un des maux dont on doit se méfier ... -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
[FRnOG] Re: [JOBS] Offre ingénieur réseau à consonance système
un collègue : tu trouvais que c'était trop calme sur FrNOG moi : bof, poster une annonce, en général, personne répond directement sur la liste, c'est tranquille le collègue : quelle naïveté moi : j'ai pris rendez-vous pour une thérapie curative la semaine prochaine -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [JOBS] Offre ingénieur réseau à consonance système
Le 09/01/12 16:43, Guillaume Tournat a écrit : En fait, vu la listes des compétences et technos, vous cherchez trois personnes... La personne n'a pas vocation à être pleinement investie des trois profils. Le réseau est la priorité. Que je sache, on trouve rarement quelqu'un qui remplisse 100% des technos énumérées, mais ça fournit un cadre global aux intéressés, L'exhaustivité dans l'annonce permet de fournir un cadre global aux intéressés. Le seul glitch, c'est le stockage, j'aurais quand même du retirer cette ligne ;-) -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [MISC] Re: Diffusion du virus gendarmerie par javascripts modifiés
Hello, Youhou, deux semaines sans lire FrNOG, ça fait du bien. Du coup, je débarque 3 plombes après, oui, afin de soutenir à mon tour cette démarche qu'à Eric Freyssinet. Concernant le fait de ne pas utiliser son adresse professionnelle, certains postent sur FrNOG avec leur adresse pro, ils sont habilités à le faire (enfin j'espère :). D'autres non, leurs propos n'ayant pas à représenter l'expression d'une communication de leur employeur. Ca me parait encore plus délicat pour un dépositaire de l'autorité. Dans cette discussion et ce contexte de mailing-list, on parle de cybercriminalité. Mais on peut parfois observer une démarche similaire dans des contextes très différents. Pour ma part, je soutiens vivement les motards de la Gendarmerie Nationale et de la Police Nationale qui prennent de leur temps, souvent personnel, pour contribuer à des formations sur route, afin de mieux armer les permis A sur nos routes, en bonne intelligence. D'autres pourraient citer d'autres contextes j'imagine. J'apprécie cette démarche de partage de l'information, d'échange, où l'optique n'est pas la répression. Donc : merci. Le 22/12/11 21:00, Raphael MAUNIER a écrit : J'ai du mal à comprendre les réactions ? -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Quagga exemple de conf BGP ?
Le 21/08/11 20:34, Michel Py a écrit : Antoine Durant a écrit: HSRP est-il envisageable sûr deux machines Quagga ? Ca m'étonnerait, vu que HSRP est propriétaire à Cisco. VRRP peut être. Linux = Heartbeat BSD = CARP Par contre, euh ... la redondance ne serait-elle pas plutôt à mettre en oeuvre en ayant deux sessions BGP (une par serveur Quagga) plutôt qu'en utilisant une VIP ? Bonne soirée, -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Quagga exemple de conf BGP ?
Le 21/08/11 21:15, Raphael Mazelier a écrit : Le 21/08/2011 20:41, Baptiste Malguy a écrit : Linux = Heartbeat BSD = CARP Tu généralises un peu. Carp est utilisable sous linux avec ucarp même si je déconseille, de même que vrrp avec keepalived, ce que je conseille nettement plus, c'est même ma solution préféré pour faire une vip sous linux. Dans les deux cas, ce n'est qu'un bout des specs qui sont implémentées: que ça soit ucarp ou keepalived, il n'y a pas de Virtual MAC, uniquement une Virtual IP. Du coup, ce n'est pas la table L2 des switchs qui change, mais bien les tables ARP de tous les hôtes de subnet. Pour ce que j'y ai prêté attention. Une autre implémentation, plus maintenue il me semble, remplace la MAC de l'interface lorsqu'elle est master, mais du coup l'adresse IP native de l'interface utilise aussi la Virtual MAC, beurk. En général les VIP sur des routeurs c'est pour redondé les defaults gw des subnets hors core, le reste du routage devant effectivement être redondé via les protocoles qui vont bien. Oui non mais bien sûr ... j'avais lu côté BGP ... on va dire que j'ai rien dit ... -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] Blacklistage mail AOL - FREE
Bonsoir, Le 01/06/11 22:08, Vincent Duvernet (Nolmë Informatique) a écrit : Bonsoir, j'ai une amie qui a régulièrement ce message d'erreur et qui ne peut donc rien envoyer vers Free. [...] Après FrNOG, ou le support underground de Free division ADSL, voici FrNOG, le support underground de Free division hébergement pour particuliers Si j'ai un serveur dédié OVH qui n'arrive pas à envoyer du mél sur Free, je peux aussi demander aux admins sys de ces deux sociétés de voir ça entre-eux directement ici, hein, je peux ? Et on s'étonne qu'ils soient frileux à répondre ... PS : et sinon, il y a FrSAG qui est plus adapté pour la partie système, à moins que BGP ne se soit invité dans le protocole SMTP re-PS : c'était le troll de vendredi en avance à cause du pont, c'est ça ? j'ai bon, hein ? hein ? -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
Re: [FRnOG] RFC 6092: Recommended Simple Security Capabilities in CPE for Providing Residential IPv6 Internet Service
2011/1/25 Rémi Bouhl remibo...@gmail.com Là tout de suite, je ne vois pas en quoi un ordinateur est menacé s'il est joignable sur les ports 1024. Un premier me vient immédiatement à l'esprist pour être en train de faire mumuse avec des DLNAs en ce moment : 1900 (UPnP) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Hello, Le 3 janvier 2011 21:32, Raphael Mazelier r...@futomaki.net a écrit : Quel est le besoin ? tu as tellement de vlan clients à gérer ? tu ne peux pas segmenter un peu avec diffèrent vswitch / différentes classes de vlan ? D'ailleurs le rajout d'interface à chaud ca fonctionne (au moins sous linux), et cela me semble gérable jusqu'à 4 interfaces par serveurs. Après si tu as plus de quatre vlans par serveurs je penses que tu as un problème d'architecture. (enfin déjà je comprends mal plus de deux). Je virtualise des pare-feux et des load-balancers, et le client, c'est moi :). C'est un choix architectural qui peut plaire ou pas. Je comprends pas le besoin d'être en promiscuous pour faire du HA. Ni le besoin d'une @Mac virtuelle. Ucarp par exemple fonctionne simplement en multicast et en floodant d'arp quand ca change. D'ailleurs je vois pas en quoi c'est sale. D'expérience les @macs virtuelles (sur les Netscreen ou autres) ca m'a plus foutu la zone qu'autre chose. Il y a doit y avoir un point que je ne saisis pas la. Déjà répondu par Thomas. C'est ucarp qui comble l'incapacité à pouvoir vraiment utilisé une @mac virtuelle sous Linux (à moins que ça n'ait changé depuis la dernière fois que j'ai regardé). Le concept d'un couple VIP + VMAC me semble plus propre qu'un flood ARP. C'est au niveau des tables des équipements L2 que le changement se voit et non dans les tables ARP de tous les équipements/serveurs L3 présents sur les mêmes segments. Ca me semble moins sale, mais on peut avoir des visions différentes. Teste la version d'essai 60 jours je suis intéressé par le retour :) C'est au programme ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Hello, Le 3 janvier 2011 23:47, Vincent Duvernet (Nolmë Informatique) vincent.duver...@nolme.com a écrit : (C'est super lourd, cela fait la 3ème fois que je ne fais pas gaffe mais le Répondre sur la liste ne fait pas de Reply sur la liste mais à l'expéditeur :/) Concernant ton problème, peux-tu donner quelques compléments d'infos : - Combien de ports physiques a ton serveur ESX ? (Est ce une pizza avec 2x1000 ou bien 2 cartes PCI 4x1000 ?) - Combien de VM tournent sur chaque serveur ? [...] (En tout cas, ça a comme un air d'usine à gaz ton installation j'adore :)) J'ai déjà traité ces problématiques (comment répartir les liens physiques de l'ESX à travers les vSwitchs, nombre de VMS par ESX, etc), et qui sont, dans la limite de ce que permettent les vSwitch, pas trop mal documentés. J'ai déjà échangé avec le support VMWare, qui à part me citer le Nexus sans savoir me dire à ce moment-là ce que c'est, ne m'a pas été très utile. D'ailleurs, il ne m'avait pas parlé du Dvswitch. Sinon, non, ce n'est pas une usine à gaz, au contraire on esssaye de faire des choses qui restent simple. Pas de SAN, de VMotion, etc. On virtualise pour éviter de gacher des ressources CPU, RAM, I/O, électricité, U dans les baies ... dont l'exploitation par machine est faible la plupart du temps. Mais la virtualisation ne permet pas toujours de faire tout ce qu'on fait en dur. Et je dois reconnaitre qu'un vServer pour administrer le tout, c'est assez appréciable, même si c'est la seule vraie raison pour laquelle j'ai un poste sous Windows au bureau :D (la console d'un serveur dans vSphere Client dans une VM Windows dans un Linux ou un Mac, des fois, ça se combien pas très bien ...) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
[FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Bonjour, Bon aller, j'amorce (je crois) la première discussion technique de l'année. La version courte pour les pressés : j'aime bien la virtualisation avec VMWare mais je rencontre quelques limitations côté réseau. le Nexus V1000 semble être une partie de la solution et je suis à la recherche de retours d'expérience. La version un peu plus longue à présent. J'ai deux problèmes à ce jour. 1. J'ai des vSwitch avec le numéro de vlan 4095 (tous les VLANs, taggués, arrivent jusqu'aux guests connecté à ces vSwitchs). En revanche, je ne peux pas restreinte les vlans vus par les guests connectés à ces vSwitch, il n'y a pas d'équivalent à un switchport trunk allowed vlan . Avoir une interface par vlan sur mes guests n'est pas une option envisageable (besoin de rebooter pour ajouter une interface, nombre limité, c'est chiant, etc). Du côté du switch physique auquel est connecté l'ESX, j'ai bien évidemment déjà mis un switchport trunk allowed vlan ..., mais j'ai besoin d'être granulaire par guest. 2. J'ai deux serveurs ESX esx1 et esx2. Sur un esx1 j'ai un guest vm1, sur esx2 un guest vm2. Ils partagent des VIPs, que ça soit par HSRP, VRRP, CARP, ... Ce qui implique une adresse MAC virtuelle (ok, ok, sous Linux, les implémentations VRRP font autrement, plus sale d'ailleurs, selon moi). Ceci m'oblige à autoriser le mode promiscuous pour les interfaces concernés sur ces guests. Ceci a un effet de bord pas du tout désiré : les interfaces de ces guests reçoivent tout le traffic des vSwitchs concernés. Deux fonctionnalités en une, moi ça m'arrange vraiment pas. Par conséquent, j'ai : - un double problème de sécurité ne pouvant pas restreinte les vlans par guest et les serveurs en promiscuous recevant plein de trafic qu'ils ne devraient pas ; - un problème de charge des guests qui reçoivent du trafic qui leur ait inutile qui remonte jusqu'au noyau de l'OS qui doit dropper les paquets dont il n'a que faire. Nexus V1000 semble apporter une réponse à mon premier problème. Je ne sais pas s'il en apporte aussi une à mon second problème. Je suis donc très intéressé par un retour sur le Nexus V1000, et si certains ont trouvé comment résoudre ces problèmes (j'imagine ne pas être le premier à les avoir). PS : je ne suis pas certain d'avoir été très clair, reformulation possible sur demande ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] VMWare, vSwitch, Nexus V1000, VLANs et mode promiscuous
Ce n'est pas ma question et je n'ai pas l'intention de jouer avec des blades. Je découvre votre solution et de ce que j'en ai compris, ça n'a rien à voir avec VMWare = à priori sans rapport avec ma question. Youhou, les commerciaux sont chauds bouillants en ce début d'année ! PS : merci pour ton retour Alexis. Le 3 janvier 2011 13:49, Igor Marty igor.ma...@bladenetwork.net a écrit : Notre solution VMReady sur nos switchs BLADE Network technologies (now IBM) est concurrentielle au Nexus 100V. Elle devrait répondre à vos attentes. Nous pouvons en discuter en off et vous proposer de tester ce qui vous permettrait en toute clarté de valider ou non la solution en fonction de vos besoins. -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
[FRnOG] Question sur l'option continue dans les route-map Cisco sur de l'outbound
Bonjour, J'ai une question bassement technique pour laquelle je me sens très con ce matin : est-ce qu'une instruction continue dans une route-map utilisée en outbound fonctionne _vraiment_ sur du Cisco ? Contexte du test: 7200 NPE-G1 avec un 12.4(21). A appliquer aussi sur des sup720 3BXL (mais pas encore testé). Ca marche très bien sur une route-map en inbound, mais sur de l'outbound, comme si l'instruction continue était absente. J'ai lu différentes remarques sur le net comme quoi ça marche/ça marche pas selon les versions d'IOS. D'après ce lien, ça devrait être bon : http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/t_bgprco.html, mais non. Bref, dans la vraie vie, ça donne quoi ? PS : tout troll concernant un meilleur support des route-map chez d'autres constructeurs restera sagement à la porte, et se consolera avec ses confrères dehors ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] Question sur l'option continue dans les route-map Cisco sur de l'outbound
Vrai. Mais pas même un refus genre feature not supported comme on peut en rencontrer dans d'autres situations ... beep ... mauvaise question ? Sans compter le fait que ... mmh mmh ... j'avais négligé le T de 12.4T ; je ne m'y fais pas à la numérotation des version d'IOS. Le 15 décembre 2010 23:28, Olivier Benghozi olivier.benghozi+fr...@gmail.com olivier.benghozi%2bfr...@gmail.com a écrit : T'as répondu toi-même à ta question: la doc parle de 12.4T, et tu indiques que tu tournes une 12.4. Le 15 déc. 2010 à 13:05, Baptiste Malguy a écrit : Bonjour, J'ai une question bassement technique pour laquelle je me sens très con ce matin : est-ce qu'une instruction continue dans une route-map utilisée en outbound fonctionne _vraiment_ sur du Cisco ? Contexte du test: 7200 NPE-G1 avec un 12.4(21). A appliquer aussi sur des sup720 3BXL (mais pas encore testé). Ca marche très bien sur une route-map en inbound, mais sur de l'outbound, comme si l'instruction continue était absente. J'ai lu différentes remarques sur le net comme quoi ça marche/ça marche pas selon les versions d'IOS. D'après ce lien, ça devrait être bon : http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/t_bgprco.html, mais non. Bref, dans la vraie vie, ça donne quoi ? PS : tout troll concernant un meilleur support des route-map chez d'autres constructeurs restera sagement à la porte, et se consolera avec ses confrères dehors ;-) -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] nocproject.org
C'est à cause des grèves qu'on a pris de l'avance sur le vendredi ? Le 23 septembre 2010 09:32, Baptiste Malguy bapti...@malguy.net a écrit : C'est à cause des grèves qu'on a pris de l'avance sur le vendredi ? Le 23 septembre 2010 09:28, Julien Gormotte jul...@gormotte.info a écrit : On Wed, 22 Sep 2010 19:25:08 +0200, Clement Game cg...@xooloo.net wrote: [...] on croirait qu'ils gardent la citadelle de helm, les renforts rouhirims en moins :) C'est le Gouffre de Helm. Et la citadelle, c'est Fort-le-Cor. Et c'est les Rohirrims, aussi. My 3 pennies. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 -- Baptiste MALGUY - www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: Incident majeur, WTF happened ?
Le 1 septembre 2010 12:40, Thomas Mangin thomas.man...@exa-networks.co.uka écrit : Ceci dit, encore un message opérationnel de plus, je ne sais pas s'il arrivera jusqu'aux cerveaux impliqués... Probablement pas, mais ce n'est pas une raison pour ne pas le faire ! Si personne ne s'était opposé au test (le cas le plus probable a voir la réactivité des NOC), RIPE aurait eu les mains blanches. Ce n'est pas le cas aujourd'hui. Question de point de vue. A titre purement personnel, je suis favorable à ce qu'a fait le RIPE. Si on doit craindre à chaque fois (ce qui reste rare) qu'on envoie du BGP RFCisé mais pour un truc non-documenté, alors clairement, le problème ne vient pas du RIPE. Transposons deux minutes cet incident au protocole SMTP (rh). Admettons avoir une option particulière expérimentale pour la commande RCPT TO . Une société l'expérimente sur ses serveurs, et ne s'embête pas forcément à la brider au périmètre de ses serveurs. Lorsq'un de ses serveurs SMTP envoie un mél à une adresse dont le serveur MX n'est pas du ressort de cette société, attendez-vous que : 1. Le serveur SMTP extérieur plante ? 2. Le serveur SMTP extérieur accepte le mél, en ignorant l'option expérimentale ? 3. Le serveur SMTP extérieur refuse le mél avec un 4x0/5x0 (modulo la politique de l'admin) ? Pour ma part, je penche pour le choix 3, le 2 faut voir ce qui se passe. Il serait gravissime que ça soit la réponse 1. Et en aucun cas la société qui expérimente n'a à être considérée comme responsable. Et non, je ne crois pas que cet amalgame BGP - SMTP soit mal placé. Il s'agit de toujours vérifier les entrées. La seule chose qu'on peut opposer comme argument est qu'on choisit avec qui on établit un lien de peering en BGP, pas qui se connecte à un serveur MX. Et j'accepte difficilement cet argument. BGP est un sujet sensible. Ok. Fragile : problème. Et ce n'est pas la faute du RIPE. Qu'on ne profite pas de cet incident pour se venger de mécontements déjà existant qu'on puisse avoir envers le RIPE ou le RIPE NCC. -- Baptiste MALGUY PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2
Re: [FRnOG] Re: Incident majeur, WTF happened ?
Le 1 septembre 2010 16:22, Thomas Mangin thomas.man...@exa-networks.co.uka écrit : Pour etre clair - je ne demande pas un réponse - je cherche seulement a montrer que les transposition c'est dangereux - et cela montre surtout ce qu'on veut ! Je souhaitais rappeler le principe que nous connaissons tous, par une mise en évidence plus facile : on fait 0 confiance à ce qui vient de l'extérieur. Dans notre cas c'est 4. le serveur mail mange les mails en retournant 250 une fois que l'ont a reçu un email encodé en utf-32 (les packets UDP sont perdus a tout jamais) Aussi oui :) BGP n'est pas un sujet sensible - c'est la boulot de beaucoup de gens a plein temps ! Visiblement si, vu qu'on en parle autant depuis vendredi. BGP ce n'est pas fragile - l'internet ca marche plutôt bien. Sur un véhicule deux-roues (vélo, scoot, moto, etc) aussi ça marche plutôt bien pour se déplacer (à fortiori dans les grandes villes), et ces usagers n'en sont pas moins TRES fragiles (oops, I did it again ... une transposition). Ce type de faille montre la fragilité des implémentations (et pas forcément du protocole, d'ailleurs). Et encore plus une chose : la presque-mono-culture Cisco. Cet incident est une très bonne piqûre de rappel de ces faits, outre la correction de la faille sur les implémentations concernées. Pas de bol CISCO a une couverture de bug minable pour son implémentation BGP dans XR ! Bon voilà, on y revient, finalement. Qu'on ne profite pas de cet incident pour se venger de mécontements déjà existant qu'on puisse avoir envers le RIPE ou le RIPE NCC. Pardon !? Quel mécontentements ? C'est une accusation facile, ça ! Pas toi personnellement. De façon générale, on tape régulièrement sur le RIPE (justifié ou pas, peu importe), et cet incident pourrait être une goutte d'eau de trop pour que certains qui en profitent. -- Baptiste
Re: [FRnOG] Grosse coupure ADSL Free
Je pensais attendre vendredi pour lancer un troll sur le sujet, mais puisque Clément me devance ... on pourrait effectivement retourner à des discussions plus intéressantes ? Ca devient bien plus que pénible. Je suis convaincu (en rêvant ne pas à tord) qu'une majorité silencieuse en raz la patate et aimerait voir des discussions plus enrichissantes. On s'en fout que Free ait (provisoirement) null-routé une IP, on s'en fout qu'un bout de réseau ADSL déraille (pas forcément chez Free :), on s'en fout que NC soit (selon certains hein, faudrait pas qu'on croit que ce sont mes propos), de la daube en barquette pour fournir de l'IP à domicile. Bref, pour faire hype, +1 avec Clément. PS: Frédéric, désolé que ça tombe sur toi, t'as tendu une belle perche. Clement Cavadore a écrit : Hello, Le mardi 24 novembre 2009 à 21:00 +0100, Frédéric a écrit : ce n'est pas pour la hotline, mais c'est interessant de connaitre les grosse coupure sur le territoire. (...) Non, justement, on s'en moque. C'est malheureusement ce genre de messages, comme ceux de problème de routage chez Untel impactant une pauvre IP en particulier, qui sont polluant de la liste, et font qu'il n'y a quasiment plus aucune intervention intéressante (d'un point de vue technique) ici. Les troll du vendredi ou autres, ca va bien 5 minutes... My 2 cts... -- Baptiste MALGUY - http://www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [HS] opensmtpd debuging session or using frnog as an entropy generator
Sebastien Gioria a écrit : Par contre on ne sait pas qui a emporte le Trol Quid de celui de ce vendredi ? Puisqu'on est parti sur la lancée *BSD: quelle mouture préférez-vous et pourquoi ? FreeBSD ? NetBSD ? OpenBSD, DragonFlyBSD ? Autre ? J'ai ptêt visé trop gros ... pas gagné qu'il passe :) --Message d'origine-- De: Xavier Magnaudeix Expéditeur: owner-fr...@frnog.org À: 'Mathieu Goessens' À: 'frnog FRnoG' À: 'Gilles Chehade' Répondre à: Xavier Magnaudeix Objet: RE: [FRnOG] [HS] opensmtpd debuging session or using frnog as an entropy generator Envoyé: 11 sep, 2009 09:12 Reply de AT phibee.net On a bien remarqué la faible nombre de messages de la liste depuis jeudi 03/09 14h43 ... Mais on se disait que tous les membres de la liste avaient pris leurs congés en septembre pour profiter du calme de juillet/aout. -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Mathieu Goessens Envoyé : vendredi 11 septembre 2009 08:53 À : frnog FRnoG; Gilles Chehade Objet : [FRnOG] [HS] opensmtpd debuging session or using frnog as an entropy generator Bonjour, Mes excuses par avance pour le hors sujet. Je reçois cette liste sur un serveur tournant sur opensmtpd, le daemon mail d'openbsd encore en test/developpement. On (le dev du projet et moi) avons reperé un bug étrange qui n'apparait que sur les messages reçus par cette liste :( . En particuliers ceux provenants de : * AT phibee.net, guillaume AT ironie.org, nicollet AT jeru.org, cedric AT polomack.com, zero AT toile-libre.org, sxpert AT sxpert.org, jp AT nexedi.com, d.rousseau AT nnx.com, bbillon AT splio.fr, frnog AT republique.org, carxwol AT hexecho.net Donc, pour aider le dev a debugguer, une réponse à ce mail serait plus que bienvenue, en particlier de la part de ces comptes/domaines, mais pas seulement (il doit y avoir pas mal de monde dans la majorité silencieuse dont le reply serait intéréssant) Les derniers vendredi ont été plutôt calmes, donc, pour ceux que cela generait de flooder la liste avec une réponse vide on peut en profiter pour parler d'openbsd, de pf, de son implem bgp, de retours d'utilisations sur ceux ci, de ses perfs smp, de son (not so)ffs, ou de son daemon mail pas encore frnog-proof etc ;) Merci d'avance pour vos réponses, Cdlt, Mathieu Goessens -- Baptiste MALGUY - http://www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Peering régionaux, ou en es t on ? (surtout pour Free)
Salut, Sauf erreur de ma part, il ne perd aucun paquet sur ton traceroute, mais tu ne montres que les six premiers hops. Ce qui compte, ce sont les stats avec la destination finale (absente de ton copier-coller). Il semble plutôt que le 4ème hop soit configuré pour dropper une partie des paquets ICMPs qui lui sont destiné, chose assez courante au travers des traceroutes que j'ai pu faire au moins ces derniers mois, par-ci par-là. Ce n'est pas la priorité des routeurs que de répondre à 100% aux traceroutes ;-) J'espère ne pas avoir dit une grosse co...ie. Denis Pugnere a écrit : Et quand il y a un GIX local (ici lyonix), il perd 1 paquet / 3 sur un échange Renater - Neuf... Packets Pings Host Loss% Last Avg Best Wrst StDev ... 2. Lyon-INTER.in2p3.fr 0.0% 0.4 1.0 0.3 33.6 4.1 3. vl3113-lyon1-rtr-021.noc.renater.fr 0.0% 0.3 0.6 0.3 7.8 1.3 4. neufcegetel-l2.peers.lyonix.net 32.8% 0.5 7.9 0.5 157.3 27.9 5. 230.92.65-86.rev.gaoland.net 0.0% 1.1 1.8 0.9 51.5 6.3 6. 84.96.128.2460.0% 1.6 1.7 1.5 4.8 0.4 ... is -- Baptiste MALGUY - http://www.malguy.net PGP fingerprint: 49B0 4F6E 4AA8 B149 B2DF 9267 0F65 6C1C C473 6EC2 signature.asc Description: OpenPGP digital signature
