Re: [FRnOG] Re: [MISC] DSAV Project: sérieux ou scam ?

2020-10-13 Par sujet Baptiste Jonglez 
Bonjour,

Pour information, on a déjà publié plusieurs papiers cette année sur cette
problématique, avec exactement la même méthodologie (envoi de requête DNS
avec spoof d'adresse source).

Le site du projet est là : http://www.closedresolver.com/

L'article de blog : 
https://blog.apnic.net/2020/10/05/are-you-filtering-for-inbound-spoofed-packets-chances-are-youre-not/

Et les papiers pour les plus motivés : http://www.closedresolver.com/#papers

On avait prévu envoyer des notifications aux réseaux affectés, mais ils
ont été plus rapides que nous !

On 13-10-20, Stephane Bortzmeyer wrote:
> > D’ailleurs, on devrait leur demander qui est leur ISP à cette
> > université :)
> 
> Il est logique que les chercheurs en sécurité aient un accès spécial,
> permettant des tests rigolos.

En réalité, faire ce genre de manip sur les réseaux d'université, c'est
trop compliqué, il a fallu trouver autre chose...

Baptiste


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] OSPF Bird et configure

2020-01-16 Par sujet Baptiste Jonglez 
Bonjour,

Je ne vois pas ce que le passage à Bird 2 apporte dans ce cas.  Tu veux
juste redistribuer certaines routes du kernel vers OSPF, mais il te faut
un moyen de les identifier.

Tu peux matcher sur tous les attributs génériques de routes décrits ici :

  https://bird.network.cz/?get_doc=16=bird-5.html#ss5.5 (bird 1.6)
  https://bird.network.cz/?get_doc=20=bird-5.html#ss5.5 (bird 2.0)

+ ceux du protocole kernel (faut scroller un peu) :

  https://bird.network.cz/?get_doc=16=bird-6.html#ss6.6


Le plus simple est probablement d'utiliser krt_source qui correspond au
"proto" de iproute2 (cf. /etc/iproute2/rt_protos), ça ressemble à ça :

- ajouter une route dans ton automatisation : "ip route replace XXX/X via YYY 
proto 142"
  (j'utilise "replace" au lieu de "add" pour écraser une éventuelle route
  existante, à toi de voir ce que tu préfères dans ce cas)

- importer ces routes dans le proto kernel : soit "import all" soit plus
  précis "import where krt_source = 142"

- exporter ces routes dans le proto OSPF : "export where krt_source = 142"

Si tu exportais vers BGP, ce serait une bonne idée de mettre une
communauté pour que tous tes routeurs sachent d'où vient la route, ça
ressemblerait à ça :

filter kernel_import {
if krt_source = 142 then {
bgp_community.add((ton_AS, 142));
accept;
}
reject;
}

protocol kernel {
...
import filter kernel_import;
}

filter bgp_export {
 ...
 if filter(bgp_community, [(ton_AS, 142)]).len > 0 then accept;
 reject;
}

protocol bgp {
...
export filter bgp_export;
}


On fait un truc du genre pour le blackhole, il suffit d'ajouter une route
/32 dans le kernel (avec le bon proto) pour qu'elle soit propagée en BGP à
tous les transitaires avec la communauté de blackhole qui va bien.  C'est
la même conf que Gitoyen dispo ici :

  
https://code.ffdn.org/gitoyen/bird-config/blob/master/etc/local/bird/common/bgp-filters.conf#L134

Baptiste

