Re: [EXTERNAL MAIL] [FRnOG] [TECH] Problème de court circuit ou disjonctage avec un Blade

[Axel HAUGUEL]

Yes,j’ai modifié les valeurs ce matin mais aucun changement… 
Cordialement / Best regards
-- 
Axel HAUGUEL
Vice-Président de Dyjix | a...@dyjix.eu 
Responsable des infrastructures systèmes & réseaux
Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu 



> Le 18 déc. 2020 à 23:18, Charley SEDEAU  a écrit :
> 
> Je ne sais pas si tu as déjà regardé, mais il y a des valeurs configurables 
> coté PDU d'après la doc 
> (https://www.senetic.fr/i/objects/mmo_39211716_1514462642_2147_24907.pdf 
> ) , 
> notamment une valeur d'overload où le PDU coupe le jus. Peut-être qu'il n'est 
> pas configuré à 16A ?
> 
> 
> 
> Je pense que ça vaudrait le coup d'essayer en sortant les blades du châssis : 
> Il y a un discover automatique des blades sur les châssis types C7000 / 
> M1000E qui se fait quelques minutes après le boot du châssis.. Ça peut 
> expliquer pourquoi la consommation augmente un peu après 4 min (mais ça ne 
> devrait pas non plus être gigantesque..) et peut-être expliquer ton soucis..
> 
> - Charley
> 
> 
> Le ven. 18 déc. 2020 à 23:06, Axel HAUGUEL  > a écrit :
> Hello,
> 
> Merci pour ta réponse. Le modèle du PDU est le suivant : 
> https://www.senetic.fr/product/163682 
> 
> Je pense en effet faire ça demain matin, tester sur une voie vide… Mais ça 
> expliquerait pas pourquoi quand tout redémarre, juste après la coupure, ça ne 
> disjoncte pas directement.. Car quand tout redémarre, on consomme beaucoup + 
> (Environ 12 - 13A)
> 
> Aucune lame n’est démarrée lorsque cela se produit… C’est vraiment étrange ! 
> Car le blade démarre et 4 minutes après, paf !
> 
> Merci
> 
> Cordialement / Best regards
> -- 
> Axel HAUGUEL
> Vice-Président de Dyjix | a...@dyjix.eu 
> Responsable des infrastructures systèmes & réseaux
> Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu 
> 
> 
> 
>> Le 18 déc. 2020 à 23:02, Charley SEDEAU > > a écrit :
>> 
>> Hello,
>> 
>> D'expérience ça ressemble vraiment à un souci de conso élec / capacité sur 
>> tes voies 
>> 
>> Quel ref de PDU utilises-tu ? Est-ce que tu es sûr qu'ils arrivent à tenir 
>> 10A (même s'ils sont prévu pour du 16A, on est pas a l'abris d'une surprise 
>> sur certains modèles "cheap"). Ou alors peut-être que ta mesure de 
>> consommation actuelle manque de précision ?
>> 
>> Ca expliquerai à la fois que ton 2nd PDU saute lorsque le 1er tombe (vu 
>> qu'il double en charge), et ca expliquerait pourquoi ton M1000E fait tomber 
>> un PDU après quelques minutes (sûrement lié au boot des blades qui sont à 
>> l'intérieur ?)
>> 
>> Dans les tests que tu peux faire histoire d'essayer de cerner le soucis :
>> - Tester sur une voie électrique 16A "vide", voir si le pb se reproduit (si 
>> tu en as une à disposition) 
>> ≈
>> - Essayer tester avec 2 alim sur le M1000E, et de les interchanger pour voir 
>> si le soucis est localisé sur l'une des alim en particulier (mais ces trucs 
>> sont normalement conçus pour être bien redondants et pour bien isoler les 
>> alim défectueuses) 
>> 
>> - Charley
>> 
>> 
>> Le ven. 18 déc. 2020 à 22:23, Axel HAUGUEL > > a écrit :
>> Hello la liste,
>> 
>> J'espère un peu la situation :
>> 
>> Dans un site où nous avons une baie, nous avons l'arrivée électrique
>> séparée par deux voies A et B, et chaque serveur rack est double alimenté
>> par chaque voie.
>> 
>> Nous avons également un bladecenter qui nous pose des soucis depuis ce
>> matin, il a 6 alimentations (dell m1000e) :
>> 
>> - Lorsqu'on le branche sur 2 PDU, les 2 PDU tombent et tous les serveurs
>> s'éteignent et redémarrent directement (+4 ampères par rapport à la conso
>> moyenne, donc j'élimine un manque de puissance électrique)
>> 
>> - J'ai essayé de le brancher qu'une alimentation sur 1 PDU, mais le PDU
>> tombe et fait tomber l'autre (alors qu'il n'est pas raccordé dessus)
>> également..
>> 
>> Je me demande si l'alimentation n'a pas un problème et crée un court
>> circuit qui se répercute dans l'autre PDU en passant par les racks.
>> 
>> Je deviens fou ! De plus, il ne disjoncte pas directement après le
>> redémarrage, mais au moins 5 minutes après...
>> 
>> Si vous avez des idées de ce que ça pourrait être, ou si vous avez déjà
>> rencontré des problèmes similaires, je suis preneur...
>> 
>> Pour information, sur les deux PDUs, je suis à 5.5 A. Donc si un PDU coupe,
>> l'autre a de quoi reprendre (capa 16A).
>> 
>> Le blade fonctionnait très bien cette nuit ...
>> 
>> Merci !
>> 
>> Cordialement / Best regards
>> -- 
>> *Axel HAUGUEL*
>> Vice-Président de Dyjix | *a...@dyjix.eu  
>> mailto:a...@dyjix.eu>>*
>> *Responsable des infrastructures systèmes & réseaux*
>> Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu 
>> 
>> ---
>> Liste de di

Re: [EXTERNAL MAIL] [FRnOG] [TECH] Problème de court circuit ou disjonctage avec un Blade

[Jeremy]

T'as plus qu'à entrer dans les joies du debug de blade.

Retire toutes les lames.
Retire toutes les alim et ventilo, et teste en le démarrant avec un seul 
module de chaque, et peut être 1 lame pour avoir un peu de charge.

Tu attends 10mn, et tu recommence.
Tu as de la chance, il n'y a que 6 modules de chaque (soit 1h de test).

Tu en a un qui a un défaut de masse qui passe par la terre, ça peut 
effectivement faire disjoncter un autre disjoncteur proche par retour 
d'harmonique.


Bonne chance,

Jérémy


Le 18/12/2020 à 23:06, Axel HAUGUEL a écrit :

Hello,

Merci pour ta réponse. Le modèle du PDU est le suivant : 
https://www.senetic.fr/product/163682 

Je pense en effet faire ça demain matin, tester sur une voie vide… Mais ça 
expliquerait pas pourquoi quand tout redémarre, juste après la coupure, ça ne 
disjoncte pas directement.. Car quand tout redémarre, on consomme beaucoup + 
(Environ 12 - 13A)

Aucune lame n’est démarrée lorsque cela se produit… C’est vraiment étrange ! 
Car le blade démarre et 4 minutes après, paf !

Merci

Cordialement / Best regards



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

Re: [EXTERNAL MAIL] [FRnOG] [TECH] Problème de court circuit ou disjonctage avec un Blade

[Axel HAUGUEL]

Hello,

Merci pour ta réponse. Le modèle du PDU est le suivant : 
https://www.senetic.fr/product/163682 

Je pense en effet faire ça demain matin, tester sur une voie vide… Mais ça 
expliquerait pas pourquoi quand tout redémarre, juste après la coupure, ça ne 
disjoncte pas directement.. Car quand tout redémarre, on consomme beaucoup + 
(Environ 12 - 13A)

Aucune lame n’est démarrée lorsque cela se produit… C’est vraiment étrange ! 
Car le blade démarre et 4 minutes après, paf !

Merci

Cordialement / Best regards
-- 
Axel HAUGUEL
Vice-Président de Dyjix | a...@dyjix.eu 
Responsable des infrastructures systèmes & réseaux
Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu 



> Le 18 déc. 2020 à 23:02, Charley SEDEAU  a écrit :
> 
> Hello,
> 
> D'expérience ça ressemble vraiment à un souci de conso élec / capacité sur 
> tes voies 
> 
> Quel ref de PDU utilises-tu ? Est-ce que tu es sûr qu'ils arrivent à tenir 
> 10A (même s'ils sont prévu pour du 16A, on est pas a l'abris d'une surprise 
> sur certains modèles "cheap"). Ou alors peut-être que ta mesure de 
> consommation actuelle manque de précision ?
> 
> Ca expliquerai à la fois que ton 2nd PDU saute lorsque le 1er tombe (vu qu'il 
> double en charge), et ca expliquerait pourquoi ton M1000E fait tomber un PDU 
> après quelques minutes (sûrement lié au boot des blades qui sont à 
> l'intérieur ?)
> 
> Dans les tests que tu peux faire histoire d'essayer de cerner le soucis :
> - Tester sur une voie électrique 16A "vide", voir si le pb se reproduit (si 
> tu en as une à disposition) 
> ≈
> - Essayer tester avec 2 alim sur le M1000E, et de les interchanger pour voir 
> si le soucis est localisé sur l'une des alim en particulier (mais ces trucs 
> sont normalement conçus pour être bien redondants et pour bien isoler les 
> alim défectueuses) 
> 
> - Charley
> 
> 
> Le ven. 18 déc. 2020 à 22:23, Axel HAUGUEL  > a écrit :
> Hello la liste,
> 
> J'espère un peu la situation :
> 
> Dans un site où nous avons une baie, nous avons l'arrivée électrique
> séparée par deux voies A et B, et chaque serveur rack est double alimenté
> par chaque voie.
> 
> Nous avons également un bladecenter qui nous pose des soucis depuis ce
> matin, il a 6 alimentations (dell m1000e) :
> 
> - Lorsqu'on le branche sur 2 PDU, les 2 PDU tombent et tous les serveurs
> s'éteignent et redémarrent directement (+4 ampères par rapport à la conso
> moyenne, donc j'élimine un manque de puissance électrique)
> 
> - J'ai essayé de le brancher qu'une alimentation sur 1 PDU, mais le PDU
> tombe et fait tomber l'autre (alors qu'il n'est pas raccordé dessus)
> également..
> 
> Je me demande si l'alimentation n'a pas un problème et crée un court
> circuit qui se répercute dans l'autre PDU en passant par les racks.
> 
> Je deviens fou ! De plus, il ne disjoncte pas directement après le
> redémarrage, mais au moins 5 minutes après...
> 
> Si vous avez des idées de ce que ça pourrait être, ou si vous avez déjà
> rencontré des problèmes similaires, je suis preneur...
> 
> Pour information, sur les deux PDUs, je suis à 5.5 A. Donc si un PDU coupe,
> l'autre a de quoi reprendre (capa 16A).
> 
> Le blade fonctionnait très bien cette nuit ...
> 
> Merci !
> 
> Cordialement / Best regards
> -- 
> *Axel HAUGUEL*
> Vice-Président de Dyjix | *a...@dyjix.eu  
> mailto:a...@dyjix.eu>>*
> *Responsable des infrastructures systèmes & réseaux*
> Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/ 


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

Re: [FRnOG] [TECH] Problème de court circuit ou disjonctage avec un Blade

[Charley SEDEAU]

Hello,

D'expérience ça ressemble vraiment à un souci de conso élec / capacité sur
tes voies

Quel ref de PDU utilises-tu ? Est-ce que tu es sûr qu'ils arrivent à tenir
10A (même s'ils sont prévu pour du 16A, on est pas a l'abris d'une surprise
sur certains modèles "cheap"). Ou alors peut-être que ta mesure de
consommation actuelle manque de précision ?

Ca expliquerai à la fois que ton 2nd PDU saute lorsque le 1er tombe (vu
qu'il double en charge), et ca expliquerait pourquoi ton M1000E fait tomber
un PDU après quelques minutes (sûrement lié au boot des blades qui sont à
l'intérieur ?)

Dans les tests que tu peux faire histoire d'essayer de cerner le soucis :
- Tester sur une voie électrique 16A "vide", voir si le pb se reproduit (si
tu en as une à disposition)
- Tester avec le châssis M1000E vide (pour éviter le pic de conso après
quelques minutes si les blades boot)
- Essayer tester avec 2 alim sur le M1000E, et de les interchanger pour
voir si le soucis est localisé sur l'une des alim en particulier (mais ces
trucs sont normalement conçus pour être bien redondants et pour bien isoler
les alim défectueuses)

- Charley


Le ven. 18 déc. 2020 à 22:23, Axel HAUGUEL  a écrit :

> Hello la liste,
>
> J'espère un peu la situation :
>
> Dans un site où nous avons une baie, nous avons l'arrivée électrique
> séparée par deux voies A et B, et chaque serveur rack est double alimenté
> par chaque voie.
>
> Nous avons également un bladecenter qui nous pose des soucis depuis ce
> matin, il a 6 alimentations (dell m1000e) :
>
> - Lorsqu'on le branche sur 2 PDU, les 2 PDU tombent et tous les serveurs
> s'éteignent et redémarrent directement (+4 ampères par rapport à la conso
> moyenne, donc j'élimine un manque de puissance électrique)
>
> - J'ai essayé de le brancher qu'une alimentation sur 1 PDU, mais le PDU
> tombe et fait tomber l'autre (alors qu'il n'est pas raccordé dessus)
> également..
>
> Je me demande si l'alimentation n'a pas un problème et crée un court
> circuit qui se répercute dans l'autre PDU en passant par les racks.
>
> Je deviens fou ! De plus, il ne disjoncte pas directement après le
> redémarrage, mais au moins 5 minutes après...
>
> Si vous avez des idées de ce que ça pourrait être, ou si vous avez déjà
> rencontré des problèmes similaires, je suis preneur...
>
> Pour information, sur les deux PDUs, je suis à 5.5 A. Donc si un PDU coupe,
> l'autre a de quoi reprendre (capa 16A).
>
> Le blade fonctionnait très bien cette nuit ...
>
> Merci !
>
> Cordialement / Best regards
> --
> *Axel HAUGUEL*
> Vice-Président de Dyjix | *a...@dyjix.eu *
> *Responsable des infrastructures systèmes & réseaux*
> Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Problème de court circuit ou disjonctage avec un Blade

[Axel HAUGUEL]

Hello la liste,

J'espère un peu la situation :

Dans un site où nous avons une baie, nous avons l'arrivée électrique
séparée par deux voies A et B, et chaque serveur rack est double alimenté
par chaque voie.

Nous avons également un bladecenter qui nous pose des soucis depuis ce
matin, il a 6 alimentations (dell m1000e) :

- Lorsqu'on le branche sur 2 PDU, les 2 PDU tombent et tous les serveurs
s'éteignent et redémarrent directement (+4 ampères par rapport à la conso
moyenne, donc j'élimine un manque de puissance électrique)

- J'ai essayé de le brancher qu'une alimentation sur 1 PDU, mais le PDU
tombe et fait tomber l'autre (alors qu'il n'est pas raccordé dessus)
également..

Je me demande si l'alimentation n'a pas un problème et crée un court
circuit qui se répercute dans l'autre PDU en passant par les racks.

Je deviens fou ! De plus, il ne disjoncte pas directement après le
redémarrage, mais au moins 5 minutes après...

Si vous avez des idées de ce que ça pourrait être, ou si vous avez déjà
rencontré des problèmes similaires, je suis preneur...

Pour information, sur les deux PDUs, je suis à 5.5 A. Donc si un PDU coupe,
l'autre a de quoi reprendre (capa 16A).

Le blade fonctionnait très bien cette nuit ...

Merci !

Cordialement / Best regards
-- 
*Axel HAUGUEL*
Vice-Président de Dyjix | *a...@dyjix.eu *
*Responsable des infrastructures systèmes & réseaux*
Téléphone : (+33) 07 61 59 67 11 | www.dyjix.eu

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

Re: [FRnOG] [ALERT] Souci Zayo ?

[Gaetan Allart via frnog]

Bonsoir,

Merci à Johann pour sa disponibilité même un jour de congé...

Suite à l’incident de Zayo à Lille qui nous a pas mal perturbé (car on
annonce des préfixes plus petits par chez eux pour l’anti-ddos),
qu’utilisez-vous comme solution/outil/boîtier/approche pour ne pas être
impacté (ou pas longtemps) par un opérateur qui annonce toujours vos routes
mais qui est totalement hs ? (A part le shut manuel de la session BGP bien
sur).

Merci pour vos retours,
Bon week-end,

Gaétan Allart

Le ven. 18 déc. 2020 à 19:54, Victor TALVAZ  a
écrit :

> Merci, c'est stable depuis 15:26.
>
> [image: image.png]
>
>
> *Victor TALVAZ*
>
>
> On Fri, Dec 18, 2020 at 4:24 PM Johann  wrote:
>
>> Hello,
>>
>> Normalement ça devrait être stable depuis que le port est revenu.
>> N'hésite pas à me ping si ce n'est pas le cas.
>>
>> Johann
>>
>> Le ven. 18 déc. 2020 à 16:02, Victor TALVAZ  a
>> écrit :
>>
>>> Hello,
>>>
>>> Je confirme avoir perdu Zayo sur Lille à 15:13. C'est remonté à 15:26.
>>>
>>> Cdlt
>>>
>>> *Victor TALVAZ*
>>>
>>>
>>> On Fri, Dec 18, 2020 at 3:53 PM Johann  wrote:
>>>
  Hello,

 Il y a un équipement qui ne va pas bien et qui entraîne en partie son
 voisin. L'équipe est dessus.
 Il est probable qu'on coupe les sessions BGP dans les minutes qui
 viennent
 pour stopper les perturbations le temps que le souci soit fixé.
 Si c'est du L2, ça devrait être stable maintenant.

 Johann

 Le ven. 18 déc. 2020 à 15:49, alexandre derumier 
 a
 écrit :

 > Salut Johann,
 >
 > oui à Civ à lille
 >
 > Mail àfr-...@zayo.com et préciser :
 >
 >   * Client – Customer : M6 WEB
 >   * Service Order : 1055509
 >   * Circuit ID : DDOS/243791//ZYO
 >   * AS34993
 >
 > 
 >
 >
 >
 >   
 >
 > 
 >
 > On 18/12/2020 15:42, Johann wrote:
 > > Hello,
 > >
 > > Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par
 > curiosité?
 > > Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un
 souci
 > sur
 > > ce POP.
 > >
 > > Johann
 > >
 > > Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a
 > écrit :
 > >
 > >> Hello,
 > >>
 > >> RAS par chez nous pour le moment (avec l'anti ddos également).
 > >>
 > >> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
 > >>
 > >> - Charley
 > >>
 > >>
 > >> Le ven. 18 déc. 2020 à 15:36, alexandre derumier <
 aderum...@odiso.com>
 > a
 > >> écrit :
 > >>
 > >>> Salut,
 > >>>
 > >>> nous aussi je pense, ca semble collé au niveau timing.
 > >>>
 > >>> (on utilise zayo en entrée avec leur solution antiddos)
 > >>>
 > >>> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
 >  Bonjour,
 > 
 >  On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un
 d'autre
 >  voit la même chose ?
 > 
 >  Merci,
 > 
 >  -- Gaëtan Allart
 > >>>
 > >>>
 > >>> ---
 > >>> 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/
 >

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

>>> --



Gaëtan Allart

CEO/Founder I 03 66 72 15 72 I 06 09 21 95 12

gae...@nexylan.com I www.nexylan.com

274 ter avenue de la Marne I Marcq-en-Baroeul

Re: [FRnOG] [ALERT] Souci Zayo ?

[Victor TALVAZ]

Merci, c'est stable depuis 15:26.

[image: image.png]


*Victor TALVAZ*


On Fri, Dec 18, 2020 at 4:24 PM Johann  wrote:

> Hello,
>
> Normalement ça devrait être stable depuis que le port est revenu.
> N'hésite pas à me ping si ce n'est pas le cas.
>
> Johann
>
> Le ven. 18 déc. 2020 à 16:02, Victor TALVAZ  a
> écrit :
>
>> Hello,
>>
>> Je confirme avoir perdu Zayo sur Lille à 15:13. C'est remonté à 15:26.
>>
>> Cdlt
>>
>> *Victor TALVAZ*
>>
>>
>> On Fri, Dec 18, 2020 at 3:53 PM Johann  wrote:
>>
>>>  Hello,
>>>
>>> Il y a un équipement qui ne va pas bien et qui entraîne en partie son
>>> voisin. L'équipe est dessus.
>>> Il est probable qu'on coupe les sessions BGP dans les minutes qui
>>> viennent
>>> pour stopper les perturbations le temps que le souci soit fixé.
>>> Si c'est du L2, ça devrait être stable maintenant.
>>>
>>> Johann
>>>
>>> Le ven. 18 déc. 2020 à 15:49, alexandre derumier  a
>>> écrit :
>>>
>>> > Salut Johann,
>>> >
>>> > oui à Civ à lille
>>> >
>>> > Mail àfr-...@zayo.com et préciser :
>>> >
>>> >   * Client – Customer : M6 WEB
>>> >   * Service Order : 1055509
>>> >   * Circuit ID : DDOS/243791//ZYO
>>> >   * AS34993
>>> >
>>> > 
>>> >
>>> >
>>> >
>>> >   
>>> >
>>> > 
>>> >
>>> > On 18/12/2020 15:42, Johann wrote:
>>> > > Hello,
>>> > >
>>> > > Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par
>>> > curiosité?
>>> > > Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un
>>> souci
>>> > sur
>>> > > ce POP.
>>> > >
>>> > > Johann
>>> > >
>>> > > Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a
>>> > écrit :
>>> > >
>>> > >> Hello,
>>> > >>
>>> > >> RAS par chez nous pour le moment (avec l'anti ddos également).
>>> > >>
>>> > >> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
>>> > >>
>>> > >> - Charley
>>> > >>
>>> > >>
>>> > >> Le ven. 18 déc. 2020 à 15:36, alexandre derumier <
>>> aderum...@odiso.com>
>>> > a
>>> > >> écrit :
>>> > >>
>>> > >>> Salut,
>>> > >>>
>>> > >>> nous aussi je pense, ca semble collé au niveau timing.
>>> > >>>
>>> > >>> (on utilise zayo en entrée avec leur solution antiddos)
>>> > >>>
>>> > >>> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
>>> >  Bonjour,
>>> > 
>>> >  On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
>>> >  voit la même chose ?
>>> > 
>>> >  Merci,
>>> > 
>>> >  -- Gaëtan Allart
>>> > >>>
>>> > >>>
>>> > >>> ---
>>> > >>> 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/
>>> >
>>>
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>>
>>

Re: [FRnOG] [MISC] Petit update - nomination présidence ARCEP

[Daniel via frnog]

C'est sa journée

https://www.zdnet.fr/actualites/bilan-soriano-cartographie-d-un-mandat-au-service-de-l-investissement-des-operateurs-39915035.htm

Le 18/12/2020 à 17:08, Stéphane Rivière a écrit :

Ca confirme ce que tu écris sur ce corporatisme.

Ton timing est excellent (dredi).
J'aime aussi le coté boomerang de l'article.

Vu son cursus de "petit parfait scolaire", orienté télécom...
L'IGN (noble et très utile institut) serait-il une punition ?


Dixit sa page Wikipédia et les références tout en bas :

Taulier à l'ARCEP, c'est le gros lot : 16000 €/mois (bruts).

« Ce fils d'une magistrate et d'un psychanalyste d'origine péruvienne
est décrit comme un ambitieux et un fin politique: "c'est un adepte des
coups de billards à trois bandes. Il est difficile de savoir ce qu'il
pense vraiment", dit un opérateur. »


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [MISC] Petit update - nomination présidence ARCEP

[Stéphane Rivière]

> Ca confirme ce que tu écris sur ce corporatisme.

Ton timing est excellent (dredi).
J'aime aussi le coté boomerang de l'article.

Vu son cursus de "petit parfait scolaire", orienté télécom...
L'IGN (noble et très utile institut) serait-il une punition ?


Dixit sa page Wikipédia et les références tout en bas :

Taulier à l'ARCEP, c'est le gros lot : 16000 €/mois (bruts).

« Ce fils d'une magistrate et d'un psychanalyste d'origine péruvienne
est décrit comme un ambitieux et un fin politique: "c'est un adepte des
coups de billards à trois bandes. Il est difficile de savoir ce qu'il
pense vraiment", dit un opérateur. »

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [ALERT] Souci Zayo ?

[Johann]

Hello,

Normalement ça devrait être stable depuis que le port est revenu.
N'hésite pas à me ping si ce n'est pas le cas.

Johann

Le ven. 18 déc. 2020 à 16:02, Victor TALVAZ  a
écrit :

> Hello,
>
> Je confirme avoir perdu Zayo sur Lille à 15:13. C'est remonté à 15:26.
>
> Cdlt
>
> *Victor TALVAZ*
>
>
> On Fri, Dec 18, 2020 at 3:53 PM Johann  wrote:
>
>>  Hello,
>>
>> Il y a un équipement qui ne va pas bien et qui entraîne en partie son
>> voisin. L'équipe est dessus.
>> Il est probable qu'on coupe les sessions BGP dans les minutes qui viennent
>> pour stopper les perturbations le temps que le souci soit fixé.
>> Si c'est du L2, ça devrait être stable maintenant.
>>
>> Johann
>>
>> Le ven. 18 déc. 2020 à 15:49, alexandre derumier  a
>> écrit :
>>
>> > Salut Johann,
>> >
>> > oui à Civ à lille
>> >
>> > Mail àfr-...@zayo.com et préciser :
>> >
>> >   * Client – Customer : M6 WEB
>> >   * Service Order : 1055509
>> >   * Circuit ID : DDOS/243791//ZYO
>> >   * AS34993
>> >
>> > 
>> >
>> >
>> >
>> >   
>> >
>> > 
>> >
>> > On 18/12/2020 15:42, Johann wrote:
>> > > Hello,
>> > >
>> > > Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par
>> > curiosité?
>> > > Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci
>> > sur
>> > > ce POP.
>> > >
>> > > Johann
>> > >
>> > > Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a
>> > écrit :
>> > >
>> > >> Hello,
>> > >>
>> > >> RAS par chez nous pour le moment (avec l'anti ddos également).
>> > >>
>> > >> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
>> > >>
>> > >> - Charley
>> > >>
>> > >>
>> > >> Le ven. 18 déc. 2020 à 15:36, alexandre derumier <
>> aderum...@odiso.com>
>> > a
>> > >> écrit :
>> > >>
>> > >>> Salut,
>> > >>>
>> > >>> nous aussi je pense, ca semble collé au niveau timing.
>> > >>>
>> > >>> (on utilise zayo en entrée avec leur solution antiddos)
>> > >>>
>> > >>> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
>> >  Bonjour,
>> > 
>> >  On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
>> >  voit la même chose ?
>> > 
>> >  Merci,
>> > 
>> >  -- Gaëtan Allart
>> > >>>
>> > >>>
>> > >>> ---
>> > >>> 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/
>> >
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

RE: [FRnOG] [TECH] lien de transit SFR

[BELLOTTO Louis]

un petit outil pourfaire les tests facilement :
http://www.elifulkerson.com/projects/mturoute.php


--
Louis


-Message d'origine-
De : David Ponzone  
Envoyé : vendredi 18 décembre 2020 14:56
À : Nicolas Parpandet 
Cc : BELLOTTO Louis ; frnog-tech 

Objet : Re: [FRnOG] [TECH] lien de transit SFR

Attention y a des ping qui attendent en argument la taille du paquet headers 
inclus, et d’autre la taille du payload.
Généralement ça affiche size_payload(size_withheaders) avant de commencer le 
ping.

Ceci dit, pour être sûr sûr que tout est ok, ajoute le bit DF.
Si ça passe à 1472(1500) avec DF, et que ça passe plus avec 1473(1501), tout va 
bien.
Sinon problème.

> Le 18 déc. 2020 à 14:41, Nicolas Parpandet  a écrit :
> 
> 
> Bonjour,
> 
> Ok bonne idée pour le mtu,
> j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 
> ICMP = 1500)
> 
> 
> Merci
> 
> Nicolas
> 
> - Mail original -
>> De: "BELLOTTO Louis" 
>> À: "frnog-tech" 
>> Envoyé: Vendredi 18 Décembre 2020 14:09:50
>> Objet: RE: [FRnOG] [TECH] lien de transit SFR
> 
>> Bonjour,
>> 
>> On a eu aussi un truc du même genre.
>> Le souci venait du réglage du MTU sur un des routeurs opérateur...
>> 
>> Point peut être à vérifier
>> 
>> 
>> --
>> Louis
>> 
>> 
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de 
>> Thierry Chich Envoyé : vendredi 18 décembre 2020 13:54 À : 'Olivier 
>> Tirat BYON' ; 'Nicolas Parpandet'
>> ; 'frnog-tech'  Objet : RE: 
>> [FRnOG] [TECH] lien de transit SFR
>> 
>> Bonjour
>> 
>> C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il 
>> peut aussi y avoir des soucis liés à la latence sur le lien qui peut 
>> diminuer fortement le débit atteignable en tcp.
>> J'ai déjà eu aussi des effets particulièrement forts de l'interaction 
>> entre politique de firewalling et offloading des cartes réseaux. Le 
>> débit passait de 70Mo/s à 250 Mo/s en désactivant l'offloading ( 
>> ethtool -K ens192 tso off) sur certaines version de redhat.
>> 
>> Tout ça pour dire que ce genre de constat dépend parfois de 
>> paramètres très complexes à identifier
>> 
>> Thierry CHICH
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de 
>> Olivier Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : 
>> Nicolas Parpandet ; frnog-tech  
>> Objet : Re: [FRnOG] [TECH] lien de transit SFR
>> 
>> Bonjour
>> 
>> Bon différence majeur entre udp et tcp... l'aquittement des paquets
>> (TCP ACK).
>> 
>> On peut tester un upload indépendament du download ent UDP mais pas 
>> du tout en TCP.
>> 
>> Il faut faire gaffe au debit en download, s'assurer qu'il y a la 
>> place dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre 
>> pour eviter les TCP RETRANSMIT
>> 
>> Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau 
>> peut atteindre ces performances indépendamment. Donc le problème en 
>> TCP ne doit pas venir du lien. Après tester des performances réelles 
>> d'un transit c'est pas facile car ca dépend aussi de l'autre 
>> extrémité;)
>> 
>> Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
>>> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
>>> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
>>> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
>>> que cela soit lié au hasard me semble faible...)
>>> 
>>> De plus, avec une dizaine de sessions tcp en // , le débit global 
>>> plafonne à 350Mbits...
>>> 
>>> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
>>> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le 
>>> problème, et cela n'avance pas !
>>> 
>>> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
>>> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
>>> de notre côté, il me semble que c'est bien en face le soucis ..., il 
>>> peut toujours subsister un doute, mais si quelqu'un à une expérience sur le 
>>> sujet !
>>> 
>>> Merci, A+
>>> 
>>> Nicolas
>>> 
>>> 
>>> 
>>> ---
>>> 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/
>> 
>> -
>> 
>> Ce message et toutes les pièces jointes sont confidentiels. Il est 
>> établi à l'attention exclusive de son ou ses destinataire(s). Toute 
>> utilisation de ce message non conforme à sa destination, toute 
>> diffusion, copie ou toute publication, totale ou partielle, est 
>> interdite, sauf autorisation expresse préalable. Son contenu ne 
>> saurait constituer en aucun cas un engagement contractuel, une offre 
>> de souscrire à 

Re: [FRnOG] [ALERT] Souci Zayo ?

[Victor TALVAZ]

Hello,

Je confirme avoir perdu Zayo sur Lille à 15:13. C'est remonté à 15:26.

Cdlt

*Victor TALVAZ*


On Fri, Dec 18, 2020 at 3:53 PM Johann  wrote:

>  Hello,
>
> Il y a un équipement qui ne va pas bien et qui entraîne en partie son
> voisin. L'équipe est dessus.
> Il est probable qu'on coupe les sessions BGP dans les minutes qui viennent
> pour stopper les perturbations le temps que le souci soit fixé.
> Si c'est du L2, ça devrait être stable maintenant.
>
> Johann
>
> Le ven. 18 déc. 2020 à 15:49, alexandre derumier  a
> écrit :
>
> > Salut Johann,
> >
> > oui à Civ à lille
> >
> > Mail àfr-...@zayo.com et préciser :
> >
> >   * Client – Customer : M6 WEB
> >   * Service Order : 1055509
> >   * Circuit ID : DDOS/243791//ZYO
> >   * AS34993
> >
> > 
> >
> >
> >
> >   
> >
> > 
> >
> > On 18/12/2020 15:42, Johann wrote:
> > > Hello,
> > >
> > > Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par
> > curiosité?
> > > Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci
> > sur
> > > ce POP.
> > >
> > > Johann
> > >
> > > Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a
> > écrit :
> > >
> > >> Hello,
> > >>
> > >> RAS par chez nous pour le moment (avec l'anti ddos également).
> > >>
> > >> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
> > >>
> > >> - Charley
> > >>
> > >>
> > >> Le ven. 18 déc. 2020 à 15:36, alexandre derumier  >
> > a
> > >> écrit :
> > >>
> > >>> Salut,
> > >>>
> > >>> nous aussi je pense, ca semble collé au niveau timing.
> > >>>
> > >>> (on utilise zayo en entrée avec leur solution antiddos)
> > >>>
> > >>> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
> >  Bonjour,
> > 
> >  On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
> >  voit la même chose ?
> > 
> >  Merci,
> > 
> >  -- Gaëtan Allart
> > >>>
> > >>>
> > >>> ---
> > >>> 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/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] Souci Zayo ?

[Johann]

 Hello,

Il y a un équipement qui ne va pas bien et qui entraîne en partie son
voisin. L'équipe est dessus.
Il est probable qu'on coupe les sessions BGP dans les minutes qui viennent
pour stopper les perturbations le temps que le souci soit fixé.
Si c'est du L2, ça devrait être stable maintenant.

Johann

Le ven. 18 déc. 2020 à 15:49, alexandre derumier  a
écrit :

> Salut Johann,
>
> oui à Civ à lille
>
> Mail àfr-...@zayo.com et préciser :
>
>   * Client – Customer : M6 WEB
>   * Service Order : 1055509
>   * Circuit ID : DDOS/243791//ZYO
>   * AS34993
>
> 
>
>
>
>   
>
> 
>
> On 18/12/2020 15:42, Johann wrote:
> > Hello,
> >
> > Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par
> curiosité?
> > Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci
> sur
> > ce POP.
> >
> > Johann
> >
> > Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a
> écrit :
> >
> >> Hello,
> >>
> >> RAS par chez nous pour le moment (avec l'anti ddos également).
> >>
> >> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
> >>
> >> - Charley
> >>
> >>
> >> Le ven. 18 déc. 2020 à 15:36, alexandre derumier 
> a
> >> écrit :
> >>
> >>> Salut,
> >>>
> >>> nous aussi je pense, ca semble collé au niveau timing.
> >>>
> >>> (on utilise zayo en entrée avec leur solution antiddos)
> >>>
> >>> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
>  Bonjour,
> 
>  On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
>  voit la même chose ?
> 
>  Merci,
> 
>  -- Gaëtan Allart
> >>>
> >>>
> >>> ---
> >>> 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/
>

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

Re: [FRnOG] [ALERT] Souci Zayo ?

[alexandre derumier]

Salut Johann,

oui à Civ à lille

Mail àfr-...@zayo.com et préciser :

 * Client – Customer : M6 WEB
 * Service Order : 1055509
 * Circuit ID : DDOS/243791//ZYO
 * AS34993





 



On 18/12/2020 15:42, Johann wrote:

Hello,

Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par curiosité?
Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci sur
ce POP.

Johann

Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a écrit :


Hello,

RAS par chez nous pour le moment (avec l'anti ddos également).

Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?

- Charley


Le ven. 18 déc. 2020 à 15:36, alexandre derumier  a
écrit :


Salut,

nous aussi je pense, ca semble collé au niveau timing.

(on utilise zayo en entrée avec leur solution antiddos)

On 18/12/2020 15:25, Gaetan Allart via frnog wrote:

Bonjour,

On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
voit la même chose ?

Merci,

-- Gaëtan Allart



---
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] [ALERT] Souci Zayo ?

[Gaetan Allart via frnog]

Oui Lille

Le ven. 18 déc. 2020 à 15:43, Johann  a écrit :

> Hello,
>
> Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par curiosité?
> Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci sur
> ce POP.
>
> Johann
>
> Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a écrit
> :
>
> > Hello,
> >
> > RAS par chez nous pour le moment (avec l'anti ddos également).
> >
> > Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
> >
> > - Charley
> >
> >
> > Le ven. 18 déc. 2020 à 15:36, alexandre derumier  a
> > écrit :
> >
> > > Salut,
> > >
> > > nous aussi je pense, ca semble collé au niveau timing.
> > >
> > > (on utilise zayo en entrée avec leur solution antiddos)
> > >
> > > On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
> > > > Bonjour,
> > > >
> > > > On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
> > > > voit la même chose ?
> > > >
> > > > Merci,
> > > >
> > > > -- Gaëtan Allart
> > >
> > >
> > >
> > > ---
> > > 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/
>
-- 



Gaëtan Allart

CEO/Founder I 03 66 72 15 72 I 06 09 21 95 12

gae...@nexylan.com I www.nexylan.com

274 ter avenue de la Marne I Marcq-en-Baroeul

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

Re: [FRnOG] [ALERT] Souci Zayo ?

[Johann]

Hello,

Est-ce que Gaëtan et Alexandre vous ne seriez pas sur Lille par curiosité?
Je suis off today, mais du coin de l'œil j'ai pu voir que y'a un souci sur
ce POP.

Johann

Le ven. 18 déc. 2020 à 15:40, Charley SEDEAU  a écrit :

> Hello,
>
> RAS par chez nous pour le moment (avec l'anti ddos également).
>
> Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?
>
> - Charley
>
>
> Le ven. 18 déc. 2020 à 15:36, alexandre derumier  a
> écrit :
>
> > Salut,
> >
> > nous aussi je pense, ca semble collé au niveau timing.
> >
> > (on utilise zayo en entrée avec leur solution antiddos)
> >
> > On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
> > > Bonjour,
> > >
> > > On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
> > > voit la même chose ?
> > >
> > > Merci,
> > >
> > > -- Gaëtan Allart
> >
> >
> >
> > ---
> > 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] [ALERT] Souci Zayo ?

[Charley SEDEAU]

Hello,

RAS par chez nous pour le moment (avec l'anti ddos également).

Vous êtes sur quel ASN ? Zayo FR ou Zayo Bandwidth ?

- Charley


Le ven. 18 déc. 2020 à 15:36, alexandre derumier  a
écrit :

> Salut,
>
> nous aussi je pense, ca semble collé au niveau timing.
>
> (on utilise zayo en entrée avec leur solution antiddos)
>
> On 18/12/2020 15:25, Gaetan Allart via frnog wrote:
> > Bonjour,
> >
> > On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
> > voit la même chose ?
> >
> > Merci,
> >
> > -- Gaëtan Allart
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] Souci Zayo ?

[alexandre derumier]

Salut,

nous aussi je pense, ca semble collé au niveau timing.

(on utilise zayo en entrée avec leur solution antiddos)

On 18/12/2020 15:25, Gaetan Allart via frnog wrote:

Bonjour,

On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
voit la même chose ?

Merci,

-- Gaëtan Allart




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

Re: [FRnOG] [ALERT] Souci Zayo ?

[David Ponzone]

Euhhh t’as pas un petit exemple ?

> Le 18 déc. 2020 à 15:25, Gaetan Allart via frnog  a écrit :
> 
> Bonjour,
> 
> On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
> voit la même chose ?
> 
> Merci,
> 
> -- 
> 
> Gaëtan Allart
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [ALERT] Souci Zayo ?

[Gaetan Allart via frnog]

Bonjour,

On a de gros soucis à travers Zayo depuis 15H13. Quelqu'un d'autre
voit la même chose ?

Merci,

-- 

Gaëtan Allart


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

Re: [FRnOG] [TECH] lien de transit SFR

[David Ponzone]

Attention y a des ping qui attendent en argument la taille du paquet headers 
inclus, et d’autre la taille du payload.
Généralement ça affiche size_payload(size_withheaders) avant de commencer le 
ping.

Ceci dit, pour être sûr sûr que tout est ok, ajoute le bit DF.
Si ça passe à 1472(1500) avec DF, et que ça passe plus avec 1473(1501), tout va 
bien.
Sinon problème.

> Le 18 déc. 2020 à 14:41, Nicolas Parpandet  a écrit :
> 
> 
> Bonjour,
> 
> Ok bonne idée pour le mtu, 
> j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 ICMP = 
> 1500)
> 
> 
> Merci
> 
> Nicolas
> 
> - Mail original -
>> De: "BELLOTTO Louis" 
>> À: "frnog-tech" 
>> Envoyé: Vendredi 18 Décembre 2020 14:09:50
>> Objet: RE: [FRnOG] [TECH] lien de transit SFR
> 
>> Bonjour,
>> 
>> On a eu aussi un truc du même genre.
>> Le souci venait du réglage du MTU sur un des routeurs opérateur...
>> 
>> Point peut être à vérifier
>> 
>> 
>> --
>> Louis
>> 
>> 
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de Thierry
>> Chich
>> Envoyé : vendredi 18 décembre 2020 13:54
>> À : 'Olivier Tirat BYON' ; 'Nicolas 
>> Parpandet'
>> ; 'frnog-tech' 
>> Objet : RE: [FRnOG] [TECH] lien de transit SFR
>> 
>> Bonjour
>> 
>> C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi 
>> y
>> avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le
>> débit atteignable en tcp.
>> J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre
>> politique de firewalling et offloading des cartes réseaux. Le débit passait 
>> de
>> 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) 
>> sur
>> certaines version de redhat.
>> 
>> Tout ça pour dire que ce genre de constat dépend parfois de paramètres très
>> complexes à identifier
>> 
>> Thierry CHICH
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de Olivier
>> Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet
>> ; frnog-tech  Objet : Re: [FRnOG] [TECH]
>> lien de transit SFR
>> 
>> Bonjour
>> 
>> Bon différence majeur entre udp et tcp... l'aquittement des paquets
>> (TCP ACK).
>> 
>> On peut tester un upload indépendament du download ent UDP mais pas du tout 
>> en
>> TCP.
>> 
>> Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans 
>> le
>> tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP
>> RETRANSMIT
>> 
>> Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut
>> atteindre ces performances indépendamment. Donc le problème en TCP ne doit 
>> pas
>> venir du lien. Après tester des performances réelles d'un transit c'est pas
>> facile car ca dépend aussi de l'autre extrémité;)
>> 
>> Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>>> 
>>> Bonjour,
>>> 
>>> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte
>>> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si
>>> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de
>>> 100Mbits/s revient tellement souvent dans nos tests, la probabilité
>>> que cela soit lié au hasard me semble faible...)
>>> 
>>> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à
>>> 350Mbits...
>>> 
>>> Cela fait plusieurs semaines que nous échangeons dans tous les sens
>>> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le 
>>> problème, et
>>> cela n'avance pas !
>>> 
>>> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de
>>> limite avec cet opérateur ?, nous avons fait énormément de contrôles
>>> de notre côté, il me semble que c'est bien en face le soucis ..., il peut
>>> toujours subsister un doute, mais si quelqu'un à une expérience sur le 
>>> sujet !
>>> 
>>> Merci, A+
>>> 
>>> Nicolas
>>> 
>>> 
>>> 
>>> ---
>>> 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/
>> 
>> -
>> Ce message et toutes les pièces jointes sont confidentiels. Il est établi à
>> l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce
>> message non conforme à sa destination, toute diffusion, copie ou toute
>> publication, totale ou partielle, est interdite, sauf autorisation expresse
>> préalable. Son contenu ne saurait constituer en aucun cas un engagement
>> contractuel, une offre de souscrire à quelconque produit ou instrument
>> financier ou une sollicitation à investir de la part du Groupe La Française 
>> et
>> toutes opinions exprimées dans ce message ne sauraient nécessairement 
>> refléter
>> celle du Groupe La Française. Le contenu de cet email peut contenir des virus
>> informatiques qui pourraie

