RE: [FRnOG] [ALERT] chaleur en ce 9 mars

2014-03-09 Par sujet sbu123fr 
Bonjour,
Pour moi  la température redescente depuis 22h, 3 eme étages.
SBU

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Frederic Dhieux
Envoyé : dimanche 9 mars 2014 22:47
À : frnog@frnog.org
Objet : Re: [FRnOG] [ALERT] chaleur en ce 9 mars

Ca a l'air de revenir, je suis redescendu de 39,9°C à 36,2°C là... (au 3eme)

Impacté sur le 1er et le 3eme. Pas eu de retour de TH2 encore par contre pour 
avoir les infos sur ce qu'il se passe.

Frédéric

Le 09/03/2014 21:45, Raphael Mazelier a écrit :
 2eme et 3eme.
 Une panne de climatisation un 9 mars...
 C'est vraiment des champions TH2.



 Le 09/03/2014 21:35, Julien (JaXX) Banchet a écrit :
 Bonsoir

 Pareil au 3ème, j’ai déjà de l'impacte

 JaXX./.

 --
 De: Pierre-Olivier Lompre pier...@gmail.com
 Répondre: pier...@gmail.com pier...@gmail.com
 Date: 9 mars 2014 at 21:27:01
 À: Bruno CAVROS / SKIWEBCENTER br...@skiwebcenter.fr
 Cc: frnog-al...@frnog.org frnog-al...@frnog.org
 Sujet:  Re: [FRnOG] [ALERT] chaleur en ce 9 mars

 Bonsoir
   Je confirme de notre coté sur la salle NERIM (11-15 est).
 Température élevée.
   Pierre-Olivier
 Le 9 mars 2014 20:09, Bruno CAVROS / SKIWEBCENTER a écrit :
 Bonsoir,



 Meteo France annonce des records en ce 9 mars, il semble qu'il en
 soit de même au 137 boulevard voltaire...



 Sauna, hamman inclus ?



 Bonne soirée



 Bruno



 SKIWEBCENTER

 Tel: +33 3 21 15 15 98 Fax: +33 3 21 15 15 99

 www.skiwebcenter.com / i...@skiwebcenter.com




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

   ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 --
 Julien (JaXX) Banchet


 ---
 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 courrier électronique ne contient aucun virus ou logiciel malveillant parce 
que la protection avast! Antivirus est active.
http://www.avast.com


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

RE: [FRnOG] [TECH] FIREWALL : Checkpoint / Palo Alto / Fortinet

2015-11-16 Par sujet sbu123fr 
Hello,

Et bien pour avoir pratiqué pendant 2 mois assidument.

L’interface est un tableur ni plus ni moins, pas ergonomique lente,  upgrade 
laborieuse (comme check point). Tu créé des règles qui après arrêt relance de 
la webui ont changé de place, c’est flippant. Ou des commentaires qui se 
déplace.

On dirait FWbuilder au tout début.

Un seule truc bien le mode de simulation de trafic (en cli)  car en webui il 
fonctionne quand il a le temps….

Plantage sporadique du FW lorsqu’on active les log dans un certain mode, 
bascule incompréhensible en mode HA.

Oui je parle bien de Cisco c’est incompréhensible venant d’eux.

Une règle peut représenter 80 ACL effective…

Et pour connaitre pas mal de personnes « enchainé »  Cisco qui l’ont intégré en 
prod. Ils ont tous été forcé de migrer vers d’autres techno. Et je parle de 
très très grand groupes. Hormis un, mais qui ne connait rien d’autre 
malheureusement pour les exploitants….

(Et Je ne suis pas un anti Cisco)

SBU

 

 

 

 

De : Joe Yabuki [mailto:joeyabuki...@gmail.com] 
Envoyé : vendredi 13 novembre 2015 20:02
À : Sylvain sbu
Cc : Rodolphe VIENCO; frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] FIREWALL : Checkpoint / Palo Alto / Fortinet

 

Sylvain, tu peux approfondir la phrase " A part Cisco ASA qui est à mon sans 
une hérésie quelque soit la prod." ? D'un point de vu expérience je veux dire, 
j'entends souvent les gens critiquer ASA sans forcement argumenter...

Joe.

 

2015-11-13 18:41 GMT+01:00 Sylvain sbu :