On 16-01-20, Duchet Rémy wrote:
> L'objectif c'est justement que Bird apprenne les routes via autre chose que 
> "STATIC".  Aujourd'hui c'est un script qui modifie un simple fichier, via de 
> l'automatisation. Et c'est STATIC => OSPF . 
> Mais dans ce sens pour ajouter une route dans la table STATIC, ça demande le 
> "configure" pour que la route soit active pour Bird. Et donc le changement de 
> la table STATIC provoque la propagation de l'intégralité de la table OSPF à 
> tous les autres devices. 
> 
> Pour la partie BGP je n'ai pas de soucis, d'autant que c'est un de nos RS.
> Par contre, dans la 2.0.7 Ipv4 et IPv6 c'est le même process. Et c'est les 
> TABLE qui semblent séparer les versions, du coup toute la config change. 
> 
> Cordialement,
> 
> Rémy 
> 
> -Original Message-
> From: Alarig Le Lay  
> Sent: jeudi, 16 janvier 2020 17:49
> To: Duchet Rémy 
> Cc: frnog@frnog.org
> Subject: Re: [FRnOG] [TECH] OSPF Bird et configure
> 
> What ?!
> 
> bird> show route
> Table master4:
> 0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10)
> via 85.166.184.1 on enp2s0
> 45.91.126.32/28  unicast [ospf_ipv4 09:47:05.225] E1 (150/20) 
> [45.91.126.96]
> via 45.91.126.96 on enp3s0.50
> 79.170.80.128/25 unicast [ospf_ipv4 10:10:59.225] E2 (150/10/64) 
> [4faa50fa] [45.91.126.236]
> via 45.91.126.236 on tinc0
> […]
> bird> show route protocol kernel_ipv4
> Table master4:
> 0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10)
> via 85.166.184.1 on enp2s0
> 85.166.184.0/22  unicast [kernel_ipv4 09:46:49.133] (10)
> dev enp2s0
> bird> show route protocol kernel_ipv6
> Table master6:
> ::/0 unicast [kernel_ipv6 09:46:49.133] (10)
> via fe80::5e5e:abff:fe43:1ece on enp2s0
> 2001:4640:a14f::/48  unreachable [kernel_ipv6 09:46:49.133] (10)
> 
> J’ai bien des routes OSPF et bird ne les apprend pas via le kernel. Je ne 
> vois pas comment ça pourrait marcher s’il le faisait d’ailleurs.
> 
> Et en version BGP (avec une full) c’est pareil :
> 
> bird> show route
> 128.0.128.0/20 via 89.234.186.33 on vmbr12 [ibgp_asbr01_ipv4 2020-01-04] 
> * (100/?) [AS25513i]
>via 89.234.186.33 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11 
> from 89.234.186.34] (100/?) [AS25513i]
> 208.0.208.0/24 via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] 
> * (100/20) [AS46559i]
>via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 
> from 89.234.186.33] (100/20) [AS46559i]
> 40.0.40.0/24   via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] 
> * (100/20) [AS4249i]
>via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 
> from 89.234.186.33] (100/20) [AS4249i] […]
> bird> show route protocol kernel1
> 89.234.186.114/32  dev tap109i0 [kernel1 2019-09-29] * (10)
> 89.234.186.115/32  dev tap106i0 [kernel1 2019-09-29] * (10)
> 80.67.190.218/32   dev tap140i0 [kernel1

Re: Re[2]: [FRnOG] [TECH] Convertisseurs VDSL2

2020-01-11 Par sujet Baptiste Jonglez 
Bonjour,

J'ai lu qu'il n'y avait pas de management, est-ce qu'il est quand même
possible de choisir le profil ? (17a plutôt que 30a)

Je pose la question parce qu'il est visiblement souvent vendu en 30a par
défaut :

https://planet.com.tw/en/product/vc-231
https://www.abix.fr/planet-vc-231-convertisseur-vdsl2-rj45-rj11-30a-410231.html
https://www.cdiscount.com/informatique/composants-informatiques/planet-vc-231-convertisseur-vdsl2-rj45-rj11-30a/f-107130602-auc4711213687242.html

Au passage, ça a l'air pas évident à trouver neuf à un prix pas
déraisonnable, quelqu'un aurait des fournisseurs à conseiller en France ?
Le prix est presque raisonnable chez Abix mais ils ont pas l'air de
l'avoir en stock.

Merci,
Baptiste

On 22-11-19, Alexis Guirlé wrote:
> Bonjour,
> 
> Pour nous, on en a plusieurs en service et j’en ai pris 4 au piff qui sont up 
> depuis le 20 Mai 2019 (Leur installation)
> 
> Donc c’est parfait.
> 
> Cordialement,
> Alexis
> 
> De : valen...@brasserie-du-slalom.fr 
> Envoyé : vendredi 22 novembre 2019 10:35
> À : BASSAGET Cédric 
> Cc : Alexis Guirlé ; Pierre-Loïc Carette - ALPESYS 
> ; frnog-t...@frnog.org; David Ponzone 
> 
> Objet : Re[2]: [FRnOG] [TECH] Convertisseurs VDSL2
> 
> 
> Salut,
> 
> Je suis plus sur la liste donc tu peux fwd ma réponse, mais ici aucun soucis, 
> j'ai juste programmé un reboot du microtik si l'interface n'est pas up en 2 
> minutes. Je n'ai pas l'impression qu'il reboot (j'entends jamais le bip du 
> démarrage du microtik).
> 
> Valentin
> 
> --
> Envoyé depuis l'application myMail pour Android
> vendredi, 22 novembre 2019, 10:24AM +01:00 de BASSAGET Cédric 
> cedric.bassaget...@gmail.com:
> 
> 
> Bonjour,
> Déterrage du vendredi !
> Est-ce que quelqu'un peut faire un retour sur la stabilité du VC-231 ? Ou 
> est-ce que vous avez trouvé d'autres modèles de pur modem vdsl2 ?
> Merci et bon week end à tous et toutes !
> Cédric
> 
> Le mar. 23 avr. 2019 à 09:40, David Ponzone 
> mailto:david.ponz...@gmail.com>> a écrit :
> Ok ensuite, faut voir combien de temps ça tient sans reboot.
> 
> David Ponzone
> 
> 
> 
> > Le 23 avr. 2019 à 10:30, Alexis Guirlé 
> > mailto:agui...@izarlink.com>> a écrit :
> >
> > Bonjour,
> >
> > Bon on a testé ^^.
> >
> > Et ceci marche plutôt bien. En sélectionnant le mode CPE et le bon profil 
> > (17A).
> >
> > Bonne semaine.
> > Alexis
> > -Message d'origine-
> > De : Valentin Surrel 
> > mailto:valen...@brasserie-du-slalom.fr>>
> > Envoyé : jeudi 18 avril 2019 07:48
> > À : Pierre-Loïc Carette - ALPESYS 
> > mailto:plcare...@alpesys.fr>>
> > Cc : Alexis Guirlé mailto:agui...@izarlink.com>>; 
> > David Ponzone mailto:david.ponz...@gmail.com>>; 
> > frnog-t...@frnog.org
> > Objet : Re: [FRnOG] [TECH] Convertisseurs VDSL2
> >
> > Bonjour,
> >
> > Mon petit doigt me dit que le VC-231 fonctionne très bien avec les DSLAM 
> > télécom. Ce mail en est la meilleure preuve ! C'est un bon moyen de mettre 
> > un "vrai" routeur à la maison ou au boulot (et c'est stable). Perso, ça me 
> > permet de faire un vpn site-to-site à pas cher.
> >
> > Il chauffe un peu par contre, à étudier si c'est pour en faire une armoire 
> > complète.
> >
> > Valentin
> >
> > - Mail original -
> >> De: "Pierre-Loïc Carette - ALPESYS" 
> >> mailto:plcare...@alpesys.fr>>
> >> À: "Alexis Guirlé" mailto:agui...@izarlink.com>>, 
> >> "David Ponzone"
> >> mailto:david.ponz...@gmail.com>>
> >> Cc: frnog-t...@frnog.org
> >> Envoyé: Lundi 15 Avril 2019 21:56:46
> >> Objet: Re: [FRnOG] [TECH] Convertisseurs VDSL2
> >
> >> Hello
> >> J'ai un gros doute que ce convertisseur fonctionne sur des DSLAM telecom.
> >> Si ca le fait ca serait avec des degradations de service car ces
> >> boitiers ne gerent qu'un nombre minimal d'annexes DSL (type de synchro).
> >> D'ailleurs les annexes se gèrent manuellement pour certaines avec des
> >> dip switchs.
> >>
> >> Ces boitiers sont fait pour faire de l'ethernet sur une paire de
> >> telephone jusqu'à 1km environ avec un boitier en maitre l'autre en CPE.
> >>
> >>
> >>
> >> Pierre-Loïc Carette
> >>
> >>
> >> Please excuse any errors as this is being sent from my mobile
> >>
> >>
> >>
> >> De : David Ponzone
> >> Envoyé : lundi 15 avril à 18:09
> >> Objet : Re: [FRnOG] [TECH] Convertisseurs VDSL2 À : Alexis Guirlé Cc :
> >> frnog-t...@frnog.org
> >>
> >>
> >> En théorie ça marche mais pas de mgmt, pas de reboot soft. David
> >> Ponzone > Le 15 avr. 2019 à 18:03, Alexis Guirlé a écrit : > >
> >> Bonjour, > > Quelqu'un a-t-il déjà utilisé des convertisseurs VDSL2
> >> Planet, genre VC-231 avec des DSLAM d'Orange ? > On cherche des modems
> >> VDSL 2 style industriel, ultra basic qu'on pourrai rack en masse... >
> >>> Cordialement, > > Alexis > > >
> >> --- > Liste de diffusion du FRnOG >
> >> http://www.frnog.org/ --- Liste de diffusion
> >> du FRnOG

Re: [FRnOG] [TECH] Un TTL qui varie sans raison

2020-01-04 Par sujet Baptiste Jonglez 
On 03-01-20, Stephane Bortzmeyer wrote:
> Le TTL change à chaque paquet.
> 2) Quel équipement ferait ça, et pourquoi ?

