Re: [FRnOG] [TECH] Packetshaper

2019-04-19 Par sujet jameboulie 
En terme de REX, vu le prix du Mb de nos jours et le nombre de cable 
sous marin qui poussent partout, ce type de matos complexe à gérer, 
n'est plus à la page, pour plusieurs raisons:


* appliance propriétaire assez cher (même si virtualisé).

* license tous les ans si souscription support (upgrade qui peut planter 
tout ton réseau quand ca ne se passe pas bien)


* quand tu as un problème, support pas réactif (via skype)

oui, trouver l'opérateur au meilleur prix, pour augmenter sa BP est LA 
solution à ton problème et virer ce genre de matos (packeteer, allot, 
sandvine etc...).


Le 19/04/2019 à 22:39, Radu-Adrian Feurdean a écrit :

On Fri, Apr 19, 2019, at 16:45, Roderick PAUL wrote:

de QOS de meme gamme de 200Mb à 2Gb environ.
Auriez vous des expériences de solution alternatives a ce jour ?

Etant le vendredi, je tente :
1. Enlever le "boitier QoS" et mettre a la place - RIEN DU TOUT
2. Augmenter la taille du tuyau.

En effet c'est un reponse pas seulement de vendredi.


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



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

Re: [FRnOG] [TECH] Packetshaper

2019-04-19 Par sujet Radu-Adrian Feurdean 
On Fri, Apr 19, 2019, at 16:45, Roderick PAUL wrote:
> de QOS de meme gamme de 200Mb à 2Gb environ.
> Auriez vous des expériences de solution alternatives a ce jour ?

Etant le vendredi, je tente :
1. Enlever le "boitier QoS" et mettre a la place - RIEN DU TOUT
2. Augmenter la taille du tuyau.

En effet c'est un reponse pas seulement de vendredi.


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

[FRnOG] [TECH] Détection et correction des erreurs was : n x 10G sur 80 km de FON ...

2019-04-19 Par sujet Michel Py 
Petit historique pour les jeunes :
La détection d'erreurs, çà a commence avec le bit de parité.

Pour les liens série : parité ou pas. 7 ou 8 bits de données, 0 ou 1 bit de 
parité. C'est une simple somme de contrôle.
Il n'y a rien à faire en cas d'erreur : on ne peut pas savoir lequel des bits a 
une erreur, seulement qu'on a une erreur.

Pour la mémoire : similaire. Sans parité : 8 bits. Avec parité : 9 bits.
Si erreur : NMI, BSOD.

Un peu plus évolué, la mémoire ECC : 8 bits de données, 3 de parité.
Cette mémoire peut corriger 1 bit d'erreur.
But : non pas de corriger les erreurs en permanence, mais de faire savoir à 
l'admin que la mémoire est en train de mourir, çà fait donc gagner un peu de 
temps en laissant le système fonctionner mais le seul remède c'est de changer 
la mémoire défectueuse. Les admins qui ignorent les corrections ECC vont 
bientôt se retrouver dans le même cas d'une erreur de parité : plus qu'un bit 
d'erreur, BSOD.

Un peu plus tard, le RAID5. Même idée, plus de bits que les données à stocker, 
un disque de plus qu'il est nécessaire. Si un disque dur meurt, remplacer le 
disque dur. Là encore, la détection et la correction de l'erreur ne sont qu'un 
moyen de gagner du temps pour résoudre le défaut. Le RAID avec un disque en 
panne continue à marcher, mais si on ne remplace pas rapidement le disque et 
qu'on ne reconstruit pas les données, le jour ou un second disque meurt on a 
tout perdu.

Et maintenant, FEC. La même idée : on transmet plus de bits que nécessaire, si 
le nombre de bits en erreur est inférieur à ce que permet le système, on peut 
corriger la trame.

Pourquoi j'en ai pas besoin :
- Si c'est de la voix ou de la vidéo en UDP, et que j'ai 1E-08 de perte, je 
m'en fous.
- Si c'est des données TCP et que j'ai 1E-08 de retransmissions, je m'en fous.

