Auteur Sujet: Hopus (Lu 206279 fois)

BadMax · « **Réponse #420 le:** 22 juin 2015 à 09:35:39 »

Attention au protocole de transfert utilisé: meme en LAN, CIFS/SMB est très gourmand en ressources CPU et peut donc empecher d'atteindre le débit nominal. Le plus rapide que j'ai jamais trouvé c'est NFS sur du LAN, on peut saturer du Gb assez facilement avec des disques SATA2/3 de 1To.

En WAN, jamais trouvé plus rapide que FTP.

petrus · « **Réponse #421 le:** 22 juin 2015 à 15:36:27 »

Citation de: BadMax le 22 juin 2015 à 09:35:39

Attention au protocole de transfert utilisé: meme en LAN, CIFS/SMB est très gourmand en ressources CPU et peut donc empecher d'atteindre le débit nominal. Le plus rapide que j'ai jamais trouvé c'est NFS sur du LAN, on peut saturer du Gb assez facilement avec des disques SATA2/3 de 1To.

En WAN, jamais trouvé plus rapide que FTP.

+1 pour NFS et FTP, mais avec plusieurs segments pour le FTP, sinon c'est tcp qui limite...

Nico · « **Réponse #422 le:** 22 juin 2015 à 23:08:14 »

Citation de: tivoli le 22 juin 2015 à 07:41:11

Copie de gros fichiers un par un j'imagine, pas en simultané ?

Oui.

Citation de: vivien le 22 juin 2015 à 09:23:01

Par contre, avec un disque dur SAS 10 000 tr/min, je monte à 1 Gb/s.

Pourtant... j'ai que ça dans sinon RAID5 !

vivien · « **Réponse #423 le:** 19 juillet 2015 à 12:37:29 »

Je me pose des questions sur la pertinence de Hopus de récupérer tous les peering de AS3215...

Traceroute Numericable (ville du Mée-sur-Seine) vers K-Net :

$ mtr -rwc100 k-net.fr Start: Sun Jul 19 12:31:06 2015 HOST: Numericable Loss% Snt Last Avg Best Wrst StDev 1.|-- 192.168.0.1 0.0% 100 15.9 11.5 1.0 258.1 29.2 2.|-- 10.105.96.1 7.0% 100 10.0 16.0 5.3 197.6 23.7 3.|-- vss1rj-ae1.100.numericable.net 0.0% 100 15.6 16.3 6.3 133.7 16.3 4.|-- ip-254.net-80-236-0.static.numericable.fr 0.0% 100 19.2 20.3 7.4 233.0 25.8 5.|-- ip-249.net-80-236-0.static.numericable.fr 0.0% 100 32.5 17.2 7.8 172.7 17.5 6.|-- 172.19.129.66 0.0% 100 20.8 29.0 16.0 116.2 17.4 7.|-- ip-95.net-80-236-7.static.numericable.fr 0.0% 100 28.1 33.3 16.4 463.3 48.6 8.|-- 193.252.227.189 0.0% 100 23.4 30.9 16.8 389.4 45.9 9.|-- 193.252.227.98 0.0% 100 19.6 33.7 16.3 329.6 43.3 10.|-- lag-pop-ly-1.th2-1.rt.hopus.net 0.0% 100 27.6 39.5 16.7 674.3 73.9 11.|-- ielo.th2-1.rt.hopus.net 0.0% 100 49.2 45.8 25.4 639.8 65.8 12.|-- te-3-1-frlyo01-c6k1.rt.ielo.net 0.0% 100 29.5 45.1 25.5 572.9 61.0 13.|-- te-2-1-cr10.ch.rt.ielo.net 0.0% 100 34.9 43.3 26.5 506.6 50.0 14.|-- kwaoo.ix-customers-gva1.ielo.net 1.0% 100 33.7 86.4 27.0 2438. 285.3 15.|-- k-net.fr 0.0% 100 33.5 44.0 27.1 372.7 43.4