Vraisemblablement le serveur lui-même.  Très certainement pour le fun, ou
pour que des ingénieurs et chercheurs se posent trop de questions :)

En tout cas, le TTL des paquets retours est stable en TCP, donc c'est un
comportement spécifique à l'ICMP.

En analysant rapidement les TTLs observés (merci Perl [1] pour l'histogramme 
rapide) :

$ ping -c 500 -i 0.2  114.114.114.114 | sed -nr 's/.*ttl=([0-9]*).*/\1/p' | 
sort -n | uniq -c | perl -lane 'print $F[1], "\t", "*" x $F[0]'
50 ***
51 *
52 
53 
54 *
55 
56 ***
57 *
58 
59 *
60 
61 
62 **
63 *
64 **
65 **
66 ***
67 ***
68 **
69 *
70 **
71 ***
72 
73 ***
74 
75 
76 **
77 *
78 **
79 ***
80 **
81 **

Les TTLs ont donc l'air d'être tirés de façon à peu près uniforme.

En TCP j'ai un TTL retour de 42, donc en supposant qu'ils partent à 64 ça
fait un décalage de 22 : ils tirent donc les TTLs uniformément entre 72 et 103.

C'est possible de faire quelque chose d'approchant avec iptables (man 
iptables-extensions) :

for ttl in {0..31}
do
  iptables -t mangle -A OUTPUT -p icmp --icmp-type echo-reply -m statistic 
--mode nth --every 32 --packet $ttl -j TTL --ttl-set $((ttl+72))
done

Là ça donne des TTL dans l'ordre, mais en cherchant un peu on doit pouvoir
faire des séquences pseudo-aléatoires.  Il y a un autre mode où on peut
appliquer une règle avec une certaine probabilité, mais là ça devient
chaud de faire une distribution uniforme à partir de ça.

Bon en tout cas, quelle que soit la méthode, ils ont l'air de s'être bien
amusés et je pense que c'est la réponse à ta question :)

Baptiste

[1] 
https://unix.stackexchange.com/questions/17/drawing-a-histogram-from-a-bash-command-output


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] Filtrage ICMP > 96 bytes sur 8.8.8.8/8.8.4.4