En plus, FEC ce n'est pas transparent en terme de latence. Pourquoi :
- On transmet plus de bits que nécessaire.
- A part la transmission, il faut analyser à l'arrivée si l'information est 
cohérente, ce qui prend du temps.
Au contraire d'un système RAID, il n'y a pas de signe clair que le disque ou le 
secteur est mort. Les bits arrivent, est-ce qu'il y a une erreur dedans ou non 
il faut exécuter l'algorithme de contrôle pour savoir, ce qui prend du temps.
- Si il y a une erreur, c'est encore pire : l'algorithme de reconstruction est 
parfois plus compliqué que l'algorithme de détection, donc il va y avoir une 
forte latence avant que la trame corrigée arrive à destination.

Faut pas oublier que pendant que tout ce business de FEC prend place, les 
paquets continuent à arriver à n x 10G, ou pire.

FEC n'enlève pas les erreur. Cà essaie de donner l'illusion qu'il n'y en a pas, 
ce qui est une solution d'attente à court-terme. Et contrairement à la mémoire 
ou au disque dur en panne, les données ne sont pas perdues : elle peuvent être 
retransmises.

Le FEC sur la ligne, c'est pas là ou j'en ai besoin.

Michel.

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

RE: [FRnOG] [TECH] n x 10G sur 80 km de FON ...

2019-04-19 Par sujet Michel Py 
> Michel Hostettler a écrit :
> La liaison peut ne pas être pourrie. Le FEC corrige les dispersions 
> chromatique et PMD
> imparables pour des débits supérieurs à 10 Gbit/s, puis les effets non 
> linéaires en WDM.

La FEC corrige n'importe quel type d'erreur ? c'est une sorte d'ECC avec plus 
de bits.
Entièrement mathématique.
Je compare çà on peu avec QOS : on essaie de rajouter de la bande passante là 
ou elle n'existe pas; la fenêtre d'utilisation est très étroite.

> En deçà de 10 Gbit/s, il peut ne pas être utilisé.

Justement, la demande originale de Charles c'était du 10 G.

C'est pour çà que je ne suis pas trop chaud pour une optique unique à 200 G : 
on essaie pousser des limites qui ne sont pas encore trop maitrisées, alors que 
le WDM 10G c'est devenu un produit banalisé.
L'environnement de prod, par nature, a tendance à préférer les solutions 
éprouvées qui ont passé le test du marché.

Michel.

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

Re: [FRnOG] [TECH] n x 10G sur 80 km de FON ...

2019-04-19 Par sujet Michel Hostettler 


La liaison peut ne pas être pourrie. Le FEC corrige les dispersions chromatique 
et PMD imparables pour des débits supérieurs à 10 Gbit/s, puis les effets non 
linéaires en WDM. En deçà de 10 Gbit/s, il peut ne pas être utilisé.

Bonnes Pâques, Michel 

- Mail original -
De: "Michel Py" 
À: "laurent guiraud" 
Cc: "Alexis Lameire" , "Charles ENEL-REHEL" 
, "frnog" 
Envoyé: Vendredi 19 Avril 2019 18:30:17
Objet: RE: [FRnOG] [TECH] n x 10G sur 80 km de FON ...

> laurent guiraud a écrit :
> Juste pour info, renseignement pris auprès de FS, leurs équipements WDM ne 
> supportent pas
> le FEC en ligne. Eh oui ça coûte un peu d'argent de développer son propre FEC 
> ou d'acheter
> une licence pour FEC standard... Donc pour du WDM amplifié, à moins d'avoir 
> une tolérance
> toute particulière pour les pertes UDP/retranscriptions TCP, mieux vaut aller 
> voir ailleurs ..

FEC c'est l'emplâtre sur une jambe de bois, çà me dérange pas de ne pas 
l'avoir. C'est des devinettes, on essaie de reconstruire le paquet avec un 
algorithme plus ou moins valable, je préfère retransmettre. Si le taux de 
retransmission devient trop élevé, c'est que le lien est trop pourri pour être 
utilisé.

