Re: [FRnOG] [TECH] LACP down entre Juniper EX4600 et HPe A5500 [SOLVED]

[Laurent Beuneche]

On 14/02/2017 18:12, Pierre LANCASTRE wrote:

Je pense qu'une bonne piste serait les messages suivants :

Feb 14 16:58:25 j-stic-lab1 /kernel: ge-0/0/1: received pdu - length 
mismatch for lacp : len 150, pdu 124
Feb 14 16:58:25  j-stic-lab1 /kernel: ge-0/0/2: received pdu - length 
mismatch for lacp : len 150, pdu 124
Feb 14 16:58:55  j-stic-lab1 /kernel: ge-0/0/1: received pdu - length 
mismatch for lacp : len 150, pdu 124
Feb 14 16:58:55  j-stic-lab1 /kernel: ge-0/0/2: received pdu - length 
mismatch for lacp : len 150, pdu 124


Si on regarde la KB ci-dessous, il semblerait que le switch HP envoie 
des BPDU trop "gros", ils devraient faire 124+4 octests (4 octets pour 
le FCS)


https://kb.juniper.net/InfoCenter/index?page=content&id=KB17674&actp=search

Regarde si tu trouves un autre type de config côté HP pour le lacp, 
peut-être aussi essayer de jouer avec la mtu des ports côté HP (ou 
Juniper) pour voir si tu as les mêmes messages.

Bonjour,
Ces logs m'orientaient effectivement vers un problème côté HP et c'était 
le cas.


Le soucis provenait de la conf mad (multi-active detection) qu'on avait 
paramétré sur l'interface Bridge
et qui nous forgeait des lacpdu extended, conf pas appropriée ici. Le 
mad est ailleurs ...


interface Bridge-Aggregation1
 description interco j-stic-lab1
 port link-type trunk
 port trunk permit vlan all
 link-aggregation mode dynamic
*mad enable*

Merci en tout cas pour vos réponses.
L.


--
Laurent Beunèche  -  (+33) 2473 67326
RSSI adjoint - Administrateur Système & Réseau

Direction des Systèmes d'Information
Université de Tours
Bat D, 60 rue du Plat d'étain BP 12050
37020 Tours cedex 1



smime.p7s
Description: S/MIME Cryptographic Signature

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput

Le 14 février 2017 à 18:57, sbu123fr  a écrit :

> Grand merci.
> Tu pense que sur des liens en île de france la latence est telle que le
> trafic peut être divisé par 4-5?
> Cdt
> Sbu
>
>
>
>  Message d'origine 
> De : Louis 
> Date : 14/02/2017 18:05 (GMT+01:00)
> À : Sylvain sbu 
> Cc : frnog-tech 
> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> cela dépend surtout du temps de réponse sur les liens. On perd en débit à
> cause des acquittements nécessaires à TCP. Les durées d'acquittement
> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
> utile ne transite.
>
> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
> performances en augmentant le nombre de paquets reçus avant acquittements.
> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>
> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
> la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
> qu'on peut tuner je crois.
>
> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
> trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
> autre sur les paramètres window TCP.
>
> Je suppose que le débit est voulu pour des gros transferts de fichier.
> Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
> transfert du même fichier sur plusieurs sessions TCP.
>
> cordialement,
>
> Louis
>
>
>
>
> Le 14 février 2017 à 16:45, Sylvain sbu  a écrit :
>
>> Bonjour,
>> Non rien a voir avec du hachage car en changeant un paramétrè de
>> "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>> cdt
>> SBU
>>
>> Le 14 février 2017 à 16:41, Dominique Rousseau  a
>> écrit :
>>
>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>> sbu12...@gmail.com] a écrit:
>>> > Bonjour,
>>> > Je ne suis pas spécialiste du transport IP.
>>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>> sur
>>> > une session TCP entre 2 liens
>>>
>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>
>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>> Elle correspond aux algorithmes de répartition entre les liens faisant
>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>> Tut te trouves alors limité par la capacité physique du lien
>>> sélectionné.
>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>
>>>
>>> --
>>> Dominique Rousseau
>>> Neuronnexion, Prestataire Internet & Intranet
>>> 21 rue Frédéric Petit - 8 Amiens
>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

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

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Michel Hostettler]

Bonjour,

Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?

Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué depuis 
12 ans.

Cordialement,
Michel

- Mail original -
De: "Louis" 
À: "sbu123fr" 
Cc: "frnog-tech" 
Envoyé: Mercredi 15 Février 2017 10:28:06
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbps

Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput

Le 14 février 2017 à 18:57, sbu123fr  a écrit :

> Grand merci.
> Tu pense que sur des liens en île de france la latence est telle que le
> trafic peut être divisé par 4-5?
> Cdt
> Sbu
>
>
>
>  Message d'origine 
> De : Louis 
> Date : 14/02/2017 18:05 (GMT+01:00)
> À : Sylvain sbu 
> Cc : frnog-tech 
> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> cela dépend surtout du temps de réponse sur les liens. On perd en débit à
> cause des acquittements nécessaires à TCP. Les durées d'acquittement
> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
> utile ne transite.
>
> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
> performances en augmentant le nombre de paquets reçus avant acquittements.
> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>
> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
> la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
> qu'on peut tuner je crois.
>
> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
> trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
> autre sur les paramètres window TCP.
>
> Je suppose que le débit est voulu pour des gros transferts de fichier.
> Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
> transfert du même fichier sur plusieurs sessions TCP.
>
> cordialement,
>
> Louis
>
>
>
>
> Le 14 février 2017 à 16:45, Sylvain sbu  a écrit :
>
>> Bonjour,
>> Non rien a voir avec du hachage car en changeant un paramétrè de
>> "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
>> cdt
>> SBU
>>
>> Le 14 février 2017 à 16:41, Dominique Rousseau  a
>> écrit :
>>
>>> Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>>> sbu12...@gmail.com] a écrit:
>>> > Bonjour,
>>> > Je ne suis pas spécialiste du transport IP.
>>> > Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>> sur
>>> > une session TCP entre 2 liens
>>>
>>> Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>>>
>>> La limitation indiquée par ton fournisseur n'est pas étonnante.
>>> Elle correspond aux algorithmes de répartition entre les liens faisant
>>> partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>>> adresses MAC source et destination, par exemple. Ce hachage sert à
>>> "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>>> correspondant a cette meme clef de hachage utilisera le meme lien.
>>> Tut te trouves alors limité par la capacité physique du lien
>>> sélectionné.
>>> Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>>> capacité de 100Mbps, et donc la limitation s'explique.
>>>
>>>
>>> --
>>> Dominique Rousseau
>>> Neuronnexion, Prestataire Internet & Intranet
>>> 21 rue Frédéric Petit - 8 Amiens
>>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>>>
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>
>>
>

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


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[Kavé Salamatian]

Bonjour à tous,

j’ai attendu de voir les discussions sur ce ce topic et voir si quelqu’un 
soulèverait la bonne question. En effet, le chiffre avancé par le Point (80%) 
est sans bases fiables, et c’est attendu puisque c’et un journaliste qui en 
parle. Mais on peut se poser ici des questions techniques du genre. Est ce 
quelqu’un connait le vrai chiffre ? ou même plus intéressant est il possible 
d’estimer  ce chiffre dans l’état actuel de l’architecture de l’Internet 
Français? 

Je me suis attelé il y’a deux ans à faire une estimation de la matrice de 
trafic française entre opérateur de différents pays (en particulier pour savoir 
quel était le pourcentage de trafic susceptible d’être directement surveillé 
par les five eyes). Le résultat a été qu’il est impossible d’estimer ces 
informations et plus généralement, toute information fiable sur la distribution 
de trafic en France sans une aide directe des opérateurs concernés. Hors, ceci 
ne coopèrent pas. On se rappellera la lettre sèche des opérateurs US opérant en 
France qui avait refusé de répondre à l’enquête de l’ARCEP sur le volume de 
trafic inter-domaine. 

Certains pourront discuter du fait, que cela ne sert à rien de connaitre la 
distribution de trafic, ou du fait que la liberté des opérateurs  de faire du 
business comme ils le souhaitent est plus importante, et que la régulation 
c’est le mal, etc….Mais je trouve un peu bizarre qu’on soit dans 
l’impossibilité d’avoir des statistiques fiables sur ces questions, et qu’en 
ayant gratté un peu je sur persuadé que personne n’a pas de statistiques 
fiables. Même le monument auto-proclamé sur la question de la résilience de 
l’Internet Français ne donne aucune indication sur du trafic.


Donc la question intéressante pour moi n’est pas que le journaliste du Point se 
soit planté et qu’il faille lui remonter les bretelles. C’est plutôt pourquoi 
personne n’est capable de donner des statistiques fiables sur une question 
pertinente. 

Pouvons nous, en tant que communauté y faire quelque chose ? du genre 
crowd-sourcing 

A+
Kv


> Le 10 févr. 2017 à 16:30, Stephane Bortzmeyer  a écrit :
> 
> Il parle d'un centre situé « quelque part dans Paris » qui abrite un
> « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements
> vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi
> il s'agit (le Point, pour faire croire qu'ils connaissent des secrets
> d'État, ne donne pas le nom de ce mystérieux centre) mais ma question
> portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain
> passe par là ».
> 
> Quelqu'un a une idée de l'origine, de la méthodologie, et de la
> véracité de ce chiffre ?  (Sinon, il va falloir que je scrape l'HTML
> de  et
> on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
> débit.)
> 
> [C'est vendredi mais ma question est sérieuse.]
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[David Ponzone]

Je vois mal comment le crowd-sourcing nous permettrait d’avoir les statistiques 
des PNI entre les puissants, à moins d’inviter les salariés de ces sociétés à 
rompre leur NDA…

On pourrait bien éteindre les GIX principaux de Paris et voir ce qui marche 
encore correctement :)


> Le 15 févr. 2017 à 11:42, Kavé Salamatian  a 
> écrit :
> 
> Bonjour à tous,
> 
> j’ai attendu de voir les discussions sur ce ce topic et voir si quelqu’un 
> soulèverait la bonne question. En effet, le chiffre avancé par le Point (80%) 
> est sans bases fiables, et c’est attendu puisque c’et un journaliste qui en 
> parle. Mais on peut se poser ici des questions techniques du genre. Est ce 
> quelqu’un connait le vrai chiffre ? ou même plus intéressant est il possible 
> d’estimer  ce chiffre dans l’état actuel de l’architecture de l’Internet 
> Français? 
> 
> Je me suis attelé il y’a deux ans à faire une estimation de la matrice de 
> trafic française entre opérateur de différents pays (en particulier pour 
> savoir quel était le pourcentage de trafic susceptible d’être directement 
> surveillé par les five eyes). Le résultat a été qu’il est impossible 
> d’estimer ces informations et plus généralement, toute information fiable sur 
> la distribution de trafic en France sans une aide directe des opérateurs 
> concernés. Hors, ceci ne coopèrent pas. On se rappellera la lettre sèche des 
> opérateurs US opérant en France qui avait refusé de répondre à l’enquête de 
> l’ARCEP sur le volume de trafic inter-domaine. 
> 
> Certains pourront discuter du fait, que cela ne sert à rien de connaitre la 
> distribution de trafic, ou du fait que la liberté des opérateurs  de faire du 
> business comme ils le souhaitent est plus importante, et que la régulation 
> c’est le mal, etc….Mais je trouve un peu bizarre qu’on soit dans 
> l’impossibilité d’avoir des statistiques fiables sur ces questions, et qu’en 
> ayant gratté un peu je sur persuadé que personne n’a pas de statistiques 
> fiables. Même le monument auto-proclamé sur la question de la résilience de 
> l’Internet Français ne donne aucune indication sur du trafic.
> 
> 
> Donc la question intéressante pour moi n’est pas que le journaliste du Point 
> se soit planté et qu’il faille lui remonter les bretelles. C’est plutôt 
> pourquoi personne n’est capable de donner des statistiques fiables sur une 
> question pertinente. 
> 
> Pouvons nous, en tant que communauté y faire quelque chose ? du genre 
> crowd-sourcing 
> 
> A+
> Kv
> 
> 
>> Le 10 févr. 2017 à 16:30, Stephane Bortzmeyer  a écrit :
>> 
>> Il parle d'un centre situé « quelque part dans Paris » qui abrite un
>> « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements
>> vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi
>> il s'agit (le Point, pour faire croire qu'ils connaissent des secrets
>> d'État, ne donne pas le nom de ce mystérieux centre) mais ma question
>> portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain
>> passe par là ».
>> 
>> Quelqu'un a une idée de l'origine, de la méthodologie, et de la
>> véracité de ce chiffre ?  (Sinon, il va falloir que je scrape l'HTML
>> de  et
>> on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
>> débit.)
>> 
>> [C'est vendredi mais ma question est sérieuse.]
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[Michel Hostettler]

Bonjour,

Il peut exister des circuits de secours hors Paris.

Cordialement,
Michel

- Mail original -
De: "David Ponzone" 
À: "Kavé Salamatian" 
Cc: "Frnog misc" 
Envoyé: Mercredi 15 Février 2017 11:50:27
Objet: Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

Je vois mal comment le crowd-sourcing nous permettrait d’avoir les statistiques 
des PNI entre les puissants, à moins d’inviter les salariés de ces sociétés à 
rompre leur NDA…

On pourrait bien éteindre les GIX principaux de Paris et voir ce qui marche 
encore correctement :)