Bonjour,
Je travaille aujourd'hui sur du PaloAlto, Stonesoft, Cisco ASA, check
point, Juniper SRX (Pas Fortinet).
En faite tout dépend de ce que tu a comme environnement, volumétrie (nombre
de FW a gérer) débit type de trafic, expérience des ressources humaine.
Chaque techno répond à un besoin très bien, et moins pour un autre. A part
Cisco ASA qui est à mon sans une hérésie quelque soit la prod.
Entre PaloAlto et Check point ce que je vois comme différence flagrante
c'est l'exploitabilité niveau 2 (Upgrade, restor from crash, installation)
bien plus simple avec Palo Alto.
Et les vus sur les stats, plus toufu sous PaloAlto, par contre le debug est
bien mieux sous Checkpoint. Chekpoint et plus véloce aussi à trafic
équivalent et "boite équivalentes"
La management lorsqu'on a un gros volume de FW à gérer est kif kif. Et a
mon avis les 2 seules exploitablent dans la vrai vie.
Je ne m’occupe plus des licence mais c'était un beau merdier chez Check
point a une époque, limite il fallait une certif gestion des licence et ça
changeait tout le temps de mode... C'est peut être toujours le cas.
SBU




Le 13 novembre 2015 16:44, Rodolphe VIENCO  a
écrit :


> Bonjour à vous tous,
>
> Je déterre un sujet vu en Juin 2015 ( [FRnOG] [TECH] Help ! Checpoint vs
> Palo Alto <
> https://www.mail-archive.com/search?l=frnog@frnog.org 
> 
>  
> =subject:%22%5C%5BFRnOG%5C%5D+%5C%5BTECH%5C%5D+Help+%5C%21+Checkpoint+vs+Palo+Alto%22=newest>
> ),
> Dans ce sujet, Palo Alto l’emporte sur Checkpoint à vos yeux, du coup, pas
> mal de question se soulèvent.
>
> Après une matinée de recherche (J’ai bouffer de la doc a m’en faire vomir),
> Je me tourne vers vous pour avoir des retours moins ciblés, achetés ou
> vendus.
>
> En faite, je recherche plutôt vos remarques personnelles, de façon
> constructive, tirées de vos propres expériences si possible.
> Je pense que vous êtes tous mieux placées que moi.
>
> 1. Pourquoi j’en suis là :
>
> Afin de mettre en avant Checkpoint face à Palo-Alto, ma sociètè
> m’a demandé de faire des recherches pour trouver les points positifs et
> négatifs généraux des 2 marques.
> J’ai orienté mes recherches vers les firewall "Next Generation” et ne me
> suis pas bloqué sur ces deux marques là uniquement afin d’en apprendre le
> plus possible sur tous.
>
> Et du coup, je references les avantages de toutes les grandes marques
> reconnues et les inconvénients. Surtout sur Checkpoint, Palo Alto et
> Fortinet.
>
> En terme d’expérience :
> J’ai travaillé sur du Checkpoint, du Fortinet, du PFSence jusqu’a
> aujourd’hui.
>
>
> 2. Ce que je peux dire d’après ce que j’ai lu :
>
> * Palo Alto et Checkpoint sont considérés par la masse comme les leaders
> du firewall
> * Checkpoint se montre meilleur en sécurité que Palo Alto, moins bon sur
> les MAJ majeurs cependant.
> * Fortinet n’est pas mis en avant
> * Checkpoint à des defaults, mais reste N’1 sur la sécurité, et c’est
> avant tout ce qui lui est demandé non?
> (cf. La bibliographie ci-dessous : - Liste non exhaustive -.)
>
> 3. L’instant Questions :
>
> - La sécurité est elle la meilleur avec Checkpoint?
> - Palo Alto est il plu simple a configuré / maintenir et mettre à jours?
> - Les prix pour chaque appliances de même catégorie sont ils correspondant?
> - Pourquoi 100% des "Fortune 100"

RE: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur différents continents

2015-10-08 Par sujet sbu123fr 
Oui j'ai fourché dsl.
SBU

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Arnaud Launay
Envoyé : jeudi 8 octobre 2015 17:05
À : frnog-...@frnog.org
Objet : Re: [FRnOG] [BIZ] Mise en place de serveurs en anycast sur
différents continents

Le Thu, Oct 08, 2015 at 05:04:08PM +0200, Sylvain sbu a écrit:
> De mémoire ; je crois que liazo c est faire. Ex Neo.

Heu ? Zayo non ? :)

Ou alors il s'est passé des trucs :-D

Arnaud.


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


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

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

2017-02-14 Par sujet sbu123fr 
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?CdtSbu


 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 : Re: [FRnOG] [TECH] Liens (MPLS) 500Mo mais plutot 5 x 100Mo