Quand l'infrastructure coute une fortune (genre : liaison transatlantique à une 
vitesse supérieure de celle de la lumière) çà justifie l'investissement, mais 
pour le commun des mortels pas.

Michel.


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


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

RE: [FRnOG] [TECH] n x 10G sur 80 km de FON ...

2019-04-19 Par sujet Michel Py 
> laurent guiraud a écrit :
> Juste pour info, renseignement pris auprès de FS, leurs équipements WDM ne 
> supportent pas
> le FEC en ligne. Eh oui ça coûte un peu d'argent de développer son propre FEC 
> ou d'acheter
> une licence pour FEC standard... Donc pour du WDM amplifié, à moins d'avoir 
> une tolérance
> toute particulière pour les pertes UDP/retranscriptions TCP, mieux vaut aller 
> voir ailleurs ..

FEC c'est l'emplâtre sur une jambe de bois, çà me dérange pas de ne pas 
l'avoir. C'est des devinettes, on essaie de reconstruire le paquet avec un 
algorithme plus ou moins valable, je préfère retransmettre. Si le taux de 
retransmission devient trop élevé, c'est que le lien est trop pourri pour être 
utilisé.

Quand l'infrastructure coute une fortune (genre : liaison transatlantique à une 
vitesse supérieure de celle de la lumière) çà justifie l'investissement, mais 
pour le commun des mortels pas.

Michel.


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

Re: [FRnOG] [TECH] Packetshaper

2019-04-19 Par sujet Jérome Fretigny 
Riverbed ?

Le ven. 19 avr. 2019 à 16:45, Roderick PAUL  a
écrit :

> Bonjour la liste,
>
> Nous avons utilisé par le passé le produit Packetshaper anciennement
> packeteer, puis bluecoat et aujourd’hui symantec.
> A ce jour nous avons des projets de plus grande envergure sur des gestions
> de QOS de meme gamme de 200Mb à 2Gb environ.
> Auriez vous des expériences de solution alternatives a ce jour ?
> L’objet est idéalement de n’avoir qu’un seul boitier en DC en amont de nos
> services et de ne pas avoir besoin d’un boitier coté Presta ( Datacenter )
> et un boitier coté client notamment pour les nomades.
> L’idée est par ailleurs de limiter la congestion de nos transits donnant
> accès a nos services via des priorisations app niveau 7.
> A l’époque il y avait riverbed mais avec l’avenement du SD WAN, peut etre y
> a-t-il d’autres acteurs efficaces .
> La discussion avec Symantec devient complexe et commence sérieusement à
> m’agacer , je me dis donc pourquoi pas tester d’autres technos.
> Le produit packetshaper nous semblait adapté à nos projets mais hors de
> prix et les solutions de POC sont limités.
>
> Merci pour vos retours avisés.
>
> Bonne journée à tous
> Paul
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [MISC] Latence Transatlantique

2019-04-19 Par sujet Michel Py 
> Stephane Bortzmeyer a écrit :
> Il suffit de ne pas transporter d'information. C'est déjà le cas de 90 %
> des courriers, 95 % des pages Web et 99 % des communiqués de presse.

Merci pour ce sourire.

> Radu-Adrian Feurdean écrit :
> La vitese de phase mais pas celle de groupe (qui est la seule qui permet la
> transmission). Pour transmettre quoi que ce soit, la limite reste c.

Pas de prix Nobel en vue, si je comprends bien ?

Michel.


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

Re: [FRnOG] [TECH] Packetshaper

2019-04-19 Par sujet Christophe Pujol 
Bonjour,

Dans l'immediat, Ça me fait penser à https://dynfi.com/fr  et à pfsense.

À bientôt,
Christophe.

Le ven. 19 avr. 2019 à 16:45, Roderick PAUL  a
écrit :

