Re: [FRnOG] [MISC] #Brexit et conséquences

[Thomas Mangin]

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

[Thomas Mangin]

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

[Thomas Mangin]

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

[Thomas Mangin]

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

[Thomas Mangin]

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

[Thomas Mangin]

On 28 Jul 2014, at 15:40, Greg Villain  wrote:

> On Jul 28, 2014, at 1:51 AM, Thomas Mangin  
> 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

[Thomas Mangin]

Une petite souris me dit que la presentation est marquée comme publique :
https://www.linx.net/archive/linx84/pdf/LINX84-BSkyB-AndyFurnell.pdf

Thomas



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [FRnOG] [MISC] Netflix in France

[Thomas Mangin]

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.

> - Le traffic devrait être gratos pour le gestionnaire de l'appliance,
> car il est placé là où ca arrange le plus l'opérateur en question (et
> l'opérateur controle la zone arrosée par l'appliance, au moyen
> d'annonces BGP)

Il n'est pas toujours possible de mettre l'appliance ou elle devrait être 
idéalement ( espace, kw disponible,capacité du réseau, etc. )
L'appliance est parfois en private peering, parfois dans le coeur, mais 
rarement très près de l'edge car il faut pouvoir l'utiliser aussi en cas de 
panne d'autres nodes, et il faut pouvoir re-router (et avoir la capacité) en 
cas de problèmes.

Sky a fait une très bonne presentation sur le sujet at LINX 84 ( si vous avez 
quelqu'un pour vous la rechercher dans la partie "membre" du site, le PDF et la 
video sont disponibles )

> - Le housing devrait être payé par le gestionnaire de l'appliance, car
> ya pas de raisons que l'opérateur assume pour le compte de sites tiers,
> des charges en electricité/clim/etc

A ce que je comprends ( et ce n'est pas mon metier ) - il faut aussi prendre en 
compte les economies ( ou pas ) faites par les deux parties.
Si le seul résultat est une meilleur latence pour le CDN, je ne pense pas que 
le FAI prenne a sa charge ce cout.

> --> On en reviendrait à un modele de "cache régionaux" + "peering
> régionaux", en quelque sorte... Un moyen intelligent de remplir les
> cogent/netcenter/autres en région ?? 

Le peering regional, cela fait quelques temps que LINX le pousse en Angleterre 
et ce n'est pas si simple. Il faut de longues discussions avec les architectes 
réseaux des "gros" pour comprendre pourquoi ce n'est pas toujours evident du 
tout pour tout le monde de retourner vers ce modèle. Comme ces discussions sont 
privées, n'espérez pas les trouver sur FRnOG ...

Thomas



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [FRnOG] [MISC] Netflix in France

[Thomas Mangin]

ai -> ait ,  base -> basse.
Thomas -> se cache.

Thomas

On 24 Jul 2014, at 08:13, Thomas Mangin  
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"  
>> 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] [MISC] Netflix in France

[Thomas Mangin]

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"  
> 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] [TECH] Statut adresses IPv4 .0

[Thomas Mangin]

On 23 Jul 2014, at 08:00, Vincent Bernat  wrote:

> ❦ 23 juillet 2014 07:53 +0100, Thomas Mangin 
>  :
> 
>> 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] [TECH] Statut adresses IPv4 .0

[Thomas Mangin]

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  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  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] [MISC] A propos des ondes radio

[Thomas Mangin]

> 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

[Thomas Mangin]

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  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

[Thomas Mangin]

On 15 Mar 2014, at 18:27, Michel Py  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 ?

[Thomas Mangin]

On 5 Mar 2014, at 15:56, Xavier Beaudouin  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] [TECH] Gamme Juniper ?

[Thomas Mangin]

> 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] [MISC] FRNOG 22.0 - RC1

[Thomas Mangin]

Troll : il manque la separation IPv6 link local et IPv6 routable 

Sent from my iPad

> On 1 Mar 2014, at 09:01, Philippe Bourcier  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] [TECH] Scripts TCL / Cisco IOS

[Thomas Mangin]

>>> 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] [TECH] Scripts TCL / Cisco IOS

[Thomas Mangin]

> [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] [MISC] FRNOG 22.0 - RC1

[Thomas Mangin]

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] [ALERT] Ralentissements chez Axione

[Thomas Mangin]

On 12 Feb 2014, at 17:16, MoncefZID  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] [ALERT] Ralentissements chez Axione

