Re: [FRnOG] [MISC] #Brexit et conséquences
Les infrastructures historiques ne bougeront pas. LINX n'a pas l'air plus inquiet que ça, quoi que ce n'est peut-être qu'une posture. On en saura plus au prochain Euro-IX[3] en novembre. Cela va prendre quelques mois/années pour comprendre les conséquences, qui vont dépendre de la stratégie de sortie (et de l’attitude des pays européens). Le pound va surement baisser, ce qui rendra surement les services de LINX moins cher en Euro - donc tout n’est pas noir … Pour le reste, je passe. C’est une liste technique, pas politique. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Slides ExaBGP FRnOG 26
ouvres … et comme tu as été trop lent, ta pénitence est de maintenant verifier que le patch est correct :-) https://github.com/Exa-Networks/exabgp/commit/c501051af27e04b9cdb4d2d6b18e31d9d267c4cc Thomas http://exa.net.uk/about/contact-us On 20 Apr 2016, at 9:09, Thomas Mangin wrote: > Michel, > >> J'ai une question de débutant (on appelle çà Google-over-FRnOG) : ExaBGP lit >> stdout; non j'ai pas lu la doc, il y aurait-il moyen que si ExaBGP voit >> quelque chose qui commence par "#" il ne fait que l'afficher ? Quand on >> n'est pas un dieu du .py, c'est pratique d'avoir la moulinette qui commente >> ce qu'elle fait. > > Bon comme c’est vraiment simple, si tu m’ouvre un ticket sur github, je te > l’écris durant les reunions d’IXManchester et d’UKNOF aujourd’hui et demain. > > Thomas signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [TECH] Slides ExaBGP FRnOG 26
Michel, > J'ai une question de débutant (on appelle çà Google-over-FRnOG) : ExaBGP lit > stdout; non j'ai pas lu la doc, il y aurait-il moyen que si ExaBGP voit > quelque chose qui commence par "#" il ne fait que l'afficher ? Quand on n'est > pas un dieu du .py, c'est pratique d'avoir la moulinette qui commente ce > qu'elle fait. Bon comme c’est vraiment simple, si tu m’ouvre un ticket sur github, je te l’écris durant les reunions d’IXManchester et d’UKNOF aujourd’hui et demain. Thomas signature.asc Description: OpenPGP digital signature
[FRnOG] [TECH] Slides ExaBGP FRnOG 26
Bonjour, Pour ceux qui aiment vraiment se torturer l’esprit. http://thomas.mangin.com/data/pdf/FRnOG%2026%20ExaBGP.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans les appareils au 30 juin 2015
On 30 Jul 2014, at 09:26, fr...@jack.fr.eu.org wrote: On 30/07/2014 00:01, Radu-Adrian Feurdean wrote: On Tue, Jul 29, 2014, at 23:42, fr...@jack.fr.eu.org wrote: La dette du gouvernement est un bienfait. Et l'IPv6 va etre massivement deploye dans les 12 prochains mois. Si tu voulais prendre un bout de papier, un stylo et un bout de cerveau .. : Très peu de personnes comprennent bien le système bancaire ( tout comme pour les réseaux ). Ce n'est pas comme cela que ca marche - mais nous sommes deja trop hors-sujet - la crise monétaire n'est pas dans la charte de FRnOG :-) Merci de ne pas m'insulter avec un dessin :-) Thomas http://en.wikipedia.org/wiki/European_Central_Bank https://www.ecb.europa.eu/mopo/strategy/pricestab/html/index.en.html signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Netflix in France
On 28 Jul 2014, at 15:40, Greg Villain fr...@tadcons.net wrote: On Jul 28, 2014, at 1:51 AM, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Je souris, Il y a 13-14 ans, les FAI ont enlevé tous leurs caches HTTP car la bande passante avait atteint un prix qui ne justifiait plus pour eux de gérer les serveurs. Depuis ils reviennent en force car la capacité du réseau ne suit plus la demande, mais gérés par les sociétés de services ( Akamai, .. ) ou fournisseurs de video ( Youtube, NetFlix, ...). Les FAI qui ont essaye d'offrir une solution de cache interne comme produit n'ont pas réussi ( autant que je sache ) car leurs gestions et les besoins des clients ne sont pas simples. C’est un peu plus complique que ca. Si tu regardes de près Akamai ou n’importe quel autre CDN, l’aspect mutualise de leur edge et la variété des types d’assets a cacher a l’edge multiplie par la taille des catalogues cumules de leurs clients fait que les niveaux d’offload qu’ils sont capables d’offrir ne dépassent pas les 25%. Dans le cas d’OpenConnect, c’est un CDN entièrement dédie aux besoins de Netflix, la valeur de l’offload est systématiquement 75% - vu la quantité de traffic qu’on genere, ca représente une veritable économie en plus du gain de satisfaction que ca représente pour leurs abonnes. Nous sommes d'accord. J'aime bien ce que fait NetFlix du cote development. Pouvoir controller l' application cliente aide aussi ainsi que connaitre les contenus populaire sont des avantages qu'un CDN généraliste n'a pas. La latence n'est aussi pas critique une fois que la video est lancée :-) Mais je ne cherche pas a' commencer ici une these sur les CDN et leurs differences, sinon il va falloir couvrir les technologies web, la gestion des droits d'auteurs, etc. et je suis en vacances :-D Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Netflix in France
Je ne suis pas sur que Netflix ai des employees cote technique en France. 2Gb est une limite assez base - avant tout reseau devrait être content avec du peering a France-IX. Thomas Sent from my iPad On 24 Jul 2014, at 04:12, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Le minimum de 2 Gbps, c'est réaliste pour un pays de la taille de la France (je vois çà de très loin) ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Netflix in France
ai - ait , base - basse. Thomas - se cache. Thomas On 24 Jul 2014, at 08:13, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Je ne suis pas sur que Netflix ai des employees cote technique en France. 2Gb est une limite assez base - avant tout reseau devrait être content avec du peering a France-IX. Thomas Sent from my iPad On 24 Jul 2014, at 04:12, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Le minimum de 2 Gbps, c'est réaliste pour un pays de la taille de la France (je vois çà de très loin) ? --- Liste de diffusion du FRnOG http://www.frnog.org/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Statut adresses IPv4 .0
Ma derriere utilisation de unnumbered remonte en debut du siècle :p Le seul petit problème avec l’unnumbered est que si l'interface qui a l'IP publique sur le LAN passe 'down' (par example le switch est éteint par le client durant le week-end ou soir), tu ne peux plus pinger ou collecter les stats SNMP. Tu ne sais donc pas si c'est un problème avec la ligne ou ou le LAN et le monitoring va chanter. Thomas On 22 Jul 2014, at 23:19, David Ponzone david.ponz...@gmail.com wrote: De l’unnumbered, on en faisait beaucoup chez ISDnet dans les années 1996-2001, et je n’ai pas le souvenir qu’on ait eu le moindre problème avec. Mais c’était sur du vrai PTP (PPP sur X21 ou DS3/E3 ou du STM1-4). Sur de l’ethernet, effectivement, c’est peut-être pas si évident. En ce qui concerne le /31, on peut penser que ça fonctionne correctement, si on en croit certains commentaires ici: http://packetlife.net/blog/2008/jun/18/using-31-bit-subnets-on-point-point-links/ Evidemment, rien de vérifiable. Et 2 articles sur les effets d’un /31 sur les protocoles de routage de Cisco à Cisco: http://mellowd.co.uk/ccie/?p=630 et de Cisco à Juniper: http://mellowd.co.uk/ccie/?p=937 Cela semble plutôt fonctionnel. Je ferai un test sur un lien peu sensible prochainement. Le 22 juil. 2014 à 18:46, Michel Py mic...@arneill-py.sacramento.ca.us a écrit : Eddy Minet a écrit : Je ne sais pas si ça a déjà été précisé ou non dans la conversation ou dans une conversation antérieure mais du coup est-ce qu'il y a les même problèmes ou plutôt est-ce que le débat est le même avec les .255 ? Oui. De même que les techniques qui essaient d'économiser les adresses sur les liens PTP (comme /31 ou IP unnumbered) ça marche dans 99% des cas et c'est un cauchemar quand ça ne marche pas. Sur un réseau de prod, c'est le genre de chose qu'on apprend à éviter, en général en se brûlant les doigts dessus. L'idée est bonne, mais il y a des cas ou il est nécessaire d'accepter un système non-optimal. Petit retour en arrière : quand IP a été inventé, c'était classfull donc la notion d'avoir un masque plus long que /24 n'existait même pas. Pierre Colombier a écrit : Je veux dire, généralement, quand on veux faire un broadcast c'est pour faire des choses liées au segment réseau. (ARP / DHCP ce genre de trucs) Ta logique est bonne, mais dans la réalité voir la réponse de Simon Morvan. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Statut adresses IPv4 .0
On 23 Jul 2014, at 08:00, Vincent Bernat ber...@luffy.cx wrote: ❦ 23 juillet 2014 07:53 +0100, Thomas Mangin thomas.man...@exa-networks.co.uk : Ma derriere utilisation de unnumbered remonte en debut du siècle :p Le seul petit problème avec l’unnumbered est que si l'interface qui a l'IP publique sur le LAN passe 'down' (par example le switch est éteint par le client durant le week-end ou soir), tu ne peux plus pinger ou collecter les stats SNMP. Tu ne sais donc pas si c'est un problème avec la ligne ou ou le LAN et le monitoring va chanter. Faut la mettre sur la loopback. :) Pour moi, le seul problème avec l'unnumbered, c'est que quand tu fais un traceroute, tu ne sais pas exactement quelle interface est en ingress. Oui, c'est le meilleur choix si tu as une IP, quand le client a un block c'est moins pratique, et il faut bien configurer ARP, etc. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] A propos des ondes radio
un ingenieur telecom m'a dit qu'en realite, il etait plus nocif d'avoir un telephone mobile continuellement emettre des signature pour trouver un reseau, Donc hyperactivite qui d'ailleurs draine la batterie, que d'avoir une antenne a proximite. Clairement. http://fr.wikipedia.org/wiki/Loi_en_carr%C3%A9_inverse http://en.wikipedia.org/wiki/Inverse-square_law Qui n'a pas eu des speakers d'ordi chanter quand le telephone juste a cote recherche un carrier ? On le saura jamais ou pas encore, car Beaucoup d'etudes sont finances par le lobby des telecom qui manipulent aisement les resultats de recherche. On peut tout faire dire par une recherché. Soupir, C'est Vendredi. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [FRNOG][TECH] Outils de transferts de fichiers sur UDP
Salut, La latence ne devrait pas causer des problemes pour des connections de données longues. Il est possible que tu satures un des coeurs de ta machine avec les IRQ. Tu peux regarder cette bonne video sur l'optimisation TCP - c'est plutôt pour du web et des petits packets mais les conseils TCP sont très pertinents. https://www.youtube.com/watch?v=hzPVeYtoNdE Si ce n'est pas ca, quand les choses ne vont pas bien : tcpdump, tshark et wireshark sont tes amis, pour voir si tu as des packets 'out of order', des retransmissions ou un une fenêtre TCP qui ne grimpe pas a cause de pertes (ou de QOS volontaire par un des réseaux intermédiaires). Bonne chance. Thomas On 18 Apr 2014, at 20:43, Erik LE VACON e...@levacon.net wrote: Bonsoir à tous, Je vous contacte dans le cadre d'une recherche de solutions de transferts de données sur réseaux à latence importante. Les volumétries concernées sont de plusieurs téras de données par jour, en transcontinental (latence de 85 à 150ms en fonction des points nous concernant). La majorité des transferts se faisant traditionnellement en TCP (rsync, ftp, scp et autres), avec les problématiques connues générées par l'augmentation du RTT, j'ai donc tenté des alternatives sur différentes solutions de transfert sur UDP, comme Tsunami-UDP, RBUDP et GridFTP, en gratuit , et Aspera en payant. Je suis passé y compris par de la tuyauterie maison from scratch à base de scripts NC, PIGZ et TAR, avec multi-threads pour le transfert... Bref, dans tous les cas, le taquet n'est pas atteint, mais les taux de transferts sont intéressant, notamment sur Tsunami, mais n'atteignent que péniblement les 500-600mbps sur le gigabit dont nous disposons actuellement, malgré des raids 0 vides hors fichiers pour test, de chaque côté, étant capables de gérer les 100-110MBps attendus, et un circuit vide. Précisons que les tests ont été menés y compris directement en sortie des RAD de chaque côté en off-hours, pour détecter d'éventuels pbs de conf sur les appliances de sécu. Donc, la question: avez vous rencontré de telles problématiques, et si oui, quelles autres solutions, de type OpenSource ou à défaut peu couteuses, avez vous adopté pour faire face ? S'entend, solutions autres que les technologies de WAN-optim embarquées sur certaines baies récentes ? Merci de vos retours, Excellent weekend à tous, -- Erik --- Liste de diffusion du FRnOG http://www.frnog.org/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Py^Hi day
On 15 Mar 2014, at 18:27, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Et moi qui pensais qu'ExaBGP allait s'installer tout pendant mon sommeil, Dur, dur .. mais je prend les patches a cet effet si qqun les a :-). ou que à défaut Thomas allait prendre l'avion, venir l'installer un samedi, m'inviter à bouffer, et repartir :P Je suis un tout petit peu occupe .. Apres l'IETF, Euro-IX, etc .. Mais quand meme, l'install avec python 2.7 c'est pas trop dur : wget https://github.com/Exa-Networks/exabgp/archive/3.3.1.tar.gz tar zxvf 3.3.1.tar.gz cd exabgp-3.3.1 ./sbin/exabgp --help avec 2.6, il faut ajouter : pip install argparse Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Gamme Juniper ?
Donc, c'est pas « open policy », si tu sélectionnes les gens avec qui tu veux bien peerer. Si la session est monte avec le route server de l'IX, c'est bien de une politique ouverte. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Gamme Juniper ?
On 5 Mar 2014, at 15:56, Xavier Beaudouin k...@oav.net wrote: Les open policy qui ne peerent pas sur les routes servers - joker. Non. peerer sur un route server comporte des risques, comme par example la separation du chemin BGP et des données qui fait que la session peut rester up quand les donnees vont vers un trou noir. Un risque que certaines organisations refusent. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] FRNOG 22.0 - RC1
Troll : il manque la separation IPv6 link local et IPv6 routable Sent from my iPad On 1 Mar 2014, at 09:01, Philippe Bourcier phili...@frnog.org wrote: Bonjour, J'ai un peu baissé le niveau du captcha (pour mieux coller avec celui du troll en cours, dirons certains), pour que les gens n'étant jamais entrés dans un DC et s'intéressant un tant soit peu au programme, aient une chance de venir. A savoir que, comme dit précédemment, le programme est technique, donc si vous ne pouvez pas répondre à ce catcha-ci, ne vous attendez pas à pouvoir comprendre ce qui va se dire pendant les conférences (qui va vraiment aller du L1 au L7). Voici donc le nouveau captcha non-élitiste, tant attendu : Qu'est ce que FE80::DEAD:BEEF ? - une MAC address - une IPv4 - une IPv6 - un GBIC ! Bonne continuation de troll et bon weekend :) Pour rappel, vous pouvez réessayer autant de fois que vous voulez, donc pour les histoires d'élitisme, vous repasserez... Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : http://zsysctl.blogspot.com --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] FRNOG 22.0 - RC1
Salut a tous, Comme FRnog est une conférence qui réunit l'élite technique du sommet du haut niveau, Vraiment, FrNOG c'est la creme française ? Il y a vraiment une fuite des cerveaux ou bien mon ego n'est pas assez gros ! Arrêtons de discuter ce sujet sinon cette liste va perdre de son elite, personne n'aime les zombies de trolls, c'est trop dur a tuer ! Au passage, si vous avez du temps : c'est l' IETF 89 a Londres la semaine prochaine. Faites moi signe si vous voulez y parler français, dans un bar de preference :-) , j'y serai toute la semaine. Thomas PS: La premiere ( et derniere ) fois que je suis venu au FrNOG, j'ai utilise Google pour le captcha car je n'avais pas touche a un routeurs depuis 4/5 ans. C'est dur a admettre sur cette liste quand meme ... ( Pour sauver la planète, si vous voulez ME répondre, enlevez la liste ) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Scripts TCL / Cisco IOS
[Thomas, tu n'as pas de version d'EXABGP écrite en TCL, par hasard ?] Non :-) J'avais pensé à EXABGP, mais je voudrais une solution qui soit contenue dans le routeur. Le but étant d'injecter une route /32 dans BGP qui pointe vers un trou noir en fonction de certains critères des messages syslog. Un switch qui supporte cumulus avec install BIRD et TCL ? :-) Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Scripts TCL / Cisco IOS
J'avais pensé à EXABGP, mais je voudrais une solution qui soit contenue dans le routeur. Un switch qui supporte cumulus avec install BIRD et TCL ? :-) J'essaie d'être un peu écolo pour une fois, je ne veux pas une bécane de plus juste pour çà. Est-ce que EXABGP fonctionnerait sur un Raspberry Pi Model B ? Oui. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Ralentissements chez Axione
Oui, j'en ai eu ma dose ces dernieres semaines ! Andrisoft a l'air cool mais ca ne fait pas FlowSpec, Arbor c'est trop cher. Je bosse donc sur une solution anti-DDOS (pour complementer ExaBGP) https://github.com/Exa-Networks/exaddos Le code est vieux de quelques jours mais ca permet deja de repérer les attaques en moins de 10 secondes. L'option que je veux c'est le 1 click RTBH / FlowSpec .. ca va venir ... Si quelqu'un est bon en Javascript, je peux faire un moteur IPFIX / SNMP / HTTP facilement mais les UI c'est pas mon truc. Thomas On 12 Feb 2014, at 15:59, MoncefZID zmon...@manaraway.com wrote: Je pense que nous sommes toujours dans les conséquences de l'attaque DDoS par amplification NTP http://www.itnews.com.au/News/372033,worlds-largest-ddos-strikes-us-europe.a spx signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [ALERT] Ralentissements chez Axione
Salut, J'ai passe quelques annees sur ExaBGP qui fait FlowSpec. A par des solutions fermees, rien n'est sortie comme UI contre les DDOS. Donc je vais ecrire l'outil .. c'est pour ameliorer mon ROI sur le code :-) Thomas On 12 Feb 2014, at 16:58, MoncefZID zmon...@manaraway.com wrote: Arbor c'est trop cher c'est relatif Les solutions ARBOR s'adaptent en fonction des besoins -Original Message- From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf Of Thomas Mangin Sent: mercredi 12 février 2014 17:28 To: frnog-ow...@frnog.org Cc: OCEANET - Cédric BASSAGET; frnog@frnog.org FRNOG Subject: Re: [FRnOG] [ALERT] Ralentissements chez Axione Oui, j'en ai eu ma dose ces dernieres semaines ! Andrisoft a l'air cool mais ca ne fait pas FlowSpec, Arbor c'est trop cher. Je bosse donc sur une solution anti-DDOS (pour complementer ExaBGP) https://github.com/Exa-Networks/exaddos Le code est vieux de quelques jours mais ca permet deja de repérer les attaques en moins de 10 secondes. L'option que je veux c'est le 1 click RTBH / FlowSpec .. ca va venir ... Si quelqu'un est bon en Javascript, je peux faire un moteur IPFIX / SNMP / HTTP facilement mais les UI c'est pas mon truc. Thomas On 12 Feb 2014, at 15:59, MoncefZID zmon...@manaraway.com wrote: Je pense que nous sommes toujours dans les conséquences de l'attaque DDoS par amplification NTP http://www.itnews.com.au/News/372033,worlds-largest-ddos-strikes-us-eu rope.a spx signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [ALERT] Ralentissements chez Axione
On 12 Feb 2014, at 17:16, MoncefZID zmon...@manaraway.com wrote: Certaines solutions ont fait et continuent à faire leurs preuves face aux menaces DDoS et le retour sur investissement est mesurable et démontrable. Sur certains sujets de sécurité il est préférable d'investir d'une façon intelligente pour garantir la meilleure protection Je ne casse pas de sucre sur le dos des solutions propriétaires. Certaines sont surement très bonnes. Mais merci de ne pas insinuer que mon travail n'est bon que pour ceux qui font leur boulot mal en ne donnant pas d'argent a un vendeur. En 10 ans, j'ai eu un total de 1 DDOS .. En 1 moins, j'en ai eu en moyenne une par jour ! Ceci dit, j'ai l'infra qui va bien : - RRD pour grapher mes interfaces - AS-STATS pour savoir quel peers me donne mon trafic - NFSEN pour analyser mes flows - Juniper avec FlowSpec configure pour arrêter les DDOS qui ne font pas plusieurs dizaines de Gbs - RTBH avec mes fournisseurs - Une version interne de ExaDDOS .. Mon problème était que les DDOS étaient de 10-15 mns. Quand le traffic était dans la dizaine de Gbs .. tout allait bien. A plusieurs dizaines de Gb, ca commence a faire vraiment mal, entre l'alerte et la configuration de la règle FlowSpec et/ou RTBH, c'était fini ! Il nous fallait donc un outil plus réactif. Au passage, nous allons aussi grossir notre réseau pour pouvoir encaisser plus. J'aime beaucoup quand je peux simplement filtrer le traffic moi-meme. Je suis sur que les vendeurs auront des solutions bien plus finies, et il y a un jour ou je les inviterai a repondre a une appelle d'offre. Aujourd'hui, je n'en ai pas le besoin. Je pourrais aussi garder ma solution en interne et la faire grossir (je connais de BON FAI avec des solutions anti-DDOS sauce maison), mais j'ai decide de prendre le code et de l'ouvrir. La solution maison est pas jolie, alors au passage ca m'aide aussi de faire ce clean up. Au résultat la communauté aura une solution de réponse aux DDOS. Et moi, avec du bol, des contributions qui m'aideront aussi. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] La salle de contrôle de l'Internet
On 11 Feb 2014, at 09:37, Emmanuel Jacquet m...@formidable-inc.net wrote: http://www.ariase.com/fr/news/media/centre-supervision-orange-business-02.jpg Ensign .. Engage ! Thomas (si vous pouvez voir la ressemblance avec l'USS enterprise) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Routage dynamique
Salut, Oui, c'est en prod sur de gros réseau pour cette utilisation - multiple 10G. J'ai ete contacte par Noction ( pub une via Facebook - et j'ai ete curieux et j'ai rempli le formulaire ). http://www.noction.com/ Je connais aussi les gars chez internap - tres sympa. http://www.internap.com/business-internet-connectivity-services/route-optimization-flow-control/ Si vous ne voulez pas tout faire vous meme. Thomas On 20 Dec 2013, at 11:43, Denis Fondras xx...@ledeuns.net wrote: Bonjour, Est-ce que ce genre de chose n'est pas une mission pour ExaBGP ? Denis Le 20/12/2013 10:19, Pierre-Yves Maunier a écrit : Bonjour Gautier, Deja il y a qqchose qui me choque dans ton énoncé : prepend et a destination de Generalement tu prepend ton AS sur tes policies out pour tenter de contrôler le trafic entrant et non le trafic sortant. Pour contrôler ton trafic sortant, les BCP recommandent l'utilisation de local pref et med sur tes policies in. Le faire automatiquement, a coup de scripts avec du expect ou de rancid (jlogin/clogin) tu peux faire des choses mais attention, un script qui va modifier ta façon de router, tu as intérêt a bien le blinder pour ne pas peter ton réseau si ton script plante. Il existe des solutions payantes mais assez onéreuse de mémoire. PS : désolé pour les accents manquants par moments, clavier qwerty powered Le 19 décembre 2013 12:21, Gautier Avril gautier.av...@bretagnetelecom.coma écrit : A l'heure actuelle, on a plusieurs transitaire et on essayer de jouer sur du prepend pour gerer le traffic à destination de tel AS en fonction de la qualité que l'on observe avec nos différents transitaires (basé sur du smokeping essentiellement). Globalement, on est sur une situation assez stable, mais il peut arriver que l'un de nos transitaires connaisse une problème vers certains AS, auquel cas une petite opération manuelle permet d'améliorer les chose (a moitié me direz vous, car on ne maitrise pas le traffic dans les deux sens). La question que je me pose est : existe t'il une méthode pour faire cela de façon dynamique, si possible assez standardisée? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [TECH] Que faire d'une liste de PCs infectés ?
Michel, Avec ExaBGP, il est possible d'écrire ce logiciel très rapidement. Une interface web, avec une API REST, une base de donnée, et un petit script pour ExaBGP pour annoncer les mises a jours. Si il y a des gens qui sont partant pour le projet, je suis prêt a aider avec l'integration d'ExaBGP (et herberger le service si ca aide). Thomas On 20 Nov 2013, at 20:31, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Manuel Guesdon a écrit: Vu le nombre de téléchargements ca intéresse :-) Ce qui serait sympa ca serait un feed BGP du genre fullbogons, qui annonce ces adresses et qu'on pourrait blackholer directement sur certains routeurs. En d'autre termes, un route-server de PC infectés. Quelque chose comme http://www.spamhaus.org/bgpf/, mais gratuit :P Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [BIZ] Où acheter du Mikrotik ?
On 28 Oct 2013, at 18:44, Florent Rivoire flor...@rivoire.fr wrote: Par contre, je me demande quel fournisseur utiliser (pour une livraison à Paris), car la page web des distributeurs n'est pas très remplie. J'utilise http://linitx.com/ Je ne sais pas si ils livrent sur Paris. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Juniper NSM
On 5 Oct 2013, at 10:18, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Pour les jeunes qui n'ont jamais vu la Cisco Pix originale, c'était un PC de daube (genre Pentium 75) avec 2 cartes réseau Intel Pro/100 (S82557, les mêmes qu'il faut avoir pour faire une Olive) dans une belle boiboîte 3U peinte en gris Cisco (avant qu'il ne soir vert) 3U avec les ports PS/2 clavier/souris cachés derrière le métal mais ça pouvait s'arranger vite fait avec une perceuse. La flash pour booter était sur une carte dans un slot. PIX est une acquisition de Cisco[1], c'est pour cela que le cli était ... différent ... Il faut aussi se souvenir des cisco 1900[2] super pour l'époque avec ses 2 ports 100 Mb et 22 port 10 Mb. Mais je suis HS. Thomas [1] http://en.wikipedia.org/wiki/Cisco_PIX [2] http://en.wikipedia.org/wiki/Cisco_Catalyst_1900 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Bonnes pratiques de configuration de BGP
Pierre, Merci pour ce document, il n'y en a pas beaucoup en français. Des exemples pour Quagga et BIRD seraient aussi utile. Quelques solutions plus avancées ne sont pas présentées dans ce document, surement car plus dures a mettre en place, donc avec moins de chances de se voir implemente correctement, car la configuration ne peux pas etre donnee pour un copier / coller. 1 - A moins d'avoir comme sur JunOS des op scripts qui mettent a' jour automatiquement le nombre de préfixes sur les session de peering [1], il est courant de voir des limites max prefix assez hautes (surtout les gros peers). il peut être aussi prudent de filtrer les routes reçues de vos peers, en utilisant l'AS_PATH : en plus de verifier le premier AS, il est très improbable qu'une route contenant l'AS d'un Tier 1, ou large reseau national ( Orange, SFR, Free ) soit valide si reçu d'un peer ! [2] 2 - Toute route reçue, devrait recevoir une communauté, qui est ensuite utilise pour filtrer les routes sortantes. Par exemples, toutes routes reçues via transit, devraient être filtrées sur les peers. Thomas [1] http://juniper.cluepon.net/index.php/OS_Auto_Tuning_Prefix_Limits [2] http://thomas.mangin.com/data/pdf/LINX%2057%20-%20Mangin%20-%20BGP%20Leak.pdf On 2 Oct 2013, at 11:30, Lorinquer Pierre pierre.lorinq...@ssi.gouv.fr wrote: Bonjour, En parallèle de l'élaboration du rapport de l'observatoire, nous avons travaillé à la rédaction d'un document synthétisant un ensemble de bonnes pratiques de configuration de BGP : http://www.ssi.gouv.fr/fr/bonnes-pratiques/recommandations-et-guides/securite-des-reseaux/le-guide-des-bonnes-pratiques-de-configuration-de-bgp.html Ce document rassemble des éléments de configuration de quatre implémentations : Alcatel-Lucent, Cisco, Juniper et OpenBGPD. Il a été rédigé en coopération avec les opérateurs suivants : - l'Association Kazar ; - France-IX ; - Jaguar Network ; - Neo Telecoms ; - Orange; - RENATER ; - SFR. Si vous souhaitez intégrer d'autres éléments de configuration (mécanisme non mentionné, extraits de configuration pour une autre implémentation ...), ou nous faire part de vos remarques ou suggestions, n'hésitez pas à nous contacter à l'adresse suivante : guide@ssi.gouv.fr Bonne lecture, Pierre Lorinquer, pour l'équipe de l'observatoire -- Pierre Lorinquer ANSSI/SDE/ST/LRP --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Fwd: The US government has betrayed the Internet. We need to take it back
On 7 Sep 2013, at 11:46, Stephane Bortzmeyer bortzme...@nic.fr wrote: De toute façon, le chiffrage ne sert à rien. C'est un résumé vraiment trop simplifié : http://www.linformaticien.com/actualites/id/30151/le-programme-de-la-nsa-qui-decrypte-le-https-et-le-ssl-bullrun-ou-bullshit.aspx Le dechiffrage est possible des lors que la clef privee n'est plus privee. Donc si vous avez le pouvoir de demander a Verisign (ou autre) la clef privee de la societe, HTTPS / SSL n'est plus un obstacle, une copie du flux peut etre decode hors-ligne. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
On 2 Sep 2013, at 17:15, Jérôme Nicolle jer...@ceriz.fr wrote: Une autre approche serait d'utiliser certains concepts intéressants du SDN avec les équipements dont tu disposes, en factorisant les routes au niveau d'un route-reflector, qui recevrait les full-view de tes transits mais n’enverrait à tes routeurs que des agrégats. Ce soft auto-magique n'existe pas encore, ça fait quelques temps qu'il me trotte dans la tête mais sans le temps ni toutes les compétences pour l'implémenter. On pourra toujours en parler au FRnOG si tu viens ;) Ces logiciels magiques existent mais sont toujours propriétaires. Certains utilisent même ExaBGP comme backend BGP pour ce travail, avec des manipulations parfois très complexes : d'ailleurs certaines de ces solutions me font un peu très peur - mais ce n'est pas grave : pas mon réseau. Il y a des gens qui me font trop confiance - et non ce n'est pas ma femme :-D Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider l'intégration. https://github.com/Thomas-Mangin/exabgp A+ Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP software
Je vais essayer de venir mais ce n est pas gagne car je suis déjà a l EPF ce week-end. sinon Skype/FaceTime ? Thomas Sent from my iPad On 2 Sep 2013, at 22:11, Jérôme Nicolle jer...@ceriz.fr wrote: Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider l'intégration. https://github.com/Thomas-Mangin/exabgp On en cause dans 2 semaines, de vive voix avec quelques binches en main ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
On 1 Jul 2013, at 19:01, Kavé Salamatian kave.salamat...@univ-savoie.fr wrote: Pourtant je lui ai bien dit tout de suite après son premier mail que non seulement cela était possible, IMHO - l'interception que tu décris est possible, et en pratique ne causerait que quelques bugs a de plus dans l'OS du routeur :-) mais j'ai vu que cela se faisait. Mais la', tu en as dit trop ou pas assez ... Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?
On 26 Jun 2013, at 11:18, Jérôme Nicolle jer...@ceriz.fr wrote: Une analyse basée sur la consommation du chip et la taille du die suffit à écarter l'hypothèse, mais on ne peut pas exclure que certains modèles export en soient capables. http://www.cl.cam.ac.uk/~sps32/ches2012-backdoor.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] trafic shaping sur linux
Pour une solution on nous limitons environ 1000 clients a quelques Mb chacun avec TC (pas d'IGP ou EGP sur la machine, juste une passerelle transparente) Nous utilisons une hash lookup table de deux niveaux sur les adresses MAC. Facile : seulement une fois que tu as un script qui génère la configuration Fiable: oui, si les règles sont bien conçues. Thomas On 7 Jun 2013, at 09:58, Antoine Durant antoine.duran...@yahoo.fr wrote: Bonjour, Une petite question concernant le trafic shaping avec TC sous Linux... Parmi-vous, est-ce que vous implantez le trafic shaping sur vos routeurs BGP (quagga par exemple) ? Facile en mettre en œuvre, fiable ? Cela bouffe t’il beaucoup de ressource machine ? Je pense utiliser tc qdisc/tc class couplé à iptables (mangle/POSTROUTING) avec CLASSIFY afin de matcher sur mes classid du tc class. J’attends vos retours d’expérience avec impatience et voir même quelque petit exemple de config si vous en avez sous la main… A++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] trafic shaping sur linux
802.1q parent 1:0 prio 5 u32 ht 2:6 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -12 link 206: tc filter add dev eth1 parent 1:0 prio 5 handle 207: protocol 802.1q u32 divisor 256 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 2:7 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -12 link 207: ... # Create a queue for each customer and assign their devices to it # filtered client 1 - 2Mb tc class add dev eth0 parent 1:0 classid 1:1000 htb rate 2097152 ceil 2097152 burst 16k prio 5 tc class add dev eth1 parent 1:0 classid 1:1000 htb rate 2097152 ceil 2097152 burst 16k prio 5 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 220:12 match u32 0xb88d1214 0x at -8 match u16 0x3dae 0x at -4 flowid 1:1000 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 220:12 match u32 0x12143dae 0x at -12 match u16 0xb88d 0x at -14 flowid 1:1000 # filtered client - 10 Mb ( 2 MAC ) tc class add dev eth0 parent 1:0 classid 1:1131 htb rate 1024 ceil 1024 burst 16k prio 5 tc class add dev eth1 parent 1:0 classid 1:1131 htb rate 1024 ceil 1024 burst 16k prio 5 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 237:7b match u32 0x68967b25 0x at -8 match u16 0x2659 0x at -4 flowid 1:1131 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 237:7b match u32 0x7b252659 0x at -12 match u16 0x6896 0x at -14 flowid 1:1131 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 340:c4 match u32 0x68a3c48c 0x at -8 match u16 0x5166 0x at -4 flowid 1:1131 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 340:c4 match u32 0xc48c5166 0x at -12 match u16 0x68a3 0x at -14 flowid 1:1131 beaucoup beaucoup plus .. Thomas On 7 Jun 2013, at 14:03, Antoine Durant antoine.duran...@yahoo.fr wrote: Pas bête... Et comment cela se présente t'il ? Peux-tu expliquer plus en détail la configuration STP ? Merci De : Thomas Mangin thomas.man...@exa-networks.co.uk À : frnog-ow...@frnog.org; Antoine Durant antoine.duran...@yahoo.fr Cc : frnog-t...@frnog.org frnog-t...@frnog.org Envoyé le : Vendredi 7 juin 2013 14h34 Objet : Re: [FRnOG] [TECH] trafic shaping sur linux Pour une solution on nous limitons environ 1000 clients a quelques Mb chacun avec TC (pas d'IGP ou EGP sur la machine, juste une passerelle transparente) Nous utilisons une hash lookup table de deux niveaux sur les adresses MAC. Facile : seulement une fois que tu as un script qui génère la configuration Fiable: oui, si les règles sont bien conçues. Thomas On 7 Jun 2013, at 09:58, Antoine Durant antoine.duran...@yahoo.fr wrote: Bonjour, Une petite question concernant le trafic shaping avec TC sous Linux... Parmi-vous, est-ce que vous implantez le trafic shaping sur vos routeurs BGP (quagga par exemple) ? Facile en mettre en œuvre, fiable ? Cela bouffe t’il beaucoup de ressource machine ? Je pense utiliser tc qdisc/tc class couplé à iptables (mangle/POSTROUTING) avec CLASSIFY afin de matcher sur mes classid du tc class. J’attends vos retours d’expérience avec impatience et voir même quelque petit exemple de config si vous en avez sous la main… A++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] trafic shaping sur linux
Oui, ce n'est pas iptables, c'est tc man tc dit tc - show / manipulate traffic control settings Thomas On 7 Jun 2013, at 14:53, Antoine Durant antoine.duran...@yahoo.fr wrote: Ok merci pour le partage, belle config et wouaa un peu chaud quand même :) Dans ton exemple si je ne me trompe pas, tu n'utilises pas IPTABLES (MARK/CLASSIFY) ?? Cela est directement via match ip src ?? Donc pas besoin d'iptables avec ta façon de faire ?? Le hashkey est une variable que tu remplaces par la MAC du serveur de ton client je présume ?? De : Thomas Mangin thomas.man...@exa-networks.co.uk À : frnog-ow...@frnog.org; Antoine Durant antoine.duran...@yahoo.fr Cc : frnog-t...@frnog.org frnog-t...@frnog.org Envoyé le : Vendredi 7 juin 2013 15h25 Objet : Re: [FRnOG] [TECH] trafic shaping sur linux C'est un peu long a expliquer ... Donc la config simplifie ... # Clear config tc qdisc del dev eth0 root handle 1 tc qdisc del dev eth1 root handle 1 # Setup HTB queueing discipline on physical interfaces tc qdisc add dev eth0 root handle 1: htb default tc qdisc add dev eth1 root handle 1: htb default # Set default for unclassified packets to 1M each direction tc class add dev eth0 parent 1:0 classid 1: htb rate 10kbit ceil 10kbit burst 16k prio tc class add dev eth1 parent 1:0 classid 1: htb rate 10kbit ceil 10kbit burst 16k prio # # eth0 - filter egress trafic on SRC MAC # Step 1, build 1st level hash table using last byte in MAC address as lookup key # Step 2, build 2nd level hash tables using 2nd to last byte in MAC address as lookup key # # See http://www.docum.org/docum.org/faq/cache/62.htmlfor info regards matching L2 header using negative offsets # tc filter add dev eth0 parent 1:0 prio 5 protocol 802.1q u32 tc filter add dev eth0 parent 1:0 prio 5 handle 2: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 800:: match ip src 0.0.0.0/0 hashkey mask 0x00ff at -8 link 2: tc filter add dev eth0 parent 1:0 prio 5 handle 200: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:0 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 200: tc filter add dev eth0 parent 1:0 prio 5 handle 201: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:1 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 201: tc filter add dev eth0 parent 1:0 prio 5 handle 202: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:2 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 202: tc filter add dev eth0 parent 1:0 prio 5 handle 203: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:3 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 203: tc filter add dev eth0 parent 1:0 prio 5 handle 204: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:4 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 204: tc filter add dev eth0 parent 1:0 prio 5 handle 205: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:5 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 205: tc filter add dev eth0 parent 1:0 prio 5 handle 206: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:6 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 206: tc filter add dev eth0 parent 1:0 prio 5 handle 207: protocol 802.1q u32 divisor 256 tc filter add dev eth0 protocol 802.1q parent 1:0 prio 5 u32 ht 2:7 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -8 link 207: ... # # eth1 - filter ingress trafic on SRC MAC # Step 1, build 1st level hash table using last byte in MAC address as lookup key # Step 2, build 2nd level hash tables using 2nd to last byte in MAC address as lookup key # # See http://www.docum.org/docum.org/faq/cache/62.htmlfor info regards matching L2 header using negative offsets # tc filter add dev eth1 parent 1:0 prio 5 protocol 802.1q u32 tc filter add dev eth1 parent 1:0 prio 5 handle 2: protocol 802.1q u32 divisor 256 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 800:: match ip src 0.0.0.0/0 hashkey mask 0x00ff at -12 link 2: tc filter add dev eth1 parent 1:0 prio 5 handle 200: protocol 802.1q u32 divisor 256 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 2:0 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -12 link 200: tc filter add dev eth1 parent 1:0 prio 5 handle 201: protocol 802.1q u32 divisor 256 tc filter add dev eth1 protocol 802.1q parent 1:0 prio 5 u32 ht 2:1 match ip src 0.0.0.0/0 hashkey mask 0xff00 at -12 link 201: tc filter add dev eth1 parent 1:0 prio 5 handle 202: protocol 802.1q u32 divisor 256
Re: [FRnOG] [TECH] contact postmaster OVH
Salut, with spammers the RFC SHOULD be read replacing SHOULD by MUST. Ce n'est pas obligatoire d'accepter l'email non plus ... Thomas On 4 Apr 2013, at 10:57, Sylvain Rochet grada...@gradator.net wrote: Salut Xavier, On Thu, Apr 04, 2013 at 11:49:42AM +0200, Xavier Beaudouin wrote: Le 4 avr. 2013 à 11:37, Sylvain Rochet grada...@gradator.net a écrit : Humm, ça ce n'est pas dramatique, rien dans le protocole SMTP n'oblige le HELO/EHLO. Si c'est une obligation, cf http://www.ietf.org/rfc/rfc2821.txt 3.2 Client Initiation Once the server has sent the welcoming message and the client has received it, the client normally sends the EHLO command to the normally != MUST server, indicating the client's identity. In addition to opening the session, use of EHLO indicates that the client is able to process service extensions and requests that the server provide a list of the extensions it supports. Older SMTP systems which are unable to support service extensions and contemporary clients which do not require service extensions in the mail session being initiated, MAY use HELO instead of EHLO. Servers MUST NOT return the extended MAY use != MUST EHLO-style response to a HELO command. For a particular connection attempt, if the server returns a command not recognized response to EHLO, the client SHOULD be able to fall back and send HELO. SHOULD != MUST In the EHLO command the host sending the command identifies itself; the command may be interpreted as saying Hello, I am domain (and, in the case of EHLO, and I support service extension requests). Après on peux avoir différentes interprétation du client's identity, comme certains spammeurs ne font pas du travail propre, certains admin de mail insitent que HELO/EHLO truc représente le FQDN complet et propre de l'IP source et que sont reverse correspondent. Ce qui est tout aussi faux, il n'y a aucune restriction sur la chaîne suivant le HELO/EHLO. Sylvain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] ARCEP vs. Skype : clarification ?
On 12 Mar 2013, at 20:17, Laurent Cima fr...@l2ct.eu wrote: Dans ce domaine, c'est surtout celle de l'irréalisme de cette autorité qui me semble essayer de montrer par tous les moyens qu'elle pourrait garder un semblant de contrôle avec des méthodes et une connaissance des télécoms des années 90. Quoi que pense le gens derrière l'ARCEP, ils ont une obligation de faire appliquer la loi, quelle soit du 19eme siècle ou d' hier, et c'est ce qu'ils font, a' raison. Ce qu'il faut changer c'est la loi, pas les actions de l'ARCEP. troll La loi, tout le monde peut faire du lobbying pour la changer. Mais le courrier ce n'est pas sur FRnOG qu'il faut l'envoyer ... Mais c'est plus marrant de taper sur l'ARCEP, je te le donne. /troll Skype permet d'utiliser des numéro de telephone français ( https://support.skype.com/fr/faq/FA256/comment-configurer-mon-numero-skype#1 ), il me semble normal que l'ARCEP lui demande de suivre les lois qui régissent ces numéros. A ma connaissance, GTalk n'offre pas de numéro de téléphone français, mon non plus et donc l'ARCEP ne me demande rien (par contre je suis enregistre avec OFCOM qui me donne des numero anglais). L'argument Skype vs Google est donc idiot, surtout que Skype c'est maintenant Microsoft. Je vois bien le jour ou quelqu'un appellera d'un telephone skype ( https://www.google.co.uk/search?q=telephone+skypeoq=telephone+skypetbm=shop ) les urgences, les pompiers, la police (numeros qui autant que je sache ne marchent pas) et succombera. L'ARCEP serai alors accuse de ne pas avoir applique la loi et d'avoir cause la mort de manière indirecte ... OFCOM a eu un différent avec Skype pour cette raison ( http://stakeholders.ofcom.org.uk/binaries/consultations/gc-usc/responses/Skype.pdf ) aussi et bizarrement, en Angleterre les numéros d'urgence marchent ! ... http://www.skype.com/fr/legal/emergency-calling/ Et ici aussi Skype n'était pas content ... Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] ARCEP vs. Skype : clarification ?
On 12 Mar 2013, at 21:20, Serge Marienon smarie...@gmail.com wrote: L’erreur est justement que cette loi n'est pas limitée au numero de telephone mais bien aux moyens de télécommunication en général. Ce n'est pas une erreur, c'est juste ce que dit la loi ... :D Ainsi Gtalk par exemple me semble soumis aux mêmes règles et cete argument me semble bien fondé. Au même titre que ma remarque précédente sur les MMO... Gtalk est peut-etre susceptible de tomber sous cette loi .. Je laisse ca aux juristes. L'ARCEP a peut-etre une discrétion pour son application - je ne peux pas en dire. Quant au problème des numéros d'urgence liés à la localisation géographique...il est connu et existe depuis les premières installations VOIP. Vrai. Les solutions sont connues pour les appels SIP emis depuis une adresse précise mais impossible à gerer pour du nomade et du non géolocalisé. Vrai. Tu peux trépigner tant que tu veux... Vrai, mais non, j'ai assez a faire sans :) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [JOBS] Offre de sysadmin linux en alternance ou CDI débutant sur Paris
OSPF - Pas besoin .. http://tools.ietf.org/html/draft-lapukhov-bgp-routing-large-dc-02 Thomas On 8 Mar 2013, at 15:16, Pierre-Yves Maunier fr...@maunier.org wrote: Bien connaitre BGP et ne pas connaitre OSPF ? Sans vouloir troller, ton IBGP tu le configures comment ? Le 8 mars 2013 13:42, Solarus sola...@ultrawaves.fr a écrit : Le 08/03/2013 13:34, Kavé Salamatian a écrit : Et en plus un bac+2 :-). Déjà qu'un doctorat n'est pas suffisant pour maitriser tout ceci , alors un étudiant juste sorti d'IUT :-) Je confirme. Avec un DUT Réseau et Télécoms et 3 ans d'expérience, je connais bien BGP mais je découvre à peine OSPF. Alors pour un étudiant en alternance, vous avez intérêt à lui mettre un bon tuteur. Cordialement, Solarus. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Pierre-Yves Maunier --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP et IPv6 (uniquement) : comment choisir son router ID ?
J'ai donc testé, et si JunOS râle lorsque le router en face n'a pas de router-id configuré (il s'annonce comme étant 0.0.0.0), mes olives n'ont pas du tout été gênées par le fait d'avoir le même router-id qu'en face. https://code.google.com/p/exabgp/wiki/FAQ Quagga is not happy with ExaBGP ExaBGP will refuse BGP OPEN message with a router-id of 0.0.0.0 in accordance with RFC6286. This is quagga's default router-id, quagga users need to setup their router-id to a non zero value when connecting to ExaBGP. http://tools.ietf.org/html/rfc6286 Une implementation BGP n'a pas a implementer 6286 pour marcher. Je me pose donc plusieurs questions : - Y-a-t'il (ou y aura-t'il) un système d'assignation global, avec l'autorité internationale et tout et tout, ou va-t-on décider des router-id à la mano et croiser les doigts ? AFAIK: non. - Savez-vous comment les différents systèmes réagissent à une collision de router-id ? Aucune implémentation ne semble vraiment donner beaucoup d'importance au router-id. Par example l'implémentation Cisco de add-path, ne l'utilise pas et prefere utiliser un index interne plutôt que le routeur id ! - Que pensez-vous de la probabilité que ça arrive, surtout sur des gros GIX. Quid du cas où il y a un route reflector ? - Avez-vous déjà rencontré le cas en prod ? - D, la réponse D. Passe. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] BGP et IPv6 (uniquement) : comment choisir son router ID ?
On 1 Feb 2013, at 15:37, Aurélien Guillaume footp...@gmail.com wrote: Voila une excellente utilisation pour la classe E :D C'est pas la classe des mauvais élèves ? Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Agregation de liens internet
On 23 Jan 2013, at 18:10, sxpert sxp...@sxpert.org wrote: On 2013-01-23 18:14, Didier Clapier wrote: Le protocole - qui est breveté - est très performant et gère très bien des lignes avec des débits différents, point faible des solutions actuelles. le brevet magique est annoncé ! La dernière boitboite que j'ai vu avait une protocol GRE incompatible ... pour être sur que tu achètes les bon produits seulement. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [BIZ] Agregation de liens internet
Salut, C'est facile si tu a une terminaison L2TP des lignes et si tu peux faire MPPP via Radius, ou ca marche relativement bien. Pour les autres cas, c'est souvent une solution a base de tunneling (GRE, IPIP ou autre) et cela les cas marche bien ... ou tres mal, ça dépend des lignes. Le cas de demonstration de deux ligne de 20Mb permettant 40Mb est bien en théorie et en pratique (ou jusqu'au jour le le FAI remarque le fait). Le problème principal est le clients qui veux la solution pour prendre deux longues lignes (donc de mauvaise qualite) pour avoir un service normal. Il faut aussi regarder si la solution fait du balancing par paquet ou par flow - par flow limite la vitesse maximale a celle d'une ligne - par paquet, deux lignes de longueur/qualité différentes (ou arrivant a deux échanges différents) peuvent poser de gros problèmes. Le bonding n'est pas une simple histoire d'acheter une boite noire pour le client, et si vous n'êtes pas de mon avis - libre a vous et bon courage ( j'ai laisse mes commerciaux vendre ce produit il y a quelques années et j'ai encore les cicatrices de certain bon cas a' montrer ). Thomas On 23 Jan 2013, at 17:15, Didier Clapier dclap...@anteor.com wrote: LOL ! Si c'était aussi simple tout le monde le ferait ;-) -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Sebastien Lesimple Envoyé : mercredi 23 janvier 2013 18:01 À : Didier Clapier Cc : frnog-...@frnog.org Objet : Re: [FRnOG] [BIZ] Agregation de liens internet Heuuu... BSD et Mikrotik sont tes amis LOL! Ooups pardon, on est pas dredi ;) Le 23/01/2013 17:36, Didier Clapier a écrit : Bonjour, Nous commercialisons exclusivement pour la France une solution d'agrégation de liens internet. Cette offre s'adresse aux fournisseurs d'accès internet et au fournisseurs de services via internet. Fournisseurs d'accès internet : vous pouvez proposer le service d'agrégation en alternative ou en sus du SDSL et avec un coût moindre sur les zones éloignées des DSLAMs. Cette offre vous permet aussi d'augmenter la bande passante (DL et UL) de vos points d'accès d'infrastructure (AP, Hotels...) en mutualisant les lignes internet déjà présentes. Vous pouvez de plus revendre ce service à des fournisseurs de service sur internet qui n'ont pas d'accès à un data center. Fournisseurs de services via internet (VoiP, Cloud, Stockage...) : Augmentez le nombre de clients potentiels en leur donnant accès à une bande passante suffisante pour vos services. Parlons de technique : l'offre fonctionne avec un serveur d'agrégation installé dans un data center et avec un modem/routeur spécifique chez le client. Le client navigue sur internet à partir du serveur d'agrégation avec une adresse IP publique fournie par le serveur d'agrégation. Le protocole propriétaire utilisé est un MLPPP très amélioré car il gère très bien les lignes avec des débits différents par exemple. La résilience est parfaite : si le client a une session https ouverte et que vous débranchez un des liens internet, la session ne se fermera pas. Vous pouvez agréger jusqu'à 4 liens internet (ADSL et SDSL par exemple). Résultat de tests effectués par notre société : Vitesse instantanées en b/s et donnée pour DL/UL Cas 1 : 2 ligne ADSL à 6Km du DSLAM : 2.3Mb/0.5Mb + 1.4Mb/0.4Mb = Ligne agrégée 3.7Mb DL/0.9Mb UL Cas 1 : 4 ligne ADSL proche du DSLAM : 18Mb/0.9Mb + 18Mb/0.9Mb + 14Mb/0.7Mb + 15Mb/0.6Mo = Ligne agrégée 60Mb/2.85Mb Parlons business : Nous vous vendons le logiciel du serveur d'agrégation ainsi que le logiciel de supervision (NOC). Le prix de ces logiciels est minimes. Ensuite vous payez une redevance par ligne agrégée. Ce mode de rémunération permet un investissement de base très bas, ensuite les coûts augmenterons avec vos profits, les prix sont libres vous pouvez facturer le service d'agrégation comme bon vous semble. Actuellement il y a 10 000 lignes agrégées en Angleterre et il n'y a pas encore de serveur d'agrégation en France, ils sont tous en Angleterre et en Hollande. L'offre à l'avantage d'être opérationnelle et commercialisable rapidement, aucun développement n'est nécessaire. Contactez-moi si vous désirez plus d'informations. Cordialement, Didier Didier Clapier Company ANTEOR / DIPM Tel : + 33 (0)1 61 37 07 01 Fax : + 33 (0)1 61 37 07 07 3, rue Eugène Carrière - 78114 Magny les hameaux France --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
+1 On 10 Jan 2013, at 11:08, David Ramahefason r...@netfacile.net wrote: Bonjour, Oui oui c'est vrai qu'avec ces deux bouquins on avait tout ce qu'il fallait pour monter un réseaux. Franchement faut arrêter de dire des conneries ... ok ces bouquins sont super pour apprendre les fondamentaux réseau mais de la à savoir comment monter un backbone faut pas déconner hein à moins que tu y sois arrivé gràce à ces ouvrages et la je dis respect. En ce qui me concerne c’était très bien pour faire les TP de dev réseau (socket/sémaphores and co). Mais il y a un moment ou faut passer de la théorie à la pratique non ?? L'époque 95 environ le Pays la Fronce. Le 10 janvier 2013 12:02, Fréderic frede...@placenet.org a écrit : Je trouve plutôt que vous nous prenez de haut... en imaginant que nous ne restons que sur nos acquis sans jamais nous poser de question... comment croyez-vous que la plupart d'entre nous ont fait à leurs débuts lorsqu'il n'y avait aucun enseignement orienté réseau IP ? quelle époque ? pt quel pays ? le Tanenbaum existe depuis 1981, le Pujole , sans parler du macchi-guilbert a+ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason r...@netfacile.net --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
On 9 Jan 2013, at 08:56, Stephane Bortzmeyer bortzme...@nic.fr wrote: Comme moi, ils n'ont pas touché un GBIC depuis des années mais savent utiliser Wikipédia Indice pour le catcha ? :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sécurité du routage BGP et Avenir de la Télématique
On 9 Jan 2013, at 09:19, Dominique Rousseau d.rouss...@nnx.com wrote: Le Tue, Jan 08, 2013 at 04:42:25PM +0100, Stephane Bortzmeyer [bortzme...@nic.fr] a écrit: http://www.bgpmon.net/accidentally-stealing-the-internet/ Merci, ça permet d'avoir le fin mot de l'histoire, sur les leaks d'ATE il y a quelques temps. On voit des routes encore plus drôle sur le net si on regarde vraiment : http://thomas.mangin.composts/asn-or-community.html Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Sécurité du routage BGP et Avenir de la Télématique
http://thomas.mangin.com/posts/asn-or-community.html Avec le / . Sent from my iPad On 9 Jan 2013, at 10:45, Stephane Bortzmeyer bortzme...@nic.fr wrote: On Wed, Jan 09, 2013 at 09:31:23AM +, Thomas Mangin thomas.man...@exa-networks.co.uk wrote a message of 19 lines which said: On voit des routes encore plus drôle sur le net si on regarde vraiment : http://thomas.mangin.composts/asn-or-community.html En effet, il faut bien regarder si on veut voir ce nom de domaine. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Forwarding de session L2TP
revente de collected L2TP ameliorer l'aggregation global private LAN : router plusieurs lignes DSL sur un même LNS, le tout en IP privés. On 9 Jan 2013, at 10:52, Raphael Mazelier r...@futomaki.net wrote: Bonjour, Je vois bien le truc techniquement parlant, mais quel est l’intérêt d'un tel setup ? Pourquoi ne pas vouloir annoncer ces lns ? Cdt, -- Raphael Mazelier Le 08/01/2013 21:04, Laurent Cima a écrit : Bonsoir, Il te faut la feature vpdn multihop. Coté radius, tu utilises l'attribut 'vpdn:vpdn-redirect-id' pour orienter ta session vers le LNS de ton choix. Laurent Le 08/01/2013 20:37, Olivier CALVANO a écrit : Bonsoir, Une petite question: Il est possible de forwarder une session L2TP (une connexion Adsl France Telecom) sur un autre routeur sans que celui si soit annoncé a FT ? Adsl == Tronc de Collect IP FT Adsl == Forwarder Cisco == Routeur Final terminant le tunnel. Le Forwarder a les sessions BGP avec FT mais annonce que sa loopback et les radius. Si oui, comment on s'y prends ? faut réécrire les requêtes radius ? Merci pour votre aide Olivier --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
La thread est deja trop longue mais SERIEUSEMENT ?? !! La réponse a la question est DANS le formulaire ! ... Ca va faire sourire mais cela faisait tellement longtemps que je n'ai pas touche un switch que j'ai du vérifier ma réponse la dernière fois que je me suis enregistre. Je n'étais que quasi sur ! et je bosse pour des réseaux depuis plus de 10 ans .. (la suite est a lire au second degré) Il y a sur cette liste des gens très vocaux (via clavier) qui sont surement très intimidant pour certain ! Pour moi, la question du formulaire n'est pas le problème - l'idée de se retrouver avec 200 inconnus que l'on imagine tous plus compétents que soi est probablement la source la plus probable du blocage psychologique. Pour les gens naturellement introverti ( voir Myers-Briggs pour votre profil ) la question est peut-etre l'excuse personnelle pour ne pas venir, et ... c'est pour ca que l'alcool est offert en fin de journée (ou pas) :D Si vous voulez venir, que vous pensez pouvoir comprendre les présentations et bénéficier d'une rencontre avec de la communauté, VENEZ. Autrement restez derrière votre clavier, mais ne venez pas vous plaindre qu'une conference GRATUITE OUVERTE A TOUS n'est pas assez accueillante. Je peux vous assurer que même les gens les plus opiniâtre sure cette liste sont charmant quand vous les rencontrez ( autrement evitez les ... ) Et pour finir, si vous ne connaissez pas vos optiques, vous pouvez toujours demander a' Philippe une présentation sur le sujet au prochain FRnOG :D :D Sincèrement, Thomas On 9 Jan 2013, at 12:18, Samuel Thibault samuel.thiba...@ens-lyon.org wrote: Metalman, le Wed 09 Jan 2013 13:16:59 +0100, a écrit : Je suis plutot d accord avec Samuel... Je viens de sortir d une l ecole d ingenieurs, dans une specialite qui inclut le reseau... On m a parle de BGP et d OSPF... De multicast, etc L intervenant qui nous a enseigne cela est un professionnel d une grande banque... Et pourtant je ne sais pas ce qu est un GBIC, et j ai eu exactement le sentiment que samuel decrit : je DOIS m interesser au reseau, mais puisque le GBIC n est pas dans mes connaissances, et que c est pour les PRO, ai-je ma place dans le public de ces conferences ?... C est ce que je me pose comme question ! (et ne me suis pas inscrit du coup) Ouf! Merci d'apporter le témoignage que je craignais, justement :) Samuel --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
( toujours au second degre - avec une pointe d'humour ) Pour moi, la question du formulaire n'est pas le problème - l'idée de se retrouver avec 200 inconnus que l'on imagine tous plus compétents que soi est probablement la source la plus probable du blocage psychologique. Oui. Du coup, éviter de confronter dès le formulaire, c'est ptet pas plus mal :) Si ils sont aussi timides et se cachent sous la chaise durant toutes la journée, leur présence n'apporte rien aux autres participants ... Si vous voulez venir, que vous pensez pouvoir comprendre les présentations et bénéficier d'une rencontre avec de la communauté, VENEZ. Justement, cette question fait déjà se dire qu'on risque bien de ne pas comprendre les présentations. Dans ce cas, on regarde les archives PUBLIQUE pour se faire une idée ... Si quelque veux venir AVANT d'avoir regarde les archives, il met la charrue avant les beux. Autrement restez derrière votre clavier, mais ne venez pas vous plaindre qu'une conference GRATUITE OUVERTE A TOUS n'est pas assez accueillante. Justement, ce n'est pas écrit ouverte à tous, mais à tous les professionnels de l'Internet. C'est une conference pour l'industrie, je ne pense pas qu'un médecin y trouve son bonheur. Les sponsors payent pour l'événement (et leurs clients potentiels sont dans l'industrie), il est donc logique que la conference soit cible ! Il y a deja assez de commerciaux ( comme pour toute conference ) et je ne pense pas que nous voulions voir Stallman parler politique au FRnOG, même si cela pourrait m'intéresser autrement ( a petite dose ). Je peux vous assurer que même les gens les plus opiniâtre sure cette liste sont charmant quand vous les rencontrez ( autrement evitez les ... ) Je sais bien ce qu'il en est, pour avoir cotoyé ce genre de monde, mais tout le monde n'a pas cette expérience. Tout le monde n'est pas ne pour venir au FRnOG :D :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]
Si ils sont aussi timides et se cachent sous la chaise durant toutes la journée, leur présence n'apporte rien aux autres participants ... Est-ce vraiment la mentalité voulue ? Les enseignants-chercheurs n'ont effectivement rien à apporter aux autres participants, à strictement parler. Totalement faux. Cette idée bloque la discussion ! Qui dit qu'un chercheur n'a rien a apporter a l'industrie ? Rencontrer des gens avec d'autres compétences (et un chercheur a surement des compétences TRES pointues et intéressantes) est toujours une expérience enrichissante. Rencontrer des gens curieux est toujours agréable. Pouvoir se rendre compte de ce que des personnes en dehors de l'industrie peuvent penser est utile. Le domaine du réseau est un domaine très vaste - des mathématiques aux vendeurs de matériel en passant par les pousseurs de GBIC, ou même experts CLOUD :p Il faut juste que les gens ne se cachent pas sous leur chaise - une conference est un lieu d'échange. C'est une conference pour l'industrie, je ne pense pas qu'un médecin y trouve son bonheur. WTF? Je ne vois même pas quoi répondre à cela. Tu viens de me parler qu'un enseignant-chercheur qui n'a rien a apporter et tu ne vois pas le rapport ? Nous parlons d'un hypothétique chercheur / étudiant - je définie bien que cette personne va devoir avoir une |ien avec le réseau (au minimum de la curiosité) Les sponsors payent pour l'événement (et leurs clients potentiels sont dans l'industrie), il est donc logique que la conference soit cible ! Bien sûr. Mais ce que je dis c'est que le ciblage annoncé sur le formulaire d'inscription est trop fin, il va refouler des gens (enseignants-chercheurs, c'était l'origine du thread) que ces mêmes sponsors auraient intérêt à cibler, pour que les étudiants qu'ils forment soient mieux préparés à être embauchés. Si c'est la raison qui les poussent a ne pas venir, je pense comme d'autres que ce n'est pas une grosse perte. En effet. Mais cibler seulement les pros du réseau, ce n'est pas cibler cela. Personne ne peux inviter le Tout-Paris :) Avec le vaste éventail de personnes déjà présentent, je vois mal les organisateurs étant encore plus ouvert ! Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mieux que l'HADOPI, Free !
On 4 Jan 2013, at 14:33, sxpert sxp...@sxpert.org wrote: non seulement ca, mais t'imagines la bande passante économisée Je me demande si ce n'est pas la raison principale. Quand tu as des liens de peering saturées, enlève la video de pub qui passe avec la video demande ! Je ne connais pas le ratio pub vs video demande mais même quelques pourcents doivent aider ! Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mieux que l'HADOPI, Free !
http://www.numerama.com/magazine/24665-blocage-des-pubs-free-pete-un-cable.html On reparle de la neutralité un peu ? NON ! : c'est une option utilisateur, beaucoup d'add-ins pour navigateur l'offre aussi sans que l'on parle de neutralité et l'option peut être désactivé. Par contre, quand je me demande qui va souffrir de cette perte de revenu publicitaire, la réponse qui me vient a l'esprit est un un gros site de video qui est en en froid avec Free ... Donc cette option pourrait-elle être un effet de bord d'une demande récente d'un organisme ministériel ??? Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Mieux que l'HADOPI, Free !
Oui mais l'option est activée par défaut c'est ça aussi qui dérange je pense Quelqu'un se souvient d'un projet de Google : Obfuscated TCP .. http://en.wikipedia.org/wiki/Obfuscated_TCP Je me demande si Chrome ne va pas changer ses options par défaut avec sa prochaine mise a jour automatique ... Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
STP ne me fais pas dire des choses que je n ai pas dites. Merci :) Sent from my iPad On 22 Dec 2012, at 21:25, Sylvain Vallerot sylv...@gixe.net wrote: On 21/12/2012 12:06, Thomas Mangin wrote: Il y a 5 ans les courbes de trafic des FAI eyeballs avaient cette forme de cloche, que l'on retrouve toujours chez les fournisseurs de transit. Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100% du temps et le DPI est utilisé pour faire passer en priorité les protocoles temps réels ou importants ( voip, email , ... ). Le P2P ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la poubelle le plus rapidement et rempli ce qui n'est pas utilisé par les autres protocoles. Beaux exemples de ce qui se passe quand on abdique la neutralité du net, ici des choix dictés par le marketing et par la déformation des usages : - assimiler le mail à un protocole temps réel ici - défavoriser le pair à pair - favoriser les communications centralisées ici - des tuyaux remplis à 100% Carton plein : tout dans le mille. Il semblerait que LEDBAT offre une solution intéressante et moins chère au même problème de gestion de capacité ... mais avec moins de contrôle pour le FAI. s/FAI/commerciaux/ J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils sont déjà tous sous surveillance pour des raisons strictement commerciales. et la --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
Je ne peux pas parler du marché français :-D mais ... Sur le marché anglais les chances d'une remise sont IMHO quasi nulles. Quasi tous les FAI avec plus de quelques milliers de lignes utilisateurs utilisent du DPI pour réguler le trafic de leurs clients. Il y a 5 ans les courbes de trafic des FAI eyeballs avaient cette forme de cloche, que l'on retrouve toujours chez les fournisseurs de transit. Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100% du temps et le DPI est utilisé pour faire passer en priorité les protocoles temps réels ou importants ( voip, email , ... ). Le P2P ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la poubelle le plus rapidement et rempli ce qui n'est pas utilisé par les autres protocoles. Il semblerait que LEDBAT offre une solution intéressante et moins chère au même problème de gestion de capacité ... mais avec moins de contrôle pour le FAI. Comme la plupart des solutions DPI peuvent être utilisées pour faire de l'interception légale de trafic et comme les demandes d'interception ne disparaitront pas même si tous les clients d'un FAI utilisant LEDBAT, un FAI ne peut pas espérer faire des économies en remplaçant son DPI par un LEDBAT cote client. je te souhaite donc bonne chance pour obtenir cette réduction Qui sait, mon analyse est peut-être totalement fausse ou le père Noel écoutera peut-etre ta demande ... Thomas On 20 Dec 2012, at 08:42, Stephane Bortzmeyer bortzme...@nic.fr wrote: La question qui tue : qui ici est prêt à faire une réduction de tarifs à ses clients pour des applications « gentilles », qui utiliseraient cet algorithme LEDBAT pour ne pas charger le réseau ? http://www.bortzmeyer.org/6817.html Auteur(s) du RFC: S. Shalunov (BitTorrent Inc), G. Hazel (BitTorrent Inc), J. Iyengar (Franklin and Marshall College), M. Kuehlewind (University of Stuttgart) Alors que tant d'efforts de recherche ont été dépensés pour faire des réseaux informatiques et des protocoles qui permettent d'aller *plus vite*, d'attendre moins longtemps avant de voir la page d'accueil de TF1, le groupe de travail LEDBAT http://tools.ietf.org/wg/ledbat (Low Extra Delay Background Transport ) de l'IETF travaillait à un tout autre projet : un protocole de transport de données qui aille *moins vite*, de façon à être un bon citoyen du réseau, à n'utiliser celui-ci que lorsqu'il est vide et qu'on peut donc faire passer ses bits sans gêner personnne. Ce RFC décrit l'*algorithme* LEDBAT, un algorithme « développement durable ». LEDBAT n'est donc pas un protocole complet, mais un algorithme de contrôle de la *fenêtre de congestion*, ce mécanisme par lequel les protocoles de transport évitent de saturer le réseau. Le plus connu et le plus utilisé de ces mécanismes est celui de TCP (RFC 5681) et ses objectifs sont d'utiliser le réseau à fond et d'assurer une relative égalité entre les flots de données qui se concurrencent sur ce réseau. LEDBAT, au contraire, vise avant tout à *céder* la place aux autre flots, non-LEDBAT. Mais pourquoi diable voudrait-on être si généreux ? Cela peut être parce qu'on estime les autres flots plus importants : si je télécharge Plus belle la vie pendant que je passe un coup de téléphone via SIP, je souhaite que le téléchargement ne prenne pas de capacité si SIP en a besoin (c'est la différence entre applications d'« arrière-plan » comme le transfert de gros fichiers et d'« avant-plan » comme un coup de téléphone ou une session SSH interactive). Ou bien cela peut être pour profiter de réductions offertes par le réseau : après tout, un routeur ou une fibre optique ne coûtent pas plus cher à l'usage, que les octets circulent ou pas (contrairement à un autoroute ou une voie ferrée). Il serait donc logique que les transports « charognards », comme LEDBAT, qui n'utilisent la capacité réseau que lorsque personne n'en veut, reçoivent une récompense financière, par exemple une réduction des prix (parlez-en à votre FAI). Pour les détails sur les motivations de LEDBAT et les raisons pour lesquelles des technqiues comme le shaping ne conviennent pas, voir le premier RFC du groupe LEDBAT, le RFC 6297. Ici, je vais me focaliser sur l'algorithme spécifié par LEDBAT et qui répond au cahier des charges : céder la place le plus vite possible. Le principe de cet algorithme est simple : utiliser les variations du temps de voyage des paquets pour détecter l'approche de la congestion et refermer alors la fenêtre de transmission. TCP utilise essentiellement le taux de pertes de paquets comme indicateur (ou les marques ECN du RFC 3168). Les routeurs ayant des tampons d'entrée-sortie, lorsque la ligne de sortie est saturée, les paquets commencent à s'entasser dans ce tampon. Lorsqu'il est plein, le routeur jette des paquets (et TCP va alors réagir). On voit que
Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
On 21 Dec 2012, at 11:21, Emmanuel Thierry m...@sekil.fr wrote: Sans vouloir engager un troll pro/anti-DPI (je pense que maintenant on connait les arguments de chaque partie par coeur), c'est dommage d'utiliser le DPI pour ce genre d'usages. Le DPI est cher. Comme tout investissement, tu dois trouver un retour ! C'est ce qui pousse les développeurs à tout faire passer au dessus d'HTTP, et qui va pousser bientôt à obfusquer son trafic pour le faire passer pour un protocole plus priorisé. Si ça se trouve on sera bientôt obligés de déployer iodine partout... IMHO, la création de websocket est a' attribuer aux administrateurs de firewalls paranoïaques plus qu'aux FAI et au DPI (pas de démarrage de troll ici non-plus - les trolls ont le droit a des vacances pour Noel aussi). Il y a ici une solution qui va dans le bon sens et qui permet aux utilisateurs et aux développeurs de prendre leurs responsabilités, ce serait dommage que de telles propositions partent à la poubelle parce que certains opérateurs se croient plus malins. L'intelligence dans le réseau on ne peut pas dire que cela ait déjà marché... Je n'ai pas de boule de cristal, et je ne sais pas si LEDBAT sera déployé massivement ou pas. Je pense que l'approche a du mérite. J'ai simplement essayé d'expliquer pourquoi une réduction de prix pour l'utilisation de LEDBAT était a mon avis improbable. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)
On 21 Dec 2012, at 14:23, Simon Perreault simon.perrea...@viagenie.ca wrote: LEDBAD est déjà massivement déployé: http://www.utorrent.com/intl/fr/help/documentation/utp Comme annoncé a' la fin de l'article de Stephane, donc j'aurai du dire : largement déployé dans de multiples applications :) Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle
Nous avons déployé 140 AP Ruckus pour la couverture d'un campus. Deux contrôleurs (actif/passif hors ligne) Content du résultat. http://www.ruckuswireless.com/ Pas de retour d'expérience avec Unify. Thomas On 14 Dec 2012, at 12:50, sxpert sxp...@sxpert.org wrote: On 2012-12-14 10:21, proreseau wrote: Bonjour, Je suis à la recherche d'une solution wifi (pour faire data et Voip) que je dois déployer à l’échelle d'un grand campus d'activité (taille d'une petite ville) avec du handover, gestion de QoS, authentification centralisé, supervision du réseau etc etc... Pourriez vous me faire part de vos retours d’expériences dans ce domaine, en terme de solutions techniques (constructeurs ou autres), caveat, contraintes légales etc etc... Merci d'avance, Tom j'ai pas encore fait de déploiement à cette échelle personnellement, mais la gamme Unifi d'Ubiquiti permets de faire ce que tu veux, pour un cout très raisonnable (moins de 200€ par borne). le controlleur est un logiciel gratuit fourni par le constructeur, qui tourne sur n'importe quelle plateforme (linux/mac/windows). Raphael --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] NAT IPv6 dans Linux 3.7
On 14 Dec 2012, at 17:38, Mathieu Goessens geb...@poolp.org wrote: On Wed, 12 Dec 2012 10:55:37 +0100, Emmanuel Thierry m...@sekil.fr wrote: Y a-t-il une justification particulière pour un NAT stateful ? Au hasard, comment tu implémentes un portail captif sans DNAT ? Tu ne peux pas faire d'interception sans DNAT, transproxying par example, et c'est pourquoi nous utilisons FreeBSD qui le supporte. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Session BGP down
La version longue de ce que PY vient de dire : http://thomas.mangin.com/data/pdf/LINX%2057%20-%20Mangin%20-%20BGP%20Leak.pdf Thomas Elle est ou la bierre ? (je ne suis pas fan de popcorn) Si c'est au swinog - je suis foutu :( On 7 Nov 2012, at 13:46, Pierre-Yves Maunier fr...@maunier.org wrote: D'ailleurs, si y'a quelqu'un d'ATE sur la liste, je recommande le filtrage des annonces de routes de clients avec des communautés BGP plutôt que de simples prefix-list, ca pourrait éviter ce genre de leak : * 194.8.251.0 193.105.232.24 100610 0 35625 6453 5511 3215 57348 i Pierre-Yves Maunier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Sent from my iPad On 3 Nov 2012, at 21:39, Raphaël Maunier raphael.maun...@jaguar-network.com wrote: Bah, ce n'est pas ce que j'ai dis. Je parle de l'open source pour faire tourner ton BGP. Je n'ai pas de windows comme serveur dns, mail, www. Mon monitoring perso, c'est Observium et j'ai même filé qq euros au projet :) Je vais eviter la discussion sur BIRD .. Je laisse ca aux gens de AMSIX :) Des retours sur Observium STP - compare a d autres solutions open source ? Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Sent from my iPad On 29 Oct 2012, at 18:39, Jérôme Nicolle jer...@ceriz.fr wrote: On 29/10/2012 19:37, Raphael Maunier wrote: C'est MAL et c'est SALE :) Oui, mais ça reste techniquement possible, et dans de rare cas souhaitable parce que ça répond à un cas de figure pas si rare Et tu fais quoi quand ton upstream vire son Cisco ou le gratuitous arp marche simplement car c'est le comportement par defaut de l'interface pour un Juniper ou ce n'est pas le cas et que ta bidouille tombe a l eau car le routeur refuse d apprendre la MAC ? Ma reponse en temps que fournisseur : c est pas supporte, pas dans le contrat, et je ne veux pas que mes clients puissent impersonaliser n importe quoi. CQFD: tu fais ce que tu veux mais je le recommende pas a d autres. Thomas Dans la meme veine on a des IP RFC1918 sur l interface et l'IP du /30 comme IP virtuelle. Je vous laisse aussi chercher pourquoi c est aussi une tres mauvaise idee :-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Sent from my iPad On 29 Oct 2012, at 19:21, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: Question subsidiaire : quel est l'apport de demander, aux transitaires, la possibilité de mettre en place deux sessions BGP, soit une par routeur. Un réel intérêt en terme de HA par rapport à la complexité induite ? Usine a gas pas forcement utile. IMHO - seulement si ton fournisseur a deux routeurs et pas vraiment utile si tu as deux transitaires. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Routeurs BGP : Conseil de topologie
Sent from my iPad On 29 Oct 2012, at 19:33, Manuel Guesdon ml+fr...@oxymium.net wrote: son interface carp est slave donc 'down'. Je n utilise pas carp .. je suis donc curieux : l interface est vraiment down ou c est seulement la MAC de l IP de service qui n'est pas annonce comme avec HSRP/VRRP ? Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Apres la fin du dernier /8 ipv4
La politique des RIR (avec RIPE en tete) est de pousser les LIR a publlier des ROA. Si tous les FAI forcent un ROA pour router un block d'IP, ces IPs ne sont pas routable sans le ROA du RIR. Et la valeur de ces IPs devient nulle . Trolldi ^ 100. Thomas On 1 Oct 2012, at 16:03, Solarus sola...@ultrawaves.fr wrote: On Mon, 1 Oct 2012 16:56:14 +0200, Pascal Rullier pas...@rullier.net wrote: A quoi ça sert alors ? en interne ? c'est une sorte de rfc1918 mais avec blocs publics uniques Ca sert à spéculer. Ils ont eu ces IP avant la création des RIR du coup ils ne sont pas obligés de les rendre si ils ne s'en servent pas. Donc ils les conservent sans s'en servir, et la rareté créant la valeur, advienne que pourra. Personnellement je n'en voudrais à personne de foutre la zone en IPv4, si ça peut pousser les gens à migrer en IPv6. ;)[Trollundi/] Solarus --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4
Salut Antoine, Et en PPS - packets per seconds - STP ? Les MB ne veulent pas dire grand choses de nos jours (tant que tu ne dépasses pas la capacité du BUS de la machine - aux alentour de 600 MB pour du PCI ?), si tu as une DDOS les PPS qui vont tuer ton infra. Un J series passe très bien les MB aussi, c'est n'est pas bcp plus cher qu'un PC non plus. Personnellement je préfère Bird a Quagga mais je ne vais pas recommencer cette discussion :D Thomas On 28 Sep 2012, at 08:35, Antoine GANCEL anto...@gancel.net wrote: Bonjour, Nous utilisons le couple debian/quagga et nos BGP tiennent très bien la charge avec 400 à 600Mo de transit par BGP et plusieurs transitaires Nous utilisons aussi nos BGP pour nous interconnecter avec nos clients en AS public ou privé sans problème particulier. Cdt, Antoine. - Mail original - De: OCEANET - Cédric BASSAGET ced...@oceanet.com À: frnog@frnog.org Envoyé: Vendredi 28 Septembre 2012 09:18:52 Objet: Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4 Bonjour à tous, Nous sommes actuellement en train de réfléchir au remplacement de nos routeurs BGP (actuellement 2 routeurs cisco 29xx), et nous nous posons la question suivante : doit-on partir sur du cisco / brocade / juniper, ou sur une solution type vyatta ? Nous avons actuellement 3 transitaires (dont 2 full view) et atteignons une centaine de Mo de transit. L'argument financier penche en faveur de quagga, mais quid des performances et de la fiabilité ? Je n'ai pas l'impression que ce type de produits soit très répandu chez les opérateurs (régionaux), ais-je raison ? Merci pour vos retours Cédric Le 27/09/2012 21:09, Jérémy Martin a écrit : Ici, on a fait le choix de partir sur Brocade avec l'excellent conseil d'ATE. Le 2024C-RT marche à merveille et peut gérer 1.5M de route. Bref, on devrait être tranquille pour une transition complète vers l'ipv6. Par contre, on a du casser notre tirelire et celle du voisin avec ... Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com Le 27/09/2012 20:36, Salim Gasmi a écrit : Bonsoir, Le nombre de préfixes v4 annoncés en BGP augmentant régulièrement, j'ai du reconfigurer le partitionnement de la TCAM de mes cisco 7600 équipés de sup720-3BXL. Toutefois, en regardant le graph de l’évolution du nombre de préfixes ici: http://bgp.potaroo.net/as6447/ on voit bien l’accélération. Mon sentiment est qu'avec la rarification des ipv4 on va avoir de plus en plus de désagrégation et que cela va encore accélérer dans les prochains temps. Sans jouer à madame Irma, pensez vous que les 800K préfixes soient possible ou vous avez des arguments qui militent pour une stagnation ? Car si on devait atteindre les 800K, il faudrait pour les possesseurs de 720-3bxl comme moi penser à passer a autre chose et la je me demande bien quoi choisir en restant chez cisco . Comme j'aime bien anticiper les problèmes, si vous avez des suggestions ou conseils je suis preneur. Cordialement, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [TECH] UBNT EdgeMax, was: Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4
A première vue, ce n'est pas fait pour gèrer de lourdes tables de routage mais forwarder a line rate. Thomas On 28 Sep 2012, at 08:59, David Touitou da...@network-studio.com wrote: 'jour si tu veux du quagga/vyatta avec du network processor hard, t'as http://www.ubnt.com/edgemax qui devrait arriver rapidement J'en parlais hier sur FRsAG, visiblement personne ne connait là bas... T'as des infos complémentaires ? David --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4
Salut, Chacun fera ses maths pour trouver la limite de sa machine: frequency * bitwidth = bandwidth Mais si PCI c'est 500MB - et pas 600MB :p : a x16 cela ne fait que 8000 MB/s donc pas de 10GB a line rate. Et en effet, a ces vitesses il faut de l'offloading de CRC, interrupt grouping, et tout le tralala pour que ca marche :) Thomas http://www.naplestech.com/shopcart/bus_speeds.asp On 28 Sep 2012, at 09:08, Guillaume Barrot guillaume.bar...@gmail.com wrote: Hello 600MB pour du PCI ? Pas en PCIe3.0 alors :D On est plutot sur du 1000Mo/s par ligne théorique. Il y aura bien des cartes N x 10GE qui vont sortir en PCIe3.0 x8 ou x16, je pense. Après il y a aussi les cartes ethernet avec du SoC intégré qui permettent d'envisager de décharger le traitement directement au niveau de la carte (lookup, etc.) A+ Le 28 septembre 2012 10:00, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : Salut Antoine, Et en PPS - packets per seconds - STP ? Les MB ne veulent pas dire grand choses de nos jours (tant que tu ne dépasses pas la capacité du BUS de la machine - aux alentour de 600 MB pour du PCI ?), si tu as une DDOS les PPS qui vont tuer ton infra. Un J series passe très bien les MB aussi, c'est n'est pas bcp plus cher qu'un PC non plus. Personnellement je préfère Bird a Quagga mais je ne vais pas recommencer cette discussion :D Thomas On 28 Sep 2012, at 08:35, Antoine GANCEL anto...@gancel.net wrote: Bonjour, Nous utilisons le couple debian/quagga et nos BGP tiennent très bien la charge avec 400 à 600Mo de transit par BGP et plusieurs transitaires Nous utilisons aussi nos BGP pour nous interconnecter avec nos clients en AS public ou privé sans problème particulier. Cdt, Antoine. - Mail original - De: OCEANET - Cédric BASSAGET ced...@oceanet.com À: frnog@frnog.org Envoyé: Vendredi 28 Septembre 2012 09:18:52 Objet: Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4 Bonjour à tous, Nous sommes actuellement en train de réfléchir au remplacement de nos routeurs BGP (actuellement 2 routeurs cisco 29xx), et nous nous posons la question suivante : doit-on partir sur du cisco / brocade / juniper, ou sur une solution type vyatta ? Nous avons actuellement 3 transitaires (dont 2 full view) et atteignons une centaine de Mo de transit. L'argument financier penche en faveur de quagga, mais quid des performances et de la fiabilité ? Je n'ai pas l'impression que ce type de produits soit très répandu chez les opérateurs (régionaux), ais-je raison ? Merci pour vos retours Cédric Le 27/09/2012 21:09, Jérémy Martin a écrit : Ici, on a fait le choix de partir sur Brocade avec l'excellent conseil d'ATE. Le 2024C-RT marche à merveille et peut gérer 1.5M de route. Bref, on devrait être tranquille pour une transition complète vers l'ipv6. Par contre, on a du casser notre tirelire et celle du voisin avec ... Cordialement, Jérémy Martin Directeur Technique FirstHeberg.com Contacts téléphoniques (Lun-Ven / 9h30-12h00 - 14h00-17h30) Standard : 09 72 125 539 (tarif local) Ligne directe : 03 66 72 03 42 Mail : j.martin AT freeheberg.com Web : http://www.firstheberg.com Le 27/09/2012 20:36, Salim Gasmi a écrit : Bonsoir, Le nombre de préfixes v4 annoncés en BGP augmentant régulièrement, j'ai du reconfigurer le partitionnement de la TCAM de mes cisco 7600 équipés de sup720-3BXL. Toutefois, en regardant le graph de l’évolution du nombre de préfixes ici: http://bgp.potaroo.net/as6447/ on voit bien l’accélération. Mon sentiment est qu'avec la rarification des ipv4 on va avoir de plus en plus de désagrégation et que cela va encore accélérer dans les prochains temps. Sans jouer à madame Irma, pensez vous que les 800K préfixes soient possible ou vous avez des arguments qui militent pour une stagnation ? Car si on devait atteindre les 800K, il faudrait pour les possesseurs de 720-3bxl comme moi penser à passer a autre chose et la je me demande bien quoi choisir en restant chez cisco . Comme j'aime bien anticiper les problèmes, si vous avez des suggestions ou conseils je suis preneur. Cordialement, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4
Dans tous les cas, en routage software, que ce soit do Quagga sous Linux, du J/SRX chez Juniper ou 7200/7300/ASR1k chez Cisco, quand tu prends beaucoup de PPS à l'occasion d'une attaque, tu perdras ton control plane donc tu ne pourras rien faire tant que l'attaque ne se calme pas. Autant que je sache, les J tourne avec un patch RT pour BSD, donc le les PPS ne devraient pas tout tuer (pas de retour d'expérience cependant) - je n'ai jamais eu de DDOS sur le J que j'ai. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Apres la fin du dernier /8 ipv4
On 28 Sep 2012, at 10:19, Arnaud Fenioux afeni...@gmail.com wrote: Des business plans émergent pour certains : - J'ai des PI/PA que je vends aux enchères, meme si les RIR ne l'autorisent pas, peuvent il l'empecher? Le transfer d'IP est autorise par RIPE. - je suis LIR, j'ai des PA que je loue et quand le client rompt le contrat je les récupère pour un nouveau client, mais pas sur qu'il y ait assez de PA pour tout le monde... et montée des prix en fleche Tu as vu les réserves d'IP chez les LIR / FAI ? Perso, je suis tranquille au moins pour 5 ans. - j'ai des PI/PA et je mets en place un NAT/Proxy 4to6 On va surement aussi voir des services/CDN spécialisé dans la conversion 6to4 / 4to6 .. ca marchera surement tres bien :D Et du coté des GIX, il fait comment le membre qui n'a pas d'IPv4? RIPE a un /16 reserve pour permettre la creation de nouveaux IX. - il vient pas sur le GIX :( - il peer uniquement en v6 - il loue ses IPv4 / il achete son transit a un seul provider qui lui prête une plage v4 Quand tu peers tu utilise les IP du LAN donc l'allocation est celle de l'IX. Pour le transit c'est pareil le /30 c'est normalement les IP du fournisseur de transit. - un (ou plusieurs) gentil(s) provider(s) (projet communautaire/associatif) lui prete qqlq ip et les route pour lui a un prix raisonable? Les nouveaux réseaux sont ceux pour qui la penurie est la plus embêtante mais je suis sur que tu pourras trouver des FAI pour te donner un /22 pour moins cher que RIPE demandait l'année dernière comme cotisation. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Apres la fin du dernier /8 ipv4
Tu as vu les réserves d'IP chez les LIR / FAI ? Perso, je suis tranquille au moins pour 5 ans. Ok, mais tu es gentils toi, tu vas surement les fournir a tes clients pour pas trop cher...dans un premier temps :p non, je ne charge pas mes clients pour leur IPs tant qu'il me fournissent une justification - comme RIPE le demande. Et du coté des GIX, il fait comment le membre qui n'a pas d'IPv4? RIPE a un /16 reserve pour permettre la creation de nouveaux IX. Ok pour la création de IXP, mais si le client final n'a qu'une ipv4 sur le vlan de peering, il va annoncer quoi? 192.175.48.0/24 Tu assumes que le client sentira un besoin d'annoncer des IPv4 ... :D Les nouveaux réseaux sont ceux pour qui la penurie est la plus embêtante mais je suis sur que tu pourras trouver des FAI pour te donner un /22 pour moins cher que RIPE demandait l'année dernière comme cotisation. Aujourd'hui, probablement, demain? hum... on aura le droit de les annonces avec son propre AS sur plusieurs transitaires sans que ca soit filtré qqlq part sur l'Internet? Mais c est sur, ceux qui auront de l'argent arriveront tjs a trouver des IP et un moyen d'avoir une connectivité V4, donc on risque de réduire l'inovation et les petites startup? La petite startup n'a pas besoin de PI, ou d'etre LIR, il lui faut juste des IPS .. Avec les solutions cloud beaucoup de startup n'ont meme plus besoin de leurs propres IP, ou même serveurs. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
Tu as vu les réserves d'IP chez les LIR / FAI ? Perso, je suis tranquille au moins pour 5 ans. Ah, c'est ce que les DSI disaient il y a 10 ans, pour justifier de ne rien faire sur IPv6. Dix ans ont passé, et le problème devient plus aigü. Vu le temps que prennent les migrations dans certaines boîtes, 5 ans, ce n'est pas trop. Notre reseau est dual-stack, nos services clients (a part le mail - le ratio spam/ham est trop haut en v6) sont tous IPv6 ... On a meme migre des machines sur FreeBSD pour pouvoir faire du DNAT ipv6 dont on a besoin (oui, NAT peut etre utile en v6). J'ai deja du ecrire ca au moins trois fois sur cette liste :D Tous clients DSL auront une IPv6 automatiquement avant la fin de l'annee, c est actuellement en production pour un petit nombre de clients. Bref, on peut avoir des reserves ET avoir une strategie IPv6 - qui prend plus de temps que prevu bizarrement :D J'ai pas mal de coup de fils de gens pour me vendre poser des question a propos de notre strategy IPv6 (vendeur de materiel reseau), donc si le marketing de ces gens y bosse, ca veut dire qu'il y a des gens qui achète derrière :D Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4
La petite startup n'a pas besoin de PI, Je me méfie toujours lorsque les fournisseurs disent aux clients de quoi ils ont besoin (ou pas). C'est une illustration. Ce que je veux communiquer est que le marche évolue et se professionnalise et que la valeur ajoute des startups et maintenant moins dans le réseaux et l'infrastructure mais plus dans les services. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Apres la fin du dernier /8 ipv4
On 28 Sep 2012, at 14:04, Nicolas CARTRON nico...@ncartron.org wrote: Par contre on commence déjà à voir sur le terrain les sociétés dont le business est la revente d'adresses IPv4... Témoin au RIPE65 hier, où la prospection commerciale était bien active.. Il faudrait savoir combien de LIR ont été créés par des gens pour mettre des IP de cote ces dernières années. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Téléphones et paranoïa
- Certains poussent même le vice encore plus loin en affirmant que même batterie retirée, il est toujours possible d'écouter. c'est exact. prends l'iPhone par exemple. il suffit d'éteindre le rétro- éclairage de l'écran apres avoir simulé l'écran d'extinction (le slider rouge) et hop, le propriétaire croit qe le telephone est effectivement éteint. on peut meme pousser le vice d'éteindre le processeur applicatif. mais le micro, la radio, et le processeur du modem, sur lequel le micro est directement attaché, peuvent continuer a fonctionner, meme si le processeur applicatif est éteint. J'ai un ami qui a code ca sur le sien, quand tu l'éteins de manière normale et ca met le téléphone en veille et il se réveille régulièrement pour lui envoyer sa position sur un serveur (avec les SSID et un traceroute si il y a un wifi ouvert aussi je crois). Et quand tu ouvres le téléphone de manière normale, ca te monte un telephone sans ses contacts, emails, etc. il faut faire quelque chose pour que son appli passe la main normalement ... C'est assez cool. Pour plus d'informations, je te recommanderai de participer au CCC congress, qui aura lieu a Hambourg juste apres Noel. Il y a deja eu pas mal de bruit sur Carrier IQ ... https://www.google.co.uk/search?q=carrier+iq+spyware Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
Ce qu il faut surtout avec conntrack c est augmenter l allocation de memoire par defaut pour le module Sent from my iPad On 8 Sep 2012, at 18:02, Frederic Dhieux frede...@syn.fr wrote: Le 08/09/2012 18:50, Radu-Adrian Feurdean a écrit : Meme pas besoin d'une regle. Charger le module conntrack est generalement assez. Sans conntrack, quelques centaines de regles posent pas beaucoup de problemes. Pour plus, faut essayer de hierarchiser un peu. le module conntrack pose plutôt problème par rapport au trafic indépendamment des règles, les règles sur certains aspects peuvent charger le serveur, même sans conntrack, si on cumule trop de règles longues à traiter dans le cycle de netfilter. Enfin dans mes souvenirs c'est plutôt ça. Fred --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Detecter DDos outils et null-router sur quagga
On 6 Sep 2012, at 14:11, Alain Thivillon a...@rominet.net wrote: Test à faire : mesurer à partir de combien d'adresses filtrés ça devient insupportable. Sur d'autres systèmes (pf) on peut charger des tables qui sont hashées. Tu peux créer des hashtables avec tc et aussi limiter chaque flow au lieu de tuer le traffic tu le rate-limite a zero. Ca devrait bien monter en charge. Par contre les docs ne sont pas trop la .. Nous nous en servons pour limiter la vitesse de connexion d'étudiants dans une résidence universitaire dans un même L2 (avec port séparation) a partir de la MAC de leurs machines (plus de 1,000). Nous construisons une premier niveau de hashing sur le dernier octet de la MAC puis un second niveau sur le deuxième octet, après ca le scan est linéaire. Je ne vois pas pourquoi cela ne pourrait pas etre fait sur les deux derniers octet d'une IP :D Le fichier configuration tc est généré et contient plus de 14,000 lignes ! Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Detecter DDos outils et null-router sur quagga
Quand à la détection, c'est pour le coup bien plus complexe. Je n'ai pas connaissance d'un produit non commercial fournissant ce service. Les technologies les plus connues sont sans doute celles de cisco et d'arbornetworks. Pareil ici, NetFlow est souvent la source des informations. Dans beaucoup de cas la solution est une sauce maison. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] VoIP / plan de numérotations
C est quelque chose comme ca que tu cherches ? http://www.ofcom.org.uk/static/numbering/index.htm Sent from my iPad On 3 Sep 2012, at 08:48, Sebastien WILLEMIJNS sebast...@willemijns.com wrote: On Mon, Sep 3, 2012, at 09:16, Sebastien Lesimple wrote: -BEGIN PGP SIGNED MESSAGE- Hello, La base de numéro en portabilité est gérée par l'APNF. Tu as le choix entre passer en direct APNF pour synchroniser tes bases avec eux, soit tu passes par un intermédiaire pour alimenter la base APNF. ok merci de ta prompte réponse. ma question était plus générique qu'autre chose... l'APNF est donc une porte obligée mais comment ca se passe au niveau international ? --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probléme sur l'Internet Européen ?
Du ACL, quoi. Il semble qu'il faut detailler mon question: qu'est-ce qu'une ACL a a faire sur un coeur de reseau pour du traffic *FORWARDE* (non destine au routeur / receive acl chez mon concurrent favori). http://en.wikipedia.org/wiki/Reverse_path_forwarding Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probléme sur l'Internet Européen ?
On 29 Aug 2012, at 20:37, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: On Wed, Aug 29, 2012, at 09:29 PM, Thomas Mangin wrote: http://en.wikipedia.org/wiki/Reverse_path_forwarding Sur un core de Tier-1 ?!?!?!?!?!?!?!?!!? WTF ? C'est sur tous mes routeurs avec des sessions EBGP ... Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probléme sur l'Internet Européen ?
Oui en loose ... Strict sur le core et ... la demo a ete faite ? Au passage je suppose que c est ca - ca pourrait être une regle de filtrage pour le control plane qui avait une faute aussi. Sent from my iPad On 29 Aug 2012, at 20:45, Frédéric Gabut-Deloraine fga...@neotelecoms.com wrote: Le 29 août 2012 à 21:38, Thomas Mangin thomas.man...@exa-networks.co.uk a écrit : On 29 Aug 2012, at 20:37, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: On Wed, Aug 29, 2012, at 09:29 PM, Thomas Mangin wrote: http://en.wikipedia.org/wiki/Reverse_path_forwarding Sur un core de Tier-1 ?!?!?!?!?!?!?!?!!? WTF ? C'est sur tous mes routeurs avec des sessions EBGP ... Ouais après y'a urpf loose et urpf strict. On tourne du loose, pas du strict sur un BB opérateur ils ont ptet oublié le mode loose à la fin de la commande family inet rpf-check :-) -- Frederic Gabut-Deloraine Network Engineer NEO TELECOMS - AS8218 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probléme sur l'Internet Européen ?
Sent from my iPad On 29 Aug 2012, at 21:01, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: On Wed, Aug 29, 2012, at 09:38 PM, Thomas Mangin wrote: http://en.wikipedia.org/wiki/Reverse_path_forwarding Sur un core de Tier-1 ?!?!?!?!?!?!?!?!!? WTF ? C'est sur tous mes routeurs avec des sessions EBGP ... Hereusement que tu n'est pas Tier-1, voir meme pas operateur majeur de transit. Ton commentaire implique que j ai tord - desole urpf loose sur le coeur de reseau c est comme BCP 78 ce n est juste pas assez deploye par les FAI. Pour ton info, balancer chez l'operateur B le retour du traffic vers les IP (ASSIGNED PA) de l'operteur A, c'est pas is marginal que ca peut sembler. Il y en a qui le font, il y en a qui veulent desesperement le faire mais ils ont peur Mais ca reste un besoin reel. D accord. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Probléme sur l'Internet Européen ?
Lire 38 pas 78 Merci l iPad ! Sent from my iPad On 29 Aug 2012, at 22:09, Thomas Mangin thomas.man...@exa-networks.co.uk wrote: Sent from my iPad On 29 Aug 2012, at 21:01, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote: On Wed, Aug 29, 2012, at 09:38 PM, Thomas Mangin wrote: http://en.wikipedia.org/wiki/Reverse_path_forwarding Sur un core de Tier-1 ?!?!?!?!?!?!?!?!!? WTF ? C'est sur tous mes routeurs avec des sessions EBGP ... Hereusement que tu n'est pas Tier-1, voir meme pas operateur majeur de transit. Ton commentaire implique que j ai tord - desole urpf loose sur le coeur de reseau c est comme BCP 78 ce n est juste pas assez deploye par les FAI. Pour ton info, balancer chez l'operateur B le retour du traffic vers les IP (ASSIGNED PA) de l'operteur A, c'est pas is marginal que ca peut sembler. Il y en a qui le font, il y en a qui veulent desesperement le faire mais ils ont peur Mais ca reste un besoin reel. D accord. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Load Balancer IPV4/IPV6
Donc réutilisable sans autre obligation que de mentionner les auteurs originaux du code. Ensuite c'est une licence BSD, pas GPL, la FSF n'a pas son mot à dire. :) Bref, la licence BSD c'est pratique. :) Donc quand un logiciel a une licence BSD, c'est que ses auteurs veulent encourager son utilisation (en entreprise ou pas) - même si ces utilisateurs ne participe pas. Dans un marche de niche comme BGP, ou AFTR, le choix de la licence a une grande importance. En pratique a moins de changer le logiciel radicalement, les entreprises qui utilisent le logiciel fournissent souvent leurs modifications afin a ne pas a avoir a les supporter a chaque mise a jour. Si A10 utilise ce code, le but des auteurs - voir leur solution utilise sur le net - est atteint. Je ne pense pas qu' ExaBGP aurai autant d'utilisateurs avec une licence plus restrictive comme la GPL / Affero GPL car je connais au moins deux sociétés qui ont intégré le code dans leur SI et n'auraient pas pu autrement. Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Load Balancer IPV4/IPV6
On 24 Aug 2012, at 13:02, Guillaume Barrot guillaume.bar...@gmail.com wrote: Avec des loadbalancers hardware, ça me parait la solution la plus simple. Par contre ça revient à dire qu'en plus d'etre un loadbalancer, c'est aussi un routeur (ce qui me parait évident, mais pas à tout le monde). HAProxy est fantastique pour du failover de service entre plusieurs datacenters sans L2 partage. Dans chaque DC : - une machine haproxy - un nombre de serveurs pour le service chaque machine haproxy a : - un IP reelle sur le LAN - une IP de service (un /32) sur le loopback avec une regle iptables pour accepter les paquets depuis eth0 (et/ou ne pas announcer son ARP sur le LAN) - un client BGP. HAProxy bind sur l'IP de service qui est announce via BGP (exabgp) dans le coeur de reseau. exabgp peux arreter d'annoncer son IP de service si une condition de test échoue (le réseau est segmente, faute sur le DC, ou autre). L'IP de service migre alors sur l'autre machine HAProxy grace a BGP. Comme haproxy est du L7, il est possible de leur faire utiliser TOUS les serveurs des deux DC ou meme de se service de VM sur le 'cloud'. Comment faire ca ? http://thomas.mangin.com/data/pdf/UKUUG%20Spring%202011%20-%20Mangin%20-%20BGP.pdf http://thomas.mangin.com/data/pdf/RIPE%2063%20-%20Mangin%20-%20BGP.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retours sur un nouveau proxy ??
Bonjour, Si il y a des fous pour me donner un retour sur ExaProxy - comme foward proxy / reverse proxy / load balancer. Il peut-faire tout ce que vous voulez au niveau de la redirection des requêtes puisque comme un peu comme varnish / squid il peut être programme. http://code.google.com/p/exaproxy/ C'est prevu pour une utilisation derrière HAProxy (car comme Python a un GIL, pour de gros trafic il faut mieux lancer une instance de ExaProxy par coeur de CPU) et il faut donc un bon LB comme HAProxy pour le balancing sur une seule IP. Nous allons ajouter le proxy protocol a exaproxy - avec du bol regardez le repo mercurial ce soir et le code sera la. Attention, je ne dirai pas que le code d' ExaProxy est production ready mais c'est maintenant en beta testing chez nous par certain de nos clients donc les grosses surprises devrait être (plus) rare :) Je n'ai pas de benchmark mais les perfs, mais avec pypy comme JIT, elles sont bien meilleures que ce a quoi je m'attendais. http://www.pypy.org/ Presentation sur ExaProxy: http://thomas.mangin.com/data/pdf/uknof%2022%20-%20Mangin%20-%20ExaProxy.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Load Balancer IPV4/IPV6
L'intelligent montera divisera le traffic en couche: L4, SSL et L7 la première couche sera en L4, DSR vers le SSL et le L7. Cela veut il dire que ce qui n'utilise pas cette configuration sont des crétins ? Si oui, il y a pas mal de crétins :) C est plus simple d acheter un boîte que de monter un cluster. Pour monter un cluster il faut des competences internes sinon la boîte c est mieux. Pour monter un cluster il faut plus de temps, les gens competents n ont souvent pas le temps. Donc cela depends, comme toujours, du contexte. Tout le monde n a pas les memes besoins. Pour 10 serveurs à 2000 euros, 2 L4, 4 SSL et 4 HAProxy, t'as une platforme plus robuste et plus scalable et hardware agnostique... Facture divisée par 10 :) Vive les mathématiques marketing, avez vous compté le coût du rack space, maintenance, etc .. en plus du coût d'achat ? Le clustering c est un choix, il faut toujours regarder le couple CAPEX + OPEX Meme dans ce cas le prix n est qu'un des facteur de decisions Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Collecteur NetFlow ?
Tant que tu ne cherches pas a savoir quelle AS est derrière quelle autre, as-stat est a mon avis le meilleur choix. https://neon1.net/as-stats/ J'ai fait une prez complete sur son installation - car c'est vraiment simple : http://thomas.mangin.com/data/pdf/Linx%2069%20-%20Mangin%20-%20AS-STATS.pdf Thomas On 5 Jul 2012, at 09:40, Fabien Delmotte wrote: Pour ma part pmacct est le meilleur Cordialement Fabien Delmotte Envoyé de mon iPhone Le 5 juil. 2012 à 10:38, Cyril Lavier cyril.lav...@davromaniak.eu a écrit : On 07/05/2012 10:29 AM, Benjamin Sonntag wrote: Bonjour FrNog, Un collègue me demande si j'ai connaissance et conseil à lui donner en matière de collecteur NetFlow. Je me suis donc dit que FrNog était le meilleur endroit pour vous demander un retour d'expérience dans ce domaine, quels logiciels utilisez-vous pour la collecte des flux, et leur analyse (répartition par ip, protocole temps dans la journée, analyse post-mortem en cas de DDoS etc.) ? J'ai utilisé, à une époque, du Ntop ( http://www.ntop.org/ ) et du pmacct ( http://www.pmacct.net/ ) et du IPT-Netflow (module iptables pour linux http://sourceforge.net/projects/ipt-netflow/ ) mais c'était sur une infra 100% libre et pour un cas bizarre ... j'imagine que vous avez de meilleurs outils. merci de votre aide :) Bonne journée à tous, Benjamin Sonntag Octopuce --- Liste de diffusion du FRnOG http://www.frnog.org/ Bonjour Benjamin. Je suis aussi à la recherche d'un bon collecteur netflow. J'ai commencé à triturer ntop, mais il partait en segfault toutes les 5 minutes. Actuellement, j'utilise as-stats (https://neon1.net/as-stats/) qui permet de faire quelques statistiques sympa à base de flux netflow. Dans quelques temps, je testerai scrutinizer, qui a l'air prometteur. Bonne journée. -- Cyril Davromaniak Lavier KeyID 59E9A881 http://www.davromaniak.eu --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Collecteur NetFlow ?
On 5 Jul 2012, at 09:50, Clement Cavadore wrote: par ailleurs c'est pas ce qu'il demande: collecte des flux, et leur analyse (répartition par ip, protocole temps dans la journée, analyse post-mortem en cas de DDoS etc.) Ooops ! je devrai apprendre a lire . pmacct should do the job. +1 Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Cohabition HSRP + VRRP
Le seul moyen - a ma connaissance - de faire bouger une IP sans gratuitious ARP est via la table de routage en changent le next-hop vers des IPs avec des ARP différentes, puis en acceptant la paquet sur la machine hôte (avec l'IP sur l'interface lo0 par exemple ou une règle sur le pare-feu). Le plus souvent un deamon OSPF ou BGP sur le serveur avec l'IP a annoncer. Et le coup de pub : comment ca se fait avec ExaBGP sous Linux : - http://thomas.mangin.com/data/pdf/UKUUG%20Spring%202011%20-%20Mangin%20-%20BGP.pdf Et comment scripter l'annonce et le retrait de routes : - http://thomas.mangin.com/data/pdf/RIPE%2063%20-%20Mangin%20-%20BGP.pdf Thomas On 21 Jun 2012, at 16:18, Baptiste wrote: L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et est annoncées au switch et aux autres hosts sur le LAN via le gratuitious. a+ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Monitoring / métrologie de centaines de liens ADSL
Je ne suis pas vendeur chez Firebrick. Peut-etre une idee a explorer :D Leur LNS fait un LCP ping (un ping au niveau L2TP, donc pas affecte par la banade passante utilise par le client) et retourne les resultat. De maniere reguliere AAISP (les meme gens) remontent vers BT des problemes de capacites qu'ils n'arrivent pas a voir eux-meme ... Lisez ce blog pour sourire et comprendre comment c'est utile. http://revk.www.me.uk/2012/06/can-bt-run-back-haul-network.html Thomas On 12 Jun 2012, at 10:21, Sebastien Lumineau wrote: Bonjour, Nous monitorons les bandes passantes d'environ 400 liens xDSL. Le principe est le suivant: - on charge le lien artificiellement pendant 10 secondes - on interroge en snmp la passerelle pour connaitre le nb d'octets qui ont transité par l'interface wan durant ce laps de temps - on en déduit la bande passante du lien à cette instant - on fait cette mesure chaque heure - les résultats sont remontées dans une base Posgres qui permet de nous sortir un graphe pour l'accès xDSL Voici un log type du script bash qui fait ça: Jun 11 16:15:02 monitor_debit v.1.4[8236]: Gateway: Cisco 878 (SDSL) at xxx.xxx.xxx.57 Jun 11 16:15:02 mesure_debit[8236]: Using http://xxx.xxx.xxx.43/DEBITEST.bigbig for bandwidth test Jun 11 16:15:02 mesure_debit[8236]: Using http://xxx.xxx.xxx.12/DEBITEST.bigbig for bandwidth test Jun 11 16:15:02 mesure_debit[8236]: Stream wget --quiet --cache=off --output-document /dev/null http://xxx.xxx.xxx.43/DEBITEST.bigbig started (pid=8302) Jun 11 16:15:02 mesure_debit[8236]: Stream wget --quiet --cache=off --output-document /dev/null http://xxx.xxx.xxx.12/DEBITEST.bigbig started (pid=8304) Jun 11 16:15:02 mesure_debit[8236]: Waiting 5 seconds before probing router... Jun 11 16:15:08 mesure_debit[8236]: Router xxx.xxx.xxx.57 first probe at 16:15:08... ok Jun 11 16:15:08 mesure_debit[8236]: Waiting 10 seconds before stopping load streams... Jun 11 16:15:18 mesure_debit[8236]: Router xxx.xxx.xxx.57 second probe at 16:15:18: ok Jun 11 16:15:18 mesure_debit[8236]: Stream 1 stopped Jun 11 16:15:18 mesure_debit[8236]: Stream 2 stopped Jun 11 16:15:18 monitor_debit v.1.4[8236]: Bandwidth download test done (108300 B/s) Comme l'interrogation se fait sur l'interface WAN de la gateway, on sait que l'on capture tout le trafic (contrairement à ce que l'on a quand on fait une mesure depuis une station où une partie du trafic peut nous échapper). Quand le modem xDSL ne répond pas au snmp (genre une livebox nouvelle génération pas sympa), on interroge la patte wan du firewall (=celui qui héberge le script); en général on préfère interroger le modem car il peut nous arriver d'avoir 2 firewalls pour un même accès DSL. Mais quand le firewall est tout seul, c'est pareil. Ca marche bien et le chargement du lien 1 fois par heure est indolore pour les utilisateurs. Parallèlement nous avons un graphe CACTI qui nous donne la charge du lien. Graphe de bande passante + graphe de charge = on est en mesure de savoir s'il y a des lenteurs parce que le lien est saturé ou si c'est parce que la bande passante n'est pas conforme. Sebastien - En réponse au message suivant - Date: lundi 11 juin 2012, 15h50 De: Baudin Maxime maxime.bau...@ac-rennes.fr Sujet: [FRnOG] [TECH] Monitoring / métrologie de centaines de liens ADSL Bonjour, Nous cherchons un moyen intelligent de monitorer des liens ADSL et surtout un moyen d'avoir de l'information sur la qualité/saturation de chaque liens. Le volume est de l'ordre de 300 à 600 liaisons (issues de n'importe quel opérateur a priori). J'explique peut-être un peu plus : J'ai, disons, un peu plus de 300 sites distants et un site principal Le site principal fournit du service numérique aux sites distants (Essentiellement des applications via un portail WEB) Le site principal a une connexion Gigabit loin d'être saturée. Les sites distants ont 1 ou 2 liens ADSL, avec des abonnements de type particuliers. Chaque site distant est autonome dans le choix de l'opérateur et du contrat qu'il souscrit (c'est comme ça, nous pouvons ergoter toute la nuit, c'est...comme ça). Par contre, le/les routeurs ADSL sont en mode bridge et la/les IP opérateurs arrivent sur un équipement réseau dont nous sommes propriétaire et que nous pouvons administrer et monitorer (ils supportent SNMPv3, nous ne l'avons pas activé pour le moment) Maintenant, nous aimerions avoir de la visibilité sur la qualité/saturation de chaque ligne. L'idée est de pouvoir affiner notre pré-diagnostique lorsqu'un site se plaint de lenteurs (par exemple), mais également de coupures ou autres problèmes imprévus. - Nous travaillons sur la mesure de performance sur la chaine applicative dans le datacenter mais nous manquons cruellement d'informations sur ce qui est hors de ce périmètre. - Nous envoyons des agents sur place à l'aveugle, ce qui est toujours désagréable
Re: [FRnOG] [TECH] Monitoring / métrologie de centaines de liens ADSL
Regarde le Firebrick http://www.firebrick.co.uk/fb6000/fb6102.php Sent from my iPad On 11 Jun 2012, at 14:50, Baudin Maxime maxime.bau...@ac-rennes.fr wrote: Bonjour, Nous cherchons un moyen intelligent de monitorer des liens ADSL et surtout un moyen d'avoir de l'information sur la qualité/saturation de chaque liens. Le volume est de l'ordre de 300 à 600 liaisons (issues de n'importe quel opérateur a priori). J'explique peut-être un peu plus : J'ai, disons, un peu plus de 300 sites distants et un site principal Le site principal fournit du service numérique aux sites distants (Essentiellement des applications via un portail WEB) Le site principal a une connexion Gigabit loin d'être saturée. Les sites distants ont 1 ou 2 liens ADSL, avec des abonnements de type particuliers. Chaque site distant est autonome dans le choix de l'opérateur et du contrat qu'il souscrit (c'est comme ça, nous pouvons ergoter toute la nuit, c'est...comme ça). Par contre, le/les routeurs ADSL sont en mode bridge et la/les IP opérateurs arrivent sur un équipement réseau dont nous sommes propriétaire et que nous pouvons administrer et monitorer (ils supportent SNMPv3, nous ne l'avons pas activé pour le moment) Maintenant, nous aimerions avoir de la visibilité sur la qualité/saturation de chaque ligne. L'idée est de pouvoir affiner notre pré-diagnostique lorsqu'un site se plaint de lenteurs (par exemple), mais également de coupures ou autres problèmes imprévus. - Nous travaillons sur la mesure de performance sur la chaine applicative dans le datacenter mais nous manquons cruellement d'informations sur ce qui est hors de ce périmètre. - Nous envoyons des agents sur place à l'aveugle, ce qui est toujours désagréable pour eux. - De même, nos gars ont l'impression de perdre leur temps pour un déplacement consistant parfois à lancer un simple speedmeter Notre supervision actuelle comprend un nagios en mode binaire : le site distant répond / ou pas. Auriez-vous une idée de la façon de mieux quantifier la qualité (relative) d'un lien ? en journée ? sur un abonnement qui, si je comprend bien, n'a aucune garantie de débit ? Nous pourrions grapher les débits et, constater une saturation lorsqu'un graphe est plat, indépendamment du débit constaté ? En ce cas comment remonter une alerte ? Mettre en place un speedmater like, régulier, pour notre infrastructure est-il, par exemple, une idée à creuser ? - le problème est que c'est une mesure échantillonnée, qui a en plus un impact direct sur la saturation de la ligne. Bien entendu se posera la question de lier ce monitoring à un outils permettant d'avoir des vues claires, pour notre équipe de helpdesk par exemple et nos équipes de terrain également. Je fais donc appel à votre expérience pour m'ouvrir les yeux Cordialement, Maxime --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Le jour où internet a changé
Je ris assez doucement quand je vois la marque avec la couleur du fruit (non pas apple) qui a mis juste son zoli site web en IPv6, mais par contre le mail... oula... il reste toujours en IPv4. Passer ses SMTP en IPv6 aucun problemes, par contre les serveurs MX resteront surement en IPv4 a cause du SPAM. La première ligne de défense anti spam sont base sur de la reputation des IP, en IPv6 cela ne marche plus trop. Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Le jour où internet a changé
Après une RBL c'est pas non plus ce qu'il y a mieux en terme de collateral damage... Nous ne parlions pas de RBL mais de base de réputation. Une RBL est une des forme de réputation :) Laissons sortir le troll pour le week-end :) Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Le jour où internet a changé
Salut Stephane, Ce qui est sûr, c'est que quand on ne veut pas bouger, on trouve facilement des tas d'excuses (tiens, il y a peut-être même un business plan pour ma future boîte de consulting, fournir des excuses pour ne pas migrer vers IPv6). Je te sens agressif ! Mon reseau est dual stack depuis des annees. Mes DNS sont dual stack depuis des annees. Mon site web est IPv6 depuis des annees. Les sites tous mes clients sont IPv6 depuis le 6. On va donner a tous nos clients DSL une IPv6 en standard nous avons rate le 6 ! Mais ce n'est pas vrai du tout. Les serveurs MX de l'AFNIC ont IPv6 depuis des années et la quasi-totalité du spam est reçue en v4, comme avant. Tous les bots sont encore IPv4 only ?? !! C'est scandaleux que les voleurs ne soit pas a la pointe de la technologie :D Mais quand tu as _UN_ serveur IPv6 qui te blaste du mail il te faut un système pour vérifier : - l'historique de fréquence d'envoi (de jamais vu a 100 message par secondes, etc) - le ratio spam/ham de l' IP - ... Bref la reputation de l'IP. Notre système maison n'est pas encore IPv6. IPv6 devra donc attendre un peu pour le MX, car le problème je l'ai vu passer une fois et tant que mon système anti-spam interne est v4 only mes MX resterons v4 only. C'est a faire : oui C'est dur : non C'est urgent : non Mettre ses serveurs mail en IPv6 sans mesure anti-spam, surement l'affaire de moins d'une heure mais comme tu le dis .. Il n'a pas de trafic ! :D La première ligne de défense anti spam sont base sur de la reputation des IP, en IPv6 cela ne marche plus trop. Parce qu'en IPv4, ça marche ? Incroyable mais oui ! Enfin le mien marche plutôt bien - en conjonction avec plein d'autres tests - pour les offres commerciales .. aucune idée. Les éradicateurs du service de messagerie de Microsoft (liste noire utilisée par d'autres fournisseurs comme Equant) ont blacklisté les serveurs de l'AFNIC et n'ont jamais fourni aucune explication. Bienvenu dans le monde SMTP - mais quel est le rapport avec IPv6 ? Bon week-end, Thomas signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [FRnOG] [MISC] Un datacenter autonome en énergie
Euh.. C'est plus deux tiers un tiers. Thomas On 7 Jun 2012, at 20:30, Radu-Adrian Feurdean wrote: On Thu, 7 Jun 2012 20:58:44 +0200, Arnaud Fenioux afeni...@gmail.com said: On pourrait imaginer d'en faire 1 sur 2 en dehors de Paris (en rêve oui je sais ;) Il me semble que chez les anglais il font exactement ca avec UKNOF : un a Londres, un ailleurs. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Un datacenter autonome en énergie
De plus il a besoin de la grille pour ses besoins en heure creuses. En assumant que le DC vende a midi l'energie qui va acheter a minuit - il faut toujours une grille qui puisse générer cette energie, et elle ne sera surement pas eolienne. Donc il reduit la pollution mais pas au dela du seuil de ses besoins en heures creuses - ce qui est mieux mais n'est clairement pas un cout zero .. L'article n'est pas objectif du tout dans ses conclusions et ses headlines. Thomas On 5 Jun 2012, at 02:33, Jérémie Bouillon wrote: On 04/06/2012 19:59, Sebastien WILLEMIJNS wrote: http://www.usinenouvelle.com/article/hp-imagine-un-datacenter-autonome-en-energie.N175858#xtor=EPR-169 Deux remarques : - D'abord ce datacenter n'est pas neutre en énergie, à coût zéro comme ils le disent. Il a faut construire le datacenter, construire et acheminer les serveurs et équipements, les remplacer petit à petit, et on pourrait ainsi en rajouter beaucoup. Sa consommation en énergie à l'usage pour l'alimentation des équipements et le refroidissement est nul, c'est très différent (mais moins marketing je suppose). - Ensuite, ce n'est pas «un datacenter» point, sous-entendu comme les milliers d'autres à travers le monde. Il héberge des besoins spécifiques, compatibles avec sa prédiction énergétique. S'il loue par exemple des baies pour serveur web, un bon slashdottage au mauvais moment pourrait poser des soucis (d'après ce qui n'est pas dit dans le texte, je n'ai pas été voir sur place). Ceci étant dit, c'est toujours ça, et c'est intéressant. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