> Bonjour la liste,
>
> Nous avons utilisé par le passé le produit Packetshaper anciennement
> packeteer, puis bluecoat et aujourd’hui symantec.
> A ce jour nous avons des projets de plus grande envergure sur des gestions
> de QOS de meme gamme de 200Mb à 2Gb environ.
> Auriez vous des expériences de solution alternatives a ce jour ?
> L’objet est idéalement de n’avoir qu’un seul boitier en DC en amont de nos
> services et de ne pas avoir besoin d’un boitier coté Presta ( Datacenter )
> et un boitier coté client notamment pour les nomades.
> L’idée est par ailleurs de limiter la congestion de nos transits donnant
> accès a nos services via des priorisations app niveau 7.
> A l’époque il y avait riverbed mais avec l’avenement du SD WAN, peut etre y
> a-t-il d’autres acteurs efficaces .
> La discussion avec Symantec devient complexe et commence sérieusement à
> m’agacer , je me dis donc pourquoi pas tester d’autres technos.
> Le produit packetshaper nous semblait adapté à nos projets mais hors de
> prix et les solutions de POC sont limités.
>
> Merci pour vos retours avisés.
>
> Bonne journée à tous
> Paul
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Christophe PUJOL

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

[FRnOG] [TECH] Packetshaper

2019-04-19 Par sujet Roderick PAUL 
Bonjour la liste,

Nous avons utilisé par le passé le produit Packetshaper anciennement
packeteer, puis bluecoat et aujourd’hui symantec.
A ce jour nous avons des projets de plus grande envergure sur des gestions
de QOS de meme gamme de 200Mb à 2Gb environ.
Auriez vous des expériences de solution alternatives a ce jour ?
L’objet est idéalement de n’avoir qu’un seul boitier en DC en amont de nos
services et de ne pas avoir besoin d’un boitier coté Presta ( Datacenter )
et un boitier coté client notamment pour les nomades.
L’idée est par ailleurs de limiter la congestion de nos transits donnant
accès a nos services via des priorisations app niveau 7.
A l’époque il y avait riverbed mais avec l’avenement du SD WAN, peut etre y
a-t-il d’autres acteurs efficaces .
La discussion avec Symantec devient complexe et commence sérieusement à
m’agacer , je me dis donc pourquoi pas tester d’autres technos.
Le produit packetshaper nous semblait adapté à nos projets mais hors de
prix et les solutions de POC sont limités.

Merci pour vos retours avisés.

Bonne journée à tous
Paul

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

Re: [FRnOG] Re: [TECH] Latence Transatlantique

2019-04-19 Par sujet Michel Hostettler 


Ben !... c'est ce que je viens de voir.

L'or aurait un indice de réfraction de 0,47, et serait transparent aux rayons X 
(< 10 nm).

Je ne suis pas plus riche... si ! dans ma tête de piaf.
Michel

- Mail original -
De: "Thierry Chich" 
À: "frnog" 
Envoyé: Vendredi 19 Avril 2019 09:28:57
Objet: Re: [FRnOG] Re: [TECH] Latence Transatlantique

L'or pour les rayons X, ai-je cru lire.