[Thomas Mangin]

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  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  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

[Thomas Mangin]

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  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] [MISC] La salle de contrôle de l'Internet

[Thomas Mangin]

On 11 Feb 2014, at 09:37, Emmanuel Jacquet  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

[Thomas Mangin]

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  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
>> a é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 ?

[Thomas Mangin]

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  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 ?

[Thomas Mangin]

On 28 Oct 2013, at 18:44, Florent Rivoire  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] Bonnes pratiques de configuration de BGP

[Thomas Mangin]

Sent from my iPad

> On 5 Oct 2013, at 14:54, Jérôme Nicolle  wrote:
> 
> Une autre pratique que j'ai déjà tenté sans problème opérationnel, mais pour 
> laquelle je suis preneur de feedback : quand les interfaces d'intercos sont 
> capables de le traiter en 100% hardware, j'applique une ACL qui filtre, pour 
> tout paquet à destination des préfixes utilisés dans l'adressage du backbone, 
> et provenant de l'extérieur de mon réseau, les paquets IP et IPv6 TCP à 
> destination des ports 22, 23 et 179.

Oui, tu n'es pas le seul.

Tu peux aussi faire tomber tous packets avec une IP source de ton backbone - 
surtout quand ton peer ne respecte pas BCP 38.

J ai meme essaye encore plus fou.
http://thomas.mangin.com/posts/bgp-firewall.html

En theorie genial, en pratique en 2004 sur les M7i c etait pas encore la : 
packets loss quand on passait plus de 50 Mb de traffic. Je vais devoir 
reessayer avec les MX ... 

Thomas
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Juniper NSM

[Thomas Mangin]

On 5 Oct 2013, at 10:18, Michel Py  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] Question pour barbus

[Thomas Mangin]

Des fois ca peut-etre un bug des drivers d'une cartes réseaux ...
Comme dans ce cas .. http://blog.krisk.org/2013/02/packets-of-death.html et 
http://blog.krisk.org/2013/02/packets-of-death-update.html

Thomas

On 4 Oct 2013, at 20:06, Jérémy Martin  wrote:

> Bonsoir,
> 
> On a un cas de pertes de trame TCP sur notre réseau qui est inexplicable et 
> sur lequel nous séchons, ainsi que SFR (pour la partie L2L).
> 
> Pour faire simple, les trame TCP port 22 et 21 (a priori, celles qui ont 
> besoins que les ACK ne soient pas perdu sous peine de forts lags) sont perdus 
> à hauteur de 5-10 % en cas de stress important de notre L2L (et uniquement à 
> cet endroit a priori).
> 
> Ce qui est très très surprenant, c'est que j'ai 2 serveurs sur le même /24, 
> avec le même kernel (debian), et a priori la même conf réseau.
> Sur l'un, on a énormément de :
> 152267 30.163305000AA.BB.CC.DD 192.168.1.17TCP106[TCP 
> Retransmission] 14558 > 52629 [PSH, ACK] Seq=205 Ack=365 Win=148 Len=52
> 
> Vous remarquerez de plus que j'utilise ici un port spécifique et que le 
> problème se produit autant en 14558 qu'en port 22.
> 
> Sur l'autre serveurs, vraiment les mêmes conditions de test, AUCUNE PERTE !
> Le HTTP et les protocoles de jeux, ou RDP ne sont absolument pas 
> touchés(aucune perteégalement).
> 
> Là je sèche vraiment. Un paramètre dans le kernelpourrait générer les 
> échanges en SSH ou FTP ?
> 
> Ce dont je suis sur :
> 1) Pas de QoS sur le L2L (officiellement, après je ne sais pas ce que fait 
> SFR dans son MPLS)
> 2) Pas de rate-limit ou QoS sur les routeurs d'un coté à l'autre du L2L (conf 
> neutres).
> 3) Pas de pertes sur le switch
> 
> Bref, si quelqu'un a déjà rencontré un cas de ce type, je suis preneur.
> Merci pour votre attention,
> 
> -- 
> Cordialement,
> Jérémy Martin
> 
> 
> __
> FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle !
> PHP + Mysql + Espace 2 à 20 Go
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [TECH] Bonnes pratiques de configuration de BGP

[Thomas Mangin]

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  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

[Thomas Mangin]

On 7 Sep 2013, at 11:46, Stephane Bortzmeyer  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

[Thomas Mangin]

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  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] BGP software

[Thomas Mangin]