2019-10-19 Par sujet Baptiste Jonglez 
On 18-10-19, Alarig Le Lay wrote:
> J’ai envie de dire « ça dépend » :p
> 
> alarig@herbizarre ~ $ mtr -bzwe -s 100 8.8.8.8
> Start: Fri Oct 18 12:42:14 2019
> HOST: herbizarre.swordarmor.fr  Loss%   Snt   
> Last   Avg  Best  Wrst StDev
>   1. AS204092 br-ganeti.regis.swordarmor.fr (89.234.186.209) 0.0%10   
>  0.2   0.3   0.1   0.4   0.0
>   2. AS204092 asbr01.cogent-rns.grifon.fr (89.234.186.7) 0.0%10   
>  0.4   1.7   0.4  12.4   3.7
>   3. AS34019  ve504-rt2-th2.bb.hivane.net (193.200.43.85)0.0%10   
>  9.3  16.2   9.3  76.1  21.0
>   4. AS34019  xe-0-0-3-rt2-vty.bb.hivane.net (193.164.153.195)   0.0%10   
>  9.8  12.8   9.7  37.4   8.7
>   5. AS34019  ge1-10-rt2-vty.bb.hivane.net (193.164.153.230) 0.0%10   
> 10.0  14.3   9.8  21.0   4.2
>   6. AS???google2.par.franceix.net (37.49.236.2) 0.0%10   
> 10.2  10.6  10.2  11.6   0.3
>   7. AS15169  108.170.244.1610.0%10   
> 16.9  19.0  16.6  38.7   6.9
>   8. AS15169  108.170.235.37 0.0%10   
> 10.3  10.9  10.2  15.8   1.6
>   9. AS15169  dns.google (8.8.8.8)   0.0%10   
> 10.4  10.3  10.1  10.4   0.0
> alarig@herbizarre ~ $ ping -s 100 -c4 8.8.8.8
> PING 8.8.8.8 (8.8.8.8) 100(128) bytes of data.
> 
> --- 8.8.8.8 ping statistics ---
> 4 packets transmitted, 0 received, 100% packet loss, time 7ms
> 
> 
> J’ai pas trop pigé le truc là…

C'est juste ta variante de ping qui n'aime pas les paquets tronqués et qui
ne t'affiche rien.  Pareil ici, ping ne montre rien mais je reçois
pourtant bien des réponses :


~$ ping -c 4 -s 200 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 200(228) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 8ms


11:58:15.491422 IP 172.23.184.82 > 8.8.8.8: ICMP echo request, id 5395, seq 1, 
length 208
11:58:15.516050 IP 8.8.8.8 > 172.23.184.82: ICMP echo reply, id 5395, seq 1, 
length 76
11:58:16.493582 IP 172.23.184.82 > 8.8.8.8: ICMP echo request, id 5395, seq 2, 
length 208
11:58:16.526372 IP 8.8.8.8 > 172.23.184.82: ICMP echo reply, id 5395, seq 2, 
length 76
11:58:17.494631 IP 172.23.184.82 > 8.8.8.8: ICMP echo request, id 5395, seq 3, 
length 208
11:58:17.521847 IP 8.8.8.8 > 172.23.184.82: ICMP echo reply, id 5395, seq 3, 
length 76
11:58:18.496148 IP 172.23.184.82 > 8.8.8.8: ICMP echo request, id 5395, seq 4, 
length 208
11:58:18.521121 IP 8.8.8.8 > 172.23.184.82: ICMP echo reply, id 5395, seq 4, 
length 76


Baptiste


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

Re: [FRnOG] [TECH] Problème de performance Fastly / Equinix Paris (ECMP déséquilibré ?)

2018-07-18 Par sujet Baptiste Jonglez 
Bonsoir,

On 15-07-18, Baptiste Jonglez wrote:
> On constate depuis quelques semaines des download parfois très lents
> depuis Fastly, sur l'archive Debian (deb.debian.org et security.debian.org).
> 
> Le symptôme : parfois le download est très rapide (> 100 Mbps voire 1 Gbps),
> parfois c'est très lent (3 à 4 Mbps).  Le tout depuis la même machine, à
> quelques secondes d'intervalle, en tapant sur la même IP Fastly.

D'après le support, le problème était bien causé par un lien qui merdait
dans un agrégat, sans plus de détails.  J'imagine que c'est sur leur
interco Equinix (2x100G d'après peeringdb) ou bien sur un étage
d'agrégation juste avant.  En tout cas, c'est résolu depuis lundi soir 16
juillet.

En terme de support, ils sont assez efficaces (merci Renaud pour le
contact initial !) :

- ils ont un site pour collecter des infos de debug : 
https://www.fastly-debug.com/
  Ça donne notamment le POP sur lequel on tombe, le RTT et débit
  (sous-)estimé depuis le POP, et la latence vers tous les autres POP.

- le support est joignable par mail à supp...@fastly.com : même sans être
  client chez eux, problème remonté à 14h30 UTC lundi dernier, résolu à 21h UTC.

Bonne soirée,
Baptiste

> 
> Pour tester, essayer de lancer plusieurs fois :
> 
>   $ wget -4 -O /dev/null 
> http://security-cdn.debian.org/pool/updates/main/l/linux/linux-image-3.2.0-6-rt-amd64-dbg_3.2.102-1_amd64.deb
> 
> Ça semble n'affecter que les clients qui sont redirigés vers l'instance
> Fastly à Paris (151.101.120.204 en IPv4, 2a04:4e42:1d::204 en IPv6) via
> GéoDNS.  Voilà un exemple depuis Gandi :
> 
>   https://paste.swordarmor.fr/zBv7
> 
> On passe de 9 minutes à 1 seconde, c'est un facteur 325 en performance
> selon si on a de la chance ou non !
> 
> 
> En testant avec le Ring NLNOG, le point commun entre tous les noeuds qui
> ont le problème, c'est que ça passe par Equinix Paris…  Ça sent très fort
> l'ECMP avec un des liens qui est complètement bouché (soit chez Equinix,
> soit chez Fastly).
> 
> Est-ce que quelqu'un a un autre moyen de tester l'infra de Fastly, pour
> voir si c'est spécifique au miroir Debian ou pas ?  J'ai pas trouvé de
> « Speedtest fastly » fourni par Fastly.  Et sinon, quand est-ce que Fastly
> se connecte au FranceIX ? ;)
> 
> Bonne soirée,
> Baptiste
> 
> 
> PS : sur des AS qui passent par des PNI avec Fastly à Paris (Telia, NTT),
> ça fonctionne bien à tous les coups :
> 
>   https://paste.swordarmor.fr/SNOP
>   https://paste.swordarmor.fr/alu7
> 
> En supposant que le PNI est bien aussi pris au retour, ça semble dire que
> le problème est chez Equinix et pas chez Fastly.
> 
> Idem depuis de la fibre Orange et SFR (qui ont probablement aussi des PNI
> avec Fastly ?  je n'ai pas d'accès rapide pour faire un traceroute), ça
> fonctionne correctement.