2017-02-15 Par sujet sbu123fr 
Exacte ! 

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  15:35  (GMT+01:00) 
À : Benjamin Bachelart <b...@bashy.eu> 
Cc : Sylvain sbu <sbu12...@gmail.com>, Xavier HINFRAY <xhinf...@gmail.com>, 
"frnog@FRnOG.org" <frnog@frnog.org>, Michel Hostettler 
<michel.hostett...@telecom-paristech.fr>, frnog-tech <frnog-t...@frnog.org> 
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 <b...@bashy.eu> 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 <luigi.1...@gmail.com>:
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 <sbu12...@gmail.com> a écrit :



> 40Kms grand max...

>

> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> 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" <luigi.1...@gmail.com>

>>> À: "sbu123fr" <sbu12...@gmail.com>

>>> Cc: "f

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

2017-02-15 Par sujet 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 <luigi.1...@gmail.com> 
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
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 <luigi.1...@gmail.com> 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 <sbu12...@gmail.com> 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 <laurent.ducas...@spaceshell.fr> 
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 <b...@bashy.eu> 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 <luigi.1...@gmail.com>:
>>
>>> 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 :
>&g

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

2017-02-15 Par sujet sbu123fr 
is 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 <sbu12...@gmail.com> a écrit :
>>>
>>>> 40Kms grand max...
>>>>
>>>> Le 15 février 2017 à 13:03, Xavier HINFRAY <xhinf...@gmail.com> 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" <luigi.1...@gmail.com>
>>>>>> À: "sbu123fr" <sbu12...@gmail.com>
>>>>>> Cc: "frnog-tech" <frnog-t...@frnog.org>
>>>>>> 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 <sbu12...@gmail.com> 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 <luigi.1...@gmail.com>
>>>>>>>   Date : 14/02/2017 18:05 (GMT+01:00)
>>>>>>>   À : Sylvain sbu <sbu12...@gmail.com>
>>>>>>>   Cc : frnog-tech <frnog-t...@frnog.org>
>>>>>>>   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
>>>>>&

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

2017-02-15 Par sujet 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 <sbu12...@gmail.com> 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 <luigi.1...@gmail.com> 
Date : 15/02/2017  17:22  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
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 <luigi.1...@gmail.com> 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 <sbu12...@gmail.com> 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 <laurent.ducas...@spaceshell.fr> 
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 <b...@bashy.eu> 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 <luigi.1...@gmail.com>:
 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 Wi

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

2017-02-15 Par sujet sbu123fr 
Oui ça ça m inquiet moins ☺

 Message d'origine 
De : Louis <luigi.1...@gmail.com> 
Date : 15/02/2017  17:20  (GMT+01:00) 
À : sbu123fr <sbu12...@gmail.com> 
Cc : Ducassou Laurent <laurent.ducas...@spaceshell.fr>, Liste FRnoG 
<frnog@frnog.org> 
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 <sbu12...@gmail.com> 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 <laurent.ducas...@spaceshell.fr> 
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 <b...@bashy.eu> 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 <luigi.1...@gmail.com>:
>>
>>> 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 sh

[FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

2016-11-10 Par sujet sbu123fr 
Bonjour,
Quelqu'un as-t-il déjà eu des souci avec l'utilisation de NETCONF sur un
vChassi de Juniper EX4500?
Essentiellement lors des commit, qui génèrent des curiosités avec les LAG
voire même sur la partie commut. proprement dite.
Les logs ne crachent pas grand-chose, mais lors des commit en NETCONF nous
avons exactement, au même moment, des pertes de paquet, jusqu'aux machines
qui y sont connectés. Théoriquement c'est parfaitement dissocié mais là ça
ne semble pas si simple.
Si qqun a déjà vu ce phénomène.
SBU 



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

RE: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

2016-11-14 Par sujet sbu123fr 
Bonjour,
J'ai un peu plus d'info, en fait c'est l'ajout de vlan sur plusieurs
interfaces (en masse via netconf) qui induit des pertes de paquet
"forwardés", de plus la plupart des appli ne voit rien sauf une...
Alors qu'à la suppression de ces vlan toujours en masse je ne constate rien.
Je ne sais pas si cela est inhérent au 4500 ou à leur version.
Les vlan sont appliquées sur les interfaces et non pas les interfaces dans
les vlans, je ne sais pas s'il y a une méthode mieux qu'une autre en fait?
SBU


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Raphael Mazelier
Envoyé : vendredi 11 novembre 2016 17:35
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf



On 10/11/2016 21:42, sbu12...@gmail.com wrote:
> Bonjour,
> Quelqu'un as-t-il déjà eu des souci avec l'utilisation de NETCONF sur 
> un vChassi de Juniper EX4500?
> Essentiellement lors des commit, qui génèrent des curiosités avec les 
> LAG voire même sur la partie commut. proprement dite.
> Les logs ne crachent pas grand-chose, mais lors des commit en NETCONF 
> nous avons exactement, au même moment, des pertes de paquet, jusqu'aux 
> machines qui y sont connectés. Théoriquement c'est parfaitement 
> dissocié mais là ça ne semble pas si simple.
> Si qqun a déjà vu ce phénomène.

Étrange, étrange.

J'ai fait beaucoup de netconf(pyez) sur des VC de 4550/4200 ou autres et je
n'ai jamais constaté ce genre de soucis.

Au moment du commit il reste du cpu pour le reste ?
d'ailleurs sur tout ce qui est soft (Lacp par exemple) le manque de CPU ça
peut provoquer des soucis sur EX (comme je le disais Pierre). Sur le
forwarding je suis extrêmement perplexe. Il faudrait que le commit est une
incidence sur le Trio ? a la limite quand tu reprogramme tout je veux bien
(gros commit avec changement de paramètre physique sur les interfaces ou
autres).
Ça apparaît à chaque fois ? sur quel type de commit/changement ? que dit le
jtac ? (on est vendredi :).

--
Raphael Mazelier


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


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

RE: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

2016-11-15 Par sujet sbu123fr 
Bonjour,

Pas de recalcule STP dans les log du moins…

Qqun m’a soufflé de vérifier si le stp effectivement mais pourquoi cela ne fait 
rien lors de la suppression…

Et le phénomène n’existe pas en cli classic. (je rollback une conf faite via 
netconf)

En tous cas merci pour vos réponses.

SBU

 

 

 

De : Guillaume Barrot [mailto:guillaume.bar...@gmail.com] 
Envoyé : mardi 15 novembre 2016 09:26
À : Sylvain Busson
Cc : Raphael Mazelier; frnog@FRnOG.org
Objet : Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

 

modif de vlans (en masse en prime), ça pue le recalcul spanningtree frelaté 
(modif de vlan > changement de topologie > recalcul spt). 

 

Tente le même modif en CLI, et je pense que tu verras les mêmes effets (ie pas 
de rapport direct avec Netconf, plutot le fait que les modifs soient faites en 
masse)

 

 

Le 15 novembre 2016 à 01:07,  a écrit :

Bonjour,
J'ai un peu plus d'info, en fait c'est l'ajout de vlan sur plusieurs
interfaces (en masse via netconf) qui induit des pertes de paquet
"forwardés", de plus la plupart des appli ne voit rien sauf une...
Alors qu'à la suppression de ces vlan toujours en masse je ne constate rien.
Je ne sais pas si cela est inhérent au 4500 ou à leur version.
Les vlan sont appliquées sur les interfaces et non pas les interfaces dans
les vlans, je ne sais pas s'il y a une méthode mieux qu'une autre en fait?
SBU


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Raphael Mazelier
Envoyé : vendredi 11 novembre 2016 17:35
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf




On 10/11/2016 21:42, sbu12...@gmail.com wrote:
> Bonjour,
> Quelqu'un as-t-il déjà eu des souci avec l'utilisation de NETCONF sur
> un vChassi de Juniper EX4500?
> Essentiellement lors des commit, qui génèrent des curiosités avec les
> LAG voire même sur la partie commut. proprement dite.
> Les logs ne crachent pas grand-chose, mais lors des commit en NETCONF
> nous avons exactement, au même moment, des pertes de paquet, jusqu'aux
> machines qui y sont connectés. Théoriquement c'est parfaitement
> dissocié mais là ça ne semble pas si simple.
> Si qqun a déjà vu ce phénomène.

Étrange, étrange.

J'ai fait beaucoup de netconf(pyez) sur des VC de 4550/4200 ou autres et je
n'ai jamais constaté ce genre de soucis.

Au moment du commit il reste du cpu pour le reste ?
d'ailleurs sur tout ce qui est soft (Lacp par exemple) le manque de CPU ça
peut provoquer des soucis sur EX (comme je le disais Pierre). Sur le
forwarding je suis extrêmement perplexe. Il faudrait que le commit est une
incidence sur le Trio ? a la limite quand tu reprogramme tout je veux bien
(gros commit avec changement de paramètre physique sur les interfaces ou
autres).
Ça apparaît à chaque fois ? sur quel type de commit/changement ? que dit le
jtac ? (on est vendredi :).

--
Raphael Mazelier


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


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





 

-- 

Cordialement,

Guillaume BARROT


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

RE: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

2016-11-15 Par sujet sbu123fr 
Plus que frelaté , qui dure qque mico secondes, bizarre.
SBU

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Raphael Mazelier
Envoyé : mardi 15 novembre 2016 20:53
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Pb Juniper Ex4500 avec Netconf

Même analyse que Guillaume, j'ai aussi vu des trucs étrange avec les vlan-range.


On 15/11/2016 09:26, Guillaume Barrot wrote:
> modif de vlans (en masse en prime), ça pue le recalcul spanningtree frelaté
> (modif de vlan > changement de topologie > recalcul spt).
>
> Tente le même modif en CLI, et je pense que tu verras les mêmes effets (ie
> pas de rapport direct avec Netconf, plutot le fait que les modifs soient
> faites en masse)
>
>

--
Raphael Mazelier


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


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

RE: [FRnOG] [TECH] Supervision réseau

2016-11-20 Par sujet sbu123fr 
"Obervium ?"

Dommage qu'il n'est pas le template ForcePoint.
SU

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Jeremy
Envoyé : dimanche 20 novembre 2016 15:16
À : asham kimo; frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Supervision réseau

Obervium ?

Jérémy

Le 20/11/2016 à 12:02, asham kimo a écrit :
> c dimanche ...et c pas grave !
> Bonjour,
>
> dans le cadre d'un stage ,la boite qui m'accueille m'a demandé de proposer
> avec une démonstration de faisabilité (POC)   une solution de supervision
> réseau gratuite , avec map graphique et qui puisse prendre en charge 
> les éléments suivants:
> Synology, routeur, UCS, Vcenter, switch, controleur wifi, borne wifi, 
> serveur local , serveur cloud ( ça j'avoue ! j'ai pas bien pigé ) et 
> un état de sauvegarde du stockage (synology).
> j'ai commencé par voir du coté de Eyesofnetwork ,Packetfence et 
> Grafana... je suis preneur pour tout retour 
> d’expérience sur ces solutions ou autres .
>et merci d'avance,
> Asham
>
> ---
> 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] Feedback JUNIPER Virtual-Chassis