Le 18/04/2019 à 15:28, Michel Hostettler a écrit :
> Pour certains matériaux  dont je ne me souviens plus du nom, l'indice de 
> réfraction est inférieur à l'unité.
> La vitesse de phase est donc supérieure à celle de la lumière.
> Michel
>
> - Mail original -
> De: "stef" 
> À: "frnog" 
> Envoyé: Jeudi 18 Avril 2019 15:14:21
> Objet: Re: [FRnOG] Re: [TECH] Latence Transatlantique
>
>> Nous savons découper le temps, l’échantillonner, sans perdre d’information. 
>> Il ne me reste plus qu’à trouver un ou deux paramètres dans mon équation 
>> afin de réussir à l’immobiliser… assurément,
> Le jour où quelqu'un arrive à figer le temps ou à dépasser la vitesse de
> la lumière, nous aurons trouvé notre nouvel Einstein... (il serait temps
> d'ailleurs pour garder le moral dans notre coin de galaxie).
>
>> dites-vous. Pourtant… le silence après Mozart n’est-il pas encore du Mozart ?
> Certainement, plus sûrement avec du Wagner :>
>
>> Il suffit de ne pas transporter d'information. C'est déjà le cas de
>> 90 % des courriers, 95 % des pages Web et 99 % des communiqués de
>> presse.
> 99% des communiqué de presse me semblent encore optimiste...
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
-- 
 

Thierry CHICH

Adjoint RSSI

SSI : Sécurité des Systèmes d'Information
PRH : Pôle réseaux et hébergement

DSI : Direction des Systèmes d'Information

04 73 99 30 54
thierry.chich@ac‑clermont.fr  ‑ 
dsi‑rese...@ac-clermont.fr 

RECTORAT ‑ 3 avenue Vercingétorix - 63033 Clermont-Ferrand Cedex ‑ Site 
internet 


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


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

Re: [FRnOG] Re: [TECH] Latence Transatlantique

2019-04-19 Par sujet Michel Hostettler 
Radu, je suis fier de vous et de votre remarque.

La transmission d'une information résulte en une bande passante et, 
effectivement, il est nécessaire de se référer à la vitesse de groupe.

Rien n'est simple, Michel


- Mail original -
De: "Radu-Adrian Feurdean" 
À: "frnog" 
Envoyé: Vendredi 19 Avril 2019 10:43:24
Objet: Re: [FRnOG] Re: [TECH] Latence Transatlantique

On Thu, Apr 18, 2019, at 15:29, Michel Hostettler wrote:
> 
> Pour certains matériaux  dont je ne me souviens plus du nom, l'indice 
> de réfraction est inférieur à l'unité.
> La vitesse de phase est donc supérieure à celle de la lumière.

La vitese de phase mais pas celle de groupe (qui est la seule qui permet la 
transmission). Pour transmettre quoi que ce soit, la limite reste c.

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


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

Re: [FRnOG] [TECH] n x 10G sur 80 km de FON ...

2019-04-19 Par sujet laurent guiraud 
Juste pour info, renseignement pris auprès de FS, leurs équipements WDM ne
supportent pas le FEC en ligne.
Eh oui ça coûte un peu d'argent de développer son propre FEC ou d'acheter
une licence pour FEC standard...
Donc pour du WDM amplifié, à moins d'avoir une tolérance toute particulière
pour les pertes UDP/retranscriptions TCP, mieux vaut aller voir ailleurs ..


Le sam. 13 avr. 2019 à 03:50, Michel Py 
a écrit :

> > Alexis Lameire a écrit :
> > bon petit calcul au doigt mouillé
>
> Mon pifomètre aiguisé me dit la même chose : il manque 9dB ou 30 km.
>
> Charles, si tu étais à 50 km avec des optiques 80 km çà pourrait passer en
> passif, mais à 80 km il te faut impérativement une solution active.
> La dernière fois que j'ai regardé le budget pour ce genre de matos était
> astronomique.
> Du genre, n x 2 optiques SFP+ 10G 80 km colorées c'était une goutte d'eau
> dans la mer.
>
> Le CWDM c'est pas forcément moins cher que le DWDM.
>
> Regarde çà : https://www.fs.com/products/73807.html
>
> $12.000 (pour jeu de 2) pour ce genre de chose c'est relativement bon
> marché (pas sur que çà comprenne tous les modules pour 10x40G, quand ils
> disent "up to" çà veut souvent dire rincette supplémentaire).
>
> Bon et puis ils mesurent le km à 0.25 dB ce qui me parait pas prudent,
> mais çà devrait passer sur 80 sans problème.
>
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] Re: [TECH] Latence Transatlantique

2019-04-19 Par sujet Radu-Adrian Feurdean 



On Thu, Apr 18, 2019, at 15:29, Michel Hostettler wrote:
> 
> Pour certains matériaux  dont je ne me souviens plus du nom, l'indice 
> de réfraction est inférieur à l'unité.
> La vitesse de phase est donc supérieure à celle de la lumière.

La vitese de phase mais pas celle de groupe (qui est la seule qui permet la 
transmission). Pour transmettre quoi que ce soit, la limite reste c.

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

Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-19 Par sujet Alexandre DERUMIER 
>>Merci Alexandre je vais effectivement vérifier je ne vois pas d'autre raison 
>>au drop.