signature.asc
Description: PGP signature

[FRnOG] [TECH] Problème de performance Fastly / Equinix Paris (ECMP déséquilibré ?)

2018-07-15 Par sujet Baptiste Jonglez 
Hello,

On constate depuis quelques semaines des download parfois très lents
depuis Fastly, sur l'archive Debian (deb.debian.org et security.debian.org).

Le symptôme : parfois le download est très rapide (> 100 Mbps voire 1 Gbps),
parfois c'est très lent (3 à 4 Mbps).  Le tout depuis la même machine, à
quelques secondes d'intervalle, en tapant sur la même IP Fastly.

Pour tester, essayer de lancer plusieurs fois :

  $ wget -4 -O /dev/null 
http://security-cdn.debian.org/pool/updates/main/l/linux/linux-image-3.2.0-6-rt-amd64-dbg_3.2.102-1_amd64.deb

Ça semble n'affecter que les clients qui sont redirigés vers l'instance
Fastly à Paris (151.101.120.204 en IPv4, 2a04:4e42:1d::204 en IPv6) via
GéoDNS.  Voilà un exemple depuis Gandi :

  https://paste.swordarmor.fr/zBv7

On passe de 9 minutes à 1 seconde, c'est un facteur 325 en performance
selon si on a de la chance ou non !


En testant avec le Ring NLNOG, le point commun entre tous les noeuds qui
ont le problème, c'est que ça passe par Equinix Paris…  Ça sent très fort
l'ECMP avec un des liens qui est complètement bouché (soit chez Equinix,
soit chez Fastly).

Est-ce que quelqu'un a un autre moyen de tester l'infra de Fastly, pour
voir si c'est spécifique au miroir Debian ou pas ?  J'ai pas trouvé de
« Speedtest fastly » fourni par Fastly.  Et sinon, quand est-ce que Fastly
se connecte au FranceIX ? ;)

Bonne soirée,
Baptiste


PS : sur des AS qui passent par des PNI avec Fastly à Paris (Telia, NTT),
ça fonctionne bien à tous les coups :

  https://paste.swordarmor.fr/SNOP
  https://paste.swordarmor.fr/alu7

En supposant que le PNI est bien aussi pris au retour, ça semble dire que
le problème est chez Equinix et pas chez Fastly.

Idem depuis de la fibre Orange et SFR (qui ont probablement aussi des PNI
avec Fastly ?  je n'ai pas d'accès rapide pour faire un traceroute), ça
fonctionne correctement.


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] TCP vs. UDP : les chiffres

2018-02-11 Par sujet Baptiste Jonglez 
Bonjour,

On 08-02-18, Stephane Bortzmeyer wrote:
> Est-ce que quelqu'un a des chiffres *récents* sur la part de trafic
> TCP vs. UDP, à divers endroits du réseau ? Je ne trouve que des vieux
> chiffres comme
>  qui ne
> tiennent pas compte, par exemple, de WebRTC.

Note que ces données de trafic sont collectées en continu et publiquement
accessibles, par exemple ici pour Equinix Chicago :

http://www.caida.org/data/monitors/passive-equinix-chicago.xml
http://www.caida.org/data/realtime/passive/?monitor=equinix-chicago-dirA

Par contre la collecte s'est arrêtée autour de 2015-2016 (visiblement
parce que le lien est passé en 100G...), mais c'est déjà plus récent que
l'étude dont tu parles.

J'ai fait de la biblio sur le sujet il y a quelques mois, et côté
académique le plus récent que j'avais trouvé c'est ça :

https://wand.net.nz/sites/default/files/imc27-alcock.pdf

Ça se base sur du trafic collecté en septembre 2015 sur un campus en
Nouvelle-Zelande, pendant une semaine.  Attention, il y a une erreur sur
le nombre de flots UDP/53, c'est 364M et non 364G...