C'est la même chose avec Bouygues Telecom :

Citation de: vivien le 06 avril 2015 à 20:04:37

Exemple une Bbox fibre sur le réseau Numericable : On passe sur le réseau de 4 FAI !

$ mtr -rwc100 k-net.fr Start: Mon Apr 6 20:01:46 2015 HOST: vivien Loss% Snt Last Avg Best Wrst StDev 1.|-- bbox.lan 0.0% 100 1.0 5.7 0.9 313.6 33.1 2.|-- ? ? 100.0 100 3.|-- 213-245-252-177.rev.numericable.fr 0.0% 100 10.3 12.1 7.5 212.2 20.6 => Numericable Vitry-sur-Seine 4.|-- ip-53.net-80-236-1.static.numericable.fr 0.0% 100 10.5 12.2 7.8 157.4 15.9 => Numericable 5.|-- ip-49.net-80-236-1.static.numericable.fr 0.0% 100 10.1 12.2 8.2 102.3 9.6 => Numericable 6.|-- lag101.350.ncc-cbv.net.bbox.fr 0.0% 100 13.7 13.6 8.7 77.7 11.5 => Bouygues Courbevoie 7.|-- ? ? 100.0 100 8.|-- be16.cbr01-ntr.net.bbox.fr 1.0% 100 9.8 13.4 9.8 24.4 2.0 => Bouygues Nanterre 9.|-- la12.rpt01-ix2.net.bbox.fr 90.0% 100 12.2 12.4 10.6 14.1 0.7 => Bouygues Aubervilliers 10.|-- ? ? 100.0 100 11.|-- ae44-0.nridf301.Paris.francetelecom.net 0.0% 100 13.2 15.8 9.8 213.8 22.8 => Orange Paris 12.|-- ae44-0.noidf001.Paris.francetelecom.net 0.0% 100 12.7 15.3 10.6 158.2 15.7 => Orange Paris 13.|-- 193.253.13.206 0.0% 100 10.5 13.9 10.5 120.4 10.9 => Orange Paris 14.|-- ielo.th2-1.rt.hopus.net 1.0% 100 12.0 14.2 10.8 87.6 9.2 => Hopus Paris 15.|-- te-3-1-frlyo01-c6k1.rt.ielo.net 0.0% 100 21.3 35.2 18.5 217.7 38.6 => Ielo Lyon 16.|-- te-2-1-cr10.ch.rt.ielo.net 0.0% 100 30.2 30.3 20.5 479.2 45.7 => Ielo Genève 17.|-- kwaoo.ix-customers-gva1.ielo.net 0.0% 100 29.4 68.7 25.2 1511. 205.6 => K-Net Genève 18.|-- 178.250.209.47 0.0% 100 27.6 31.9 25.4 397.6 37.0 => Site web k-net.fr

petrus · « **Réponse #424 le:** 19 juillet 2015 à 13:42:14 »

Pour moi c'est pas au niveau Hopus qu'il faut se poser les questions, mais plutôt au niveau de NC & Bouygues, qui acceptent les routes annoncées par 3215 et les préfèrent à d'autres.

C'est un cas assez classique où l'on préfère les routes d'un peer plutôt que d'un transitaire, payant. Je ne vois rien de choquant à ce que ça passe à travers N opérateurs, tant que le routage est "cohérent" (ie ne pas passer par un peering à Londres ou Amsterdam) et correct.

Synack · « **Réponse #425 le:** 19 juillet 2015 à 19:02:31 »

Peut-être K-Net préfère que son trafic arrive directement à Genève plutôt qu'à Paris ? IELO serait alors favorisé par rapport aux IX sur Paris ou Amsterdam pour soulager les liens longue distance ?

Sur le looking glass d'Orange je vois un prepend de 4 pour K-net sur IELO qui reste best route avec une local pref normale à 100, donc il y a probablement un prepend plus élevé via les autres routes ? Faudrait voir l'ensemble des choix pour Orange au lieu d'uniquement le best pour savoir, ou que K-Net donne les infos.