Re: [FRnOG] [MISC] Petit update - nomination présidence ARCEP

[Jérôme Marteaux]

Le 09/12/2020 à 12:03, Jérôme Nicolle a écrit :
> Bonjour Olivier,
> 
> Le 09/12/2020 à 10:37, Olivier Tirat BYON a écrit :
>> Indépendamment de ta campagne contre AD 
> 
> Ce n'est pas une campagne contre AD, c'est une campagne pour retrouver
> un régulateur fonctionnel.
> 
> On s'est déjà laissé berner par Sébastien Soriano, qui nous a fait
> perdre 6 ans sur le B2B et a raté plein d'autres choses, hors ces deux
> là sont un peu Dupont et Dupond quand tu croises leurs CV. Il faut du
> changement pour que le secteur progresse.
> 

Bonjour Jérôme,

Un article d'hier à propos de Soriano:
https://www.letelegramme.fr/bretagne/fibre-optique-la-bretagne-se-paie-l-ex-patron-de-l-arcep-17-12-2020-12675681.php

Ca confirme ce que tu écris sur ce corporatisme.

Jérôme

-- 
Jérôme Marteaux


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

Re: [FRnOG] [TECH] lien de transit SFR

[Nicolas Parpandet]

Bonjour,

Ok bonne idée pour le mtu, 
j'ai le ping qui monte à 1472, donc c'est OK à priori... (+20 IP + 8 ICMP = 
1500)