> Le 15 févr. 2017 à 11:42, Kavé Salamatian  a 
> écrit :
> 
> Bonjour à tous,
> 
> j’ai attendu de voir les discussions sur ce ce topic et voir si quelqu’un 
> soulèverait la bonne question. En effet, le chiffre avancé par le Point (80%) 
> est sans bases fiables, et c’est attendu puisque c’et un journaliste qui en 
> parle. Mais on peut se poser ici des questions techniques du genre. Est ce 
> quelqu’un connait le vrai chiffre ? ou même plus intéressant est il possible 
> d’estimer  ce chiffre dans l’état actuel de l’architecture de l’Internet 
> Français? 
> 
> Je me suis attelé il y’a deux ans à faire une estimation de la matrice de 
> trafic française entre opérateur de différents pays (en particulier pour 
> savoir quel était le pourcentage de trafic susceptible d’être directement 
> surveillé par les five eyes). Le résultat a été qu’il est impossible 
> d’estimer ces informations et plus généralement, toute information fiable sur 
> la distribution de trafic en France sans une aide directe des opérateurs 
> concernés. Hors, ceci ne coopèrent pas. On se rappellera la lettre sèche des 
> opérateurs US opérant en France qui avait refusé de répondre à l’enquête de 
> l’ARCEP sur le volume de trafic inter-domaine. 
> 
> Certains pourront discuter du fait, que cela ne sert à rien de connaitre la 
> distribution de trafic, ou du fait que la liberté des opérateurs  de faire du 
> business comme ils le souhaitent est plus importante, et que la régulation 
> c’est le mal, etc….Mais je trouve un peu bizarre qu’on soit dans 
> l’impossibilité d’avoir des statistiques fiables sur ces questions, et qu’en 
> ayant gratté un peu je sur persuadé que personne n’a pas de statistiques 
> fiables. Même le monument auto-proclamé sur la question de la résilience de 
> l’Internet Français ne donne aucune indication sur du trafic.
> 
> 
> Donc la question intéressante pour moi n’est pas que le journaliste du Point 
> se soit planté et qu’il faille lui remonter les bretelles. C’est plutôt 
> pourquoi personne n’est capable de donner des statistiques fiables sur une 
> question pertinente. 
> 
> Pouvons nous, en tant que communauté y faire quelque chose ? du genre 
> crowd-sourcing 
> 
> A+
> Kv
> 
> 
>> Le 10 févr. 2017 à 16:30, Stephane Bortzmeyer  a écrit :
>> 
>> Il parle d'un centre situé « quelque part dans Paris » qui abrite un
>> « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements
>> vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi
>> il s'agit (le Point, pour faire croire qu'ils connaissent des secrets
>> d'État, ne donne pas le nom de ce mystérieux centre) mais ma question
>> portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain
>> passe par là ».
>> 
>> Quelqu'un a une idée de l'origine, de la méthodologie, et de la
>> véracité de ce chiffre ?  (Sinon, il va falloir que je scrape l'HTML
>> de  et
>> on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
>> débit.)
>> 
>> [C'est vendredi mais ma question est sérieuse.]
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[David Ponzone]

Certainement pas assez gros pour compenser, il y aura goulot d’étranglement 
massif entre ceux qui n’ont pas de PNI.
Donc si on part du principe que les puissants utilisent des PNI pour passer 80% 
au moins de leur traffic, ceux qui continuent de communiquer correctement en 
coupant les 3 ou 4 GIX de Paris (et aussi de Lyon si tu veux) ont probablement 
du PNI largement dimensionné.
Mais là, c’est quand même du troll velu de vacances scolaires.

> Le 15 févr. 2017 à 12:01, Michel Hostettler 
>  a écrit :
> 
> Bonjour,
> 
> Il peut exister des circuits de secours hors Paris.
> 
> Cordialement,
> Michel
> 
> - Mail original -
> De: "David Ponzone" 
> À: "Kavé Salamatian" 
> Cc: "Frnog misc" 
> Envoyé: Mercredi 15 Février 2017 11:50:27
> Objet: Re: [FRnOG] [MISC] Article du Point sur la cyberguerre
> 
> Je vois mal comment le crowd-sourcing nous permettrait d’avoir les 
> statistiques des PNI entre les puissants, à moins d’inviter les salariés de 
> ces sociétés à rompre leur NDA…
> 
> On pourrait bien éteindre les GIX principaux de Paris et voir ce qui marche 
> encore correctement :)
> 
> 
>> Le 15 févr. 2017 à 11:42, Kavé Salamatian  a 
>> écrit :
>> 
>> Bonjour à tous,
>> 
>> j’ai attendu de voir les discussions sur ce ce topic et voir si quelqu’un 
>> soulèverait la bonne question. En effet, le chiffre avancé par le Point 
>> (80%) est sans bases fiables, et c’est attendu puisque c’et un journaliste 
>> qui en parle. Mais on peut se poser ici des questions techniques du genre. 
>> Est ce quelqu’un connait le vrai chiffre ? ou même plus intéressant est il 
>> possible d’estimer  ce chiffre dans l’état actuel de l’architecture de 
>> l’Internet Français? 
>> 
>> Je me suis attelé il y’a deux ans à faire une estimation de la matrice de 
>> trafic française entre opérateur de différents pays (en particulier pour 
>> savoir quel était le pourcentage de trafic susceptible d’être directement 
>> surveillé par les five eyes). Le résultat a été qu’il est impossible 
>> d’estimer ces informations et plus généralement, toute information fiable 
>> sur la distribution de trafic en France sans une aide directe des opérateurs 
>> concernés. Hors, ceci ne coopèrent pas. On se rappellera la lettre sèche des 
>> opérateurs US opérant en France qui avait refusé de répondre à l’enquête de 
>> l’ARCEP sur le volume de trafic inter-domaine. 
>> 
>> Certains pourront discuter du fait, que cela ne sert à rien de connaitre la 
>> distribution de trafic, ou du fait que la liberté des opérateurs  de faire 
>> du business comme ils le souhaitent est plus importante, et que la 
>> régulation c’est le mal, etc….Mais je trouve un peu bizarre qu’on soit dans 
>> l’impossibilité d’avoir des statistiques fiables sur ces questions, et qu’en 
>> ayant gratté un peu je sur persuadé que personne n’a pas de statistiques 
>> fiables. Même le monument auto-proclamé sur la question de la résilience de 
>> l’Internet Français ne donne aucune indication sur du trafic.
>> 
>> 
>> Donc la question intéressante pour moi n’est pas que le journaliste du Point 
>> se soit planté et qu’il faille lui remonter les bretelles. C’est plutôt 
>> pourquoi personne n’est capable de donner des statistiques fiables sur une 
>> question pertinente. 
>> 
>> Pouvons nous, en tant que communauté y faire quelque chose ? du genre 
>> crowd-sourcing 
>> 
>> A+
>> Kv
>> 
>> 
>>> Le 10 févr. 2017 à 16:30, Stephane Bortzmeyer  a écrit :
>>> 
>>> Il parle d'un centre situé « quelque part dans Paris » qui abrite un
>>> « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements
>>> vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi
>>> il s'agit (le Point, pour faire croire qu'ils connaissent des secrets
>>> d'État, ne donne pas le nom de ce mystérieux centre) mais ma question
>>> portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain
>>> passe par là ».
>>> 
>>> Quelqu'un a une idée de l'origine, de la méthodologie, et de la
>>> véracité de ce chiffre ?  (Sinon, il va falloir que je scrape l'HTML
>>> de  et
>>> on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
>>> débit.)
>>> 
>>> [C'est vendredi mais ma question est sérieuse.]
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[Kavé Salamatian]

pas si velu que ca. On peut utiliser les pannes pour avoir des informations « 
cachés » sur les capacités alternatives. Ca à déjà été utilisé en « tomographie 
réseau ».

Kv
> Le 15 févr. 2017 à 12:05, David Ponzone  a écrit :
> 
> Certainement pas assez gros pour compenser, il y aura goulot d’étranglement 
> massif entre ceux qui n’ont pas de PNI.
> Donc si on part du principe que les puissants utilisent des PNI pour passer 
> 80% au moins de leur traffic, ceux qui continuent de communiquer correctement 
> en coupant les 3 ou 4 GIX de Paris (et aussi de Lyon si tu veux) ont 
> probablement du PNI largement dimensionné.
> Mais là, c’est quand même du troll velu de vacances scolaires.
> 
>> Le 15 févr. 2017 à 12:01, Michel Hostettler 
>>  a écrit :
>> 
>> Bonjour,
>> 
>> Il peut exister des circuits de secours hors Paris.
>> 
>> Cordialement,
>> Michel
>> 
>> - Mail original -
>> De: "David Ponzone" 
>> À: "Kavé Salamatian" 
>> Cc: "Frnog misc" 
>> Envoyé: Mercredi 15 Février 2017 11:50:27
>> Objet: Re: [FRnOG] [MISC] Article du Point sur la cyberguerre
>> 
>> Je vois mal comment le crowd-sourcing nous permettrait d’avoir les 
>> statistiques des PNI entre les puissants, à moins d’inviter les salariés de 
>> ces sociétés à rompre leur NDA…
>> 
>> On pourrait bien éteindre les GIX principaux de Paris et voir ce qui marche 
>> encore correctement :)
>> 
>> 
>>> Le 15 févr. 2017 à 11:42, Kavé Salamatian  
>>> a écrit :
>>> 
>>> Bonjour à tous,
>>> 
>>> j’ai attendu de voir les discussions sur ce ce topic et voir si quelqu’un 
>>> soulèverait la bonne question. En effet, le chiffre avancé par le Point 
>>> (80%) est sans bases fiables, et c’est attendu puisque c’et un journaliste 
>>> qui en parle. Mais on peut se poser ici des questions techniques du genre. 
>>> Est ce quelqu’un connait le vrai chiffre ? ou même plus intéressant est il 
>>> possible d’estimer  ce chiffre dans l’état actuel de l’architecture de 
>>> l’Internet Français? 
>>> 
>>> Je me suis attelé il y’a deux ans à faire une estimation de la matrice de 
>>> trafic française entre opérateur de différents pays (en particulier pour 
>>> savoir quel était le pourcentage de trafic susceptible d’être directement 
>>> surveillé par les five eyes). Le résultat a été qu’il est impossible 
>>> d’estimer ces informations et plus généralement, toute information fiable 
>>> sur la distribution de trafic en France sans une aide directe des 
>>> opérateurs concernés. Hors, ceci ne coopèrent pas. On se rappellera la 
>>> lettre sèche des opérateurs US opérant en France qui avait refusé de 
>>> répondre à l’enquête de l’ARCEP sur le volume de trafic inter-domaine. 
>>> 
>>> Certains pourront discuter du fait, que cela ne sert à rien de connaitre la 
>>> distribution de trafic, ou du fait que la liberté des opérateurs  de faire 
>>> du business comme ils le souhaitent est plus importante, et que la 
>>> régulation c’est le mal, etc….Mais je trouve un peu bizarre qu’on soit dans 
>>> l’impossibilité d’avoir des statistiques fiables sur ces questions, et 
>>> qu’en ayant gratté un peu je sur persuadé que personne n’a pas de 
>>> statistiques fiables. Même le monument auto-proclamé sur la question de la 
>>> résilience de l’Internet Français ne donne aucune indication sur du trafic.
>>> 
>>> 
>>> Donc la question intéressante pour moi n’est pas que le journaliste du 
>>> Point se soit planté et qu’il faille lui remonter les bretelles. C’est 
>>> plutôt pourquoi personne n’est capable de donner des statistiques fiables 
>>> sur une question pertinente. 
>>> 
>>> Pouvons nous, en tant que communauté y faire quelque chose ? du genre 
>>> crowd-sourcing 
>>> 
>>> A+
>>> Kv
>>> 
>>> 
 Le 10 févr. 2017 à 16:30, Stephane Bortzmeyer  a écrit :
 
 Il parle d'un centre situé « quelque part dans Paris » qui abrite un
 « bâtiment ultrasécurisé [...] 14 000 mètres carrés d'équipements
 vitaux pour l'Internet français ». Bon, je vous laisse deviner de quoi
 il s'agit (le Point, pour faire croire qu'ils connaissent des secrets
 d'État, ne donne pas le nom de ce mystérieux centre) mais ma question
 portait sur un autre chiffre « 80 % du trafic direct [?] métropolitain
 passe par là ».
 
 Quelqu'un a une idée de l'origine, de la méthodologie, et de la
 véracité de ce chiffre ?  (Sinon, il va falloir que je scrape l'HTML
 de  et
 on aura au moins le pourcentage en capacité, à défaut d'avoir celui en
 débit.)
 
 [C'est vendredi mais ma question est sérieuse.]
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 


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

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[Emmanuel Jacquet]

Hors sujet mais

Le 15 février 2017 à 11:42, Kavé Salamatian
 a écrit :
> En effet, le chiffre avancé par le Point (80%) est sans bases fiables,
> et c’est attendu puisque c’et un journaliste qui en parle.

Juste pour souligner ce point, je crois que c'est un peu facile et
gratuit de taper sur "les journalistes qui écrivent des conneries", si
je traduis bien ton propos. Certains font bien leur boulot.

M.


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

Re: [FRnOG] [MISC] La Poste et les services secrets français

[Sébastien Lesimple]

Bon, aller, ca va bien comme ca les conneries...
openaliasbox.org / openmailbox.com => Blacklist sur tous les MX clients.


On 15/02/2017 12:41, FanThomaS wrote:
> Non mais j'insiste, ce n'est pas un troll.
>
> Le 2017-02-15 06:50, Michel Py a écrit :
>>> Inutile de raconter n'importe quoi pour essayer de faire oublier le
>>> sujet principal. Ca sent le mec de mèche.
>>
>> En effet, il y a des trolls qui méritent des croquettes, et d'autres
>> qu'il ne faut pas nourrir.
>>
>> Olivier, LE troll de la liste du FRnOG c'est MOI. Quand je suis en
>> vacances ou occupé, David s'en occupe. J'apprécie ton humour; vu que
>> tu viens juste de descendre de l'avion, il doit te rester un peu
>> d'Anglais  de Floride dans tes oreilles : Don't feed the troll.
>>
>> Les conneries de Michel Riguidel et de Christine Albanel, c'est du
>> troll validé par le volume. Les conneries de fantomas, non. La
>> prochaine fois que fantomas nous pondra un article dans "Le Monde" ou
>> "Le Point", on pourra en discuter.
>>
>> Je remarque que le troll récent à propos de la cyberguerre crève de
>> faim à part quelques croquettes pour quelque jours il va pas
>> passer l'hiver.
>>
>> Un bon troll ! La station Mir va s'écraser sur Paris et çà sera la fin
>> de l'Internet, hein ?
>>
>> Michel.
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/



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

Re: [FRnOG] [MISC] La Poste et les services secrets français

[David Ponzone]

Mais non, arrête, il est rigolo, ça me rappelle un film avec Jacques Villeret 
et Thierry Lhermitte :)