Une autre raison possible, c'est si jamais le buffer de l'asic du switch sature.
apres je ne connais pas du tout la gamme ex3400, ni le traffic que tu envoi.

mais j'ai déjà eu le cas sur des vieux cisco 2960, où il y avait un buffer 
partagé pour 4 ports 1gbit,
et en vrai on pouvais pas tirer 4x1gbit sans drop.
(mais ca se voit dans les counters du switch dans ce cas)



- Mail original -
De: "Kevin Thiou" 
À: "aderumier" 
Cc: "frnog-tech" 
Envoyé: Vendredi 19 Avril 2019 10:00:57
Objet: Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

Moi no plus je ne touche pas la MTU. 
Merci Alexandre je vais effectivement vérifier je ne vois pas d'autre raison au 
drop. 

Le jeu. 18 avr. 2019 à 20:09, Alexandre DERUMIER < [ mailto:aderum...@odiso.com 
| aderum...@odiso.com ] > a écrit : 


>>Quelles pourrait être la raison de leur disparition ? Si le paquet est trop 
>>gros, le switch va en faire plusieurs petits non ? 

Ca depend si le protocol/client spécifie le "do not fragment bit" (DF). 

dans ce cas, ca drop. 

(par exemple, avec https c'est le cas généralement, avec que http non. ) 



- Mail original - 
De: "Kevin Thiou" < [ mailto:kevinth...@gmail.com | kevinth...@gmail.com ] > 
Cc: "frnog-tech" < [ mailto:frnog-t...@frnog.org | frnog-t...@frnog.org ] > 
Envoyé: Jeudi 18 Avril 2019 10:31:35 
Objet: Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper 
ex3400 

J'ai continué à chercher, mais je me pose une question sur la disparition 
de mes paquets. 

Quelles pourrait être la raison de leur disparition ? Si le paquet est trop 
gros, le switch va en faire plusieurs petits non ? 

Le mer. 17 avr. 2019 à 10:47, Kevin Thiou < [ mailto:kevinth...@gmail.com | 
kevinth...@gmail.com ] > a écrit : 

> Effectivement il y a quelque chose qui joue avec ma MTU. 
> Sur la pieuvre, quelque soit la MTU que je configure, je me retrouve avec 
> une MTU à 1574 derrière le Pfsense (je soupçonne le scrubbing). 
> 
> Du coup je vais sortir le pfsense de la chaîne pour voir si c'est mieux. 
> 
> Merci de vos réponses. 
> 
> Le mar. 16 avr. 2019 à 17:00, Kevin Thiou < [ mailto:kevinth...@gmail.com | 
> kevinth...@gmail.com ] > a écrit : 
> 
>> C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de rapport 
>> à la borne vu que les paquets sont bien envoyés en voix ou en vidéo. 
>> 
>> Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou < [ 
>> mailto:m...@kodekh-telecom.fr | m...@kodekh-telecom.fr ] > a 
>> écrit : 
>> 
>>> Bonsoir 
>>> 
>>> Peux-tu donner les caractéristiques de la pieuvre ? 
>>> 
>>> Envoyé de mon iPhone 
>>> 
>>> Kamel 
>>> 
>>> > Le 16 avr. 2019 à 16:09, Kevin Thiou < [ mailto:kevinth...@gmail.com | 
>>> > kevinth...@gmail.com ] > a écrit : 
>>> > 
>>> > Bonjour, 
>>> > 
>>> > j'ai un problème auquel je ne trouve pas de solution. 
>>> > 
>>> > Je test une nouvelle pieuvre qui a des capacités vidéo. 
>>> > 
>>> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo l'appel 
>>> > n'aboutie pas. 
>>> > 
>>> > J'ai fais des traces pour voir où cela coince. J'arrive à la 
>>> conclusion que 
>>> > les paquets INVITE sont perdus entre un esxi et l'interface du switch 
>>> où 
>>> > celui-ci est connecté. 
>>> > 
>>> > Ca me parait étrange, donc une de mes traces doit être bancale. 
>>> > 
>>> > Sur l'esxi je fais : 
>>> > 
>>> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture* 
>>> > The trace session is enabled. 
>>> > The session filter IP(src or dst) address is 172.19.136.58 
>>> > The session filter VLAN is 515 
>>> > The output file is capture 
>>> > No server port specifed, select 48586 as the port 
>>> > Local CID 2 
>>> > Listen on port 48586 
>>> > Accept...Vsock connection from port 1033 cid 2 
>>> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread 
>>> > failedDestroying session 9 
>>> > 
>>> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options 
>>> analyzer 
>>> > : 
>>> > *set forwarding-options analyzer packet_capture input ingress interface 
>>> > ge-0/0/0.0* 
>>> > *set forwarding-options analyzer packet_capture input ingress interface 
>>> > ge-1/0/0.0* 
>>> > *set forwarding-options analyzer packet_capture input egress interface 
>>> > ge-1/0/0.0* 
>>> > *set forwarding-options analyzer packet_capture input egress interface 
>>> > ge-0/0/0.0* 
>>> > *set forwarding-options analyzer packet_capture output interface 
>>> > ge-0/0/47.0* 
>>> > 
>>> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump : 
>>> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58* 
>>> > 
>>> > Je me retrouve avec rien dans la capture. 
>>> > 
>>> > Quelqu'un aurait il une idée ? 
>>> > 
>>> > --- 
>>> > Liste de diffusion du FRnOG 
>>> > [ http://www.frnog.org/ | http://www.frnog.org/ ] 
>>> 
>>> 

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

Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper ex3400

2019-04-19 Par sujet Kevin Thiou 
Moi no plus je ne touche pas la MTU.

Merci Alexandre je vais effectivement vérifier je ne vois pas d'autre
raison au drop.

Le jeu. 18 avr. 2019 à 20:09, Alexandre DERUMIER  a
écrit :

> >>Quelles pourrait être la raison de leur disparition ? Si le paquet est
> trop
> >>gros, le switch va en faire plusieurs petits non ?
>
> Ca depend si le protocol/client spécifie le "do not fragment bit"  (DF).
>
> dans ce cas, ca drop.
>
> (par exemple, avec https c'est le cas généralement, avec que http non. )
>
>
>
> - Mail original -
> De: "Kevin Thiou" 
> Cc: "frnog-tech" 
> Envoyé: Jeudi 18 Avril 2019 10:31:35
> Objet: Re: [FRnOG] [TECH] Perte de paquet entre esxi et le switch juniper
> ex3400
>
> J'ai continué à chercher, mais je me pose une question sur la disparition
> de mes paquets.
>
> Quelles pourrait être la raison de leur disparition ? Si le paquet est
> trop
> gros, le switch va en faire plusieurs petits non ?
>
> Le mer. 17 avr. 2019 à 10:47, Kevin Thiou  a écrit
> :
>
> > Effectivement il y a quelque chose qui joue avec ma MTU.
> > Sur la pieuvre, quelque soit la MTU que je configure, je me retrouve
> avec
> > une MTU à 1574 derrière le Pfsense (je soupçonne le scrubbing).
> >
> > Du coup je vais sortir le pfsense de la chaîne pour voir si c'est mieux.
> >
> > Merci de vos réponses.
> >
> > Le mar. 16 avr. 2019 à 17:00, Kevin Thiou  a
> écrit :
> >
> >> C'est une Polycom RealPresence Trio 8500, mais je ne vois pas de
> rapport
> >> à la borne vu que les paquets sont bien envoyés en voix ou en vidéo.
> >>
> >> Le mar. 16 avr. 2019 à 16:26, Kamel Moudachirou 
> a
> >> écrit :
> >>
> >>> Bonsoir
> >>>
> >>> Peux-tu donner les caractéristiques de la pieuvre ?
> >>>
> >>> Envoyé de mon iPhone
> >>>
> >>> Kamel
> >>>
> >>> > Le 16 avr. 2019 à 16:09, Kevin Thiou  a écrit
> :
> >>> >
> >>> > Bonjour,
> >>> >
> >>> > j'ai un problème auquel je ne trouve pas de solution.
> >>> >
> >>> > Je test une nouvelle pieuvre qui a des capacités vidéo.
> >>> >
> >>> > Lors d'un appel voix, tout fonctionne. Lors d'un test en vidéo
> l'appel
> >>> > n'aboutie pas.
> >>> >
> >>> > J'ai fais des traces pour voir où cela coince. J'arrive à la
> >>> conclusion que
> >>> > les paquets INVITE sont perdus entre un esxi et l'interface du
> switch
> >>> où
> >>> > celui-ci est connecté.
> >>> >
> >>> > Ca me parait étrange, donc une de mes traces doit être bancale.
> >>> >
> >>> > Sur l'esxi je fais :
> >>> >
> >>> > *pktcap-uw --trace --ip 172.19.136.58 --vlan 515 -o capture*
> >>> > The trace session is enabled.
> >>> > The session filter IP(src or dst) address is 172.19.136.58
> >>> > The session filter VLAN is 515
> >>> > The output file is capture
> >>> > No server port specifed, select 48586 as the port
> >>> > Local CID 2
> >>> > Listen on port 48586
> >>> > Accept...Vsock connection from port 1033 cid 2
> >>> > *Dump: 5*, broken : 0, drop: 0, file err: 0Join with dump thread
> >>> > failedDestroying session 9
> >>> >
> >>> > Sur le switch c'est un ex3400 j'ai configuré un forwarding-options
> >>> analyzer
> >>> > :
> >>> > *set forwarding-options analyzer packet_capture input ingress
> interface
> >>> > ge-0/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input ingress
> interface
> >>> > ge-1/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input egress
> interface
> >>> > ge-1/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture input egress
> interface
> >>> > ge-0/0/0.0*
> >>> > *set forwarding-options analyzer packet_capture output interface
> >>> > ge-0/0/47.0*
> >>> >
> >>> > qui envoie le trafic vers un serveur qui fait tourner un tcpdump :
> >>> > *sudo tcpdump -n -i enp3s0f1 host 172.19.136.58*
> >>> >
> >>> > Je me retrouve avec rien dans la capture.
> >>> >
> >>> > Quelqu'un aurait il une idée ?
> >>> >
> >>> > ---
> >>> > 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] Re: [TECH] Latence Transatlantique

2019-04-19 Par sujet Thierry Chich 

L'or pour les rayons X, ai-je cru lire.

Le 18/04/2019 à 15:28, Michel Hostettler a écrit :

Pour certains matériaux  dont je ne me souviens plus du nom, l'indice de 
réfraction est inférieur à l'unité.
La vitesse de phase est donc supérieure à celle de la lumière.
Michel

- Mail original -
De: "stef" 
À: "frnog" 
Envoyé: Jeudi 18 Avril 2019 15:14:21
Objet: Re: [FRnOG] Re: [TECH] Latence Transatlantique


Nous savons découper le temps, l’échantillonner, sans perdre d’information. Il 
ne me reste plus qu’à trouver un ou deux paramètres dans mon équation afin de 
réussir à l’immobiliser… assurément,

Le jour où quelqu'un arrive à figer le temps ou à dépasser la vitesse de
la lumière, nous aurons trouvé notre nouvel Einstein... (il serait temps
d'ailleurs pour garder le moral dans notre coin de galaxie).


dites-vous. Pourtant… le silence après Mozart n’est-il pas encore du Mozart ?

Certainement, plus sûrement avec du Wagner :>


Il suffit de ne pas transporter d'information. C'est déjà le cas de
90 % des courriers, 95 % des pages Web et 99 % des communiqués de
presse.

99% des communiqué de presse me semblent encore optimiste...


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


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

--
   

Thierry CHICH

Adjoint RSSI

SSI : Sécurité des Systèmes d'Information
PRH : Pôle réseaux et hébergement

DSI : Direction des Systèmes d'Information

04 73 99 30 54
thierry.chich@ac‑clermont.fr  ‑ 
dsi‑rese...@ac-clermont.fr 


RECTORAT ‑ 3 avenue Vercingétorix - 63033 Clermont-Ferrand Cedex ‑ Site 
internet 



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