2016-10-26 Par sujet sbu123fr 
Bonjour,
Même souci avec snmp et LACP (sur 2200 et 4500), le CPU de la RE est trop juste.
Cdt
SBU

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Cyril Lavier
Envoyé : mercredi 26 octobre 2016 15:32
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Feedback JUNIPER Virtual-Chassis

Bonjour.

J'en fais tourner pas mal dans les bureaux (10 stacks de 4-5 membres et 4 
stacks de 2 membres tout en EX3300), et ça tourne bien.

Il faut bien suivre les recommandations (OS dans les mêmes versions, bien 
cabler) et ça tourne sans trop de soucis.

Par contre, 2 choses : 
- Par expérience, je conseille le mode pré-provisionné sur les VChassis, et pas 
le provisionning dynamique basé sur le poids du master, car au moment de 
changer un membre, si tu ne vérifies pas le poids du nouveau membre, et hop, il 
se retrouve master et tu perds toute la conf de ton stack, et là, t'es bon pour 
aller chercher un backup à restaurer.
- Quand on fait du poll SNMP sur des stacks de 5 switchs, ça pique un peu en 
temps de polling, donc il faut faire attention à ça.

Mais pour le reste, ça tourne correctement.

Merci.

- Original Message -
From: "Jean-Baptiste COUPIAC" 
To: frnog@frnog.org
Sent: Wednesday, 26 October, 2016 15:26:44
Subject: [FRnOG] [TECH] Feedback JUNIPER Virtual-Chassis

Bonjour la liste,

J'utilise depuis quelques temps la techno Juniper Virtual-Chassis sur des 
switchs entrées de gamme EX2200-EX3300 (techno de Stack chez Juniper). Je 
trouve la techno assez fiable.

Y'a t'il du monde qui a du recul / un feedback sur VirtualChassis (en bien ou 
pas bien :)) ?

Merci,
__

*Jean-Baptiste COUPIAC*
Tél. : +33 5 34 45 55 00 <%20+33534455500>
4 rue Kennedy 31000 Toulouse - France