> Le 15 févr. 2017 à 12:51, Sébastien Lesimple 
>  a écrit :
> 
> Bon, aller, ca va bien comme ca les conneries...
> openaliasbox.org / openmailbox.com => Blacklist sur tous les MX clients.
> 
> 
> On 15/02/2017 12:41, FanThomaS wrote:
>> Non mais j'insiste, ce n'est pas un troll.
>> 
>> Le 2017-02-15 06:50, Michel Py a écrit :
 Inutile de raconter n'importe quoi pour essayer de faire oublier le
 sujet principal. Ca sent le mec de mèche.
>>> 
>>> En effet, il y a des trolls qui méritent des croquettes, et d'autres
>>> qu'il ne faut pas nourrir.
>>> 
>>> Olivier, LE troll de la liste du FRnOG c'est MOI. Quand je suis en
>>> vacances ou occupé, David s'en occupe. J'apprécie ton humour; vu que
>>> tu viens juste de descendre de l'avion, il doit te rester un peu
>>> d'Anglais  de Floride dans tes oreilles : Don't feed the troll.
>>> 
>>> Les conneries de Michel Riguidel et de Christine Albanel, c'est du
>>> troll validé par le volume. Les conneries de fantomas, non. La
>>> prochaine fois que fantomas nous pondra un article dans "Le Monde" ou
>>> "Le Point", on pourra en discuter.
>>> 
>>> Je remarque que le troll récent à propos de la cyberguerre crève de
>>> faim à part quelques croquettes pour quelque jours il va pas
>>> passer l'hiver.
>>> 
>>> Un bon troll ! La station Mir va s'écraser sur Paris et çà sera la fin
>>> de l'Internet, hein ?
>>> 
>>> Michel.
>>> 
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] La Poste et les services secrets français

[Cédric ML]

Moi ça me rappelle j34nk3vin, mais en pas drole...



Le 15/02/2017 à 12:58, David Ponzone a écrit :

Mais non, arrête, il est rigolo, ça me rappelle un film avec Jacques Villeret 
et Thierry Lhermitte :)



Le 15 févr. 2017 à 12:51, Sébastien Lesimple  
a écrit :

Bon, aller, ca va bien comme ca les conneries...
openaliasbox.org / openmailbox.com => Blacklist sur tous les MX clients.


On 15/02/2017 12:41, FanThomaS wrote:

Non mais j'insiste, ce n'est pas un troll.

Le 2017-02-15 06:50, Michel Py a écrit :

Inutile de raconter n'importe quoi pour essayer de faire oublier le
sujet principal. Ca sent le mec de mèche.

En effet, il y a des trolls qui méritent des croquettes, et d'autres
qu'il ne faut pas nourrir.

Olivier, LE troll de la liste du FRnOG c'est MOI. Quand je suis en
vacances ou occupé, David s'en occupe. J'apprécie ton humour; vu que
tu viens juste de descendre de l'avion, il doit te rester un peu
d'Anglais  de Floride dans tes oreilles : Don't feed the troll.

Les conneries de Michel Riguidel et de Christine Albanel, c'est du
troll validé par le volume. Les conneries de fantomas, non. La
prochaine fois que fantomas nous pondra un article dans "Le Monde" ou
"Le Point", on pourra en discuter.

Je remarque que le troll récent à propos de la cyberguerre crève de
faim à part quelques croquettes pour quelque jours il va pas
passer l'hiver.

Un bon troll ! La station Mir va s'écraser sur Paris et çà sera la fin
de l'Internet, hein ?

Michel.


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



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


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



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

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Xavier HINFRAY]

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière. Donc 
tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler 
 a écrit :
>Bonjour,
>
>Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
>?
>
>Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
>depuis 12 ans.
>
>Cordialement,
>Michel
>
>- Mail original -
>De: "Louis" 
>À: "sbu123fr" 
>Cc: "frnog-tech" 
>Envoyé: Mercredi 15 Février 2017 10:28:06
>Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>100Mo
>
>Probablement oui :
>
>http://smutz.us/techtips/NetworkLatency.html
>
>*Round trip latency*
>
>*TCP Throughput with no packet loss*
>
>*TCP Throughput with 2% packet loss*
>
>0 ms
>
>93.50 Mbps
>
>3.72 Mbps
>
>30 ms
>
>16.20 Mbps
>
>1.63 Mbps
>
>60 ms
>
>8.07 Mbps
>
>1.33 Mbps
>
>90 ms
>
>5.32 Mbps
>
>0.85 Mbps
>
>Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>
>Le 14 février 2017 à 18:57, sbu123fr  a écrit :
>
>> Grand merci.
>> Tu pense que sur des liens en île de france la latence est telle que
>le
>> trafic peut être divisé par 4-5?
>> Cdt
>> Sbu
>>
>>
>>
>>  Message d'origine 
>> De : Louis 
>> Date : 14/02/2017 18:05 (GMT+01:00)
>> À : Sylvain sbu 
>> Cc : frnog-tech 
>> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> cela dépend surtout du temps de réponse sur les liens. On perd en
>débit à
>> cause des acquittements nécessaires à TCP. Les durées d'acquittement
>> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de
>donnée
>> utile ne transite.
>>
>> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>> performances en augmentant le nombre de paquets reçus avant
>acquittements.
>> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les
>liens.
>>
>> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité
>de
>> la connexion. Les derniers OS ont des valeurs par défaut optimisées
>mais
>> qu'on peut tuner je crois.
>>
>> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs
>de
>> trafic. Il existe pas mal d'équipements sur le marché qui jouent
>entre
>> autre sur les paramètres window TCP.
>>
>> Je suppose que le débit est voulu pour des gros transferts de
>fichier.
>> Souvent, la solution adoptée est d'utiliser des outils qui
>parallélisent le
>> transfert du même fichier sur plusieurs sessions TCP.
>>
>> cordialement,
>>
>> Louis
>>
>>
>>
>>
>> Le 14 février 2017 à 16:45, Sylvain sbu  a écrit
>:
>>
>>> Bonjour,
>>> Non rien a voir avec du hachage car en changeant un paramétrè de
>>> "fenêtre" il est possible d'augmenter le max traffic a 75% des
>500Mo.
>>> cdt
>>> SBU
>>>
>>> Le 14 février 2017 à 16:41, Dominique Rousseau 
>a
>>> écrit :
>>>
 Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
 sbu12...@gmail.com] a écrit:
 > Bonjour,
 > Je ne suis pas spécialiste du transport IP.
 > Mais mon fournisseur de collecte m'explique que sur son service
>IP MPLS
 > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic
>max
 sur
 > une session TCP entre 2 liens

 Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.

 La limitation indiquée par ton fournisseur n'est pas étonnante.
 Elle correspond aux algorithmes de répartition entre les liens
>faisant
 partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
 adresses MAC source et destination, par exemple. Ce hachage sert à
 "choisir" l'un des liens faisant partie de l'aggregat, et tout le
>trafic
 correspondant a cette meme clef de hachage utilisera le meme lien.
 Tut te trouves alors limité par la capacité physique du lien
 sélectionné.
 Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir
>une
 capacité de 100Mbps, et donc la limitation s'explique.


 --
 Dominique Rousseau
 Neuronnexion, Prestataire Internet & Intranet
 21 rue Frédéric Petit - 8 Amiens
 tel: 03 22 71 61 90 - fax: 03 22 71 61 99 -
>http://www.neuronnexion.coop


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

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

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Article du Point sur la cyberguerre

[Kavé Salamatian]

Merci d’avoir demandé une clarification. Je confirme certains journalistes font 
bien leur boulot, et le propos de mon mail n’était pas d’attaquer les 
journalistes, mais bien de constater qu’aucun journaliste ne peut bien faire 
son boulot sur la question qui nous intéresse parce que personne n’a de réponse 
fiable à la question. Je suggère aussi en filigrane qu’un bon journaliste 
devrait se saisir de la question autrement plus importante et stratégique de 
savoir « pourquoi personne n’a de réponse à la question ?» :-)

A+

kv 
> Le 15 févr. 2017 à 12:49, Emmanuel Jacquet  a écrit :
> 
> Hors sujet mais
> 
> Le 15 février 2017 à 11:42, Kavé Salamatian
>  a écrit :
>> En effet, le chiffre avancé par le Point (80%) est sans bases fiables,
>> et c’est attendu puisque c’et un journaliste qui en parle.
> 
> Juste pour souligner ce point, je crois que c'est un peu facile et
> gratuit de taper sur "les journalistes qui écrivent des conneries", si
> je traduis bien ton propos. Certains font bien leur boulot.
> 
> M.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Michel Hostettler]

Le monde est mal fichu.
Les technologies évolues, mais pas les hommes, ni la vitesse de la lumière. 
Pour les femmes, je n'ose pas me prononcer.

Je me suis trompé d'échelle. La mienne était cassée.
Pour 5 µs / km, avec 30 ms, nous avons 6000 km de fibre optique

soit Paris - Campagnole et Campagnole - Paris

Cordialememt,
Michel (l'un d'eux)

- Mail original -
De: "Xavier HINFRAY" 
À: frnog@frnog.org, "Michel Hostettler" 
, "Louis" 
Cc: "sbu123fr" , "frnog-tech" 
Envoyé: Mercredi 15 Février 2017 13:03:49
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière. Donc 
tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler 
 a écrit :