Merci

Nicolas

- Mail original -
> De: "BELLOTTO Louis" 
> À: "frnog-tech" 
> Envoyé: Vendredi 18 Décembre 2020 14:09:50
> Objet: RE: [FRnOG] [TECH] lien de transit SFR

> Bonjour,
> 
> On a eu aussi un truc du même genre.
> Le souci venait du réglage du MTU sur un des routeurs opérateur...
> 
> Point peut être à vérifier
> 
> 
> --
> Louis
> 
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Thierry
> Chich
> Envoyé : vendredi 18 décembre 2020 13:54
> À : 'Olivier Tirat BYON' ; 'Nicolas Parpandet'
> ; 'frnog-tech' 
> Objet : RE: [FRnOG] [TECH] lien de transit SFR
> 
> Bonjour
> 
> C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y
> avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le
> débit atteignable en tcp.
> J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre
> politique de firewalling et offloading des cartes réseaux. Le débit passait de
> 70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur
> certaines version de redhat.
> 
> Tout ça pour dire que ce genre de constat dépend parfois de paramètres très
> complexes à identifier
> 
> Thierry CHICH
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Olivier
> Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet
> ; frnog-tech  Objet : Re: [FRnOG] [TECH]
> lien de transit SFR
> 
> Bonjour
> 
> Bon différence majeur entre udp et tcp... l'aquittement des paquets
> (TCP ACK).
> 
> On peut tester un upload indépendament du download ent UDP mais pas du tout en
> TCP.
> 
> Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le
> tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP
> RETRANSMIT
> 
> Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut
> atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas
> venir du lien. Après tester des performances réelles d'un transit c'est pas
> facile car ca dépend aussi de l'autre extrémité;)
> 
> Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>>
>> Bonjour,
>>
>> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte
>> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si
>> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de
>> 100Mbits/s revient tellement souvent dans nos tests, la probabilité
>> que cela soit lié au hasard me semble faible...)
>>
>> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à
>> 350Mbits...
>>
>> Cela fait plusieurs semaines que nous échangeons dans tous les sens
>> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, 
>> et
>> cela n'avance pas !
>>
>> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de
>> limite avec cet opérateur ?, nous avons fait énormément de contrôles
>> de notre côté, il me semble que c'est bien en face le soucis ..., il peut
>> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet 
>> !
>>
>> Merci, A+
>>
>> Nicolas
>>
>>
>>
>> ---
>> 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/
> 
> -
> Ce message et toutes les pièces jointes sont confidentiels. Il est établi à
> l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce
> message non conforme à sa destination, toute diffusion, copie ou toute
> publication, totale ou partielle, est interdite, sauf autorisation expresse
> préalable. Son contenu ne saurait constituer en aucun cas un engagement
> contractuel, une offre de souscrire à quelconque produit ou instrument
> financier ou une sollicitation à investir de la part du Groupe La Française et
> toutes opinions exprimées dans ce message ne sauraient nécessairement refléter
> celle du Groupe La Française. Le contenu de cet email peut contenir des virus
> informatiques qui pourraient endommager votre système informatique. Bien que
> Groupe La Française ait pris toutes les précautions raisonnables pour 
> minimiser
> ce risque, nous déclinons toute responsabilité pour tout dommage que vous
> pourriez subir en raison de virus informatiques. Si vous recevez ce courriel
> par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur.
> Nous vous invitons à prendre connaissance de notre politique de 
> confidentialité
> et de cookies en cliquant ici
> https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/
> --