---
Liste de diffusion du FRnOG
http://www.frnog.org/
--
Cyril "Davromaniak" Lavier
KeyID 59E9A881
http://www.davromaniak.eu


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


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

RE: [FRnOG] [TECH] Phénomène incompréhensible via VPN IPSEC

2016-12-09 Par sujet sbu123fr 
Bonjour,
Est-ce un VPN rules base ou routes base. Si c'est une rules base j'ai déjà
eu des souci avec les services qui se comportaient bizarre et différemment
dans les rules VPN... (ALG  peut être?) j'avais dû faire des services
custom?
Un bon moyen de voir si c'est un souci de MTU tu fais ssh sur une machine
linux et tu cherches une commande qui retour plein de ligne, type "dmessage"
si ça n'affiche pas toutes les ligne et que ça fige c'est surement le MTU
qui n'est pas bon.
SBU


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
Sébastien 65
Envoyé : vendredi 9 décembre 2016 20:52
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Phénomène incompréhensible via VPN IPSEC

Bonjour,

J'ai un VPN IPSEC entre deux sites sur lequel je rencontre un gros problème
que je n'arrive pas à comprendre et résoudre.

Le VPN est bien montée entre les deux routeurs Cisco. Je ping bien des
machines depuis n'importe quel côté du VPN.

J'arrive à monter des sessions TSE sans problème, faire du SSH, du FTP, là
où cela se complique est que certain service http/https ne fonctionnent pas,
le navigateur tourne en rond...

J'arrive à monter des partages Windows sans aucun problème par contre les
partages présents sur serveur LINUX impossible !! Je peux utiliser
l'interface d'admin pour accéder à une imprimante Brother mais pas celui de
la Sharp (les deux imprimantes sont sur le même switch - depuis le lan je
n'ai pas de soucis pour m'y connecter).

Par exemple j'ai plusieurs NAS (D-Link) sur lequel je ne peux pas accéder à
l'interface WEB (http) depuis le site distant, ni à utiliser les partages
réseaux, cela mais trois plombe à afficher les partages ça mouline pendant
des minutes...

Chose encore plus délirante est que dans le poste de travail je vois bien la
capacité du lecteur réseau (espace disque utilisé/restante) mais je ne peux
pas y rentrer, ça mouline...

Avez-vous déjà rencontré le phénomène ? Ai-je loupé un truc dans la
configuration du VPN ?

Merci pour vos lumières !

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


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

[FRnOG] RE: [MISC] google renforce ses test de déclenchement de captcha?

2016-12-13 Par sujet sbu123fr 
Apparemment c'est plus général, certains autres gros consommateurs de masquage 
d'IP ont eu leurs captcha les semaines passées.
SBU

-Message d'origine-
De : Stephane Bortzmeyer [mailto:bortzme...@nic.fr] 
Envoyé : mardi 13 décembre 2016 15:12
À : Sylvain sbu
Cc : frnog-m...@frnog.org
Objet : Re: [MISC] google renforce ses test de déclenchement de captcha?

On Tue, Dec 13, 2016 at 10:53:51AM +0100,  Sylvain sbu  
wrote  a message of 11 lines which said:

> Ce matin nous avons "tous" nos utilisateurs (dérriere differents AS)  
> qui nous demandent si cela est normal ce captcha.
> Si quelqu'un a-t-il des infos..?...

Non. Mais, il y a quelques jours, Gogle a annoncé le contraire :

http://www.androidauthority.com/google-recaptcha-734446/


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

Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?