A moins que tous les AS-path soient identiques et que ce soient les metrics qui différencient (chez IELO ou chez K-Net)

En tout cas ça sent l'optimisation d'occupation de lien pour le coup. Sinon pour moi ça pose un problème quand même ce genre de routage, ça veut dire qu'on ajoute des points de risque et qu'on a pas mal d'oeufs dans le même panier avec un point de passage Orange/Hopus/IELO pour une grande majorité des FAI FR.

vivien · « **Réponse #426 le:** 19 juillet 2015 à 19:33:08 »

K-Net choisit où il envoie son trafic, mais pas où il le reçoit.

Une solution (mise en place par Adeli) est de faire des annonces plus précises sur les peering, ce qui force l'èmetteur a passer par les peering, même si ce n'est pas la route optimale. Bref, ce n'est pas une bonne solution.

Le problème, ce sont les local pref chez Bouygues, SFR et Numericable, qui privilégient les PNI coûte que coûte quand un peering sur un GIX est possible. (Je ne parle pas d'Orange et Free qui ne peerent pas sur les GIX). Cela a déja une fois posé problème, lors de la panne de courant sur TH2 qui avait impacté le cœur du réseau Neo Telecom qui continuait à annoncer les routes sans permettre au trafic de passer (et Free qui a décidé brutalement d’ignorer les routes de Neo pour éviter que cela se reproduise)

petrus · « **Réponse #427 le:** 19 juillet 2015 à 19:50:04 »

Citation de: Synack le 19 juillet 2015 à 19:02:31

Sur le looking glass d'Orange je vois un prepend de 4 pour K-net sur IELO qui reste best route avec une local pref normale à 100, donc il y a probablement un prepend plus élevé via les autres routes ? Faudrait voir l'ensemble des choix pour Orange au lieu d'uniquement le best pour savoir, ou que K-Net donne les infos.

Tu as testé sur quel looking glass ? OTIP (opentransit) ou RBCI, ou route-server.opentransit.net en telnet ?

Si tu n'as pas fait sur rbci (3215), il y a des chances que la policy interne ne soit pas la même dans 5511 et donc les localpref & possibles communautés effacées.

Synack · « **Réponse #428 le:** 19 juillet 2015 à 20:41:21 »

Citation de: vivien le 19 juillet 2015 à 19:33:08

K-Net choisit où il envoie son trafic, mais pas où il le reçoit.

Une solution (mise en place par Adeli) est de faire des annonces plus précises sur les peering, ce qui force l'èmetteur a passer par les peering, même si ce n'est pas la route optimale. Bref, ce n'est pas une bonne solution.

Le problème, ce sont les local pref chez Bouygues, SFR et Numericable, qui privilégient les PNI coûte que coûte quand un peering sur un GIX est possible. (Je ne parle pas d'Orange et Free qui ne peerent pas sur les GIX). Cela a déja une fois posé problème, lors de la panne de courant sur TH2 qui avait impacté le cœur du réseau Neo Telecom qui continuait à annoncer les routes sans permettre au trafic de passer (et Free qui a décidé brutalement d’ignorer les routes de Neo pour éviter que cela se reproduise)

Quand les local pref sont égales, tu peux très facilement forcer le trafic en entrant, bien sûr que tu peux choisir ton entrant même si c'est plus technique que le sortant.

Après c'est normal en temps normal de privilégier le PNI puis les IX puis le transit, juste il faut faire un peu d'ingénierie pour gérer les cas particuliers comme celui là. Je pense que Bouygues et NC sont trop occupés à gérer leur saturation en entrant pour s'attarder sur le sortant là, tant que la latence est correcte.

Pour le cas Neo - Free, le problème c'est surtout d'avoir créé une situation où quasi tout le monde prenait Neo pour avoir du peering free en France. On en revient toujours au même problème : Quand on limite les routes et la qualité pour être joint ou quand on accumule tout par un opérateur, on est plus exposé aux gros problèmes.

Citation de: petrus le 19 juillet 2015 à 19:50:04

Tu as testé sur quel looking glass ? OTIP (opentransit) ou RBCI, ou route-server.opentransit.net en telnet ?

Si tu n'as pas fait sur rbci (3215), il y a des chances que la policy interne ne soit pas la même dans 5511 et donc les localpref & possibles communautés effacées.

Oups, tu as tout à fait raison pardon

J'étais sur OTI, ce qui n'a pas de sens là. Je suis déjà en vacances dans la tête =)

Boris de Bouygues Telecom · « **Réponse #429 le:** 19 juillet 2015 à 23:13:55 »

Bonjour,

Nous avons bien pris en compte les demandes.

La local pref des GIX va être mise comme celle d'un PNI. La demande pour faire ce changement pour France-IX a déjà été envoyée par l’ingénierie aux équipes en charge de l'appliquer. Cela n'a aucun impact sur le dimensionnement, car le trafic de Bouygues Telecom est très fortement asymétrique. Aucun risque de saturer les 60 Gb/s.

Si nous n'observons pas d'effet indésirable, le changement de local pref sera transposé aux autres GIX.

Boris.

Synack · « **Réponse #430 le:** 20 juillet 2015 à 00:32:09 »

Top ça

Bengelly · « **Réponse #431 le:** 20 juillet 2015 à 10:30:11 »

Citation de: Synack le 20 juillet 2015 à 00:32:09

Top ça

Je plussoie, cela ne pourra être que positif pour la communauté. Par exemple, notre AS voyait le trafic entrant BYTEL passer par des PNI alors que nous peerons ensemble partout où nous le pouvons (AMS-IX, DE-CIX, FRANCE-IX, HOPUS) :

#### Trace prise le 30/06 #### :

--- Nice Trace to 193.41.95.1 ---

1) bbox.lan (192.168.1.254) 199.657 ms, 12/12 ps, 0.0% loss
2) nor75-h08-89-91-210-126.dsl.sta.abo.bbox.fr (89.91.210.126) 315.322 ms, 11/11 ps, 0.0% loss [AS 5410] France
3) 109.9-1-5.bsr01-th2.net.bbox.fr (195.36.231.254) 321.894 ms, 11/11 ps, 0.0% loss [AS 5410] France
4) be15.cbr01-cro.net.bbox.fr (212.194.171.92) 391.659 ms, 11/11 ps, 0.0% loss [AS 5410] France
5) la12.rpt02-ix2.net.bbox.fr (212.194.171.88) 383.400 ms, 3/11 ps, 63.6% loss [AS 5410] France
6) 83.167.32.213.static.not.updated.neotelecoms.com (83.167.32.213) 471.147 ms, 11/11 ps, 0.0% loss [AS 8218] France
7) et-8-0-0.tcr2.rb.par.core.as8218.eu (83.167.55.162) 449.734 ms, 11/11 ps, 0.0% loss [AS 8218] France

et-2-0-0.tcr1.rb.par.core.as8218.eu (83.167.55.148) 376.290 ms, 10/10 ps, 0.0% loss [AS 8218] France
9) xe-0-0-1.ter1.ntc.par.core.as8218.eu (83.167.55.97) 339.824 ms, 10/10 ps, 0.0% loss [AS 8218] France
10) prodware-gw1.ter1.ntc.par.cust.as8218.eu (46.255.177.129) 352.431 ms, 10/10 ps, 0.0% loss [AS 8218] France
11) lo1.rr01-par01.prodware.net (193.41.95.1) 322.578 ms, 10/10 ps, 0.0% loss [AS 57928] France

Encore une fois, merci à BYTEL de jouer le jeu du peering à fond.

@++