RE: [FRnOG] [TECH] lien de transit SFR

[BELLOTTO Louis]

Bonjour,

On a eu aussi un truc du même genre.
Le souci venait du réglage du MTU sur un des routeurs opérateur...

Point peut être à vérifier


--
Louis



-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Thierry 
Chich
Envoyé : vendredi 18 décembre 2020 13:54
À : 'Olivier Tirat BYON' ; 'Nicolas Parpandet' 
; 'frnog-tech' 
Objet : RE: [FRnOG] [TECH] lien de transit SFR

Bonjour

C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y 
avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le 
débit atteignable en tcp. 
J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre 
politique de firewalling et offloading des cartes réseaux. Le débit passait de  
70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur 
certaines version de redhat.

Tout ça pour dire que ce genre de constat dépend parfois de paramètres très 
complexes à identifier

Thierry CHICH

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Olivier 
Tirat BYON Envoyé : vendredi 18 décembre 2020 12:25 À : Nicolas Parpandet 
; frnog-tech  Objet : Re: [FRnOG] [TECH] 
lien de transit SFR

Bonjour

Bon différence majeur entre udp et tcp... l'aquittement des paquets
(TCP ACK).

On peut tester un upload indépendament du download ent UDP mais pas du tout en 
TCP.

Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le 
tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP 
RETRANSMIT

Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut 
atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas 
venir du lien. Après tester des performances réelles d'un transit c'est pas 
facile car ca dépend aussi de l'autre extrémité;)

Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>
> Bonjour,
>
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
> que cela soit lié au hasard me semble faible...)
>
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
>
> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, 
> et cela n'avance pas !
>
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
> de notre côté, il me semble que c'est bien en face le soucis ..., il peut 
> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet !
>
> Merci, A+
>
> Nicolas
>
>
>
> ---
> 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/