2018-05-22 Par sujet sbu123fr 
+1 pour libreNMS (sauf juniper ex 45xxx , ex 3300 et moins qu' il atomise au 
pooling) après de nombreuses années sous Observium.Et Cacti 1.x et ses graphs 
"réal time" addictif lors des opé..En plus libreNMS intègre (pour ce que j 
utilise) :- wethermap disparu sous Cacti 1.x- rancid- raccourci ssh- gestion de 
vu par group d équipementsEtc
Manque que la gestion des fw forcepoint :(
Au fait si qqun connaît un wethermap like plus jolie et libre...Sbu


Envoyé de mon Galaxy A5 2017 Orange
 Message d'origine De : Michel Py 
 Date : 23/05/2018  02:51  (GMT+01:00) À : 
Jérôme Quintard , frnog-m...@frnog.org Objet : [FRnOG] 
[MISC] RE: Outils cool, qu'utilisez-vous ? 
> Jérôme Quintard a écrit :
> Est-que vous avez des pépites que vous estimez incontournable...

J'utilise LibreNMS à la place d'Observium, très content jusqu'à présent malgré 
un hoquet récemment.

Pour IPAM je suis en train de regarder, je pensais aller sur PHPIPAM. Je lirai 
avec attention les contribs à ce sujet.

Michel.


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

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

Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?

2018-05-23 Par sujet sbu123fr 
C juste un lien vers ton outils préféré pas un client ssh


Envoyé de mon Galaxy A5 2017 Orange
 Message d'origine De : Wallace  Date : 
23/05/2018  10:32  (GMT+01:00) À : frnog@frnog.org Objet : Re: [FRnOG] [MISC] 
RE: Outils cool, qu'utilisez-vous ? 
Sympa tous ces accès ssh par le web mais plus personne n'utilise de vrai
terminal?

Je dois être trop accros à Terminator et sa gestion des multifenêtres
pour passer à du web only.

De notre côté on a des bastions ssh fait maison géré par Ansible, les
users peuvent se connecter que depuis des points de sortie VPN fixes
qu'on gère aussi mais tout se passe en terminal pas d'accès web, seul un
Mosh est en place pour les utilisateurs en astreinte ayant une connexion
pas stable.


Le 23/05/2018 à 09:40, Nicolas Girardi a écrit :
> Bonjour à tous,
>
> Dans le même genre sshkeybox.
>
> Nicolas Girardi.
>
>> Le 23 mai 2018 à 09:36, Kevin CHAILLY | Service Technique 
>>  a écrit :
>>
>>
>>
>> Bonjour,
>>
>>
>> Pour les accès centralisés, je recommande fortement MobaXterm, et dans un 
>> navigateur, Guacamole avec quelques scripts pour l'alimenter est un outil 
>> assez puissant. ( ssh / vnc / tse ).
>>
>>
>> Kévin
>>
>> 
>> De : frnog-requ...@frnog.org  de la part de Jérôme 
>> Quintard 
>> Envoyé : mardi 22 mai 2018 23:07
>> À : frnog-m...@frnog.org
>> Objet : [FRnOG] [MISC] Outils cool, qu'utilisez-vous ?
>>
>> Salut à tous,
>>
>> Je cherchais il y a quelques temps un IPAM/DCMI en remplacement de racktable 
>> et après de nombreuses réponses je suis devenu accroc de netbox (même si il 
>> manque à mon niveau quelques fonctionnalités). Cette découverte m'amène à me 
>> demander quels autres outils, sympa il existe dans nos métiers (orienté 
>> devops ou tech pure). Existe t'il des ressources/awesome sur ce sujet...
>>
>> Outre centreon/zabbix, j'utilise observium, cacti, bookspace (que j'adore en 
>> lieu et plave d'un wiki pour regrouper nos docs), royalts pour centraliser 
>> les accès (SSH, TSE, Web, etc.). GNS, docker pour les labs.
>>
>> Est-que vous avez des pépites que vous estimez incontournable...
>>
>> Jérôme
>>
>> ---
>> 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] RE: Outils cool, qu'utilisez-vous ?

2018-05-23 Par sujet sbu123fr 
Une carte?


Envoyé de mon Galaxy A5 2017 Orange
 Message d'origine De : Michel Py 
<mic...@arneill-py.sacramento.ca.us> Date : 23/05/2018  17:26  (GMT+01:00) À : 
"'r...@futomaki.net'" <r...@futomaki.net>, sbu123fr <sbu12...@gmail.com>, 
Jérôme Quintard <jquint...@outlook.com>, frnog-m...@frnog.org Objet : RE: 
[FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ? 
> r...@futomaki.net a écrit :
> En effet librenms / observium a la fâcheuse tendance à poller de manière bien 
> trop violente à coup
> de snmpbulwalk. ça tue les switchs avec des cpus/control plane en carton 
> style ex2k 3k 5k.

Ah c'est donc çà qui se passe. Je confirme, avec certains matos çà plante. En 
général sur Cisco çà se passe bien, mais j'ai quelques antiquités qui passent à 
100% CPU.


> David Ponzone a écrit  :
> Oui, le produit est automagique, mais ne pas pouvoir restreindre le poller à 
> ne prendre
> que l’essentiel a un arrière-goût de "société de consommation" désagréable.

C'est vrai, j'ai des châssis sur lesquels il y a 60 sondes de température, 
c'est un peu overkill. Ceci dit, c'est quand même bien sympa. L'intégration 
avec oxidized aussi.

Par contre si quelqu'un a compris comment faire une carte, je suis preneur. 
J'ai commencé à regarder, il y a un gout d'usine à gaz.

Michel.


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

Re: [FRnOG] [MISC] RE: Outils cool, qu'utilisez-vous ?

2018-05-23 Par sujet sbu123fr 
Je vais peut-être dire une connerie mais y a  pas moyen de limiter les path OID 
sur les devices et squizer les infos dont on a pas besoin. Pour éviter de 
parsser la mib entière?


Envoyé de mon Galaxy A5 2017 Orange
 Message d'origine De : Clément Cavadore  
Date : 23/05/2018  23:23  (GMT+01:00) À : frnog@frnog.org, Raphael Mazelier 
 Objet : Re: [FRnOG] [MISC] RE: Outils cool, 
qu'utilisez-vous ? 
Je pense que ton patch pourrait intéresser pas mal de monde ici, moi y compris: 
il est vrai qu'observium est un peu bourrin sur les requêtes snmp (notamment 
sur le discovery de l'état des sessions BGP, par exemple, lorsqu'elles sont 
nombreuses)


