La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => 
Incidents SFR => Discussion démarrée par: hwti le 23 avril 2020 à 15:41:17
-
Depuis 14h48, plus d'accès à 1.1.1.1 sur ma ligne SFR FTTH.
A noter que j'ai aussi eu une coupure PON à 15h23.
En revanche https://mozilla.cloudflare-dns.com/ (le DoH de Firefox) est OK, de même que 1.1.1.2 et 1.1.1.3.
Il y a un routage bizarre, qui se termine par une boucle :
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms box [192.168.1.1]
2 * * * Délai d’attente de la demande dépassé.
3 3 ms 4 ms 4 ms 110.42.154.77.rev.sfr.net [77.154.42.110]
4 6 ms 4 ms 7 ms 229.10.136.77.rev.sfr.net [77.136.10.229]
5 4 ms 4 ms 4 ms 229.10.136.77.rev.sfr.net [77.136.10.229]
6 7 ms 3 ms 4 ms 101.172.136.77.rev.sfr.net [77.136.172.101]
7 17 ms 13 ms 13 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
8 45 ms 31 ms 46 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
9 33 ms 32 ms 32 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
10 58 ms * 64 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
11 48 ms * 51 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
12 80 ms 77 ms 76 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
13 66 ms * 68 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
14 * * 93 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
15 83 ms 83 ms 85 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
16 * 114 ms 110 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
17 102 ms 103 ms 103 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
18 124 ms 129 ms 125 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
19 * 111 ms 112 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
20 128 ms 131 ms 152 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
21 * 125 ms 127 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
22 153 ms * 158 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
23 142 ms * 146 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
24 165 ms * 171 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
25 160 ms 160 ms * 108.97.30.212.rev.sfr.net [212.30.97.108]
26 180 ms * 190 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
27 176 ms 178 ms 179 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
28 192 ms 196 ms 198 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
29 193 ms * 191 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
30 218 ms 211 ms 215 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
-
En ADSL aussi ...
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 31 | 31 | 0 | 0 | 4 | 0 |
| 1.84.135.77.rev.sfr.net - 0 | 31 | 31 | 5 | 5 | 6 | 5 |
| 49.184.154.77.rev.sfr.net - 0 | 31 | 31 | 5 | 6 | 9 | 6 |
| 189.147.154.77.rev.sfr.net - 0 | 31 | 31 | 5 | 12 | 205 | 22 |
| 229.10.136.77.rev.sfr.net - 0 | 31 | 31 | 24 | 24 | 28 | 25 |
| 101.172.136.77.rev.sfr.net - 0 | 31 | 31 | 24 | 24 | 25 | 25 |
| 108.97.30.212.rev.sfr.net - 0 | 31 | 31 | 33 | 34 | 38 | 34 |
| 226.244.79.86.rev.sfr.net - 16 | 19 | 16 | 59 | 71 | 80 | 59 |
| 108.97.30.212.rev.sfr.net - 9 | 23 | 21 | 56 | 57 | 59 | 57 |
| 226.244.79.86.rev.sfr.net - 16 | 19 | 16 | 84 | 92 | 103 | 97 |
| 108.97.30.212.rev.sfr.net - 16 | 19 | 16 | 79 | 82 | 94 | 82 |
| 226.244.79.86.rev.sfr.net - 24 | 17 | 13 | 106 | 118 | 130 | 115 |
| 108.97.30.212.rev.sfr.net - 23 | 18 | 14 | 105 | 106 | 108 | 107 |
| 226.244.79.86.rev.sfr.net - 25 | 16 | 12 | 133 | 141 | 151 | 150 |
| 108.97.30.212.rev.sfr.net - 36 | 14 | 9 | 130 | 131 | 133 | 131 |
| 226.244.79.86.rev.sfr.net - 25 | 16 | 12 | 155 | 163 | 172 | 172 |
| 108.97.30.212.rev.sfr.net - 27 | 15 | 11 | 154 | 156 | 159 | 157 |
| 226.244.79.86.rev.sfr.net - 39 | 13 | 8 | 0 | 187 | 203 | 184 |
| 108.97.30.212.rev.sfr.net - 27 | 15 | 11 | 172 | 179 | 183 | 180 |
| 226.244.79.86.rev.sfr.net - 55 | 11 | 5 | 0 | 216 | 223 | 223 |
| 108.97.30.212.rev.sfr.net - 16 | 19 | 16 | 202 | 204 | 207 | 204 |
| 226.244.79.86.rev.sfr.net - 36 | 14 | 9 | 0 | 240 | 248 | 236 |
| 108.97.30.212.rev.sfr.net - 36 | 14 | 9 | 0 | 229 | 230 | 229 |
| 226.244.79.86.rev.sfr.net - 55 | 11 | 5 | 0 | 265 | 272 | 272 |
| 108.97.30.212.rev.sfr.net - 42 | 12 | 7 | 0 | 253 | 256 | 253 |
| 226.244.79.86.rev.sfr.net - 36 | 14 | 9 | 279 | 287 | 300 | 286 |
| 108.97.30.212.rev.sfr.net - 42 | 12 | 7 | 263 | 273 | 280 | 278 |
| 226.244.79.86.rev.sfr.net - 55 | 11 | 5 | 0 | 309 | 318 | 318 |
| 108.97.30.212.rev.sfr.net - 46 | 11 | 6 | 0 | 302 | 304 | 304 |
| 226.244.79.86.rev.sfr.net - 39 | 13 | 8 | 0 | 332 | 342 | 339 |
|________________________________________________|______|______|______|______|______|______|
-
J'avoue c'est la même !
PS C:\WINDOWS\system32> tracert 1.1.1.1
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms dumaos.lan [192.168.77.1]
2 1 ms <1 ms <1 ms 10.0.0.1
3 2 ms <1 ms 1 ms 35cou1-nro-2.nro.gaoland.net [109.24.76.104]
4 2 ms 2 ms 3 ms 170.242.96.84.rev.sfr.net [84.96.242.170]
5 16 ms 16 ms 15 ms 229.10.136.77.rev.sfr.net [77.136.10.229]
6 15 ms 15 ms 15 ms 229.10.136.77.rev.sfr.net [77.136.10.229]
7 15 ms 14 ms 15 ms 101.172.136.77.rev.sfr.net [77.136.172.101]
8 26 ms 26 ms 25 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
9 59 ms 68 ms 70 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
10 50 ms * * 108.97.30.212.rev.sfr.net [212.30.97.108]
11 85 ms 90 ms 95 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
12 76 ms 74 ms 73 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
13 * * 106 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
14 * 99 ms 102 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
15 * 128 ms * 226.244.79.86.rev.sfr.net [86.79.244.226]
16 125 ms 124 ms 123 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
17 150 ms 162 ms 163 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
18 147 ms * 148 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
19 186 ms 186 ms 186 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
20 175 ms 174 ms 172 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
21 200 ms 196 ms * 226.244.79.86.rev.sfr.net [86.79.244.226]
22 195 ms * 196 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
23 238 ms 234 ms 238 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
24 225 ms 225 ms 223 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
25 254 ms 272 ms * 226.244.79.86.rev.sfr.net [86.79.244.226]
26 251 ms * 249 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
27 * 285 ms * 226.244.79.86.rev.sfr.net [86.79.244.226]
28 * 281 ms 280 ms 108.97.30.212.rev.sfr.net [212.30.97.108]
29 314 ms * 318 ms 226.244.79.86.rev.sfr.net [86.79.244.226]
30 302 ms 303 ms * 108.97.30.212.rev.sfr.net [212.30.97.108]
-
Depuis un accès câble également :
$ mtr -bzrwc100 1.1.1.1
Start: 2020-04-23T16:42:54+0200
HOST: vivien Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.0.1) 0.0% 100 0.3 0.3 0.2 0.6 0.1
2. AS??? ? ? 100.0 100
3. AS21502 evy1rj-ge-1-1-5.200.numericable.net (195.132.10.177) 0.0% 100 6.2 16.8 5.8 53.7 14.3
4. AS15557 13.229.154.77.rev.sfr.net (77.154.229.13) 0.0% 100 6.8 7.9 6.2 30.4 3.3
5. AS15557 229.10.136.77.rev.sfr.net (77.136.10.229) 0.0% 100 13.1 9.4 8.1 16.6 1.4
6. AS15557 229.10.136.77.rev.sfr.net (77.136.10.229) 0.0% 100 8.1 8.7 7.8 16.4 0.9
7. AS15557 101.172.136.77.rev.sfr.net (77.136.172.101) 0.0% 100 8.5 8.8 8.0 16.5 1.0
8. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 0.0% 100 18.6 20.1 18.0 104.1 9.4
9. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 9.0% 100 50.4 54.8 42.3 65.7 6.6
10. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 13.0% 100 43.8 42.9 41.5 46.7 0.7
11. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 15.0% 100 76.0 79.4 66.9 91.3 6.4
12. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 27.0% 100 67.7 67.4 64.3 69.7 0.9
13. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 22.0% 100 102.8 104.1 91.0 117.4 6.4
14. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 24.0% 100 92.7 91.8 87.6 94.9 1.3
15. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 23.0% 100 131.4 128.4 111.5 139.5 6.7
16. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 30.0% 100 118.5 116.3 109.5 125.2 2.1
17. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 25.0% 100 158.9 152.1 140.1 163.8 6.5
18. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 28.0% 100 142.0 140.4 132.4 148.8 2.6
19. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 32.0% 100 184.1 175.5 159.7 190.1 6.5
20. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 36.0% 100 166.1 164.9 153.9 174.8 2.8
21. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 44.0% 100 203.5 199.5 184.7 211.2 6.8
22. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 32.0% 100 191.3 189.1 178.2 198.2 3.0
23. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 38.0% 100 237.5 224.3 205.0 237.5 6.6
24. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 39.0% 100 215.7 213.0 201.2 219.0 3.3
25. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 40.0% 100 259.3 248.2 228.8 262.8 7.0
26. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 43.0% 100 240.9 246.5 223.2 285.6 14.5
27. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 51.0% 100 264.5 272.4 256.7 285.6 6.2
28. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 40.0% 100 259.3 261.0 246.8 266.1 3.5
29. AS15557 226.244.79.86.rev.sfr.net (86.79.244.226) 49.0% 100 289.3 297.3 279.3 311.4 6.6
30. AS12626 108.97.30.212.rev.sfr.net (212.30.97.108) 48.0% 100 286.3 285.5 269.7 290.1 3.9
Noter que a chaque bond, la latence augmente de près de 10ms, c'est donc une boucle entre deux équipements distant de plus de 700km.
Fibre optique : Détail du calcul du ping en fonction de la distance :
- La vitesse de la lumière dans un cœur de silice = 200 000 000 m/s = 5 micro seconde par km
- Les bobines de compensation de la dispersion chromatique ajoutent 1/7ème de distance supplémentaire
- 10 micro seconde par équipement WDM traversé (si extraction du trafic)
100 km de fibre donne donc 1,2ms de latence aller/retour.
Exemple en prenant en compte les équipements DWDM : Pour un Paris <=> Lyon direct de 500km de fibre, c'est 6,04ms, uniquement lié à la vitesse de la lumière (un ping c'est un aller-retour) + les équipements à intervalle régulier pour amplifier le signal +5% pour les longueurs de love + entrée / sortie du DWDM :
- 2,5 ms pour la vitesse de la lumière (aller)
- 2,5 ms pour la vitesse de la lumière (retour)
- 0,3571 ms pour les bobines de compensation de la dispersion chromatique (aller)
- 0,3571 ms pour les bobines de compensation de la dispersion chromatique (retour)
- 0,2857 ms qui correspond a +5 % des chiffres ci-dessus pour les longueurs de love
- 0,010 ms pour le WDM à Lyon (aller)
- 0,010 ms pour le WDM à Lyon (retour)
- 0,010 ms pour le WDM à Paris (aller)
- 0,010 ms pour le WDM à Paris (retour)
Total : 6,04ms
(https://lafibre.info/images/peering/202004_1111_cloudflare_hs_depuis_sfr.png)
-
Idem depuis l'AS15557 en FTTH aussi :
mtr -zr 1.1.1.1
Start: 2020-04-23T17:59:31+0200
HOST: xxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.1 0.0% 10 0.4 0.5 0.4 0.7 0.1
2. AS15557 xxxxxxxxxxxxxxxxxxx 0.0% 10 0.9 0.9 0.8 1.1 0.1
3. AS15557 249.142.24.109.rev. 0.0% 10 1.3 1.4 1.3 1.7 0.2
4. AS15557 229.10.136.77.rev.s 0.0% 10 3.3 3.2 2.9 3.5 0.2
5. AS15557 229.10.136.77.rev.s 0.0% 10 2.7 2.9 2.7 3.3 0.2
6. AS15557 101.172.136.77.rev. 0.0% 10 2.8 2.9 2.8 3.2 0.1
7. AS12626 108.97.30.212.rev.s 0.0% 10 12.2 12.3 12.2 12.4 0.1
8. AS15557 226.244.79.86.rev.s 50.0% 10 44.5 45.3 37.1 51.2 5.9
9. AS12626 108.97.30.212.rev.s 10.0% 10 36.0 36.4 36.0 36.8 0.2
10. AS15557 226.244.79.86.rev.s 30.0% 10 72.6 71.2 63.2 77.1 4.5
11. AS12626 108.97.30.212.rev.s 10.0% 10 60.3 61.1 60.3 61.8 0.5
12. AS15557 226.244.79.86.rev.s 0.0% 10 99.2 99.2 91.8 107.1 4.6
13. AS12626 108.97.30.212.rev.s 30.0% 10 84.6 85.5 84.2 86.2 0.8
14. AS15557 226.244.79.86.rev.s 30.0% 10 119.6 120.9 116.9 125.6 3.2
15. AS12626 108.97.30.212.rev.s 40.0% 10 110.6 110.1 108.9 110.8 0.8
16. AS15557 226.244.79.86.rev.s 20.0% 10 145.1 147.8 142.7 153.0 3.5
17. AS12626 108.97.30.212.rev.s 10.0% 10 132.5 134.4 132.2 135.8 1.4
18. AS15557 226.244.79.86.rev.s 10.0% 10 170.9 173.3 163.3 180.4 5.5
19. AS12626 108.97.30.212.rev.s 40.0% 10 157.7 159.2 157.1 161.9 1.8
20. AS15557 226.244.79.86.rev.s 70.0% 10 196.3 201.8 196.3 206.0 5.0
21. AS12626 108.97.30.212.rev.s 20.0% 10 181.1 183.2 181.1 185.6 1.5
22. AS15557 226.244.79.86.rev.s 30.0% 10 222.1 218.4 207.4 231.0 8.0
23. AS12626 108.97.30.212.rev.s 30.0% 10 206.0 207.7 205.6 211.0 1.9
24. AS15557 226.244.79.86.rev.s 60.0% 10 247.8 242.6 236.0 247.8 4.9
25. AS12626 108.97.30.212.rev.s 40.0% 10 231.6 231.6 229.6 233.9 1.4
26. AS15557 226.244.79.86.rev.s 60.0% 10 268.0 264.8 259.6 270.4 5.2
27. AS12626 108.97.30.212.rev.s 60.0% 10 252.7 254.1 252.7 256.9 1.9
28. AS15557 226.244.79.86.rev.s 40.0% 10 296.9 292.5 286.4 298.4 5.1
29. AS12626 108.97.30.212.rev.s 50.0% 10 279.7 280.0 277.9 282.0 1.9
30. AS15557 226.244.79.86.rev.s 50.0% 10 312.1 312.5 308.4 315.9 2.8
-
DNS de CLoudFLare, donc pour ceux qui n'ont pas mis de DNS secondaire et qui utilisent ce serveur DNS, ils n'ont plus aucun accès à Internet.
Petite vidéo : A noter que la boucle est entre deux AS de SFR. 3 AS SFR apparaissent dans ce traceroute.
https://lafibre.info/videos/altice/202004_sfr_dns_cloudflare_inaccessible.mp4
-
Depuis le réseau de milywan via open vpn
1. AS??? 10.0.4.3 0.0% 10 0.2 0.3 0.2 0.4 0.0
2. AS??? te1.805.ccr1072.cor 50.0% 10 0.3 0.4 0.3 0.5 0.1
3. AS57199 te1.ccr1072.core.th 40.0% 10 0.4 0.4 0.4 0.5 0.0
4. AS57199 te4.2985.ccr1072.co 90.0% 10 0.8 0.8 0.8 0.8 0.0
5. AS??? cloudflare.par.fran 0.0% 10 3.1 3.4 2.2 11.9 3.0
6. AS13335 one.one.one.one 0.0% 10 2.1 2.0 1.9 2.1 0.1
Sinon sur le réseau cable idem que vous, traceroute qui fait des bouclrs
-
merci pour les explications vivien
-
... Merci SFR !
-
Pas de souci en cable de mon côté
adrien@MacBook-Pro-de-Adrien ~ % traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 64 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 16.005 ms 9.558 ms 8.982 ms
2 10.93.32.1 (10.93.32.1) 16.097 ms 16.047 ms 17.609 ms
3 195-132-5-190.rev.numericable.fr (195.132.5.190) 18.067 ms 17.153 ms 16.178 ms
4 172.19.132.146 (172.19.132.146) 28.745 ms 28.535 ms 26.470 ms
5 cloudflare.par.franceix.net (37.49.237.49) 28.637 ms 32.869 ms 52.334 ms
6 one.one.one.one (1.1.1.1) 27.568 ms 28.465 ms 26.921 ms
-
cbd69, tu n'aurais pas une IP AS21502 (Numericable) ?
Perso, je suis sur le réseau Numericable, mais avec une IP AS15557 (SFR).
Dans le sens sortant j'utilise les peering / transit de Numericable mais en entrée, j'utilise les peering / transit de SFR.
L'asymétrie est systématique.
-
cbd69, tu n'aurais pas une IP AS21502 (Numericable) ?
Perso, je suis sur le réseau Numericable, mais avec une IP AS15557 (SFR).
Dans le sens sortant j'utilise les peering / transit de Numericable mais en entrée, j'utilise les peering / transit de SFR.
L'asymétrie est systématique.
Vivien j'ai toujours été client Numericable depuis + de 10 ans, et j'ai une ip en 85.16*.*** sur l'AS21502
Comment voir les IP's de Numericable ? Le range coté NC
-
L'outil d'Hurricane Electric permet d'avoir facilement l'AS pour une IP.
Exemple avec mon IP : https://bgp.he.net/ip/93.29.248.0
Cela correspond à la plage IP 93.0.0.0/11 => C'est l'AS15557
-
Ce qui est étrange, c'est que 1.1.1.2 et 1.1.1.3 font partie du même bloc, et fonctionnent.
-
J'espère qu'il n'utilise pas 1.1.1.1 qq part sur leur réseau... ;D
On voit très souvent des box ou routeurs qui utilisent l'IP 1.1.1.1 pour du routage interne
-
Résolu (FTTH AS15557):
$ mtr -bzr 1.1.1.1
Start: 2020-04-23T22:42:04+0200
HOST: xxxxxxxxxxxxxxxxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.1 0.0% 10 0.6 0.5 0.4 0.6 0.1
2. AS15557 xxxxxxxxxxxxxxxxxxx 0.0% 10 0.9 0.9 0.9 1.0 0.0
3. AS15557 249.142.24.109.rev. 0.0% 10 1.4 1.4 1.2 1.5 0.1
4. AS15557 226.10.136.77.rev.s 0.0% 10 1.4 1.5 1.2 3.0 0.5
5. AS13335 141.101.67.254 0.0% 10 45.4 8.4 1.7 45.4 14.0
6. AS13335 one.one.one.one (1. 0.0% 10 1.1 1.1 1.0 1.2 0.1
-
J'ai pensé à ça, mais si c'était le cas est-ce que l'équipement en question ne devrait pas répondre ou bloquer le trafic au lieu de le router ?
Effectivement, c'est revenu à 22h10 ici.
-
Sans doute aucune idée une simple hypothèse.
Je me rappel qu'il y a quelques années maintenant j'avais posté un problème similaire de bouclage réseau mais vers un site du gov US.
J'ignore comment cela est possible.
-
$ mtr -bzr 1.1.1.1
Start: 2020-04-23T22:42:04+0200
HOST: xxxxxxxxxxxxxxxxxxx Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.1.1 0.0% 10 0.6 0.5 0.4 0.6 0.1
2. AS15557 xxxxxxxxxxxxxxxxxxx 0.0% 10 0.9 0.9 0.9 1.0 0.0
3. AS15557 249.142.24.109.rev. 0.0% 10 1.4 1.4 1.2 1.5 0.1
4. AS15557 226.10.136.77.rev.s 0.0% 10 1.4 1.5 1.2 3.0 0.5
5. AS13335 141.101.67.254 0.0% 10 45.4 8.4 1.7 45.4 14.0
6. AS13335 one.one.one.one (1. 0.0% 10 1.1 1.1 1.0 1.2 0.1
:o
Je ne savais pas qu'il y avait des parties du réseau SFR avec une latence si bonne et stable.
Quand on compare, moi qui ne suis pas si loin géographiquement, c'est beaucoup moins bon.
Certes les NRO ne semblent pas toujours reliés de la manière la plus logique, ici en partant dans la direction opposée à Paris, ce qui multiplie au moins la distance par trois, mais ça n'explique pas les variations entre pings successifs.
~ ᐅ mtr -bzr 1.1.1.1
Start: 2020-04-23T22:50:35+0200
HOST: TR Loss% Snt Last Avg Best Wrst StDev
1. AS??? box (192.168.1.1) 0.0% 10 0.4 0.3 0.3 0.5 0.1
2. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
3. AS15557 110.42.154.77.rev.s 0.0% 10 4.7 5.8 3.7 8.0 1.3
4. AS15557 221.10.136.77.rev.s 0.0% 10 5.2 6.4 4.6 8.6 1.3
5. AS13335 141.101.67.254 0.0% 10 5.1 8.8 4.9 15.6 4.2
6. AS13335 one.one.one.one (1. 0.0% 10 7.8 6.2 3.9 9.3 1.7
-
J'espère qu'il n'utilise pas 1.1.1.1 qq part sur leur réseau... ;D
On voit très souvent des box ou routeurs qui utilisent l'IP 1.1.1.1 pour du routage interne
imagine un test de route statique, un truc temporaire, ou qui ne devait pas fuiter d'un réseau interne...
Rien qu'à cause de tout ça les ip 2.2.2.2 et 2.3.4.5 sont blackholées en entrée du réseau d'orange. DDoS permanent d'IBN. De l'icmp, de l'udp, de l'ipsec (oui oui), bref, du bruit.
-
Pour ma part, j'avais rencontré des gros problème depuis mardi soir, 1.1.1.1 étant mon dns.
C'était tellement plus possible que j'ai remis Unbound depuis hier. C'était par intermittence mais trop visible car le problème se produisait a chaque résolution d'adresse et il m'était impossible d'utiliser un navigateur correctement.
-
J'ai en effet eu des soucis à la fois sur ma connexion câble mais aussi sur ma connexion FTTH (j'utilise bien les DNS de CloudFlare) mardi et surtout mercredi. Résolu depuis.
-
Bonjour,
pour ceux qui ont eu des problèmes, vous n'utilisez "que" 1.1.1.1 ?
vous n'avez pas mis 1.0.0.1 en secondaire (ou un DNS d'un autre service - Google, OpenDNS, Quad9, DNS FDN, ....).
-
cbd69, tu n'aurais pas une IP AS21502 (Numericable) ?
Perso, je suis sur le réseau Numericable, mais avec une IP AS15557 (SFR).
Dans le sens sortant j'utilise les peering / transit de Numericable mais en entrée, j'utilise les peering / transit de SFR.
L'asymétrie est systématique.
En effet je suis sur AS21502 :
Origin AS Announcement Description
AS21502 IRR Valid ROA Signed and Valid 89.2.0.0/15 SFR SA
-
Bonjour,
pour ceux qui ont eu des problèmes, vous n'utilisez "que" 1.1.1.1 ?
vous n'avez pas mis 1.0.0.1 en secondaire (ou un DNS d'un autre service - Google, OpenDNS, Quad9, DNS FDN, ....).
Si, j'ai bien 1.0.0.1 en secondaire.
-
Et du coup, tu as quand même eu des soucis de connexions ?
il ne bascule pas automatiquement sur le 2nd en cas de panne ?
-
Si mais je pense que je n'ai pas dû mettre les deux DNS sur toutes mes machines (flemmard que je suis) car cela n'a pas impacté tous mes ordis. Mais je comrprends mieux pourquoi maintenant.
-
Petit traceroute depuis ma connexion câble, c'est comme vous tous revenu, grâce a un salarié de SFR qui a réussi à escalader la chose (pas facile la veille d'un week-end avec confinement) :
$ mtr -bzrwc100 1.1.1.1
Start: 2020-04-24T15:30:41+0200
HOST: vivien Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.0.1) 0.0% 100 0.3 0.8 0.2 28.4 3.3
2. AS??? ? ? 100.0 100
3. AS21502 evy1rj-ge-1-1-5.200.numericable.net (195.132.10.177) 0.0% 100 7.0 8.3 5.9 30.8 3.7
4. AS15557 13.229.154.77.rev.sfr.net (77.154.229.13) 0.0% 100 7.5 7.3 5.9 10.2 0.8
5. AS15557 246.137.136.77.rev.sfr.net (77.136.137.246) 0.0% 100 8.6 8.6 7.5 15.6 1.0
6. AS15557 226.10.136.77.rev.sfr.net (77.136.10.226) 0.0% 100 10.8 9.3 8.2 12.8 0.8
7. AS15557 226.10.136.77.rev.sfr.net (77.136.10.226) 0.0% 100 9.3 8.8 7.9 11.3 0.6
8. AS13335 141.101.67.254 0.0% 100 11.0 17.8 9.1 81.7 15.2
9. AS13335 one.one.one.one (1.1.1.1) 0.0% 100 9.3 13.5 9.2 55.8 10.3
-
Sans doute aucune idée une simple hypothèse.
Je me rappel qu'il y a quelques années maintenant j'avais posté un problème similaire de bouclage réseau mais vers un site du gov US.
J'ignore comment cela est possible.
Ici : https://lafibre.info/sfr-espace-technique/probleme-de-routage-gt-tracert-nist-gov/
A l'époque, c'était un bug sur la nouvelle version (6.2.3) déployée sur un ASR9010.
Pour hier, j'ai l’impression que petrus n'est pas mal sur ses hypothèses.
-
Sinon pour revenir sur les DNS de cloudfare 1.1.1.1, le gain rapidité et confidentialité est significatif ? couplé à un vpn ?
-
cloudflare et confidentialité dans la même phrase, pas mal :)
https://iscloudflaresafeyet.com
-
cloudflare et confidentialité dans la même phrase, pas mal :)
https://iscloudflaresafeyet.com
Ouais, en même temps, moi aussi j'aurais pu pondre une page sur Internet avec un article à charge.
La phrase marrante de la page : Instead of the user directly connecting to the intended website, the user is connected to Cloudflare's servers instead.
Voil, tout est dit ;D
-
Vu que CF agit en tant que reverse proxy pour pas mal de sites, cette phrase est parfaitement vraie ;)
-
Vu que CF agit en tant que reverse proxy pour pas mal de sites, cette phrase est parfaitement vraie ;)
Je n'ai pas dit qu'elle nétait pas vraie, si tu suis mon raisonnement ;)
-
Pour ce qui est de la vie privée, je ne connais pas mieux que DNS_over_TLS aka DoT (http://"https://en.wikipedia.org/wiki/DNS_over_TLS").
Avec comme fournisseur de DNS chiffré, LDN rattaché à FDN, Quad9 et beaucoup d'autres.
Ça se fait en quelques minutes sous Debian et Debian likes avec
apt install stubby
systemctl enable stubby
vi /etc/stubby/stubby.yml
systemctl restart stubby
echo 'nameserver 127.0.0.1' > /etc/resolv.conf
chattr +i /etc/resolv.conf
Ça me parait être une meilleur solution que les DNS de Cloudfare, google, FAI
-
Il y a une autre solution qui est d'installer son propre résolveur en local. Comme cela on n'interroge personne, et les requêtes ne passent pas par un serveur centralisé. Car même en TLS, c'est déchiffré au bout sur le serveur.
Et installer un résolveur local, c'est très simple avec unbound :
https://korben.info/installer-serveur-dns-unbound.html
-
Que se passe-t-il pour les serveurs racines si tout le monde les pointent?
-
Que se passe-t-il pour les serveurs racines si tout le monde les pointent?
En fait, tu les as en cache, ce sont les serveurs des domaines (free.fr...) surtout que tu interroges. Et heureusement que les serveurs racine ne tombent pas facilement, car ils seraient attaqués souvent.
-
Unbound pointe directement les racines, non?
Si tout le monde passe sur Unbound local, les serveurs racines tiennent?
-
Ton serveur local interroge les serveurs racines en clair
-
Les serveurs racine sont massivement distribués. Pas de soucis de ce coté là.
Mais oui, idéalement il faut faire tourner un resolver par réseau, pas un par machine, ça ne sert pas à grand chose et c'est même plutôt préjudiciable (moins d'utilisation du cache, plus de fingerprinting possible d'un seul utilisateur en analysant les requetes...).
Le faire tourner sur le routeur, ou un serveur si on en a un, c'est mieux.
-
Mais oui, idéalement il faut faire tourner un resolver par réseau, pas un par machine, ça ne sert pas à grand chose et c'est même plutôt préjudiciable (moins d'utilisation du cache, plus de fingerprinting possible d'un seul utilisateur en analysant les requetes...).
Et il faut qu'il soit en DoH pour pouvoir activer l'ESNI dans Firefox.
-
Il y a une autre solution qui est d'installer son propre résolveur en local. Comme cela on n'interroge personne, et les requêtes ne passent pas par un serveur centralisé. Car même en TLS, c'est déchiffré au bout sur le serveur.
Là tout est en clair à la sortie de ton PC.
Avec du DoH, tout est chiffré jusqu'au serveur central. Il faut donc avoir confiance dans celui-ci mais si c'est le cas impossible pour un attaquant de savoir les requêtes que tu as demandé, a condition que le serveur DoH soit mutualisé avec de nombreuses personnes.
-
C'est possible à faire avec unbound :
https://medspx.fr/blog/Sysadmin/unbound/
https://www.bortzmeyer.org/doh-mon-resolveur.html
D'autre part, mes requêtes ne passent pas par mon fournisseur d'accès, Google, ou cloudflare, et surtout ne me mentent pas. C'est un gros progrès pour la vie privée. Et elles sont très rapides, alors qu'un serveur DNS peut être engorgé, être lent à répondre.
-
C'est possible à faire avec unbound :
https://medspx.fr/blog/Sysadmin/unbound/
https://www.bortzmeyer.org/doh-mon-resolveur.html
D'autre part, mes requêtes ne passent pas par mon fournisseur d'accès, Google, ou cloudflare, et surtout ne me mentent pas. C'est un gros progrès pour la vie privée. Et elles sont très rapides, alors qu'un serveur DNS peut être engorgé, être lent à répondre.
Si tu utilises les serveurs racine, tes requêtes sont visibles en clair sur le réseau, donc ton fournisseur d'accès les voit.
L'architecture DNS fait qu'on est obligé de faire confiance à au moins un intermédiaire fournisseur de DoT/DoH, ou à son FAI (voire un peu des deux selon la situation).
-
Si tu utilises les serveurs racine, tes requêtes sont visibles en clair sur le réseau, donc ton fournisseur d'accès les voit.
Ou peut les voir, cela m'étonnerait quand même qu'il analyse et enregistre tout le trafic qui peut passer par lui ! Tandis que les requêtes DNS, alors là pas sûr du tout, et Google encore moins.
A ce propos, je trouve regrettable que Firefox, dans ses dernières versions insiste pour que la barre d'adresse soit aussi une barre de recherche Google, ce que j'avais explicitement désactivé. Alors que Firefox se targue du respect de la vie privée. Il a fallu que je retourne dans les options pour le re-désactiver.
-
Pour la vitesse, quand on utilise un résolveur DNS tel que celui de son FAI, on a généralement une meilleur latence car le gros des requêtes sont en cache (vous n’êtes pas le seul à aller voir le site toto.fr) et le DNS de votre FAI est généralement le plus proche au niveau latence (ils sont régionalisés chez certains FAI)
Quand on a un résolveur DNS sur sa propre machine, un site qui n'a pas été visité les dernières minutes n e sera pas en cache et il faudra faire une demande au DNS autoritaire.
-
En tout cas, au feeling, je trouve que mes résolutions DNS sont très rapides, et je ne suis jamais impacté par les problèmes de résolution DNS de mon FAI, ce qui est un problème récurrent (il n'y a qu'à voir le nombre de sujets sur ce forum).
-
Les DNS opérateurs peuvent permettre d'accéder aux caches "onnet" aussi.
-
Salut,
je viens de de tester à mon tour 8) ... et tout semble ok
il va donc de soi que la page web est accessible ;-)
- pensez à clearer vos cache DNS.
- pensez à installer DNScrypt sur vos poste... ça peut aider
- il y a d'autres DNS alternatifs gratuit
Enfin passez donc sur LINUX ( ubuntu ou fedora / centos / debian : GNOME a fait d'énormes progrès )
-
nouveau test sur le nom de domaine one.one.one.one : c'est le DNS secondaire 1.0.0.1 qui répond ...
( il y avait le même problème chez orange fibre avec la livebox4 MAIS PAS sur livebox5
-
Avec une connexion câble :
traceroute to one.one.one.one (1.1.1.1), 30 hops max, 38 byte packets
1 192.168.5.1 (192.168.5.1) 0.49 ms 0.485 ms 0.441 ms
2 192.168.0.1 (192.168.0.1) 1.336 ms 1.06 ms 1.285 ms
3 10.71.192.1 (10.71.192.1) 12.812 ms 8.888 ms 7.848 ms
4 213-245-255-217.rev.numericable.fr (213.245.255.217) 13.415 ms 8.481 ms 7.589 ms
5 172.19.132.146 (172.19.132.146) 23.925 ms 24.264 ms 19.607 ms
6 cloudflare.par.franceix.net (37.49.237.49) 18.338 ms 18.198 ms 25.285 ms
7 one.one.one.one (1.1.1.1) 16.92 ms 16.512 ms 17.784 ms
-
nouveau test sur le nom de domaine one.one.one.one : c'est le DNS secondaire 1.0.0.1 qui répond ...
Il n'y a pas de primaire et de secondaire ...Il y a 2 entrées A pour le domaine one.one.one.one tu peux tomber sur l'un ou l'autre..
https://toolbox.googleapps.com/apps/dig/#A/one.one.one.one
je tombe aussi sur 1.0.0.1 avec Bouygues d'ailleurs ... et 10 min plus tard sur 1.1.1.1 ... (il faut attendre plusieurs minutes ou faire un ipconfig /flushdns )
-
1) ce n’est pas le sujet ( faut bien lire l’intitulé du post de départ).
2) t’as ton interprétation de la résolution dns.
-
Montres les impr/ecr de tes essais
c'est bon tu me crois ?
-
1) ce n’est pas le sujet ( faut bien lire l’intitulé du post de départ).
2) t’as ton interprétation de la résolution dns.
1) tout comme ton post https://lafibre.info/sfr-espace-technique/routage-vers-1-1-1-1/msg754111/#msg754111 alors ...
2) Je crois que tu ne comprends pas ce que tu fais quand tu fais un tracert vers one.one.one.one ....
-
pour les esprits lents et contradictoires qui n'apportent rien au sujet, rappel de celui-ci
SFR: Routage vers 1.1.1.1 problématique
;D
-
beh non, c'est pas le plaisir de la contradiction c'est une question de logique.
En faisant un traceroute vers one.one.one.one ça ne correspond pas au sujet car
one.one.one.one renvoie vers 2 adresses IP (1.0.0.1 ET 1.1.1.1).
Donc si tu veux être sur de faire un traceroute vers 1.1.1.1, il faut taper
tracert 1.1.1.1
et pas
tracert one.one.one.one
Si tu tapes tracert one.one.one.one tu as 50 % de chances de faire un traceroute vers 1.1.1.1 et 50 % de chance de faire une traceroute vers 1.0.0.1 (ce que tu as obtenu.)
Avant de me qualifier ainsi, pour les esprits lents et contradictoires
il faudrait que tu comprennes les commandes que tu tapes et ce qu'il se passe réellement...
en l’occurrence, dans ton post : https://lafibre.info/sfr-espace-technique/routage-vers-1-1-1-1/msg754111/#msg754111 tu as fait un traceroute vers 1.0.0.1 à la 2eme ligne.. et ça n'a aucun rapport avec un quelconque DNS 1.1.1.1 qui ne répond pas..
NB : ça fait 6 jours que l'incident est clos chez SFR..
-
Désolé pour tout :-X
Si l'incident est clos chez SFR. Faut clore ce sujet.
-
Depuis la nuit de mercredi à jeudi, les routes vers 1.1.1.1 et 1.0.0.1 passent par Level3 pour joindre Cloudflare à Londres, avec parfois des pertes de paquets.
Pour mozilla.cloudflare-dns.com, ce n'est pas le cas, malgré un ping moyen très légèrement plus élevé qu'attendu, à 8ms.
En testant une autre adresse AnyCast utilisée pour les DNS, 9.9.9.9, elle passe par LyonIX alors que Quad9 est censé être sur FranceIX.
-
Exact, chez moi aussi je vais à Londres pour 1.1.1.1, mais pour https://speed.cloudflare.com/ je vais à Paris.
$ mtr -zrwc100 1.1.1.1
Start: 2020-06-02T22:16:37+0200
HOST: vivien1 Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 100 0.4 0.4 0.3 3.0 0.4
2. AS??? ? ? 100.0 100
3. AS21502 evy1rj-ge-1-1-5.200.numericable.net 0.0% 100 7.0 7.4 6.0 26.5 2.4
4. AS15557 13.229.154.77.rev.sfr.net 0.0% 100 8.2 7.7 6.4 14.1 0.9
5. AS15557 246.137.136.77.rev.sfr.net 0.0% 100 8.5 13.7 7.7 52.3 10.5
6. AS15557 102.244.5.109.rev.sfr.net 0.0% 100 9.4 10.9 8.5 45.1 4.9
7. AS15557 102.244.5.109.rev.sfr.net 0.0% 100 9.1 9.3 8.3 13.5 0.8
8. AS3356 lag-5.ear3.Paris1.Level3.net 0.0% 100 18.3 10.7 8.1 24.4 3.8
9. AS3356 ae-2-52.ear3.London2.Level3.net 41.0% 100 14.8 16.1 14.8 26.1 1.8
10. AS3356 195.50.116.34 0.0% 100 17.2 18.7 16.0 30.5 3.5
11. AS13335 one.one.one.one 0.0% 100 15.2 16.1 15.0 43.1 2.8
-
Depuis SFR FTTH a Marseille je passe bien par France-IX "Marseille" ? ping de 13 c'est plutot Paris
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms box [192.168.1.1]
2 1 ms 1 ms 1 ms 49.13.136.77.rev.sfr.net [77.136.13.49]
3 1 ms 2 ms 1 ms 102.89.136.77.rev.sfr.net [77.136.89.102]
4 5 ms 5 ms 5 ms 66.10.136.77.rev.sfr.net [77.136.10.66]
5 4 ms 5 ms 5 ms 66.10.136.77.rev.sfr.net [77.136.10.66]
6 12 ms 13 ms 12 ms cloudflare.mrs.franceix.net [37.49.232.29]
7 13 ms 13 ms 13 ms one.one.one.one [1.1.1.1]
-
c'est étonnant que tu remontes jusque Paris pour 1.1.1.1 ... Depuis Bouygues, je sors à Marseille et j'ai un ping de 8 ms sur 1.1.1.1
1 bbox.lan (192.168.1.254) 2.118 ms 4.136 ms 1.340 ms
2 i19-les01-t2-31-37-192-2.sfr.lns.abo.bbox.fr (31.37.192.2) 5.382 ms 7.136 ms 15.297 ms
3 62.34.2.36 (62.34.2.36) 4.592 ms 5.894 ms 4.734 ms
4 * 62.34.2.41 (62.34.2.41) 5.877 ms 4.840 ms
5 * * *
6 * lag24.rpt02-mrs.net.bbox.fr (212.194.170.56) 9.874 ms 10.000 ms
7 * * *
8 one.one.one.one (1.1.1.1) 9.286 ms 8.764 ms 8.567 ms
-
cloudflare.mrs.franceix.net répond, mais pas cloudflare.par.franceix.net.
141.101.67.254, qui était le dernier saut avant 1.1.1.1 sur certains traceroute (ceux qui n'avaient pas cloudflare.par.franceix.net, et qui passaient donc directement de l'AS SFR à Cloudflare) est fonctionnel, et utilisé pour mozilla.cloudflare-dns.com par exemple.
-
J’ai vu ça également !
-
Pareil depuis K-net :
tracert 1.1.1.1
Détermination de l’itinéraire vers one.one.one.one [1.1.1.1]
avec un maximum de 30 sauts :
1 <1 ms <1 ms <1 ms k-box.home [192.168.1.1]
2 3 ms 2 ms 2 ms 74.covage [10.2.0.177]
3 * * * Délai d’attente de la demande dépassé.
4 11 ms 11 ms 11 ms k-net-5.covage [10.2.0.5]
5 12 ms 11 ms 11 ms te0-6-0-2-4.agr21.par04.atlas.cogentco.com [149.11.174.129]
6 11 ms 11 ms 11 ms be3169.ccr31.par04.atlas.cogentco.com [154.54.37.237]
7 12 ms 12 ms 12 ms be3184.ccr42.par01.atlas.cogentco.com [154.54.38.157]
8 17 ms 17 ms 17 ms be3675.rcr21.bru01.atlas.cogentco.com [154.54.57.166]
9 18 ms 18 ms 18 ms cloudflare.demarc.cogentco.com [149.11.170.82]
10 17 ms 17 ms 17 ms one.one.one.one [1.1.1.1]
Itinéraire déterminé.
-
Corrigé ce matin à 6h !
Pour le ping, j'ai déjà vu mieux, mais ça va.
Start: 2020-06-04T19:30:52+0200
HOST: i7 Loss% Snt Last Avg Best Wrst StDev
1.|-- i7 0.0% 100 0.2 0.2 0.2 0.4 0.0
2.|-- box 0.0% 100 1.2 1.2 1.0 2.6 0.2
3.|-- ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
4.|-- 110.42.154.77.rev.sfr.net 1.0% 100 6.1 6.4 3.9 9.5 1.4
5.|-- 221.10.136.77.rev.sfr.net 0.0% 100 7.0 7.6 5.2 11.2 1.4
6.|-- 141.101.67.254 0.0% 100 6.2 15.0 5.9 38.8 9.7
7.|-- one.one.one.one 0.0% 100 9.4 7.3 5.0 9.6 1.3
-
Bonjour
Juste un mot parce que j'ai lu plus haut dans le sujet qu'avec un serveur local de DNS les requêtes DNS passaient en clair, je dirais qu'avec Unbound c'est oublier DNSSec/DNScrypt non ? ça ne chiffre pas les requêtes DNS ?
-
Non, c'est en clair (le mieux pour vérifier c'est une capture Wireshark)
DNSSec ce sont des extensions pour authentifier la réponse, mais c'est en clair.
-
.../...
En testant une autre adresse AnyCast utilisée pour les DNS, 9.9.9.9, elle passe par LyonIX alors que Quad9 est censé être sur FranceIX.
Il y a une instance quad9 sur LyonIX.
-
Excellent.
Traceroute depuis Adeli (Ain) :
$ mtr -zrwc100 dns9.quad9.net
Start: Sat Jun 13 16:33:40 2020
HOST: lafibre Loss% Snt Last Avg Best Wrst StDev
1. AS43142 bgp2.adeli.biz 0.0% 100 0.2 0.2 0.2 0.3 0.0
2. AS??? pch-as42.ix.lyonix.net 0.0% 100 2.0 2.0 1.6 7.9 0.6
3. AS19281 2620:fe::fe:9 0.0% 100 1.8 2.2 1.7 6.6 0.8
Traceroute depuis Bouygues (Lyon) :
$ mtr -zrwc100 dns9.quad9.net
Start: 2020-06-13T16:33:26+0200
HOST: lyo Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:de11:100::1 0.0% 100 0.6 0.9 0.6 11.3 1.1
2. AS5410 2001:860:bbe0:108::1 0.0% 100 0.2 0.4 0.2 0.8 0.1
3. AS5410 la10.bsr01-cbv.ipv6.net.bbox.fr 0.0% 100 0.5 0.4 0.3 0.9 0.1
4. AS??? pch-as42.ix.lyonix.net 0.0% 100 1.3 1.7 1.1 10.6 1.4
5. AS19281 dns9.quad9.net 0.0% 100 1.3 1.7 1.1 20.0 1.9
Et à Paris on va bien sur Paris : (ci-dessous Bouygues Paris)
$ mtr -zrc100 dns9.quad9.net
Start: 2020-06-13T16:39:05+0200
HOST: ubuntu Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:f70a::1 0.0% 100 0.5 0.5 0.4 3.4 0.3
2. AS5410 2001:860:bbee:da::1 0.0% 100 1.1 1.0 0.9 1.4 0.1
3. AS??? pch1.par.franceix.n 10.0% 100 2.6 2.0 1.7 4.8 0.4
4. AS19281 dns9.quad9.net 0.0% 100 1.3 1.1 1.1 1.6 0.1
(un truc qui fonctionne bien comme ça c'est cool)
-
Et à Paris on va bien sur Paris : (ci-dessous Bouygues Paris)
...
(un truc qui fonctionne bien comme ça c'est cool)
Justement, si j'en parlais, c'est que depuis SFR ça va sur Lyon, alors que ça devrait aller sur Paris.
$ mtr -zrwc100 9.9.9.9
Start: 2020-06-13T20:26:58+0200
HOST: i7 Loss% Snt Last Avg Best Wrst StDev
1. AS??? box 0.0% 100 1.2 1.2 0.8 3.4 0.2
2. AS15557 1.55.95.92.rev.sfr.net 78.0% 100 8354. 8858. 7969. 9969. 702.9
3. AS15557 110.42.154.77.rev.sfr.net 0.0% 100 3.7 6.3 3.7 13.8 1.6
4. AS15557 30.12.6.109.rev.sfr.net 0.0% 100 21.0 16.6 10.9 25.3 2.8
5. AS??? pch-as42.ix.lyonix.net 0.0% 100 14.2 14.5 11.2 60.6 5.2
6. AS19281 dns9.quad9.net 0.0% 100 13.2 13.5 10.4 18.4 1.5
-
Je confirme, chez moi (client SFR câble) cela va aussi sur Lyon, alors que je suis à coté de Paris.
$ mtr -zrwc100 9.9.9.9
Start: 2020-06-13T21:59:39+0200
HOST: vivien1 Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 100 0.3 0.3 0.3 0.5 0.1
2. AS??? ? ? 100.0 100
3. AS21502 evy1rj-ge-1-1-5.200.numericable.net 0.0% 100 7.0 6.9 4.1 28.7 2.4
4. AS8228 197.117.223.213.rev.sfr.net 0.0% 100 6.7 7.4 6.6 8.5 0.4
5. AS15557 30.12.6.109.rev.sfr.net 0.0% 100 17.3 20.5 13.8 54.6 7.2
6. AS??? pch-as42.ix.lyonix.net 0.0% 100 13.9 15.4 13.1 42.0 3.8
7. AS19281 dns9.quad9.net 0.0% 100 15.1 14.7 11.0 20.0 0.9
Je n'ai pas mis le traceroute Bouygues en IPv4, mais cela ne marche pas, cela va systématiquement sur Paris en IPv4.
Maintenant ce n'est pas simple pour un opérateur et j'ai été très étonné que cela fonctionne chez Bouygues en IPv6, il y a moins de deux ans LyonIX était un aspirateur en IPv4 mais surtout en IPv6 : tout ce qui était en peering sur Lyon était priorisé pour le trafic sortant (uniquement en sortant) et les acquittements pour plus de 100 Gb/s de trafic entrant (qui lui ne passait par LyonIX) s'écoulait par LyonIX.
Exemple de traceroute Bouygues Paris => Gandi Paris qui passe par LyonIX en 2015 (et beaucoup d'opérateurs alors qu'il y a un peering sur Paris entre Bouygues et Gandi)
Orange annonce tout Hopus à Bouygues Telecom sur le peering de Lyon
Petit traceroute Bouygues Telecom (Bbox câble sur Paris) => Gandi (Paris)
Réseau Numericable => Collecte Bouygues Telecom sur Courbevoie (ncc-cbv.net.bbox.fr) => Lyon IX => Perring avec AS3215 sur Lyon-IX=> Hopus Lyon => Hopus Paris => Gandi
$ mtr -rwc100 gandi.net
Start: Sat Sep 26 12:08:48 2015
HOST: vivien Loss% Snt Last Avg Best Wrst StDev
1.|-- bbox.lan 0.0% 100 5.9 3.2 0.9 22.4 4.1
2.|-- 10.112.0.1 0.0% 100 10.3 11.5 7.4 57.5 6.1
3.|-- eps1rj-ge-0-1-5.100.numericable.net 0.0% 100 10.1 12.6 7.8 38.4 5.1
4.|-- ip-53.net-80-236-1.static.numericable.fr 1.0% 100 22.2 13.2 7.8 39.9 6.8
5.|-- ip-49.net-80-236-1.static.numericable.fr 0.0% 100 12.4 11.5 8.2 23.7 2.9
6.|-- lag101.350.ncc-cbv.net.bbox.fr 1.0% 100 10.8 17.0 8.6 81.2 12.4
7.|-- ? ? 100.0 100
8.|-- la10.bsr02-cbv.net.bbox.fr 66.0% 100 12.4 13.3 10.3 23.7 2.9
9.|-- be16.cbr01-cro.net.bbox.fr 0.0% 100 18.5 15.7 11.5 25.3 3.1
10.|-- be5.cbr01-lyo.net.bbox.fr 1.0% 100 26.7 24.1 18.2 38.7 4.1
11.|-- la44.bsr01-lyo.net.bbox.fr 89.0% 100 23976 23339 21638 24386 901.6
12.|-- la10.bsr02-lyo.net.bbox.fr 1.0% 100 18.6 20.8 16.2 61.3 6.1
13.|-- 193.253.13.85 0.0% 100 20.9 22.2 17.4 79.0 8.1
14.|-- 193.252.227.98 0.0% 100 20.4 22.1 17.9 44.8 4.9
15.|-- lag-pop-ly-1.th2-1.rt.hopus.net 0.0% 100 19.7 22.0 17.7 34.7 3.8
16.|-- lag-pop-th2-1.std-1.rt.hopus.net 0.0% 100 34.7 22.3 18.0 43.6 4.3
17.|-- gandi.std-1.rt.hopus.net 0.0% 100 25.2 25.5 18.2 51.6 6.4
18.|-- xe0-0-2-2-core3-d.paris.gandi.net 0.0% 100 20.0 22.3 18.3 39.6 3.8
19.|-- xe1-6-5-gdist3-d.paris.gandi.net 0.0% 100 27.1 22.7 18.3 52.3 4.7
20.|-- website.vip.gandi.net 0.0% 100 19.1 22.7 17.4 72.3 7.5
Note : 193.253.13.85 et 193.252.227.9 sont des IP appartenant à Orange AS3215
-
Quitte à choisir, j'ai troqué les DNS de Cloudfare par les DNS de FDN !
Et il me semble pour ma part plus cohérent !
Et très légèrement plus rapide ...
-
Quitte à choisir, j'ai troqué les DNS de Cloudfare par les DNS de FDN !
Et il me semble pour ma part plus cohérent !
Et très légèrement plus rapide ...
FDN n'a pas de DoH, du coup c'est en clair et pas d'ESNI dans Firefox, c'est dommage.
-
Cloudfare passe de nouveau par LONDRES ...
-
Cloudfare passe de nouveau par LONDRES ...
Depuis vendredi, donc c'est peut-être lié aux soucis de Cloudflare.
Les routes anycast semblent plus longues à rétablir, ce n'est pas la première fois.
-
On me dit que le DNS 1.1.1.1 de Cloudflare est à nouveau inaccessible sur SFR depuis environ 1 heure
=> https://twitter.com/fvoron/status/1324327238423220228
-
Je confirme, pour 1.1.1.1 : TTL exceeded
Son compère 1.0.0.1 est toujours routé correctement :
Start: 2020-11-05T14:33:23+0100
HOST: bl Loss% Snt Last Avg Best Wrst StDev
1. AS??? 172.16.1.1 0.0% 5 0.3 0.2 0.2 0.3 0.0
2. AS??? ??? 100.0 5 0.0 0.0 0.0 0.0 0.0
3. AS15557 77.154.114.82 0.0% 5 3.0 3.2 3.0 3.5 0.2
4. AS15557 77.136.10.129 0.0% 5 4.4 4.7 4.3 5.5 0.5
5. AS15557 77.136.10.129 0.0% 5 4.6 4.5 4.0 4.9 0.4
6. AS??? 37.49.237.49 0.0% 5 18.8 18.2 7.8 35.9 10.7
7. AS13335 1.0.0.1 0.0% 5 4.6 5.1 4.6 5.8 0.5
-
Je confirme, inaccessible aussi via 4G
-
Résolu