-
 Ce message et toutes les pièces jointes sont confidentiels. Il est établi à 
l'attention exclusive de son ou ses destinataire(s). Toute utilisation de ce 
message non conforme à sa destination, toute diffusion, copie ou toute 
publication, totale ou partielle, est interdite, sauf autorisation expresse 
préalable. Son contenu ne saurait constituer en aucun cas un engagement 
contractuel, une offre de souscrire à quelconque produit ou instrument 
financier ou une sollicitation à investir de la part du Groupe La Française et 
toutes opinions exprimées dans ce message ne sauraient nécessairement refléter 
celle du Groupe La Française. Le contenu de cet email peut contenir des virus 
informatiques qui pourraient endommager votre système informatique. Bien que 
Groupe La Française ait pris toutes les précautions raisonnables pour minimiser 
ce risque, nous déclinons toute responsabilité pour tout dommage que vous 
pourriez subir en raison de virus informatiques. Si vous recevez ce courriel 
par erreur, merci de le détruire et d'en avertir immédiatement l'expéditeur. 
Nous vous invitons à prendre connaissance de notre politique de confidentialité 
et de cookies en cliquant ici 
https://www.la-francaise.com/fr/politique-de-confidentialite-et-de-cookies/ 
-
 This message and any attachments are confidential and may be legally 