>Bonjour,
>
>Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
>?
>
>Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
>depuis 12 ans.
>
>Cordialement,
>Michel
>
>- Mail original -
>De: "Louis" 
>À: "sbu123fr" 
>Cc: "frnog-tech" 
>Envoyé: Mercredi 15 Février 2017 10:28:06
>Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>100Mo
>
>Probablement oui :
>
>http://smutz.us/techtips/NetworkLatency.html
>
>*Round trip latency*
>
>*TCP Throughput with no packet loss*
>
>*TCP Throughput with 2% packet loss*
>
>0 ms
>
>93.50 Mbps
>
>3.72 Mbps
>
>30 ms
>
>16.20 Mbps
>
>1.63 Mbps
>
>60 ms
>
>8.07 Mbps
>
>1.33 Mbps
>
>90 ms
>
>5.32 Mbps
>
>0.85 Mbps
>
>Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>
>Le 14 février 2017 à 18:57, sbu123fr  a écrit :
>
>> Grand merci.
>> Tu pense que sur des liens en île de france la latence est telle que
>le
>> trafic peut être divisé par 4-5?
>> Cdt
>> Sbu
>>
>>
>>
>>  Message d'origine 
>> De : Louis 
>> Date : 14/02/2017 18:05 (GMT+01:00)
>> À : Sylvain sbu 
>> Cc : frnog-tech 
>> Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> cela dépend surtout du temps de réponse sur les liens. On perd en
>débit à
>> cause des acquittements nécessaires à TCP. Les durées d'acquittement
>> s'accroissent avec les temps de réponse. Pendant ce temps là, pas de
>donnée
>> utile ne transite.
>>
>> Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>> performances en augmentant le nombre de paquets reçus avant
>acquittements.
>> Cela fonctionne bien du moment qu'il n'y a pas de perte sur les
>liens.
>>
>> Le fenêtrage est dynamique sur les serveurs en fonction de la qualité
>de
>> la connexion. Les derniers OS ont des valeurs par défaut optimisées
>mais
>> qu'on peut tuner je crois.
>>
>> L'autre solution est d'optimiser le trafic TCP avec des optimiseurs
>de
>> trafic. Il existe pas mal d'équipements sur le marché qui jouent
>entre
>> autre sur les paramètres window TCP.
>>
>> Je suppose que le débit est voulu pour des gros transferts de
>fichier.
>> Souvent, la solution adoptée est d'utiliser des outils qui
>parallélisent le
>> transfert du même fichier sur plusieurs sessions TCP.
>>
>> cordialement,
>>
>> Louis
>>
>>
>>
>>
>> Le 14 février 2017 à 16:45, Sylvain sbu  a écrit
>:
>>
>>> Bonjour,
>>> Non rien a voir avec du hachage car en changeant un paramétrè de
>>> "fenêtre" il est possible d'augmenter le max traffic a 75% des
>500Mo.
>>> cdt
>>> SBU
>>>
>>> Le 14 février 2017 à 16:41, Dominique Rousseau 
>a
>>> écrit :
>>>
 Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
 sbu12...@gmail.com] a écrit:
 > Bonjour,
 > Je ne suis pas spécialiste du transport IP.
 > Mais mon fournisseur de collecte m'explique que sur son service
>IP MPLS
 > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic
>max
 sur
 > une session TCP entre 2 liens

 Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.

 La limitation indiquée par ton fournisseur n'est pas étonnante.
 Elle correspond aux algorithmes de répartition entre les liens
>faisant
 partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
 adresses MAC source et destination, par exemple. Ce hachage sert à
 "choisir" l'un des liens faisant partie de l'aggregat, et tout le
>trafic
 correspondant a cette meme clef de hachage utilisera le meme lien.
 Tut te trouves alors limité par la capacité physique du lien
 sélectionné.
 Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir
>une
 capacité de 100Mbps, et donc la limitation s'explique.


 --
 Dominique Rousseau
 Neuronnexion, Prestataire Internet & Intranet
 21 rue Frédéric Petit - 8 Amiens
 tel: 03 22 71 61 90 - fax: 03 22 71 61 99 -
>http://www.neuronnexion.coop


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

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

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Sylvain sbu]

40Kms grand max...

Le 15 février 2017 à 13:03, Xavier HINFRAY  a écrit :

> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>
> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
> michel.hostett...@telecom-paristech.fr> a écrit :
>>
>> Bonjour,
>>
>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?
>>
>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>> depuis 12 ans.
>>
>> Cordialement,
>> Michel
>>
>> - Mail original -
>> De: "Louis" 
>> À: "sbu123fr" 
>> Cc: "frnog-tech" 
>> Envoyé: Mercredi 15 Février 2017 10:28:06
>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>
>> Probablement oui :
>>
>> http://smutz.us/techtips/NetworkLatency.html
>>
>> *Round trip latency*
>>
>> *TCP Throughput with no packet loss*
>>
>> *TCP Throughput with 2% packet loss*
>>
>> 0 ms
>>
>> 93.50 Mbps
>>
>> 3.72 Mbps
>>
>> 30 ms
>>
>> 16.20 Mbps
>>
>> 1.63 Mbps
>>
>> 60 ms
>>
>> 8.07 Mbps
>>
>> 1.33 Mbps
>>
>> 90 ms
>>
>> 5.32 Mbps
>>
>> 0.85 Mbps
>>
>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>>
>> Le 14 février 2017 à 18:57, sbu123fr  a écrit :
>>
>>  Grand merci.
>>>  Tu pense que sur des liens en île de france la latence est telle que le
>>>  trafic peut être divisé par 4-5?
>>>  Cdt
>>>  Sbu
>>>
>>>
>>>
>>>   Message d'origine 
>>>  De : Louis 
>>>  Date : 14/02/2017 18:05 (GMT+01:00)
>>>  À : Sylvain sbu 
>>>  Cc : frnog-tech 
>>>  Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>
>>>  cela dépend surtout du temps de réponse sur les liens. On perd en débit à
>>>  cause des acquittements nécessaires à TCP. Les durées d'acquittement
>>>  s'accroissent avec les temps de réponse. Pendant ce temps là, pas de donnée
>>>  utile ne transite.
>>>
>>>  Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
>>>  performances en augmentant le nombre de paquets reçus avant acquittements.
>>>  Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.
>>>
>>>  Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
>>>  la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
>>>  qu'on peut tuner je crois.
>>>
>>>  L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
>>>  trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
>>>  autre sur les paramètres window TCP.
>>>
>>>  Je suppose que le débit est voulu pour des gros transferts de fichier.
>>>  Souvent, la solution adoptée est d'utiliser des outils qui parallélisent le
>>>  transfert du même fichier sur plusieurs sessions TCP.
>>>
>>>  cordialement,
>>>
>>>  Louis
>>>
>>>
>>>
>>>
>>>  Le 14 février 2017 à 16:45, Sylvain sbu  a écrit :
>>>
>>>  Bonjour,
  Non rien a voir avec du hachage car en changeant un paramétrè de
  "fenêtre" il est possible d'augmenter le max traffic a 75% des 500Mo.
  cdt
  SBU

  Le 14 février 2017 à 16:41, Dominique Rousseau  a
  écrit :

  Le Tue, Feb 14, 2017 at 04:29:48PM +0100, Sylvain sbu [
>  sbu12...@gmail.com] a écrit:
>
>>  Bonjour,
>>  Je ne suis pas spécialiste du transport IP.
>>  Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>>  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>>
>  sur
>
>>  une session TCP entre 2 liens
>>
>
>  Tes "4 liens", je suppose que c'est "5", avec de l'aggregation.
>
>  La limitation indiquée par ton fournisseur n'est pas étonnante.
>  Elle correspond aux algorithmes de répartition entre les liens faisant
>  partie de l'aggregat. Tu peux avoir un "hachage" effectuée sur les
>  adresses MAC source et destination, par exemple. Ce hachage sert à
>  "choisir" l'un des liens faisant partie de l'aggregat, et tout le trafic
>  correspondant a cette meme clef de hachage utilisera le meme lien.
>  Tut te trouves alors limité par la capacité physique du lien
>  sélectionné.
>  Comme tu parles de 5 liens pour obtenir 500Mbps, chacun doit avoir une
>  capacité de 100Mbps, et donc la limitation s'explique.
>
>
>  --
>  Dominique Rousseau
>  Neuronnexion, Prestataire Internet & Intranet
>  21 rue Frédéric Petit - 8 Amiens
>  tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
>  ---
>  Liste de diffusion du FRnOG
>  http://www.frnog.org/



>>>
>>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
> --
> Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
>

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

[FRnOG] [TECH] IPSec pour tunneliser SIG SIP

[Sébastien Lesimple]

Salut!

Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour
shooter de la Sig SIP dans un tunnel IPSEC?

On me reparle d'Interco SIP avec Verizon ces derniers temps...

Dans mes lointains souvenirs, il fallait tunneliser SIG et Media,
aujourd'hui, seule la Sig est a tunneliser.

Donc, Tomato, OpenVPN, OpenSwan...?

Seb.


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

Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP

[David Ponzone]

OpenVPN fait pas d’IPSec, il me semble.

Sinon Openswan ou Strongswan.
Ou sinon tu mets une box/VM dédiée, genre VyOS ou RouterOS.



> Le 15 févr. 2017 à 13:55, Sébastien Lesimple 
>  a écrit :
> 
> Salut!
> 
> Petit sondage rapide, vous utiliseriez quoi comme solution VPN pour
> shooter de la Sig SIP dans un tunnel IPSEC?
> 
> On me reparle d'Interco SIP avec Verizon ces derniers temps...
> 
> Dans mes lointains souvenirs, il fallait tunneliser SIG et Media,
> aujourd'hui, seule la Sig est a tunneliser.
> 
> Donc, Tomato, OpenVPN, OpenSwan...?
> 
> Seb.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] IPSec pour tunneliser SIG SIP

[Laurent]

Le 15/02/2017 à 14:18, David Ponzone a écrit :
> OpenVPN fait pas d’IPSec, il me semble.

Je confirme : tunnel ssl


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

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Après quelques recherche, j'arrive à la conclusion que la limitation du
temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
de l'OS.

L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
les (très) vieux OS, la valeur maxi de window size était 65535 octets parce
que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
1323 est largement utilisée. Elle introduit un paramètre window size
scaling factor (8 bits) qui est un multiplcateur de la valeur de window
size. Le window size est étendu 16Mo au lieu de 64Ko.

Calculateur de bande passante sur une session TCP :
https://www.switch.ch/network/tools/tcp_throughput/
Pour la formule, c'est ici :
http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/

Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
faudrait une taille window de ~1800 Ko.

Il faut regarder les paramètres de l'OS pour voir si les paramètres
permettent d'avoir une window de cette taille.

Sur les windows récents, les paramètres sont décrits ici :
http://www.speedguide.net/articles/windows-8-10-2012-server-tcpip-tweaks-5077
- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
paramètre est normal.

c:\>netsh interface tcp show global

Paramètres TCP globaux
--
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA: enabled
Accès direct au cache: disabled
*Réglage auto fenêtre de réception   : normal*

Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window
maxi associée à ce paramètre "normal".

Il faudrait tester un téléchargement depuis un windows d'un gros fichier
avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On
verrait quel débit on obtient et Wireshark pourrait donner la taille de
window.

Louis

Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :

> 40Kms grand max...
>
> Le 15 février 2017 à 13:03, Xavier HINFRAY  a écrit :
>
>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>>
>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> michel.hostett...@telecom-paristech.fr> a écrit :
>>>
>>> Bonjour,
>>>
>>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?
>>>
>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>>> depuis 12 ans.
>>>
>>> Cordialement,
>>> Michel
>>>
>>> - Mail original -
>>> De: "Louis" 
>>> À: "sbu123fr" 
>>> Cc: "frnog-tech" 
>>> Envoyé: Mercredi 15 Février 2017 10:28:06
>>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>>>
>>> Probablement oui :
>>>
>>> http://smutz.us/techtips/NetworkLatency.html
>>>
>>> *Round trip latency*
>>>
>>> *TCP Throughput with no packet loss*
>>>
>>> *TCP Throughput with 2% packet loss*
>>>
>>> 0 ms
>>>
>>> 93.50 Mbps
>>>
>>> 3.72 Mbps
>>>
>>> 30 ms
>>>
>>> 16.20 Mbps
>>>
>>> 1.63 Mbps
>>>
>>> 60 ms
>>>
>>> 8.07 Mbps
>>>
>>> 1.33 Mbps
>>>
>>> 90 ms
>>>
>>> 5.32 Mbps
>>>
>>> 0.85 Mbps
>>>
>>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
>>>
>>> Le 14 février 2017 à 18:57, sbu123fr  a écrit :
>>>
>>>  Grand merci.
  Tu pense que sur des liens en île de france la latence est telle que le
  trafic peut être divisé par 4-5?
  Cdt
  Sbu



   Message d'origine 
  De : Louis 
  Date : 14/02/2017 18:05 (GMT+01:00)
  À : Sylvain sbu 
  Cc : frnog-tech 
  Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

  cela dépend surtout du temps de réponse sur les liens. On perd en débit à
  cause des acquittements nécessaires à TCP. Les durées d'acquittement
  s'accroissent avec les temps de réponse. Pendant ce temps là, pas de 
 donnée
  utile ne transite.

  Effectivement, un fenêtrage plus haut (window) permet d'améliorer les
  performances en augmentant le nombre de paquets reçus avant acquittements.
  Cela fonctionne bien du moment qu'il n'y a pas de perte sur les liens.

  Le fenêtrage est dynamique sur les serveurs en fonction de la qualité de
  la connexion. Les derniers OS ont des valeurs par défaut optimisées mais
  qu'on peut tuner je crois.

  L'autre solution est d'optimiser le trafic TCP avec des optimiseurs de
  trafic. Il existe pas mal d'équipements sur le marché qui jouent entre
  autre sur les paramètres window TCP.

  Je suppose que le débit est voulu pour des gros transferts de fichier.
  Souvent, la solution adoptée est d'utiliser des outils qui parallélisent 
 le
  transfert du même fichier sur plusieurs sessions TCP.

  cordialement,

  Louis