Dans les trucs intéressants il y a QUIC (déjà à l'époque), qui pèse 1.2 To
contre 12 To pour HTTPS et 11 To pour HTTP.

Et sinon, comme attendu, DNS domine en nombre de flots (364M flots DNS,
contre 126M flots en combinant HTTP+HTTPS+QUIC).  Par contre en octets ça
représente moins de 1%.  C'est dommage qu'il n'y ait pas les statistiques
en paquets dans le papier.

Si tu trouves des études encore plus récentes, ça m'intéresse :)

Baptiste


signature.asc
Description: PGP signature

Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

2016-10-03 Par sujet Baptiste Jonglez 
On Mon, Oct 03, 2016 at 02:11:05PM +0200, Olivier Benghozi wrote:
> L'adressage interne de la boite que personne n'a envie de changer selon 
> l'adressage des liens externes, c'est un problème clairement généralisé.
> Du coup on va immanquablement voir du NPTv6 lorsque l'IPv6 se retrouvera en 
> entreprise.

Ou pas, le double adressage IPv6 public + privé (ULA¹) sert justement à ça.

L'adressage en ULA est stable et peut servir en interne, tandis que
l'adressage public peut changer mais c'est pas bien grave
(autoconfiguration des postes via RA/DHCPv6).

OpenWRT fait déjà ça par défaut, le routeur distribue des IPv6 en ULA +
des IPv6 publiques quand le WAN a une connectivité IPv6.

¹ https://en.wikipedia.org/wiki/Unique_local_address

> > Le 3 oct. 2016 à 13:21, Pierre Colombier  a écrit :
> > 
> > Le problème avec IPV6, c'est surtout les mauvaises habitudes prises avec le 
> > nat depuis 15 ans.
> > 
> > Le réseau d'entreprise "tout ouvert derrière une box qui fait nat" en IPv6, 
> > c'est le carnage...
> > 
> > Et il y en a combien des comme ça ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] RFC 7854: BGP Monitoring Protocol (BMP)

2016-06-28 Par sujet Baptiste Jonglez 
Intéressant, merci !

Je suis étonné que ni ton article, ni la RFC ne citent mrtdump, qui est
pourtant similaire ?  C'est le format utilisé par RIS et Routeviews pour
stocker les RIB et updates BGP :

  
https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris
  http://www.routeviews.org/tools.html

Il y a plusieurs outils pour parser ce format :

  https://bitbucket.org/ripencc/bgpdump/wiki/Home (antique)
  https://bgpstream.caida.org (récent)

L'équivalent de BMP serait une session BGP avec un Quagga ou un Bird, qui
dumpe ce qu'il reçoit au format mrtdump.  Ceci dit, un des avantages que
je vois à BMP est qu'on peut avoir accès à tous les messages BGP
directement, et pas uniquement ce qui concerne la meilleure route (ou
toutes les routes si on utilise ADD_PATH).

Baptiste