privileged or otherwise protected from disclosure. It is intended only for the 
stated addressee(s). Any use, dissemination, copy or disclosure of this message 
not in accordance with its purpose, either in whole or in part, is prohibited 
without our prior formal approval. Its contents, given solely for information, 
does not constitute a commitment or an

RE: [FRnOG] [TECH] lien de transit SFR

[Thierry Chich]

Bonjour

C'est vrai que j'aurais pensé à priori à un shaping. Bien sûr, il peut aussi y 
avoir des soucis liés à la latence sur le lien qui peut diminuer fortement le 
débit atteignable en tcp. 
J'ai déjà eu aussi des effets particulièrement forts de l'interaction entre 
politique de firewalling et offloading des cartes réseaux. Le débit passait de  
70Mo/s à 250 Mo/s en désactivant l'offloading ( ethtool -K ens192 tso off) sur 
certaines version de redhat.

Tout ça pour dire que ce genre de constat dépend parfois de paramètres très 
complexes à identifier

Thierry CHICH

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Olivier 
Tirat BYON
Envoyé : vendredi 18 décembre 2020 12:25
À : Nicolas Parpandet ; frnog-tech 
Objet : Re: [FRnOG] [TECH] lien de transit SFR

Bonjour

Bon différence majeur entre udp et tcp... l'aquittement des paquets
(TCP ACK).