On 2 Sep 2013, at 17:15, Jérôme Nicolle  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] Un routeur de cœur de réseau peut-il espionner le trafic ?

[Thomas Mangin]

On 1 Jul 2013, at 19:01, Kavé Salamatian  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 ?

[Thomas Mangin]

On 26 Jun 2013, at 11:18, Jérôme Nicolle  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

[Thomas Mangin]

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  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 
> À : frnog-ow...@frnog.org; Antoine Durant  
> Cc : "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

Re: [FRnOG] [TECH] trafic shaping sur linux

[Thomas Mangin]

tocol 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  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 
> À : frnog-ow...@frnog.org; Antoine Durant  
> Cc : "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  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

[Thomas Mangin]

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  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] contact postmaster OVH

[Thomas Mangin]

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  wrote:

> Salut Xavier,
> 
> 
> On Thu, Apr 04, 2013 at 11:49:42AM +0200, Xavier Beaudouin wrote:
>> Le 4 avr. 2013 à 11:37, Sylvain Rochet  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 " (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  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 ?

[Thomas Mangin]

On 12 Mar 2013, at 21:20, Serge Marienon  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] [MISC] ARCEP vs. Skype : clarification ?

[Thomas Mangin]

On 12 Mar 2013, at 20:17, Laurent Cima  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.   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. 

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+skype&oq=telephone+skype&tbm=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] [JOBS] Offre de sysadmin linux en alternance ou CDI débutant sur Paris

[Thomas Mangin]

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  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  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 ?

[Thomas Mangin]

On 1 Feb 2013, at 15:37, Aurélien Guillaume  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] [TECH] BGP et IPv6 (uniquement) : comment choisir son router ID ?

[Thomas Mangin]

> 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] [BIZ] Agregation de liens internet

[Thomas Mangin]

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  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] [BIZ] Agregation de liens internet

[Thomas Mangin]

On 23 Jan 2013, at 18:10, sxpert  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] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]

[Thomas Mangin]

+1

On 10 Jan 2013, at 11:08, David Ramahefason  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  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] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]

[Thomas Mangin]

>> 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] Re: [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]

[Thomas Mangin]

( 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]

[Thomas Mangin]

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  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] [TECH] Forwarding de session L2TP

[Thomas Mangin]

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

[FRnOG] Re: [TECH] Sécurité du routage BGP et Avenir de la Télématique

[Thomas Mangin]

>> http://thomas.mangin.com/posts/asn-or-community.html

Avec le / .

Sent from my iPad

On 9 Jan 2013, at 10:45, Stephane Bortzmeyer  wrote:

> On Wed, Jan 09, 2013 at 09:31:23AM +,
> Thomas Mangin  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] Sécurité du routage BGP et Avenir de la Télématique

[Thomas Mangin]

On 9 Jan 2013, at 09:19, Dominique Rousseau  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/

Re: [FRnOG] [MISC] Frnog et profs/chercheurs/écoles [Was: Le routage, enjeu de cyberstratégie]

[Thomas Mangin]

On 9 Jan 2013, at 08:56, Stephane Bortzmeyer  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] [MISC] Mieux que l'HADOPI, Free !

[Thomas Mangin]

On 4 Jan 2013, at 14:33, sxpert  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 !

[Thomas Mangin]

> 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] [MISC] Mieux que l'HADOPI, Free !

[Thomas Mangin]

>> 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] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

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  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)

[Thomas Mangin]

On 21 Dec 2012, at 14:23, Simon Perreault  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] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

[Thomas Mangin]

On 21 Dec 2012, at 11:21, Emmanuel Thierry  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)

[Thomas Mangin]

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  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  
> ("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 
> j

Re: [FRnOG] [TECH] NAT IPv6 dans Linux 3.7

[Thomas Mangin]

On 14 Dec 2012, at 17:38, Mathieu Goessens  wrote:

> On Wed, 12 Dec 2012 10:55:37 +0100, Emmanuel Thierry  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] [FRNOG] [TECH] Solution Wifi moyenne échelle

[Thomas Mangin]

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  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] [ALERT] Session BGP down

[Thomas Mangin]

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  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

[Thomas Mangin]

Sent from my iPad

On 3 Nov 2012, at 21:39, Raphaël Maunier  
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

[Thomas Mangin]

Sent from my iPad

On 29 Oct 2012, at 19:33, Manuel Guesdon  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] [TECH] Routeurs BGP : Conseil de topologie