On Tue, Jun 28, 2016 at 02:59:54PM +0200, Stephane Bortzmeyer wrote:
> Un nouveau jouet !
> 
> http://www.bortzmeyer.org/7854.html
> 
> 
> 
> Auteur(s) du RFC: J. Scudder (Juniper
>   Networks), R. Fernando
>   (Cisco), S. Stuart (Google)
> 
> Chemin des normes
> 
> 
> 
> 
> Ce nouveau protocole *BMP* ("BGP Monitoring Protocol") va faciliter le 
> travail des administrateurs réseaux qui font du BGP. Il permet 
> d'obtenir sous une forme structurée les tables BGP. Avant, la solution 
> la plus répandue était d'utiliser l'interface en ligne de commande du 
> routeur (show ip bgp routes sur un Cisco), et d'analyser le résultat 
> depuis son programme, une méthode qui est très fragile, le format de 
> sortie ayant été conçu pour des humains et pas pour des programmes.
> 
> Les tables convoitées sont bien sûr la RIB mais aussi des informations 
> comme les mises à jour de routes reçues. BMP donne accès à une table 
> BGP nommée Adj-RIB-In, « "Adjacent [peers] Routing Information Base - 
> Incoming" », définie dans le RFC 4271, section 1.1. Elle stocke les 
> informations brutes (avant les décisions par le routeur) transmises par 
> les pairs BGP.
> 
> BMP fonctionne (section 3) en établissant une connexion TCP avec le 
> routeur convoité. Celui-ci envoie ensuite l'information qu'il veut. Il 
> n'y a pas de négociation ou de discussion au début. Dès que la 
> connexion est établie, le routeur transmet. Il envoie d'abord des 
> messages "Peer Up" pour chacun de ses pairs, puis des messages "Route 
> Monitoring" pour toute sa base de routes (la section 5 les décrit plus 
> en détails). Une fois que c'est fait, le routeur transmet des messages 
> indiquant les changements : "Route Monitoring" en cas d'annonce ou de 
> retrait d'une route, "Peer Up" ou "Peer Down" s'il y a des changements 
> chez les pairs. Autres messages possibles : "Stats Report" pour envoyer 
> des statistiqes globales (voir les sections 4.8 et 7), "Initiation" et 
> "Termination" pour les débuts et fins de sessions, "Route Mirroring" 
> pour envoyer verbatim les annonces BGP reçues (c'est une vision de plus 
> bas niveau que "Route Monitoring" et cela permet, par exemple, 
> d'analyser des annonces BGP syntaxiquement incorrectes, cf. section 6).
> 
> Le client BMP ne transmet jamais de message au serveur (au routeur), à 
> tel point que le routeur peut parfaitement fermer la moitié de la 
> connexion TCP, ou mettre sa fenêtre d'envoi à zéro (ou encore, jeter 
> tous les messages qui seraient envoyés). Toute la configuration est 
> dans le routeur.
> 
> Le format des messages est décrit en section 4. C'est du classique. On 
> trouve dans le message un numéro de version (actuellement 1), la 
> longueur du message, le type du message (la liste des types est 
> indiquée plus haut) représentée par un entier (0 pour "Route 
> Monitoring", 1 pour "Stats Report" (ou "Statistics Report"), etc), puis 
> les données. À noter que le type arrive après la longueur, alors que 
> c'est en général le contraire (encodage TLV).
> 
> Pour la plupart des messages BMP, il y aura un second en-tête, 
> rassemblant les informations sur le pair (son adresse IP, son AS, etc).
> 
> Les différents paramètres numériques sont désormais stockés dans un 
> registre IANA 
> .
> 
> Quelques petits mots sur la sécurité pour finir. Pour économiser ses 
> ressources, le routeur peut évidemment (section 3.2) restreindre 
> l'ensemble des adresses IP autorisées à se connecter en BMP à lui, tout 
> comme il peut limiter le nombre de sessions BMP (par exemple, une au 
> maximum par adresse IP, cinq au total). Il peut aussi y avoir des 
> questions de confidentialité (section 11). Bien sûr, la liste des 
> routes dans la DFZ est publique, mais ce n'est pas forcément le cas des 
> "peerings" privés ou de VPN utilisant BGP comme ceux du RFC 4364. Donc, 
> attention à bien restreindre l'accès.
> 
> BMP est en cours d'élaboration depuis pas mal de temps déjà. Résultat, 
> des mises en œuvre ont eu le temps d'apparaitre. Wireshark sait

Re: [FRnOG] [TECH] Géolocaliser des traceroutes, besoin de votre aide

2016-05-24 Par sujet Baptiste Jonglez 
Salut,

J'imagine que tu connais déjà OpenIPMap, du RIPE ?

  
https://ripe68.ripe.net/presentations/397-2014-05.ripe68.openipmap.emileaben.pdf
  
https://ripe69.ripe.net/wp-content/uploads/presentations/83-2014-11.emileaben.ripe69.openipmap.pdf
  https://github.com/emileaben/django-openipmap

Ca se base sur l'analyse des reverse DNS, des IP (IXP connus), un peu de
crowdsourcing, et une vérification de la cohérence du résultat via le RTT.

Tous les traceroutes d'Atlas peuvent être visualisés avec, par exemple :

  https://atlas.ripe.net/measurements/3679340/#!openipmap

Baptiste

On Mon, May 23, 2016 at 05:43:23PM +0200, Salim Gasmi wrote:
> Bonjour,
> 
> Voila, cela fait maintenant plus d'un an que je travaille sur mon temps libre 
> à un projet consistant a tenter de géolocaliser les routeurs d'un traceroute.
> Je sais, vous souriez et vous vous dites que c'est un projet mort d'avance ;)
> 
> La méthodologie est simple, écrire un algo d'IA qui analyse les traceroutes 
> comme un humain le ferait.
> En gros analyser les reverses, les latences plus un peu de bon sens pour 
> essayer de géolocaliser correctement les hops.
> En s'appuyant en plus sur les bases déjà existantes comme openip du RIPE ou 
> DDEC.
> 
> Pour cela, cela nécessite des nodes dans des endroits différents pour croiser 
> les informations.
> Par exemple une ip dont le reverse semblerait être à New York, mais qui 
> depuis Paris ping en 3ms, l'algo peut détecter l'erreur.
> Après en tentant de la magie vaudou, on peut même essayer d'estimer ou 
> pourrait se trouver le node en croisant avec les grosses villes et les autres 
> nodes et un peu de bon sens.
> 
> Le projet inclu déjà 4 nodes, 2 en France et 2 aux US (merci Michel!)
> 
> Pour le moment, cela marche plus ou moins bien, en gros 90% des 
> géolocalisations sont correctes.
> Cela pourrait sembler suffisant, mais sur un traceroute de 10 hops, cela fait 
> 1 hop mal placé (et généralement pas pour rire).
> 
> Donc, si je vous écrit tout cela, c'est que je recherche des nodes 
> supplémentaires.
> Un node, c'est juste un machine ou vous me créez un compte ssh sur lequel le 
> tool va se connecter et lancer la commande mtr.
> Donc le compte peut être chrooté ou en VM, voir même sous docker.
> L’intérêt d'avoir son node, c'est déjà pour aider et pouvoir s'amuser (vous 
> êtes des geeks) à voir visuellement ses traceroutes depuis chez soi.
> Le must serait un node en asie ou amerique du sud (je sais, je suis exigent), 
> mais je suis preneur de toute autre localisation.
> 
> Exemple: un traceroute entre un node aux US et www.gov.kg au kyrgyzstan
> https://geotr.gasmi.net/index.php?node=1=www.gov.kg
> 
> Si vous voulez jouer avec le tool, c'est ici: https://geotr.gasmi.net
> N’espérez pas avoir une précision au niveau des villes de France, c'est trop 
> petit comme pays, je n'en suis pas encore la, trop peu de nodes.
> 
> Bien sur, quand le code sera fonctionnel (ce n'est pas encore le cas, trop 
> d'erreurs à mon gout), il passera en Open Source.
> 
> Merci d'avance aux geeks qui voudraient participer, c'est encore du beta, 
> mais malgré cela, je ne connais pour le moment, aucun autre outil moins faux 
> que celui la ;)
> 
> Salim
> 
> Ps:
> Inutile de me remonter les traceroutes erronés que vous ne manquerez pas de 
> trouver, j'en ai déjà pour toute une vie en base.
> Par contre, si vous bossez chez un opérateur et/ou que vous êtes sur qu'un 
> routeur est mal placé et que vous êtes certain de sa vraie localisation, je 
> suis preneur de l'info.
> Ca me permettra de comprendre pourquoi l'algo a lamentablement foiré.


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] overthebox