On peut tester un upload indépendament du download ent UDP mais pas du tout en 
TCP.

Il faut faire gaffe au debit en download, s'assurer qu'il y a la place dans le 
tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour eviter les TCP 
RETRANSMIT

Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau peut 
atteindre ces performances indépendamment. Donc le problème en TCP ne doit pas 
venir du lien. Après tester des performances réelles d'un transit c'est pas 
facile car ca dépend aussi de l'autre extrémité;)

Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>
> Bonjour,
>
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR, l'UDP monte 
> bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme si 
> il y avait une QOS quelque part sur les sessions TCP, (le chiffre de 
> 100Mbits/s revient tellement souvent dans nos tests, la probabilité 
> que cela soit lié au hasard me semble faible...)
>
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
>
> Cela fait plusieurs semaines que nous échangeons dans tous les sens 
> avec l'opérateur (iperfs etc), c'est bien sur à nous de prouver le problème, 
> et cela n'avance pas !
>
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de 
> limite avec cet opérateur ?, nous avons fait énormément de contrôles 
> de notre côté, il me semble que c'est bien en face le soucis ..., il peut 
> toujours subsister un doute, mais si quelqu'un à une expérience sur le sujet !
>
> Merci, A+
>
> Nicolas
>
>
>
> ---
> 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] [TECH] lien de transit SFR

