La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => Opérateurs grand public alternatifs => 
MilkyWan => Discussion démarrée par: maximushugus le 04 octobre 2021 à 17:54:20
-
Bonjour,
J'ai une petite question.
Depuis quelques jours je me suis rendu compte que le ping vers l'endpoint de mon tunnel GRE chez MilkyWan était moins bon que d'habitude : je le ping en 11 ou 12 ms contre 3 en temps normal.
Je précise que je suis chez SFR en région lyonnaise et que l'endpoint (le routeur) de MilkyWan se situe également en région lyonnaise.
J'ai donc fait un traceroute vers l'endpoint :
tracert 80.67.167.31
Détermination de l’itinéraire vers lo0.rb4011.col.vnx.infra.ip4.milkywan.net [80.67.167.31]
avec un maximum de 30 sauts :
1 <1 ms 1 ms <1 ms pfSense.home.arpa [192.168.3.1]
2 4 ms 2 ms 2 ms 69cba1-nro-2.nro.gaoland.net [109.24.76.77]
3 2 ms 2 ms 3 ms 197.142.24.109.rev.sfr.net [109.24.142.197]
4 11 ms 12 ms 12 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
5 11 ms 9 ms 25 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
6 14 ms 17 ms 15 ms milkywan.mrs.franceix.net [37.49.232.24]
7 10 ms 10 ms 10 ms milkywan-l2.peers.lyonix.net [77.95.71.132]
8 12 ms 12 ms 11 ms lo0.rb4011.col.vnx.infra.ip4.milkywan.net [80.67.167.31]
Itinéraire déterminé.
De ce que je comprends je pars de Lyon chez SFR jusqu'à Marseille avant de revenir sur Lyon...
Est-ce normal ?
D'ailleurs je ne savais pas que MilkyWan avait un POP à Marseille ?
J'ai également essayé de faire le traceroute vers l'endpoint (mon ancien) à Paris :
tracert 80.67.167.26
Détermination de l’itinéraire vers lo0.rb4011.col.cbo.infra.ip4.milkywan.net [80.67.167.26]
avec un maximum de 30 sauts :
1 1 ms <1 ms 1 ms pfSense.home.arpa [192.168.3.1]
2 4 ms 1 ms 1 ms 69cba1-nro-2.nro.gaoland.net [109.24.76.77]
3 6 ms 6 ms 6 ms 197.142.24.109.rev.sfr.net [109.24.142.197]
4 13 ms 10 ms 11 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
5 10 ms 11 ms 11 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
6 15 ms 16 ms 16 ms milkywan.mrs.franceix.net [37.49.232.24]
7 17 ms 14 ms 16 ms po1.1262.ces2024.core.cbo.bb.ip4.milkywan.net [80.67.167.134]
8 16 ms 15 ms 16 ms lo0.rb4011.col.cbo.infra.ip4.milkywan.net [80.67.167.26]
Itinéraire déterminé.
Je passe de Lyon par Marseille pour aller à Paris...
Quelqu'un pourrait-il m'éclairer ?
-
Hello,
SFR préfère nous joindre par Marseille (en réalité Paris pour nous) que par Lyon, où nous avons une session de peering. C'est dommage, mais je n'y peux rien :(
-
Ok pas de soucis :)
Je croyais (probablement à tort) que le principe du BGP entre les AS c'était faire peering/transit mais aussi pour choisir la route la plus courte/efficace automatiquement : visiblement il y a une bonne part humaine quand même
-
L'algo de sélection de la "meilleur" route en BGP (https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#anc2) permet pas mal d'ajustement manuel.
Il y a toujours de la politique associé aux frontières, même si elles sont virtuelles.
-
A priori SFR a rétabli un routage plus direct:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.254 - 1 | 4247 | 4246 | 0 | 0 | 22 | 0 |
| 69all1-nro-1.nro.gaoland.net - 1 | 4099 | 4059 | 0 | 1 | 45 | 1 |
| 109.51.20.93.rev.sfr.net - 1 | 4142 | 4113 | 0 | 1 | 43 | 1 |
| 96.147.6.194.rev.sfr.net - 1 | 4153 | 4128 | 0 | 1 | 73 | 1 |
| 96.147.6.194.rev.sfr.net - 1 | 4112 | 4075 | 0 | 1 | 39 | 1 |
| milkywan-l2.peers.lyonix.net - 1 | 4133 | 4103 | 0 | 1 | 46 | 1 |
|lo0.rb4011.col.vnx.infra.ip4.milkywan.net - 1 | 4142 | 4113 | 0 | 1 | 41 | 1 |
|________________________________________________|______|______|______|______|______|______|
-
Oui c'est le cas chez moi aussi effectivement.
Je me demande si la vue de ce topic par quelqu'un chez SFR n'y serait pas étrangère ?
-
C’est possible, c’est tout aussi probable qu’il ai effectué des maintenances sur Vénissieux et ai donc re-routé le trafic un moment.
-
Depuis hier j'ai remarqué que depuis Lyon le trafic vers Milkywan à Venissieux (donc a côté) passe par Paris :
tracert 80.67.167.31
Détermination de l’itinéraire vers lo0.rb4011.col.vnx.infra.ip4.milkywan.net [80.67.167.31]
avec un maximum de 30 sauts :
1 1 ms <1 ms <1 ms pfSense.home.arpa [192.168.3.1]
2 5 ms 5 ms 4 ms 69lyo1-nro-1.nro.gaoland.net [109.24.76.41]
3 4 ms 5 ms 8 ms 193.142.24.109.rev.sfr.net [109.24.142.193]
4 14 ms 11 ms 11 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
5 15 ms 13 ms 13 ms 40.147.6.194.rev.sfr.net [194.6.147.40]
6 15 ms 19 ms 18 ms milkywan.par.franceix.net [37.49.236.27]
7 10 ms 13 ms 10 ms tfe1.2986.ccr2004.edge.vnx.bb.ip4.milkywan.net [80.67.167.247]
8 10 ms 14 ms 12 ms lo0.rb4011.col.vnx.infra.ip4.milkywan.net [80.67.167.31]
Est ce que ça pourrait venir du changement récent (avant hier je crois) de routeur de Milkywan à Vénissieux avec une route qui a été modifiée du fait de l'interruption de service le temps du changement ? Ce serait temporaire dans ce cas
-
J'en doute :
a7050sx.edge.vnx#show ip bgp neighbors 77.95.71.13 advertised-routes
BGP routing table information for VRF default
Router identifier 80.67.167.2, local AS number 57199
Route status codes: s - suppressed, * - valid, > - active, E - ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast, q - Queued for advertisement
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI Origin Validation codes: V - valid, I - invalid, U - unknown
AS Path Attributes: Or-ID - Originator ID, C-LST - Cluster List, LL Nexthop - Link Local Nexthop
Network Next Hop Metric AIGP LocPref Weight Path
* > 45.13.104.0/22 77.95.71.132 - - - - 57199 ?
* > 80.67.167.0/24 77.95.71.132 - - - - 57199 ?
-
Je relance/mets à jour le sujet : le peering en local de Lyon vers Milkywan chez SFR semble toujours passer par Paris :
Voici un traceroute depuis chez moi (région lyonnaise) vers Milkywan sur Vénissieux :
tracepath -b 80.67.167.31
1?: [LOCALHOST] pmtu 1500
1: _gateway (192.168.3.1) 0.761 ms
2: 69lyo1-nro-1.nro.gaoland.net (109.24.76.41) 3.711 ms
3: 193.142.24.109.rev.sfr.net (109.24.142.193) 4.546 ms asymm 4
4: 40.147.6.194.rev.sfr.net (194.6.147.40) 10.430 ms asymm 5
5: 40.147.6.194.rev.sfr.net (194.6.147.40) 12.272 ms
6: milkywan.par.franceix.net (37.49.236.27) 17.714 ms
7: te1.2986.a7050sx.edge.vnx.bb.ip4.milkywan.net (80.67.167.247) 13.161 ms asymm 5
8: lo0.rb4011.col.vnx.infra.ip4.milkywan.net (80.67.167.31) 13.010 ms reached
Voici également le traceroute depuis le site peering de SFR (http://peering.sfr.net/index.php?task=lg (http://peering.sfr.net/index.php?task=lg)) en partant de Lyon vers Milkywan Vénissieux :
traceroute to 80.67.167.31 (80.67.167.31), 30 hops max, 60 byte packets
1 109.0.65.1 [AS198949/AS15557] 0.392 ms 0.513 ms 0.600 ms
2 80.118.202.245 [AS198949/AS15557] 0.780 ms 0.950 ms 84.96.234.161 [AS198949/AS15557] 0.955 ms
3 194.6.147.40 [AS198949/AS8228] 9.473 ms 9.435 ms 9.464 ms
4 194.6.147.40 [AS198949/AS8228] 9.053 ms 9.026 ms 9.106 ms
5 37.49.236.27 [AS57734] 7.791 ms 7.795 ms 7.789 ms
6 80.67.167.247 [AS57199] 7.883 ms 7.820 ms 7.870 ms
7 80.67.167.31 [AS57199] 7.739 ms 7.681 ms 7.649 ms
Je ne sais pas si de notre côté on peut le signaler à SFR pour qu'ils rétablissent un peering plus local (via le site mentionné plus haut dans le "request form") ?
En dehors de ça petit retour d’expérience depuis un tunnel chez Milkywan : cela fonctionne super bien, je recommande chaudement :)
-
J'ai fait un mail au NOC SFR, on verra bien
-
Merci (j'avoue que le message était surtout destiné à SFR plus qu'à toi, à ne pas du tout prendre comme un coup de pression pour toi, je voulais que mettre à jour l'info) :)
-
Petite mise à jour.
le peering local (Vénissieux) de Milkwan en région lyonnaise (à 5km au sud de Lyon) avec SFR semble toujours passer par Marseille (mais on ne voit pas les routeurs intermédiaires) :
[maxime@yoga-730 ~]$ tracepath 80.67.167.31
1?: [LOCALHOST] pmtu 1500
1: pfSense.home.arpa 0.671 ms
1: pfSense.home.arpa 0.761 ms
2: 69cba1-nro-2.nro.gaoland.net 4.355 ms
3: 197.142.24.109.rev.sfr.net 5.983 ms
4: te1.a1k2.col.vnx.infra.ip4.milkywan.net 13.376 ms reached
Reprise : pmtu 1500 hops 4 back 8
Voici par exemple la weathermap de Milkywan pendant un télécharement de quelques minutes depuis 1fichier.com en passant par mon tunnel chez Milkywan : cf ci dessous.
Pour information il y a quelques mois lors d'une maintenance sur le réseau de Milkywan lors de laquelle je crois que le routeur de DC2 avait été arrêté brièvement, mon ping vers l'endpoint de mon tunnel sur Vénissieux était revenue pendant quelques minutes à 3ms.
J'imagine que la balle est toujours dans le camps de SFR. Je trouve ça dommage car à mon sens ne pas privilégier le peering en local surcharge les fibre à longue distance (cf la capture)
-
SFR ne m'annonce pas ton IP sur Lyon mais sur Marseille, donc forcément...
a7050sx.edge.vnx#show bgp nei 77.95.71.13 received-routes | i 109.11.243.0/24
a7050sx.edge.vnx#
-
SFR ne m'annonce pas ton IP sur Lyon mais sur Marseille, donc forcément...
a7050sx.edge.vnx#show bgp nei 77.95.71.13 received-routes | i 109.11.243.0/24
a7050sx.edge.vnx#
Je suis pas sur de comprendre pourquoi :o
-
J'essaye de m’intéresser un peu au BGP et fonctionnement d'un réseau.
Je regardais donc et essayais de comprendre le routage pour les différents ISP chez Milkywan.
Par exemple en regardant sur le Looking Glass le "ip bgp as" de SFR :
https://lg.milkywan.fr/cgi-bin/bgplg?cmd=show+ip+bgp+as&req=15557
Je vois que la gateway sélectionnée est toujours "80.67.167.1"
En faisant un petit coup de "dig -x 80.67.167.1" je me rends compte qu'il s'agit du routeur de DC2.
Pour Bouygues idem :
https://lg.milkywan.fr/cgi-bin/bgplg?cmd=show+ip+bgp+as&req=5410
De ce que je comprends donc, SFR et Bouygues annonce leurs plages d'IP en priorité en région parisienne ?
Est ce que mon raisonnement est bon ?
-
Pas compris, y'a bien du 80.67.167.2 qui est venissieux sur ton lien
-
Ok, je croyais comprendre que seule la ligne "selected' était prise en compte et les autres en "fail over". Mais en fait le routage se fait au plus rapide entre les différentes gateway proposées pour une destination ?
D'où le "problème" du routage vers mon IP SFR puisque dans ce cas seul la gateway 80.67.167.1 est annoncée ?
https://lg.milkywan.fr/cgi-bin/bgplg?cmd=show+ip+bgp&req=109.11.243.50
-
La meilleure route n'est pas forcément la même selon l'endroit où tu te trouves sur le réseau. Le Looking-glass voit tous les routeurs à la même distance, il choisit donc celui qui a l'ip la plus petite. L'information de la meilleure route n'est pas pertinente dans ce cas.
Dans le cas de ton IP, elle n'est annoncée par SFR que sur notre routeur de DC2, en effet.
-
Merci pour la réponse et explications.
Autre question (encore :) ) :
Comment se fait il que si on regarde "IP BGP AS" de SFR (https://lg.milkywan.fr/cgi-bin/bgplg?cmd=show+ip+bgp+as&req=15557), pour ce qui concerne mon subnet on a 2 "types" d'annonces dans la liste, avec un subnet /11 et puis chaque subnet /24 :
I*> N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 iet par exemple
I*> N 109.11.243.0/24 80.67.167.1 400 210 15557 ?
I* N 109.11.243.0/24 80.67.167.1 400 210 15557 ?
I* N 109.11.243.0/24 80.67.167.1 400 210 15557 ?
-
Il faut demander à SFR, je ne gère pas leurs annonces :)
-
Petite mise à jour.
Cette semaine j'ai eu une coupure de ma connexion FTTH d'environ 8 minutes (visualisé via mon pfSense) en pleine journée. Je n'avais jusque là pas fait le rapprochement avec quoi que ce soit.
Ce jour en faisant un tour sur mon pfSense pour tout autre chose, je me rends compte d'une bonne surprise : la latence vers le réseau MilkyWan est repassée à 3ms contre 16 auparavant.
Je m'empresse de faire un traceroute vers mon point d'accès chez MilkyWan :
tracepath 80.67.167.31 -b
1?: [LOCALHOST] pmtu 1500
1: pfSense.home.arpa (192.168.3.1) 0.638 ms
1: pfSense.home.arpa (192.168.3.1) 0.502 ms
2: 69lyo1-nro-1.nro.gaoland.net (109.24.76.41) 4.846 ms
3: 193.142.24.109.rev.sfr.net (109.24.142.193) 4.449 ms asymm 4
4: te1.a1k2.col.vnx.infra.ip4.milkywan.net (80.67.167.193) 3.377 ms reached
Reprise : pmtu 1500 hops 4 back 5
Je remarque deux choses :
1) effectivement la latence est bien réduite
2) le premier routeur SFR que j’atteins est 69lyo1-nro-1.nro.gaoland.net (109.24.76.41) contre 69cba1-nro-2.nro.gaoland.net auparavant.
Sur le looking glass de Milkywan en faisant un "show ip bgp" sur mon IP je n'ai plus que l'accès générique via Paris ou Lyon :
flags ovs destination gateway lpref med aspath origin
I*> N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.1 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 210 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
I* N 109.0.0.0/11 80.67.167.2 400 310 15557 i
La ligne spécifique au subnet /24 de mon IP qui n'était jusque là annoncée que sur Paris a disparue.
Donc probablement que quelqu'un de chez SFR a suivi et modifié cela : merci à lui :)
-
Mise à jour (pas du tout à titre de reproche mais informatif)
Depuis quelques mois j'observe que la latence depuis chez moi sur Lyon depuis SFR vers l'endpoint Milkywan sur Vénissieux a augmenté, autour de 10ms (cependant cela fonctionne à la perfection).
Le traceroute n'est pas très informatif :
tracepath 80.67.167.31
1?: [LOCALHOST] pmtu 1500
1: pfSense.home.arpa 0.399 ms
1: pfSense.home.arpa 0.387 ms
2: 69lyo1-nro-1.nro.gaoland.net 1.176 ms
3: 193.142.24.109.rev.sfr.net 5.768 ms asymm 4
4: te1.a1k2.col.vnx.infra.ip4.milkywan.net 11.305 ms reached
J'ai essayé de regarder la weathermap pour voir par où passait mon trafic (cf photo plus bas).
J'ai lancé un speedtest de 3 min sur speedtest.milkywan.fr qui se situe sur CBO. J'ai comparé la weathermap avant et après.
J'ai l'impression que le trafic depuis Venissieux pour SFR sur Lyon passe par Appliwave.
Est ce que cela ne pourrait pas être pénalisant pour Milkywan si jamais il y avait facturation (ce dont je doute en réalité) comme il s'agit de Transit IP ?
A moins que ce ne soit pas du tout ce chemin et que je me sois trompé.
-
Au risque de me répéter...
Il faut demander à SFR, je ne gère pas leurs annonces :)
-
Au risque de me répéter...
Moi je ne gère que ce qui sort de mon réseau. Pour ce qui rentre, c'est à SFR de gérer, et ils font n'importe quoi.
Je sais bien, c'est pour ça que je disais à titre informatif.
Mais lorsqu'un AS est dans ce genre de situation où celui d'en face fait passer par un transitaire, cela n'est il pas pénalisant financièrement ?
-
Ça fait bien longtemps que le peering coute plus cher que le transit...
-
Ne pas oublier l'aspect résilience qui est important et qui explique certaines situations de la part des opérateurs (typiquement le fait que Bouygues Telecom envoie beaucoup de trafic vers Marseille quand on sur Lyon)
-
Bouygues qui est maintenant en remote peering depuis Marseille ?