2015-09-25 Par sujet Baptiste Jonglez 
On Fri, Sep 25, 2015 at 11:39:25AM +0200, Raphael Mazelier wrote:
> Rappelons que cela ne fonctionne correctement que si les différents liens
> agrégés sont fortement similaires (notamment en terme de latences), et que
> le débit agrégé est a peu près égal à 1.9 * la bp du lien le plus faible.

Sauf à utiliser Multipath TCP, qui est *précisément* fait pour fonctionner
sur des technos très différentes (genre, VDSL + 3G).

Ça tombe bien, c'est ce qu'utilise la solution d'OVH :)

> Et bien sur c'est reculer pour mieux sauter, la fibre étant la seule
> solution d'avenir :)

+1, mais on n'a parfois malheureusement pas le choix (ou les moyens financiers 
;) )


pgpLWcVKkNKF8.pgp
Description: PGP signature

Re: [FRnOG] [TECH] overthebox

2015-09-25 Par sujet Baptiste Jonglez 
On Fri, Sep 25, 2015 at 11:23:52AM +0200, slesim...@laposte.net wrote:
> Oui sans compter que cela ne fonctionnera probablement parfaitement qu'avec 
> leurs accès. 

De: "Clément Breuil"  
> il feront payer 9.99€/mo donc pas prêt à le lâcher le code 

Bin en fait, non, c'est entièrement basé sur des technos libres existantes :
Multipath TCP, vtun/OpenVPN, et ShadowSocks.  Ils filent même le code de
leur boiboîte, basé sur OpenWRT.  Donc ça peut s'utiliser sans acheter
leur boiboîte côté client, et en utilisant son propre serveur VPN de
l'autre côté.

Une analyse rapide écrite sur le coup :

  
http://bitsofnetworks.org/ovhs-overthebox-internet-access-link-aggregation-using-multipath-tcp.html

Baptiste


pgpZOJ6uTSM1V.pgp
Description: PGP signature

Re: [FRnOG] [TECH] connectivité temporaire pour site isolé

2014-07-05 Par sujet Baptiste Jonglez 
On Sat, Jul 05, 2014 at 09:05:54AM +0200, David Ponzone wrote:
 Au niveau topo, ça peut passer. La Villa est à 20m d’altitude, le NRA de St 
 Raph (83118 SRA) est dans un bâtiment à côté de La Poste, à 12m d’altitude, 
 et je vois pas d’obstacle majeur entre les 2.
 Mais les pins peuvent être assez hauts, donc il faudrait mettre l’antenne sur 
 le toit de la Villa. En ensuite, il faut avoir un local en visu avec de 
 l’ADSL dans le centre de St Raph.
 En 2 mois et en pleine saison, c’est peut-être un peu compliqué.
 
 Joel: si vous voulez explorer cette voie, vous pouvez regarder:
 
 http://infinetwireless.com
 
 Il faut compter 1500€ pour le matériel pour équiper les 2 extrémités d ‘une 
 liaison point-à-point de 100Mbps sur plusieurs kilomètres de distance.

1500 €, rien que ça ?

Avec du matos Ubiquity, tu t'en tirerais pour moins de 300 €, pour pareil,
50Mbps à 100Mbps sur plusieurs kilomètres (avec des Nanobridge, par
exemple).


pgpDgCyQPeOxC.pgp
Description: PGP signature

Re: [FRnOG] [MISC] Fibre SFR et IPv6 (Was: SFR passe la fibre à 300Mbps)

2013-10-12 Par sujet Baptiste Jonglez 
On Fri, Oct 11, 2013 at 06:50:11PM +0200, Emmanuel Thierry wrote:
 
 Plus précisément du softwire: http://tools.ietf.org/html/rfc5571
 Il y aura peut être prochainement une implémentation publique open-source (je 
 suis volontairement évasif).

Ah, intéressant.  Ceci dit, ça n'utilise que des technos existantes,
non ? (L2TPv2, PPP, RA, DHCPv6)

Visiblement, SFR utilise xl2tpd comme LAC sur la Neufbox.  Il y a donc
une implémentation libre, au moins dans ce cas-là (à moins que SFR
n'ait patché xl2tpd, mais j'en doute).

J'ai essayé de causer avec le LNS Cisco de SFR en utilisant xl2tpd, et
ça cause bien.  Juste, il y a une authentification Challenge/Response
au niveau L2TP (donc avant même la négociation PPP) qui ne passe pas,
vu qu'il me manque le secret partagé…

Merci,
Baptiste


pgpdKU1fTFpp9.pgp
Description: PGP signature

[FRnOG] [MISC] NRO actifs pour FTTH Free à Lyon ?

2013-05-25 Par sujet Baptiste Jonglez 
Bonjour,

Plusieurs NRO Free ont ouvert récemment à Lyon, dans le 7ème :

  http://francois04.free.fr/liste_dslam.php?dpt=69ville=Lyontype=F

Je pense surtout à DEL69-F, DUH69-F et GOU69-F, qui ont l'air récents.

Cependant, d'après le test d'éligibilité de Free [1], je n'ai pu
trouver aucune adresse éligible à la fibre dans ces quartiers.

Sont-ils déjà en production, et est-il possible d'avoir une idée de la
couverture géographique de chacun ?

Merci,
Baptiste

[1] http://www.free.fr/adsl/internet.html


pgp51myS1NnIJ.pgp
Description: PGP signature