[Olivier Tirat BYON]

Bonjour

Bon différence majeur entre udp et tcp... l'aquittement des paquets
(TCP ACK).

On peut tester un upload indépendament du download ent UDP mais pas du
tout en TCP.

Il faut faire gaffe au debit en download, s'assurer qu'il y a la place
dans le tuyau pour les paquets TCP ACK. Et bien geré la fenêtre pour
eviter les TCP RETRANSMIT

Si en fait ton lien passe les 850 Mbit/s en udp  c'est que le niveau
peut atteindre ces performances indépendamment. Donc le problème en TCP
ne doit pas venir du lien. Après tester des performances réelles d'un
transit c'est pas facile car ca dépend aussi de l'autre extrémité;)

Le 18/12/2020 à 11:52, Nicolas Parpandet a écrit :
>
> Bonjour,
>
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR,
> l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme 
> si il y avait une QOS quelque part sur les sessions TCP,
> (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la 
> probabilité que cela soit lié au hasard me semble faible...)
>
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
>
> Cela fait plusieurs semaines que nous échangeons dans tous les sens avec 
> l'opérateur (iperfs etc), 
> c'est bien sur à nous de prouver le problème, et cela n'avance pas !
>
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite 
> avec cet opérateur ?,
> nous avons fait énormément de contrôles de notre côté, il me semble que c'est 
> bien en face le soucis ...,
> il peut toujours subsister un doute, mais si quelqu'un à une expérience sur 
> le sujet !
>
> Merci, A+
>
> Nicolas
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] lien de transit SFR

[Kavé Salamatian]

Glasnost fait le job. Voir ici 
https://github.com/marcelscode/glasnost

Kv

> Le 18 déc. 2020 à 11:52, Nicolas Parpandet  a écrit :
> 
> 
> 
> Bonjour,
> 
> Nous avons un nouveau lien de transit 1Gbits/s avec SFR,
> l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme 
> si il y avait une QOS quelque part sur les sessions TCP,
> (le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la 
> probabilité que cela soit lié au hasard me semble faible...)
> 
> De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
> 350Mbits...
> 
> Cela fait plusieurs semaines que nous échangeons dans tous les sens avec 
> l'opérateur (iperfs etc), 
> c'est bien sur à nous de prouver le problème, et cela n'avance pas !
> 
> est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite 
> avec cet opérateur ?,
> nous avons fait énormément de contrôles de notre côté, il me semble que c'est 
> bien en face le soucis ...,
> il peut toujours subsister un doute, mais si quelqu'un à une expérience sur 
> le sujet !
> 
> Merci, A+
> 
> Nicolas
> 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] lien de transit SFR

[Raphael Mazelier]

Bonjour,

Latence, packet loss quelconque ? Quel type de lien de transit ? sur 
quel medium ?


btw pourquoi prendre du transit chez SFR ? (seul transitaire disponible ?)

Cdt,

On 18/12/2020 11:52, Nicolas Parpandet wrote:


Bonjour,

Nous avons un nouveau lien de transit 1Gbits/s avec SFR,
l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme 
si il y avait une QOS quelque part sur les sessions TCP,
(le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la 
probabilité que cela soit lié au hasard me semble faible...)

De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
350Mbits...

Cela fait plusieurs semaines que nous échangeons dans tous les sens avec 
l'opérateur (iperfs etc),
c'est bien sur à nous de prouver le problème, et cela n'avance pas !

est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec 
cet opérateur ?,
nous avons fait énormément de contrôles de notre côté, il me semble que c'est 
bien en face le soucis ...,
il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le 
sujet !

Merci, A+

Nicolas



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



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

[FRnOG] [TECH] lien de transit SFR

[Nicolas Parpandet]

Bonjour,

Nous avons un nouveau lien de transit 1Gbits/s avec SFR,
l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme 
si il y avait une QOS quelque part sur les sessions TCP,
(le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la 
probabilité que cela soit lié au hasard me semble faible...)

De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
350Mbits...

Cela fait plusieurs semaines que nous échangeons dans tous les sens avec 
l'opérateur (iperfs etc), 
c'est bien sur à nous de prouver le problème, et cela n'avance pas !

est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec 
cet opérateur ?,
nous avons fait énormément de contrôles de notre côté, il me semble que c'est 
bien en face le soucis ...,
il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le 
sujet !

Merci, A+

Nicolas



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