Le 23 mai 2018 23:04:51 GMT+02:00, Raphael Mazelier  a écrit 
:
>On 23/05/2018 17:26, Michel Py wrote:
>
>> Ah c'est donc çà qui se passe. Je confirme, avec certains matos çà
>plante. En général sur Cisco çà se passe bien, mais j'ai quelques
>antiquités qui passent à 100% CPU.
>>  >
>>> David Ponzone a écrit  :
>>> Oui, le produit est automagique, mais ne pas pouvoir restreindre le
>poller à ne prendre
>>> que l’essentiel a un arrière-goût de "société de consommation"
>désagréable.
>> 
>
>Bon puisque je suis lancé sur Observium/LibreNMS. Donc on peut 
>désactiver quelques MIBs pour rendre cela moins pire.
>
>Maintenant le fond du problème c'est que le poller d'observium est 
>complètement naif pour dire les choses gentiment.
>Basiquement il fait pour chaque device des gros snmpbulkwalk de quasi 
>toutes la MIB à chaque fois. Le seul parallélisme étant réalise au 
>niveau host.
>
>L'ennui c'est que les devices n'ont pas été prévu pour ça (surtout
>quand 
>on a des gros stacks avec genre +1000ports). Il faudrait que je
>retrouve 
>le papier de juniper qui expliquait clairement qu'il ne fallait pas 
>faire ça mais faire des snmpget ciblé. OK on peut se dire que les 
>constructeurs ont tord mais ce n'est pas très constructif. Surtout cela
>
>ne sert globalement à rien de tout reparser (un port va t'il changer de
>
>type à tous les polls ?).
>
>Un poller plus intelligent (par exemple celui de cacti/spine) sépare
>les 
>choses en deux :
>- un poll de découverte des interfaces ou autres (et il le cache), poll
>
>occasionnel, à coup de bulkwalk ciblé.
>- un poll régulier à coup de get ciblé sur les oids précis de ce que 
>l'on a autodécouvert.
>Cerise sur le gateau on peut // les get sur l'ensemble des oids/devices
>
>que l'on avait découvert ce qui va bcp plus vite au final.
>
>C'est plus au moins ce que j'avais patché à l'arrache dans observium ce
>
>qui me permettait de poller mes stacks d'EX3300 sans tout arracher le 
>tout dans un temps raisonnable.
>
>Il faudrait que je retrouve si ça intéresse du monde.
>
>Reconnaissons toutefois qu'Observium est un bon outil qui permet en 3 
>clicks de superviser son matos réseaux. La gui est très joli, il faut 
>juste pas regarder sous le capot :)
>
>
>
>--
>Raphael Mazelier
>
>
>---
>Liste de diffusion du FRnOG
>http://www.frnog.org/

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

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

RE: [FRnOG] [TECH] Le réseau chauffe ou pas ?

2020-03-18 Par sujet sbu123fr 
X 3 chez nous 60k usersSbuEnvoyé de mon Samsung Galaxy S10e Orange
 Message d'origine De : Stephane Bortzmeyer  
Date : 18/03/2020  10:04  (GMT+01:00) À : frnog-t...@frnog.org Objet : [FRnOG] 
[TECH] Le réseau chauffe ou pas ? Zayo voit une augmentation du trafic sur 
certains peerings. Par 
contre,c'est calme au 
France-IXEt chez 
vous ?---Liste de diffusion du 
FRnOGhttp://www.frnog.org/
---
Liste de diffusion du FRnOG
http://www.frnog.org/