La Fibre
Télécom => Peering Transit (appairage) => 
Peering entre opérateurs => Discussion démarrée par: ut0mt8 le 30 janvier 2018 à 10:33:24
-
Il existe a priori un petit souci de routage sur certaine plage d’IP d’abonné SFR.RED. (Exemple ip 89.156.40.80).
Le 1er souci c’est que nous avons un PNI avec SFR et que ce range n’est pas annoncé. Bon soit.
A la limite me disant que c’est une IP ex NC je m’attendrais à l’avoir annoncé via France-IX (sur les RS) mais non.
Donc nous passons via un de nos transits : en l’occurrence Zayo France (ex-Neo) et là c’est assez moche car nous passons par le Lyonix ?! (alors que l’abonné est en IDF).
<PRDNETRHP500>tracert 89.156.40.80
traceroute to 89.156.40.80 (89.156.40.80), 30 hops at most, 40 bytes each packet, press CTRL_C to break
1 ae11.tcr1.rb.par.core.as8218.eu (213.152.16.98) 1.801 ms 1.197 ms 0.932 ms
2 ae8.tcr1.sfr.lyn.core.as8218.eu (83.167.55.13) 14.817 ms 7.351 ms 7.382 ms
3 numericable.peers.lyonix.net (77.95.71.24) 34.603 ms 8.357 ms 8.241 ms
4 * * *
5 * * *
6 * * *
7 rom1rj-so-0-0-0.0.numericable.net (80.236.4.205) 9.132 ms 9.013 ms 8.809 ms
mpls label=309776 Exp=0 TTL=1 S=1
8 ip-111.net-80-236-2.static.numericable.fr (80.236.2.111) 9.577 ms 9.267 ms 9.505 ms
mpls label=572016 Exp=0 TTL=1 S=1
9 ip-49.net-80-236-3.static.numericable.fr (80.236.3.49) 9.902 ms 9.592 ms 9.554 ms
10 195-132-10-227.rev.numericable.fr (195.132.10.227) 9.672 ms 9.767 ms 9.529 ms
Au délà du routage moche qui ne devrait pas poser plus de probleme que cela, le fait est que ce client a une énorme dégradation de connectivité vers chez nous.
J'ai ouvert un ticket aux opérations chez SFR sait on jamais...
-
Hello,
Effectivement, c'est moche :
traceroute to 89.156.40.80 (89.156.40.80), 30 hops max, 40 byte packets
1 193.41.95.153.clients.prodware.net (193.41.95.153) 3.645 ms 4.891 ms 7.286 ms
2 prodware.th2-2.rt.hopus.net (37.77.34.36) 3.342 ms 2.807 ms 3.424 ms
3 sfr.th2-2.rt.hopus.net (37.77.34.29) 4.339 ms 3.352 ms 2.289 ms
4 149.10.136.77.rev.sfr.net (77.136.10.149) 4.992 ms 5.679 ms 4.822 ms
5 149.10.136.77.rev.sfr.net (77.136.10.149) 4.973 ms 5.285 ms 5.295 ms
6 110.172.154.77.rev.sfr.net (77.154.172.110) 4.738 ms 4.885 ms 4.030 ms
7 195-132-10-227.rev.numericable.fr (195.132.10.227) 4.747 ms 4.838 ms 6.154 ms
8 * * *
9 * *^C
Peut-être que le johann pourra t'aidersur ce coup ci.
Bon courage.
@++
-
Donc nous passons via un de nos transits : en l’occurrence Zayo France (ex-Neo) et là c’est assez moche car nous passons par le Lyonix ?! (alors que l’abonné est en IDF).
C'est marrant j'écrivais justement à coté que les IX régionaux ne servaient probablement à rien d'autre que d'apporter des emmerdements (en dehors des boites purement locales, et en dehors de Marseille).
Le 1er souci c’est que nous avons un PNI avec SFR et que ce range n’est pas annoncé. Bon soit.
C'est probablement une erreur.
Au délà du routage moche qui ne devrait pas poser plus de probleme que cela, le fait est que ce client a une énorme dégradation de connectivité vers chez nous.
Ça se serait déjà vu, un port plein au Lyonix sur un IX régional auquel personne ne fait gaffe...
J'ai ouvert un ticket aux opérations chez SFR sait on jamais...
Chez Zayo aussi non?
-
Troll détecté. Le peering en région, c’est pour les opérateurs qui savent y faire, c’est tout :)
-
Bon alors je dois signaler la réactivité de SFR sur ce coup la.
J'apprends bien gentiment ce pfx via mon PNI maintenant.
Au passage ils ont avoué qu'ils avaient une saturation sur le peering NC<>FranceIx, et donc qu'ils avaient fait du ménage/tri sur les pfx annoncé (le pfx en question n'était plus annoncé sur FranceIx).
En revanche il devait rester tout sur NC<>Lyonix (ou cela ne devait pas très bien se passer... port 1G ?).
Conclusion : on désature FranceIX et paf on oublie un détail ;)
Je leur ai conseillé de shut vu que ca doit plus foutre le bronx qu'autre chose.
Quant au débat sur l'utilité des IX régionaux je suis assez d'accord avec le stbol. Ca parait une bonne idée sur le papier de vouloir décentraliser la France, mais en pratique tes copains en face (FAI ou contents) n'ont souvent pas de réseaux régionalisé (ou alors pas très bien géré khof khof). Donc c'est assez useless, voir error-prone. La France n'étant pas bien grande les quelques ms de perdu à faire un allez retour à Paris ne sont sans doute pas bien grave et bien plus facilement gérable.
Déjà que le multi IX européen ca peut être relou à gérer alors bon...
-
M'est d'avis que ce n'est pas comme ça que la décentralisation avancera...
je suis entrain de monter le futur réseau de mon asso, la régionalisation est au coeur de mes préoccupations, vu que je vais avoir transits et peering en région.
Et je sais que plusieurs opérateurs (au hasard, bouygues) sont entrain de réaménager leurs plages pour régionnaliser plus simplement.
-
Bytel ils ont d'autres soucis que la régionnalisation pour le moment (aka victime de leur succès il faut upgrade et faire de la place dans les tuyaus).
Après la régionnalisation on y est déjà. La France est une région du monde ;)
Je ne pense honnetement pas qu'il faille descendre au délà. (enfin disons que je ne vois pas bien à quoi ca sert à l'echelle de la France, je dirais pas la meme chose des US)
Tiens un exemple d'actualité : AWS région France : 3 AZ, 2 à Paris, 1 à Marseille; bah voila AWS a estimé que Paris <>Marseille c'était négligeable en ms. Et que la France n'était donc qu'un seul gros DC; une région. Je suis assez d'accord.
-
pour clarifier (si besoin est, car ca apparait dans peeringdb) SFR et Zayo ont des ports 10G a LyonIX.
ni l'un ni l'autre ne sont saturés à cet endroit.
10ms, c'est 3ms de plus qu'une latence lyon-paris, non ? est-ce que c'est vraiment ce qui dégradait ?
sur le coup on aurait pu chercher vers quels endroit des paquets seraient perdus ...
[some troll inside]
si on veut aller dans le sens que la france est une region a part entière en terme de BGP, et que la distance lyon paris ne compte donc pas,
alors désaturer son port sur un premier IXP pour répartir sur l'autre, ou encore, avoir une redondance sur un autre IXP, semble être un mouvement correct au sens de la desserte régionnale concernée.
Donc pourquoi pas LyonIX ?
-
Hello,
Après avoir regardé de plus prés, on a exactement le même soucis que ut0mt8.
On ne reçoit ce préfixe que par LyonIX à l'instant T. Sans doute pour les raisons évoqué par ut0mt8 plus haut.
Ceci explique pourquoi le routage fait un détour par Lyon vers ce préfixe lorsque cela passe par Zayo France.
Je vais tenter de régler la chose avec SFR/ex-NC.
-
M'est d'avis que ce n'est pas comme ça que la décentralisation avancera...
je suis entrain de monter le futur réseau de mon asso, la régionalisation est au coeur de mes préoccupations, vu que je vais avoir transits et peering en région.
Sans vouloir être désagréable le moins du monde, tu confonds 3 cacahuètes de traf entre des beigebox, et des dizaines de Gb/s de distribution de contenu.
Comme déjà indiqué: c'est pas pareil.
-
On n'a pas la même vision du réseau, que veux-tu.
-
si on veut aller dans le sens que la france est une region a part entière en terme de BGP, et que la distance lyon paris ne compte donc pas,
alors désaturer son port sur un premier IXP pour répartir sur l'autre, ou encore, avoir une redondance sur un autre IXP, semble être un mouvement correct au sens de la desserte régionnale concernée.
Donc pourquoi pas LyonIX ?
On revient juste dans la problematique initiale ou quoi qu'il arrive desaturer un port d'un ix en splittant les prefixes ca amene à rien de bon.
Donc au final autant avoir un point central à upgrader non ?
-
bah voila AWS a estimé que Paris <>Marseille c'était négligeable en ms. Et que la France n'était donc qu'un seul gros DC; une région.
Ce qui en soi c'est une ineptie, car Paris-Marseille c'est la meme distance que Francfort-Londres (par la route ou par fibre).
-
Bah non au contraire c'est très cohérent. Il faut connaitre la terminologie AWS : une région c'est un ensemble de datacenters (AZ) proche géographiquement accessible entre eux sans surcout, qui possédent les meme service et la meme legislation du pays.
Mais maintenant que j'y pense vu que la région s'appelle Paris je suis pris d'un doute. Je me demande si quelqu'un peut me confirmer ou infirmer qu'une des AZ de paris est bien à marseille ou pas. Je connais une partie des DCs (DC3, PA4, PA6, un bout de TH2) ou AWS s'est implanté à Paris mais du coup je me demande...
-
et la meme legislation du pays.
La ca a un sens, de point de vue autre que technique.
Mais tout traiter comme un ensemble, avec 800km de distance, c'est techniquement du n'importe quoi.
Je me demande si quelqu'un peut me confirmer ou infirmer qu'une des AZ de paris est bien à marseille ou pas.
Aujourd'hui, 03 Feb 2018, selon http://ec2-reachability.amazonaws.com/ (http://ec2-reachability.amazonaws.com/), il n'y a que 2 points de presence EC2 en France, les 2 a Paris. Mais ca ne les empeche pas d'avoir soit un AZ toute fraiche soit une en preparation.
Il y a aussi l'histoire des autres services (notamment CloudFront et route53), qui peuvent entre sur des sites autres que celles hebergeant du EC2.
-
Sur la région de Paris, il y a trois AZ disponibles (2 seulement d'après le lien de raf, mais sur la console EC2, j'ai le choix entre 3 AZ).
Pour Marseille, c'est seulement ce que Amazon appelle une Edge Network Location : ça regroupe du CloudFront, peut-être du Route 53 (et peut-être d'autres choses que je ne connais pas...). Et ce genre de POP peut servir aussi à faire rentrer du trafic dans le réseau Amazon en étant plus "proche" de l'utilisateur, par exemple vers S3 (via ce qu'ils appellent S3 Accelerate), où tout le chemin Bucket S3 <--> Edge AWS peut ne pas sortir du réseau Amazon (= faire Paris-Marseille dans le réseau d'Amazon et non celui du FAI).
-
Au temps pour moi. Donc nous avons bien 3 A-Z à Paris (je confirme que j'ai accès via ma console AWS).
Mon argumentation tombe à l'eau :)