>

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Benjamin Bachelart]

Oui mais non,

Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
liens de façon parfaitement aléatoire, souvent les équipements balancent le
trafic de manière *déterministe* sur l'un des liens physiques, en se basant
sur le couple adresse source-destination, cela peut-être Adresse IP source
/ Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
exceptions, et sûrement des solutions propriétaires.

Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas (exception
faite des solutions propriétaires ou solutions non déterministes de
balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,

2017-02-15 14:56 GMT+01:00 Louis :

> Après quelques recherche, j'arrive à la conclusion que la limitation du
> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
> de l'OS.
>
> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
> les (très) vieux OS, la valeur maxi de window size était 65535 octets parce
> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
> 1323 est largement utilisée. Elle introduit un paramètre window size
> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
> size. Le window size est étendu 16Mo au lieu de 64Ko.
>
> Calculateur de bande passante sur une session TCP :
> https://www.switch.ch/network/tools/tcp_throughput/
> Pour la formule, c'est ici :
> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-
> throughput-for-long-distance-links/
>
> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
> faudrait une taille window de ~1800 Ko.
>
> Il faut regarder les paramètres de l'OS pour voir si les paramètres
> permettent d'avoir une window de cette taille.
>
> Sur les windows récents, les paramètres sont décrits ici :
> http://www.speedguide.net/articles/windows-8-10-2012-
> server-tcpip-tweaks-5077
> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
> paramètre est normal.
>
> c:\>netsh interface tcp show global
>
> Paramètres TCP globaux
> --
> État de mise à l'échelle côté réception : enabled
> État de déchargement Chimney : automatic
> État NetDMA: enabled
> Accès direct au cache: disabled
> *Réglage auto fenêtre de réception   : normal*
>
> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window
> maxi associée à ce paramètre "normal".
>
> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On
> verrait quel débit on obtient et Wireshark pourrait donner la taille de
> window.
>
> Louis
>
> Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :
>
> > 40Kms grand max...
> >
> > Le 15 février 2017 à 13:03, Xavier HINFRAY  a écrit
> :
> >
> >> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
> >> Donc tout dépend de la distance entre le point de départ et d'arrivée.
> >>
> >> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
> >> michel.hostett...@telecom-paristech.fr> a écrit :
> >>>
> >>> Bonjour,
> >>>
> >>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms
> ?
> >>>
> >>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué
> depuis 12 ans.
> >>>
> >>> Cordialement,
> >>> Michel
> >>>
> >>> - Mail original -
> >>> De: "Louis" 
> >>> À: "sbu123fr" 
> >>> Cc: "frnog-tech" 
> >>> Envoyé: Mercredi 15 Février 2017 10:28:06
> >>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
> 100Mo
> >>>
> >>> Probablement oui :
> >>>
> >>> http://smutz.us/techtips/NetworkLatency.html
> >>>
> >>> *Round trip latency*
> >>>
> >>> *TCP Throughput with no packet loss*
> >>>
> >>> *TCP Throughput with 2% packet loss*
> >>>
> >>> 0 ms
> >>>
> >>> 93.50 Mbps
> >>>
> >>> 3.72 Mbps
> >>>
> >>> 30 ms
> >>>
> >>> 16.20 Mbps
> >>>
> >>> 1.63 Mbps
> >>>
> >>> 60 ms
> >>>
> >>> 8.07 Mbps
> >>>
> >>> 1.33 Mbps
> >>>
> >>> 90 ms
> >>>
> >>> 5.32 Mbps
> >>>
> >>> 0.85 Mbps
> >>>
> >>> Table 2 - Effect of Latency and 2% Packet Loss on TCP Throughput
> >>>
> >>> Le 14 février 2017 à 18:57, sbu123fr  a écrit :
> >>>
> >>>  Grand merci.
>   Tu pense que sur des liens en île de france la latence est telle que
> le
>   trafic peut être divisé par 4-5?
>   Cdt
>   Sbu
> 
> 
> 
>    Message d'origine 
>   De : Louis 
>   Date : 14/02/2017 18:05 (GMT+01:00)
>   À : Sylvain sbu 
>   Cc : frnog-tech 
>   Objet : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
> 
>   cela dépend surtout du temps de réponse sur les liens. On perd en
> débit à
>   cause des

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
une session TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :

> Oui mais non,
>
> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
> liens de façon parfaitement aléatoire, souvent les équipements balancent le
> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
> sur le couple adresse source-destination, cela peut-être Adresse IP source
> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> exceptions, et sûrement des solutions propriétaires.
>
> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> (exception faite des solutions propriétaires ou solutions non déterministes
> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>
> cordialement,
>
> 2017-02-15 14:56 GMT+01:00 Louis :
>
>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>> de l'OS.
>>
>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> parce
>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>
>> Calculateur de bande passante sur une session TCP :
>> https://www.switch.ch/network/tools/tcp_throughput/
>> Pour la formule, c'est ici :
>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> ghput-for-long-distance-links/
>>
>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>> faudrait une taille window de ~1800 Ko.
>>
>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>> permettent d'avoir une window de cette taille.
>>
>> Sur les windows récents, les paramètres sont décrits ici :
>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>> tcpip-tweaks-5077
>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>> paramètre est normal.
>>
>> c:\>netsh interface tcp show global
>>
>> Paramètres TCP globaux
>> --
>> État de mise à l'échelle côté réception : enabled
>> État de déchargement Chimney : automatic
>> État NetDMA: enabled
>> Accès direct au cache: disabled
>> *Réglage auto fenêtre de réception   : normal*
>>
>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>> window
>> maxi associée à ce paramètre "normal".
>>
>> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
>> On
>> verrait quel débit on obtient et Wireshark pourrait donner la taille de
>> window.
>>
>> Louis
>>
>> Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :
>>
>> > 40Kms grand max...
>> >
>> > Le 15 février 2017 à 13:03, Xavier HINFRAY  a
>> écrit :
>> >
>> >> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
>> >> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>> >>
>> >> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
>> >> michel.hostett...@telecom-paristech.fr> a écrit :
>> >>>
>> >>> Bonjour,
>> >>>
>> >>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30
>> ms ?
>> >>>
>> >>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas
>> évolué depuis 12 ans.
>> >>>
>> >>> Cordialement,
>> >>> Michel
>> >>>
>> >>> - Mail original -
>> >>> De: "Louis" 
>> >>> À: "sbu123fr" 
>> >>> Cc: "frnog-tech" 
>> >>> Envoyé: Mercredi 15 Février 2017 10:28:06
>> >>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>> 100Mo
>> >>>
>> >>> Probablement oui :
>> >>>
>> >>> http://smutz.us/techtips/NetworkLatency.html
>> >>>
>> >>> *Round trip latency*
>> >>>
>> >>> *TCP Throughput with no packet loss*
>> >>>
>> >>> *TCP Throughput with 2% packet loss*
>> >>>
>> >>> 0 ms
>> >>>
>> >>> 93.50 Mbps
>> >>>
>> >>> 3.72 Mbps
>> >>>
>> >>> 30 ms
>> >>>
>> >>> 16.20 Mbps
>> >>>
>> >>> 1.63 Mbps
>> >>>
>> >>> 60 ms
>> >>>
>> >>> 8.07 Mbps
>> >>>
>> >>> 1.33 Mbps
>> >>>
>> >>> 90 ms
>> >>>
>> >>> 5.32 Mbps
>> >>>
>> >>> 0.85 Mbps
>> >>>
>> >>> Table 2 - Effect of Latency and 2% Packet Loss on TC

Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou Laurent]

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.


Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.


Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.


Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
une session TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :


Oui mais non,

Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
liens de façon parfaitement aléatoire, souvent les équipements balancent le
trafic de manière *déterministe* sur l'un des liens physiques, en se basant
sur le couple adresse source-destination, cela peut-être Adresse IP source
/ Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
exceptions, et sûrement des solutions propriétaires.

Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
(exception faite des solutions propriétaires ou solutions non déterministes
de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,

2017-02-15 14:56 GMT+01:00 Louis :


Après quelques recherche, j'arrive à la conclusion que la limitation du
temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
de l'OS.

L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
les (très) vieux OS, la valeur maxi de window size était 65535 octets
parce
que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
1323 est largement utilisée. Elle introduit un paramètre window size
scaling factor (8 bits) qui est un multiplcateur de la valeur de window
size. Le window size est étendu 16Mo au lieu de 64Ko.

Calculateur de bande passante sur une session TCP :
https://www.switch.ch/network/tools/tcp_throughput/
Pour la formule, c'est ici :
http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
ghput-for-long-distance-links/

Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
faudrait une taille window de ~1800 Ko.

Il faut regarder les paramètres de l'OS pour voir si les paramètres
permettent d'avoir une window de cette taille.

Sur les windows récents, les paramètres sont décrits ici :
http://www.speedguide.net/articles/windows-8-10-2012-server-
tcpip-tweaks-5077
- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
paramètre est normal.

c:\>netsh interface tcp show global

Paramètres TCP globaux
--
État de mise à l'échelle côté réception : enabled
État de déchargement Chimney : automatic
État NetDMA: enabled
Accès direct au cache: disabled
*Réglage auto fenêtre de réception   : normal*

Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
window
maxi associée à ce paramètre "normal".

Il faudrait tester un téléchargement depuis un windows d'un gros fichier
avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
On
verrait quel débit on obtient et Wireshark pourrait donner la taille de
window.

Louis

Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :


40Kms grand max...

Le 15 février 2017 à 13:03, Xavier HINFRAY  a

écrit :

Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
Donc tout dépend de la distance entre le point de départ et d'arrivée.

Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
michel.hostett...@telecom-paristech.fr> a écrit :

Bonjour,

Est-ce encore plausible de nos jours, un temps d'aller retour de 30

ms ?

Le document daterait de janvier 2005. Les réseaux n'ont-ils pas

évolué depuis 12 ans.

Cordialement,
Michel

- Mail original -
De: "Louis" 
À: "sbu123fr" 
Cc: "frnog-tech" 
Envoyé: Mercredi 15 Février 2017 10:28:06
Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x

100Mo

Probablement oui :

http://smutz.us/techtips/NetworkLatency.html

*Round trip latency*

*TCP Throughput with no packet loss*

*TCP Throughput with 2% packet loss*

0 ms

93.50 Mbps

3.72 Mbps

30 ms

16.20 Mbps

1.63 Mbps

60 ms

8.07 Mbps

1.33 Mbps

90 ms

5.32 Mbps

0.85 Mbp

RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent  
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis :
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>>> tcpip-tweaks-5077
>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>>> paramètre est normal.
>>>
>>> c:\>netsh interface tcp show global
>>>
>>> Paramètres TCP globaux
>>> --
>>> État de mise à l'échelle côté réception : enabled
>>> État de déchargement Chimney : automatic
>>> État NetDMA    : enabled
>>> Accès direct au cache    : disabled
>>> *Réglage auto fenêtre de réception   : normal*
>>>
>>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>>> window
>>> maxi associée à ce paramètre "normal".
>>>
>>> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
>>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
>>> On
>>> verrait quel débit on obtient et Wireshark pourrait donner la taille de
>>> window.
>>>
>>> Louis
>>>
>>> Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :
>>>
 40Kms grand max...

 Le 15 février 2017 à 13:03, Xavier HINFRAY  a
>>> écrit :
> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.
> Donc tout dépend de la distance entre le point de départ et d'arrivée.
>
> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <
> michel.hostett...@telecom-paristech.fr> a écrit :
>> Bonjour,
>>
>> Est-ce encore plau

RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

Exacte ! 

 Message d'origine 
De : Louis  
Date : 15/02/2017  15:35  (GMT+01:00) 
À : Benjamin Bachelart  
Cc : Sylvain sbu , Xavier HINFRAY , 
"frnog@FRnOG.org" , Michel Hostettler 
, frnog-tech  
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo 

Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus 
d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
"Mais mon fournisseur de collecte m'explique que sur son service IP MPLS 500Mo 
sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur une session 
TCP entre 2 liens"



Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
Oui mais non,

Sur un LAG, le 
trafic ne se répartie pas - comme par magie - sur tous les liens de 
façon parfaitement aléatoire, souvent les équipements balancent le 
trafic de manière *déterministe* sur l'un des liens physiques, en se 
basant sur le couple adresse source-destination, cela peut-être Adresse 
IP source / Adresse IP destination, ou de même avec l'adresse MAC, 
parfois peut-être par flux (Source IP+Port - Dest IP+Port), il existe 
sûrement des exceptions, et sûrement des solutions propriétaires.

Donc
 avec toutes les tailles de fenêtre tcp, vous ne pourrez pas (exception 
faite des solutions propriétaires ou solutions non déterministes de 
balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de 
100Mbps sur un LAG 5x100Mbps pour un même flux.

cordialement,
2017-02-15 14:56 GMT+01:00 Louis :
Après quelques recherche, j'arrive à la conclusion que la limitation du

temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps

(comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres

de l'OS.



L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur

les (très) vieux OS, la valeur maxi de window size était 65535 octets parce

que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC

1323 est largement utilisée. Elle introduit un paramètre window size

scaling factor (8 bits) qui est un multiplcateur de la valeur de window

size. Le window size est étendu 16Mo au lieu de 64Ko.



Calculateur de bande passante sur une session TCP :

https://www.switch.ch/network/tools/tcp_throughput/

Pour la formule, c'est ici :

http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throughput-for-long-distance-links/



Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il

faudrait une taille window de ~1800 Ko.



Il faut regarder les paramètres de l'OS pour voir si les paramètres

permettent d'avoir une window de cette taille.



Sur les windows récents, les paramètres sont décrits ici :

http://www.speedguide.net/articles/windows-8-10-2012-server-tcpip-tweaks-5077

- paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le

paramètre est normal.



c:\>netsh interface tcp show global



Paramètres TCP globaux

--

État de mise à l'échelle côté réception     : enabled

État de déchargement Chimney     : automatic

État NetDMA                        : enabled

Accès direct au cache            : disabled

*Réglage auto fenêtre de réception   : normal*



Malheureusement, je n'ai pas moyen de savoir quelle est la taille de window

maxi associée à ce paramètre "normal".



Il faudrait tester un téléchargement depuis un windows d'un gros fichier

avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat . On

verrait quel débit on obtient et Wireshark pourrait donner la taille de

window.



Louis



Le 15 février 2017 à 13:43, Sylvain sbu  a écrit :



> 40Kms grand max...

>

> Le 15 février 2017 à 13:03, Xavier HINFRAY  a écrit :

>

>> Les reseaux et serveurs ont evolués. Mais pas la vitesse de la lumière.

>> Donc tout dépend de la distance entre le point de départ et d'arrivée.

>>

>> Le 15 février 2017 10:47:28 GMT+01:00, Michel Hostettler <

>> michel.hostett...@telecom-paristech.fr> a écrit :

>>>

>>> Bonjour,

>>>

>>> Est-ce encore plausible de nos jours, un temps d'aller retour de 30 ms ?

>>>

>>> Le document daterait de janvier 2005. Les réseaux n'ont-ils pas évolué 
>>> depuis 12 ans.

>>>

>>> Cordialement,

>>> Michel

>>>

>>> - Mail original -

>>> De: "Louis" 

>>> À: "sbu123fr" 

>>> Cc: "frnog-tech" 

>>> Envoyé: Mercredi 15 Février 2017 10:28:06

>>> Objet: Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

>>>

>>> Probablement oui :

>>>

>>> http://smutz.us/techtips/NetworkLatency.html

>>>

>>> *Round trip latency*

>>>

>>> *TCP Throughput with no packet loss*

>>>

>>> *TCP Throughput with 2% packet loss*

>>>

>>> 0 ms

>>>

>>> 93.50 Mbps

>>>

>>> 3.72 Mbps

>>>

>>> 30 ms

>>>

>>> 16.20 Mbps

>>>

>>> 1.63 Mbps

>>>

>>> 60 ms

>>>

>>> 8.07 Mbps

>>>

>>> 1.33 Mbps

>>>

>>> 90 ms

>>>

>>> 5.32 Mbps

>>>

>>> 0.85 Mbps

>>>

>>> Table 2 - Effect 

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
disque classique est obligé de faire en permanence des aller-retours.

Le 15 février 2017 à 17:07, sbu123fr  a écrit :

> Bonjour
> Avec du multi session on obtient 280Mo
> Donc pas de souci de 100Mo sur la chaîne de liaison
>
>
>  Message d'origine 
> De : Ducassou Laurent 
> Date : 15/02/2017 16:36 (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
> 100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
> plus
> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
> >
> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
> >
> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> > une session TCP entre 2 liens"
> >
> >
> >
> > Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
> >
> >> Oui mais non,
> >>
> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
> les
> >> liens de façon parfaitement aléatoire, souvent les équipements
> balancent le
> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
> basant
> >> sur le couple adresse source-destination, cela peut-être Adresse IP
> source
> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
> peut-être
> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
> >> exceptions, et sûrement des solutions propriétaires.
> >>
> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
> >> (exception faite des solutions propriétaires ou solutions non
> déterministes
> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
> de
> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
> >>
> >> cordialement,
> >>
> >> 2017-02-15 14:56 GMT+01:00 Louis :
> >>
> >>> Après quelques recherche, j'arrive à la conclusion que la limitation du
> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
> paramètres
> >>> de l'OS.
> >>>
> >>> L'article de 2005 ne précise pas les valeurs de window size utilisées.
> Sur
> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
> >>> parce
> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la
> RFC
> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
> >>>
> >>> Calculateur de bande passante sur une session TCP :
> >>> https://www.switch.ch/network/tools/tcp_throughput/
> >>> Pour la formule, c'est ici :
> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
> >>> ghput-for-long-distance-links/
> >>>
> >>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s
> max), il
> >>> faudrait une taille window de ~1800 Ko.
> >>>
> >>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
> >>> permettent d'avoir une window de cette taille.
> >>>
> >>> Sur les windows récents, les paramètres sont décrits ici :
> >>> http://www.speedguide.net/articles/windows-8-10-2012-server-
> >>> tcpip-tweaks-5077
> >>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7,
> le
> >>> paramètre est normal.
> >>>
> >>> c:\>netsh interface tcp show global
> >>>
> >>> Paramètres TCP globaux
> >>> --
> >>> État de mise à l'échelle côté réception : enabled
> >>> État de déchargement Chimney : automatic
> >>> État NetDMA: enabled
> >>> Accès direct au cache: disabled
> >>> *Réglage auto fenêtre de réception   : normal*
> >>>
> >>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
> >>> window
> >>> maxi associée à ce paramètre "normal".
> >>>
> >>> Il faudrait tester un téléchargement depuis un windows d'un gros
> fichier
> >>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat
> .
> >>> On
> >>> verrait quel débit on obtient et Wireshark pourrait donner la taille de
> >>> window.
> >>>

Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Louis]

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez
fiable. Pas de lecture disque

Le 15 février 2017 à 17:20, Louis  a écrit :

> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
> débit. Avec un transfert multi-session, la tête de lecture/écriture d'un
> disque classique est obligé de faire en permanence des aller-retours.
>
> Le 15 février 2017 à 17:07, sbu123fr  a écrit :
>
>> Bonjour
>> Avec du multi session on obtient 280Mo
>> Donc pas de souci de 100Mo sur la chaîne de liaison
>>
>>
>>  Message d'origine 
>> De : Ducassou Laurent 
>> Date : 15/02/2017 16:36 (GMT+01:00)
>> À : frnog@frnog.org
>> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>> 100Mo
>>
>> Plus simplement :
>>
>> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
>> 500Mbit/s.
>>
>> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
>> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>>
>> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
>> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
>> client final crois disposer de 500Mbit/s entre chaque site, mais en
>> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
>> 100Mbit/s sur D et que E est au repos.
>>
>> Je crois avoir compris cela...
>>
>>
>> Le 15/02/2017 à 15:35, Louis a écrit :
>> > Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
>> plus
>> > d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>> >
>> > J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>> >
>> > "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>> > 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>> sur
>> > une session TCP entre 2 liens"
>> >
>> >
>> >
>> > Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
>> >
>> >> Oui mais non,
>> >>
>> >> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous
>> les
>> >> liens de façon parfaitement aléatoire, souvent les équipements
>> balancent le
>> >> trafic de manière *déterministe* sur l'un des liens physiques, en se
>> basant
>> >> sur le couple adresse source-destination, cela peut-être Adresse IP
>> source
>> >> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
>> peut-être
>> >> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> >> exceptions, et sûrement des solutions propriétaires.
>> >>
>> >> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> >> (exception faite des solutions propriétaires ou solutions non
>> déterministes
>> >> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus
>> de
>> >> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>> >>
>> >> cordialement,
>> >>
>> >> 2017-02-15 14:56 GMT+01:00 Louis :
>> >>
>> >>> Après quelques recherche, j'arrive à la conclusion que la limitation
>> du
>> >>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>> >>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
>> paramètres
>> >>> de l'OS.
>> >>>
>> >>> L'article de 2005 ne précise pas les valeurs de window size
>> utilisées. Sur
>> >>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>> >>> parce
>> >>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant,
>> la RFC
>> >>> 1323 est largement utilisée. Elle introduit un paramètre window size
>> >>> scaling factor (8 bits) qui est un multiplcateur de la valeur de
>> window
>> >>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>> >>>
>> >>> Calculateur de bande passante sur une session TCP :
>> >>> https://www.switch.ch/network/tools/tcp_throughput/
>> >>> Pour la formule, c'est ici :
>> >>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>> >>> ghput-for-long-distance-links/
>> >>>
>> >>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s
>> max), il
>> >>> faudrait une taille window de ~1800 Ko.
>> >>>
>> >>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>> >>> permettent d'avoir une window de cette taille.
>> >>>
>> >>> Sur les windows récents, les paramètres sont décrits ici :
>> >>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>> >>> tcpip-tweaks-5077
>> >>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7,
>> le
>> >>> paramètre est normal.
>> >>>
>> >>> c:\>netsh interface tcp show global
>> >>>
>> >>> Paramètres TCP globaux
>> >>> --
>> >>> État de mise à l'échelle côté réception : enabled
>> >>> État de déchargement Chimney : automatic
>> >>> État NetDMA: enabled
>> >>> Accès direct au cache: disabled
>> >>> *Réglage auto fenêtre de réception   : normal*
>> >>>
>> >>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>> >>> window
>> >>> maxi associée à ce paramè

RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

Oui ça ça m inquiet moins ☺

 Message d'origine 
De : Louis  
Date : 15/02/2017  17:20  (GMT+01:00) 
À : sbu123fr  
Cc : Ducassou Laurent , Liste FRnoG 
 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr  a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent  
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis :
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>>> tcpip-tweaks-5077
>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>>> paramètre est normal.
>>>
>>> c:\>netsh interface tcp show global
>>>
>>> Paramètres TCP globaux
>>> --
>>> État de mise à l'échelle côté réception : enabled
>>> État de déchargement Chimney : automatic
>>> État NetDMA    : enabled
>>> Accès direct au cache    : disabled
>>> *Réglage auto fenêtre de réception   : normal*
>>>
>>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>>> window
>>> maxi associée à ce paramètre "normal".
>>>
>>> Il faudrait tester un téléchargement depuis un windows d'un gros fichier
>>> avec une liaison >500 Mbps. Par exemple http://ovh.net/files/1Gio.dat .
>>> On
>>> verrait quel débit on obtient et Wireshark pourrait donner la 

RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes 

 Message d'origine 
De : Louis  
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr  
Cc : Ducassou Laurent , Liste FRnoG 
 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis  a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr  a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent  
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
> "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
> une session TCP entre 2 liens"
>
>
>
> Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
>
>> Oui mais non,
>>
>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>> liens de façon parfaitement aléatoire, souvent les équipements balancent le
>> trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>> sur le couple adresse source-destination, cela peut-être Adresse IP source
>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>> exceptions, et sûrement des solutions propriétaires.
>>
>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>> (exception faite des solutions propriétaires ou solutions non déterministes
>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>
>> cordialement,
>>
>> 2017-02-15 14:56 GMT+01:00 Louis :
>>
>>> Après quelques recherche, j'arrive à la conclusion que la limitation du
>>> temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
>>> (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
>>> de l'OS.
>>>
>>> L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
>>> les (très) vieux OS, la valeur maxi de window size était 65535 octets
>>> parce
>>> que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
>>> 1323 est largement utilisée. Elle introduit un paramètre window size
>>> scaling factor (8 bits) qui est un multiplcateur de la valeur de window
>>> size. Le window size est étendu 16Mo au lieu de 64Ko.
>>>
>>> Calculateur de bande passante sur une session TCP :
>>> https://www.switch.ch/network/tools/tcp_throughput/
>>> Pour la formule, c'est ici :
>>> http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
>>> ghput-for-long-distance-links/
>>>
>>> Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
>>> faudrait une taille window de ~1800 Ko.
>>>
>>> Il faut regarder les paramètres de l'OS pour voir si les paramètres
>>> permettent d'avoir une window de cette taille.
>>>
>>> Sur les windows récents, les paramètres sont décrits ici :
>>> http://www.speedguide.net/articles/windows-8-10-2012-server-
>>> tcpip-tweaks-5077
>>> - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
>>> paramètre est normal.
>>>
>>> c:\>netsh interface tcp show global
>>>
>>> Paramètres TCP globaux
>>> --
>>> État de mise à l'échelle côté réception : enabled
>>> État de déchargement Chimney : automatic
>>> État NetDMA    : enabled
>>> Accès direct au cache    : disabled
>>> *Réglage auto fenêtre de réception   : normal*
>>>
>>> Malheureusement, je n'ai pas moyen de savoir quelle est la taille de
>>> window
>>> maxi associée à ce paramètre "normal".
>>>
>>> 

Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou laurent]

Totalement cohérent alors. 

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr  a écrit :
>C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ
>en "mono" 100 et des bananes 
>
> Message d'origine 
>De : Louis  
>Date : 15/02/2017  17:22  (GMT+01:00) 
>À : sbu123fr  
>Cc : Ducassou Laurent , Liste FRnoG
> 
>Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais
>plutot 5 x 100Mo 
>
>Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est
>assez fiable. Pas de lecture disque
>Le 15 février 2017 à 17:20, Louis  a écrit :
>280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le
>débit. Avec un transfert multi-session, la tête de lecture/écriture
>d'un disque classique est obligé de faire en permanence des
>aller-retours.
>Le 15 février 2017 à 17:07, sbu123fr  a écrit :
>BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo
>sur la chaîne de liaison 
>
> Message d'origine 
>De : Ducassou Laurent  
>Date : 15/02/2017  16:36  (GMT+01:00) 
>À : frnog@frnog.org 
>Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>  100Mo 
>
>Plus simplement :
>
>Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
>500Mbit/s.
>
>Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
>
>que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
>Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
>compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
>client final crois disposer de 500Mbit/s entre chaque site, mais en 
>réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
>100Mbit/s sur D et que E est au repos.
>
>Je crois avoir compris cela...
>
>
>Le 15/02/2017 à 15:35, Louis a écrit :
>> Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait
>plus
>> d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>>
>> J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre
>sites).
>>
>> "Mais mon fournisseur de collecte m'explique que sur son service IP
>MPLS
>> 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max
>sur
>> une session TCP entre 2 liens"
>>
>>
>>
>> Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit
>:
>>
>>> Oui mais non,
>>>
>>> Sur un LAG, le trafic ne se répartie pas - comme par magie - sur
>tous les
>>> liens de façon parfaitement aléatoire, souvent les équipements
>balancent le
>>> trafic de manière *déterministe* sur l'un des liens physiques, en se
>basant
>>> sur le couple adresse source-destination, cela peut-être Adresse IP
>source
>>> / Adresse IP destination, ou de même avec l'adresse MAC, parfois
>peut-être
>>> par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>>> exceptions, et sûrement des solutions propriétaires.
>>>
>>> Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>>> (exception faite des solutions propriétaires ou solutions non
>déterministes
>>> de balancing sur LAG - ce que je n'ai pas encore observé -) avoir
>plus de
>>> 100Mbps sur un LAG 5x100Mbps pour un même flux.
>>>
>>> cordialement,
>>>
>>> 2017-02-15 14:56 GMT+01:00 Louis :
>>>
 Après quelques recherche, j'arrive à la conclusion que la
>limitation du
 temps de réponse est obsolète. Donc, oui tu peux atteindre les
>500Mbps
 (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des
>paramètres
 de l'OS.

 L'article de 2005 ne précise pas les valeurs de window size
>utilisées. Sur
 les (très) vieux OS, la valeur maxi de window size était 65535
>octets
 parce
 que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant,
>la RFC
 1323 est largement utilisée. Elle introduit un paramètre window
>size
 scaling factor (8 bits) qui est un multiplcateur de la valeur de
>window
 size. Le window size est étendu 16Mo au lieu de 64Ko.

 Calculateur de bande passante sur une session TCP :
 https://www.switch.ch/network/tools/tcp_throughput/
 Pour la formule, c'est ici :
 http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
 ghput-for-long-distance-links/

 Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s
>max), il
 faudrait une taille window de ~1800 Ko.

 Il faut regarder les paramètres de l'OS pour voir si les paramètres
 permettent d'avoir une window de cette taille.

 Sur les windows récents, les paramètres sont décrits ici :
 http://www.speedguide.net/articles/windows-8-10-2012-server-
 tcpip-tweaks-5077
 - paragraphe Receive Window Auto-Tuning Level. Test sur un windows
>7, le
 paramètre est normal.

 c:\>netsh interface tcp show global

 Paramètres TCP globaux
 --
 État de mise à l'échelle côté réception : enabled
 État de déchargement Chimney : automatic
 État NetDMA    : enabled
 Accès direc

[FRnOG] [MISC] Dépanage d'un SFP 1000Base LX noname à TH2 pour demain

[Sébastien Lesimple]

Hello!

J'ai un de mes camarade de jeux qui est en carafe chez TH2, il lui faut
un SFP 1000BaseLX monomode noname pour monter un X-Connect sur un
équipement SMC.

Y'a rupture de stock chez les LDLC/GrosBill and co à Paris, quelqu'un
peut il lui en revendre un pour demain?

Merci,

Seb;


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

RE: [FRnOG] [MISC] La Poste et les services secrets français

[Michel Py]

> Olivier Varenne a écrit :
> Oui, mais j'aime bien donner un petit coup sur la bête du bout de mon bâton 
> et la
> regarder s'énerver derrière les barreaux. Tant pis, je me vengerai sur un 
> client.

Quand tu fais çà c'est ce qu'il veut. C'est toi qui est dans la cage, il te 
fait réagir. On aime tous se défouler, mais çà dépend avec qui. Les trolls qui 
me font sourire, je leur donne des croquettes.

Michel.


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

Re: [FRnOG] [MISC] La Poste et les services secrets français

[Philippe Bourcier]

Bonsoir,

C'est bien ce que j'avais fait, mais il semblerait qu'il y avait un 
petit détail de conf de la liste que j'avais zappé.


Normalement là on est bon... si c'est pas le cas, c'est que Sympa n'est 
pas sympa avec moi.




Bon, aller, ca va bien comme ca les conneries...
openaliasbox.org / openmailbox.com => Blacklist sur tous les MX 
clients.





Cordialement,
--
Philippe Bourcier
web : http://sysctl.org/
blog : https://www.linkedin.com/today/author/philippebourcier


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

[FRnOG] [TECH] TCP mangling et net-neutrality

[Jérôme Nicolle]

Plop,

Ce post pour une seule simple question : d'après vous, est ce que
réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
tunneling, est une fonction compatible avec l'obligation de neutralité
du transporteur de paquets ?

Merci d'avance pour vos réflexions !

-- 
Jérôme Nicolle
06 19 31 27 14


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

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

[Kavé Salamatian]

> Le 15 févr. 2017 à 22:11, Jérôme Nicolle  a écrit :
> 
> Plop,
> 
> Ce post pour une seule simple question : d'après vous, est ce que
> réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
> tunneling, est une fonction compatible avec l'obligation de neutralité
> du transporteur de paquets ?
Il y’a de nombreuses définitions de la neutralité mais il y’a des éléments 
communs. On peut ainsi considérer comme contraire à la neutralité de 
l’opérateur tous changement d’entête TCP ou autre qui :
- n’est pas rendu nécessaire par un impératif technique incontournable (ex 
changer le contenu de l’entête TCP pour faire du masquerading et faire du NAT), 
- ou par une norme technique (comme changer le TTL quand on traverse un 
routeur) 
- ou que cela est fait pour le bénéfice de l’opérateur et non pas du client

Kv


> 
> Merci d'avance pour vos réflexions !
> 
> -- 
> Jérôme Nicolle
> 06 19 31 27 14
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

[Alarig Le Lay]

On mer. 15 févr. 22:11:04 2017, Jérôme Nicolle wrote:
> Plop,
> 
> Ce post pour une seule simple question : d'après vous, est ce que
> réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
> tunneling, est une fonction compatible avec l'obligation de neutralité
> du transporteur de paquets ?
> 
> Merci d'avance pour vos réflexions !

Salut,

Pour moi on commence à arriver à la limite, mais cependant ça peut être
nécessaire.
Par exemple, à une époque grifon (FAI associatif dont je fais partie)
était monohomé et le transitaire de l’époque a oublié de remonter une
session BGP. Ce qui n’est pas pratique quand on est monohomé.
Cependant, les IPs d’interco étaient encore pingables, donc a monté un
GRE vers ARN (un autre FAI asso) et on a réannoncé les IPs dans le GRE.
Et là… patatra, des trucs comme laposte.net et aws qui marchent plus, à
cause du MTU du GRE.
On a donc réécrit le MSS des paquets pour l’adapter au GRE le temps que
l’on soit multi-homé.

Cette bidouille n’est restée que quelques mois dans la conf des routeurs
et à été virée dès que possible ; mais ça a permis de réparer les
problèmes des pieds niclés qui droppent l’ICMP.

-- 
alarig


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

[Kavé Salamatian]

Ce cas ne va pas a l’encontre de la neutralité du net car 
1- impératif technique (pas d’autre moyens)
2- bénéfice client et non pas de l’opérateur seul.

A+

Kv
> Le 15 févr. 2017 à 22:45, Alarig Le Lay  a écrit :
> 
> On mer. 15 févr. 22:11:04 2017, Jérôme Nicolle wrote:
>> Plop,
>> 
>> Ce post pour une seule simple question : d'après vous, est ce que
>> réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
>> tunneling, est une fonction compatible avec l'obligation de neutralité
>> du transporteur de paquets ?
>> 
>> Merci d'avance pour vos réflexions !
> 
> Salut,
> 
> Pour moi on commence à arriver à la limite, mais cependant ça peut être
> nécessaire.
> Par exemple, à une époque grifon (FAI associatif dont je fais partie)
> était monohomé et le transitaire de l’époque a oublié de remonter une
> session BGP. Ce qui n’est pas pratique quand on est monohomé.
> Cependant, les IPs d’interco étaient encore pingables, donc a monté un
> GRE vers ARN (un autre FAI asso) et on a réannoncé les IPs dans le GRE.
> Et là… patatra, des trucs comme laposte.net et aws qui marchent plus, à
> cause du MTU du GRE.
> On a donc réécrit le MSS des paquets pour l’adapter au GRE le temps que
> l’on soit multi-homé.
> 
> Cette bidouille n’est restée que quelques mois dans la conf des routeurs
> et à été virée dès que possible ; mais ça a permis de réparer les
> problèmes des pieds niclés qui droppent l’ICMP.
> 
> -- 
> alarig


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

Re: [FRnOG] [TECH] TCP mangling et net-neutrality

[o . varenne]

A mon sens,  pas de soucis. 

Tant que l'intérêt de cette manipulation est purement  technique il y a pas de 
soucis. 


Par contre si l'objectif est d'assurer une rente,  réaliser des économies 
uniquement profitables à toi et qui impactent un ou plusieurs utilisateurs,  ou 
si cela permet de réaliser de l'écoute/capture de données à l'insue de 
l'utilisateur, oui c'est un problème. 


Sinon si une simple manipulation technique était un problème de neutralité,  
alors finalement la notion même de compatibilité entre protocoles serait à mal 
puisque cela nécessite en général de manipuler et transformer les données... 


Cordialement,


Olivier Varenne


Co-gérant – Commercial & Développement


IPConnect

1068 rue de la vielle poste

34000 MONTPELLIER


04 27 04 40 00

www.ipconnect.fr






On Wed, Feb 15, 2017 at 10:11 PM +0100, "Jérôme Nicolle"  
wrote:










Plop,

Ce post pour une seule simple question : d'après vous, est ce que
réécrire les entêtes TCP, ou même juste le MRU et MTU sur un service de
tunneling, est une fonction compatible avec l'obligation de neutralité
du transporteur de paquets ?

Merci d'avance pour vos réflexions !

-- 
Jérôme Nicolle
06 19 31 27 14


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






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

[FRnOG] [JOBS] PowerDNS recrute !

[Nico CARTRON]

Bonjour à tous,

PowerDNS, qui fait maintenant partie d'Open-Xchange, recrute un 
"Solutions Engineer".
Plus de détails ici: 
https://www.open-xchange.com/jobs/solution-architect-mf/


TL;DR: vous voulez travailler dans un environnement open-source, avec 
des projets bien sympa techniquement?

Viendez et rejoignez-nous !

Rémi et moi-même serons présents au prochain FrNOG, donc n'hésitez pas à 
venir nous voir pour discuter du poste ou de PowerDNS de manière plus 
large :)


Et non, je n'ai pas mis de salaire indicatif, car je ne suis pas en 
charge du recrutement :)



Cheers,

--
Nico CARTRON
PowerDNS/Open-Xchange



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

RE: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[sbu123fr]

100Mb nous sommes en 2017…… en IDF…

 

De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr] 
Envoyé : mercredi 15 février 2017 17:52
À : frnog@frnog.org; sbu123fr; Louis
Cc : Liste FRnoG
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo 
mais plutot 5 x 100Mo

 

Totalement cohérent alors. 

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr  a écrit :

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes 

 Message d'origine 
De : Louis  
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr  
Cc : Ducassou Laurent , Liste FRnoG 
 
Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo 

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis  a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr  a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison 

 Message d'origine 
De : Ducassou Laurent  
Date : 15/02/2017  16:36  (GMT+01:00) 
À : frnog@frnog.org 
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
  100Mo 

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS 
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est 
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de 
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le 
client final crois disposer de 500Mbit/s entre chaque site, mais en 
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à 
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
 Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
 d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

 J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

 "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
 500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
 une session TCP entre 2 liens"



 Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
 Oui mais non,

 Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
 liens de façon parfaitement aléatoire, souvent les équipements balancent le
 trafic de manière *déterministe* sur l'un des liens physiques, en se basant
 sur le couple adresse source-destination, cela peut-être Adresse IP source
 / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
 par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
 exceptions, et sûrement des solutions propriétaires.

 Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
 (exception faite des solutions propriétaires ou solutions non déterministes
 de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
 100Mbps sur un LAG 5x100Mbps pour un même flux.

 cordialement,

 2017-02-15 14:56 GMT+01:00 Louis :
 Après quelques recherche, j'arrive à la conclusion que la limitation du
 temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
 (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
 de l'OS.

 L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
 les (très) vieux OS, la valeur maxi de window size était 65535 octets
 parce
 que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
 1323 est largement utilisée. Elle introduit un paramètre window size
 scaling factor (8 bits) qui est un multiplcateur de la valeur de window
 size. Le window size est étendu 16Mo au lieu de 64Ko.

 Calculateur de bande passante sur une session TCP :
 https://www.switch.ch/network/tools/tcp_throughput/
 Pour la formule, c'est ici :
 http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
 ghput-for-long-distance-links/

 Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
 faudrait une taille window de ~1800 Ko.

 Il faut regarder les paramètres de l'OS pour voir si les paramètres
 permettent d'avoir une window de cette taille.

 Sur les windows récents, les paramètres sont décrits ici :
 http://www.speedguide.net/articles/windows-8-10-2012-server-
 tcpip-tweaks-5077
 - paragraphe Receive Window Auto-Tuning Level. Test sur un windows 7, le
 paramètre est normal.

 c:\>netsh interface tcp show global

 Paramètres TCP globaux

  _  


 État de mise à l'échelle côté réception : enabled
 État de déchargement Chimney : automatic
 État NetDMA: enabled
 Accès direct au cache: disabled
 *

[FRnOG] [ALERT] Problème sur NRA 05119RIS

[Frederic Hermann]

Depuis ce matin 6h30 , les lignes SDSL et ADSL sur ce NRA semblent down. 
Quelqu'un confirme / a des infos ? 


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

Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Ducassou Laurent]

Vois avec ton fournisseur pour te faire livrer un lien 1Gbit/s shape à 
500Mbit/s et non 5 lien 100Mbit/s agrégée...


Ca fait 3 ans que même Orange propose en province des liens 
200/500/1000Mbit alors en IDF...


Là c'est plus à toi de voir avec ton fournisseur que autre chose... 
(optionnellement, en passant de 5 liens à 1, tu risque d'avoir la 
facture qui baisse)



Le 15/02/2017 à 23:22, sbu12...@gmail.com a écrit :

100Mb nous sommes en 2017…… en IDF…

  


De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
Envoyé : mercredi 15 février 2017 17:52
À : frnog@frnog.org; sbu123fr; Louis
Cc : Liste FRnoG
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo 
mais plutot 5 x 100Mo

  


Totalement cohérent alors.

Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr  a écrit :

C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 
100 et des bananes

 Message d'origine 
De : Louis 
Date : 15/02/2017  17:22  (GMT+01:00)
À : sbu123fr 
Cc : Ducassou Laurent , Liste FRnoG 

Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 
100Mo

Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez 
fiable. Pas de lecture disque
Le 15 février 2017 à 17:20, Louis  a écrit :
280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. 
Avec un transfert multi-session, la tête de lecture/écriture d'un disque 
classique est obligé de faire en permanence des aller-retours.
Le 15 février 2017 à 17:07, sbu123fr  a écrit :
BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la 
chaîne de liaison

 Message d'origine 
De : Ducassou Laurent 
Date : 15/02/2017  16:36  (GMT+01:00)
À : frnog@frnog.org
Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
   100Mo

Plus simplement :

Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
500Mbit/s.

Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
que chaque site est relié que avec une fibre optique à 100Mbit/s.

Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
client final crois disposer de 500Mbit/s entre chaque site, mais en
réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
100Mbit/s sur D et que E est au repos.

Je crois avoir compris cela...


Le 15/02/2017 à 15:35, Louis a écrit :
  Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
  d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.

  J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).

  "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
  500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
  une session TCP entre 2 liens"



  Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
  Oui mais non,

  Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
  liens de façon parfaitement aléatoire, souvent les équipements balancent le
  trafic de manière *déterministe* sur l'un des liens physiques, en se basant
  sur le couple adresse source-destination, cela peut-être Adresse IP source
  / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
  par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
  exceptions, et sûrement des solutions propriétaires.

  Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
  (exception faite des solutions propriétaires ou solutions non déterministes
  de balancing sur LAG - ce que je n'ai pas encore observé -) avoir plus de
  100Mbps sur un LAG 5x100Mbps pour un même flux.

  cordialement,

  2017-02-15 14:56 GMT+01:00 Louis :
  Après quelques recherche, j'arrive à la conclusion que la limitation du
  temps de réponse est obsolète. Donc, oui tu peux atteindre les 500Mbps
  (comprendre 500 bits/s, soit 62.5 Mo/s max) mais ça dépend des paramètres
  de l'OS.

  L'article de 2005 ne précise pas les valeurs de window size utilisées. Sur
  les (très) vieux OS, la valeur maxi de window size était 65535 octets
  parce
  que le champ était limité à 16 bits dans l'en-tête TCP. Maintenant, la RFC
  1323 est largement utilisée. Elle introduit un paramètre window size
  scaling factor (8 bits) qui est un multiplcateur de la valeur de window
  size. Le window size est étendu 16Mo au lieu de 64Ko.

  Calculateur de bande passante sur une session TCP :
  https://www.switch.ch/network/tools/tcp_throughput/
  Pour la formule, c'est ici :
  http://bradhedlund.com/2008/12/19/how-to-calculate-tcp-throu
  ghput-for-long-distance-links/

  Pour atteindre les 500Mbps (comprendre 500 bits/s, soit 62.5 Mo/s max), il
  faudrait une taille window de ~1800 Ko.

  Il faut regarder les paramètres de l'OS pour voir si les paramètres
  permettent d'avoir une window de cette taille.

  Sur les windows récents, les paramètres sont décrits

RE: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

[Arthur Pellissier]

+1 : aujourd'hui il est moins cher de poser une FON 1gbps pour faire du 500Mbps... Sans compter la possibilité d'évolution derrière.


Si tu veux te faire une idée du tarif d'une FON sur ton site envoie moi un mail ;) 


De : frnog-requ...@frnog.org  de la part de Ducassou Laurent 
Envoyé : jeudi 16 février 2017 08:47:09
À : frnog@frnog.org
Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
 



Vois avec ton fournisseur pour te faire livrer un lien 1Gbit/s shape à

500Mbit/s et non 5 lien 100Mbit/s agrégée...

Ca fait 3 ans que même Orange propose en province des liens 
200/500/1000Mbit alors en IDF...

Là c'est plus à toi de voir avec ton fournisseur que autre chose... 
(optionnellement, en passant de 5 liens à 1, tu risque d'avoir la 
facture qui baisse)


Le 15/02/2017 à 23:22, sbu12...@gmail.com a écrit :
> 100Mb nous sommes en 2017…… en IDF…
>
>   
>
> De : Ducassou laurent [mailto:laurent.ducas...@spaceshell.fr]
> Envoyé : mercredi 15 février 2017 17:52
> À : frnog@frnog.org; sbu123fr; Louis
> Cc : Liste FRnoG
> Objet : Re: [SPAM] RE : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
>   
>
> Totalement cohérent alors.
>
> Le 15 février 2017 17:50:24 GMT+01:00, sbu123fr  a écrit :
>
> C ce qu on a fait en "multi session" (-p) nous arrivons à 480 environ en "mono" 100 et des bananes
>
>


 






 











Arthur Pellissier


Ingénieur Commercial -
Sales Engineer

5 Quai Marcel Dassault, 92150 Suresnes, France





  
 
 





 +33 1 85 60 10 35

 +33 6 88 02 14 17 
 apelliss...@waycom.net






 



























This message is confidential. It may also be privileged or
 otherwise protected by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax
 any message containing deadlines as incoming e-mail are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.

 


















 Message d'origine 
> De : Louis 
> Date : 15/02/2017  17:22  (GMT+01:00)
> À : sbu123fr 
> Cc : Ducassou Laurent , Liste FRnoG 
> Objet : Re: RE : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo
>
> Si c'est ça, on peut utiliser iperf pour mesurer des débits. C'est assez fiable. Pas de lecture disque
> Le 15 février 2017 à 17:20, Louis  a écrit :
> 280Mbps = 35Mo/s C'est peut-être les vitesses de disque qui limitent le débit. Avec un transfert multi-session, la tête de lecture/écriture d'un disque classique est obligé de faire en permanence des aller-retours.
> Le 15 février 2017 à 17:07, sbu123fr  a écrit :
> BonjourAvec du multi session on obtient 280MoDonc pas de souci de 100Mo sur la chaîne de liaison
>
>  Message d'origine 
> De : Ducassou Laurent 
> Date : 15/02/2017  16:36  (GMT+01:00)
> À : frnog@frnog.org
> Objet : Re: RE : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x
>    100Mo
>
> Plus simplement :
>
> Soit 5 sites distant, chaqu'un relié en fibre optique à un nuage MPLS
> 500Mbit/s.
>
> Pour que 2 sites ne puissent parler entre eux que à max 100Mbit/s c'est
> que chaque site est relié que avec une fibre optique à 100Mbit/s.
>
> Ca arrive souvent dans les nuages MPLS des DSP ce "problème de
> compréhension" avec des offres "5 sites - 500Mbit/s" par exemple. Le
> client final crois disposer de 500Mbit/s entre chaque site, mais en
> réalité le site A peux envoyer au B 100Mbit/s pendant que le C envoi à
> 100Mbit/s sur D et que E est au repos.
>
> Je crois avoir compris cela...
>
>
> Le 15/02/2017 à 15:35, Louis a écrit :
>   Sylvain n'a pas parlé d’agrégat 5x100Mbps. On est en 2017, on ne fait plus
>   d'aggrégat 5x100Mbps mais plutôt du 2x1Gbps avec du shaping.
>
>   J'ai plutôt compris 500Mbps sur quatre liens (comprendre quatre sites).
>
>   "Mais mon fournisseur de collecte m'explique que sur son service IP MPLS
>   500Mo sur 4 liens, je ne pourrais jamais dépasser 100Mo de trafic max sur
>   une session TCP entre 2 liens"
>
>
>
>   Le 15 février 2017 à 15:19, Benjamin Bachelart  a écrit :
>   Oui mais non,
>
>   Sur un LAG, le trafic ne se répartie pas - comme par magie - sur tous les
>   liens de façon parfaitement aléatoire, souvent les équipements balancent le
>   trafic de manière *déterministe* sur l'un des liens physiques, en se basant
>   sur le couple adresse source-destination, cela peut-être Adresse IP source
>   / Adresse IP destination, ou de même avec l'adresse MAC, parfois peut-être
>   par flux (Source IP+Port - Dest IP+Port), il existe sûrement des
>   exceptions, et sûrement des solutions propriétaires.
>
>   Donc avec toutes les tailles de fenêtre tcp, vous ne pourrez pas
>   (exception faite des solutions propriétaires ou solutions non déterministes
>   de balancing sur LAG - ce que je n'