[Thomas Mangin]

Sent from my iPad

On 29 Oct 2012, at 19:21, "Radu-Adrian Feurdean" 
 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

[Thomas Mangin]

Sent from my iPad

On 29 Oct 2012, at 18:39, Jérôme Nicolle  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] [MISC] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

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  wrote:

> On Mon, 1 Oct 2012 16:56:14 +0200, Pascal Rullier 
> 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] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

On 28 Sep 2012, at 14:04, Nicolas CARTRON  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/

[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

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

[FRnOG] Re: [TECH] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

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

Re: [FRnOG] [TECH] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

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

Re: [FRnOG] [TECH] Apres la fin du dernier /8 ipv4

[Thomas Mangin]

On 28 Sep 2012, at 10:19, Arnaud Fenioux  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] Sup720-3BXL et préfixes v4

[Thomas Mangin]

> 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] Sup720-3BXL et préfixes v4

[Thomas Mangin]

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  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  
> 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  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" 
> > À: 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: [TECH] UBNT EdgeMax, was: Re: [FRnOG] [TECH] Sup720-3BXL et préfixes v4

[Thomas Mangin]

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  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

[Thomas Mangin]

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  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" 
> À: 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: [FRnOG] [MISC] Téléphones et paranoïa

[Thomas Mangin]

>> - 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

[Thomas Mangin]

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  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

[Thomas Mangin]

> 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] Detecter DDos outils et null-router sur quagga

[Thomas Mangin]

On 6 Sep 2012, at 14:11, Alain Thivillon  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] VoIP / plan de numérotations

[Thomas Mangin]

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  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 ?

[Thomas Mangin]

Lire 38 pas 78 Merci l iPad !

Sent from my iPad

On 29 Aug 2012, at 22:09, Thomas Mangin  
wrote:

> 
> 
> Sent from my iPad
> 
> On 29 Aug 2012, at 21:01, "Radu-Adrian Feurdean" 
>  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] Probléme sur l'Internet Européen ?

[Thomas Mangin]

Sent from my iPad

On 29 Aug 2012, at 21:01, "Radu-Adrian Feurdean" 
 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 ?

[Thomas Mangin]

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  
wrote:

> 
> Le 29 août 2012 à 21:38, Thomas Mangin 
> a écrit :
> 
>> 
>> On 29 Aug 2012, at 20:37, "Radu-Adrian Feurdean" 
>>  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 ?

[Thomas Mangin]

On 29 Aug 2012, at 20:37, "Radu-Adrian Feurdean" 
 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 ?

[Thomas Mangin]

> 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] Load Balancer IPV4/IPV6

[Thomas Mangin]

> 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

[Thomas Mangin]

>> 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] Retours sur un nouveau proxy ??

[Thomas Mangin]

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

[Thomas Mangin]

On 24 Aug 2012, at 13:02, Guillaume Barrot  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] Collecteur NetFlow ?

[Thomas Mangin]

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] Collecteur NetFlow ?

[Thomas Mangin]

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  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] Cohabition HSRP + VRRP

[Thomas Mangin]

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] Cohabition HSRP + VRRP

[Thomas Mangin]

Tout marche bien tant que tes deux routers acceptent les packets "gratuitous 
arp" des serveurs quand l'IP de service bouge.
De mémoire sur les équipements que j'ai vu, le default chez Juniper est bloque, 
Cisco accepte. De plus l'option est parfois par interface et non par VLAN.

Thomas

On 21 Jun 2012, at 10:36, Germain Maurice wrote:

> Salut tout le monde,
> 
> J'ai une baie avec un transit IP sur un lien actif/passif moyennant 
> l'utilisation de 2 switchs + du HSRP, ça fonctionne bien, pas de souci.
> J'aimerais sur cette infra pouvoir mettre en place du 2 HAproxy avec du VRRP 
> entre les deux.
> Est-ce que la cohabitation des 2 normes est bien possible en sein d'un même 
> réseau ?
> 
> Merci à vous !
> 
> ---
> 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

[Thomas Mangin]

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 A&AISP (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 
> 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 

Re: [FRnOG] [TECH] Monitoring / métrologie de centaines de liens ADSL

[Thomas Mangin]

Regarde le Firebrick 
http://www.firebrick.co.uk/fb6000/fb6102.php

Sent from my iPad

On 11 Jun 2012, at 14:50, "Baudin Maxime"  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/