Re: [FRnOG] [TECH] Transparence aux VLANs sur offres CELAN/CE2O/DSLE ?
Salut Michel! Ici Frame Relay a disparu de la circulation, ca n'a pas vraiment pris à part chez les carriers internationaux genre WorldCom/KPN/BT etc... Le pseudo wire, c'est tombé dans les oubliettes en 2007/2008 il me semble; C'etait les bonnes vielles transfix qui servaient a fournir du last mile là ou il n'y avait pas de possibilité de faire du DSL. Ceci dit c'était bien pratique et stable là ou il n'y avait rien d'autre... Ces offres de références sont constuites sur le réseau de transport MPLS Orange. Il y a peut etre encore quelques endroits ou il passe par un bout de réseau ATM dasn des coins paumés mais en théorie toute l'infra est 100% MPLS. Leur objectif est d'unifier tous les réseaux de toutes les filiales du groupe. Le patron d'OWF m'avait dit l'an dernier qu'ils étaient contraint de muter vers cette solution car les volumes de données traitées augmentait chaque années d'environs 50%, et que c'était la seule façon pour eux de gérer ces évolutions simplement et dans des coûts acceptables. Seb. Le 09/11/2014 08:23, Michel Py a écrit : David Ponzone a écrit : Oui, le CELAN supporte le QinQ. Ca serait intéressant de savoir ce qu'il y a derrière. C'est courant chez nous aussi, avec Comcast on peut commencer à jouer avec 200Mbps (délivré sur GigE, naturellement). A part la MTU et la latence, c'est pseudo-wire. Tu mets ton switch avec tes VLANs comme si c'était un câble crossover, et çà marche pratiquement pareil. D'après ce que je comprends, mais info de seconde main à prendre avec des pincettes, ca reste MPLS / VPLS. Le bon vieux frame-relay n'est pas mort, il a changé de nom. Michel. P.S: Pour ceux qui ne sont jamais allés à un IETF a Minneapolis, je me rappelle de mon premier. A l'aéroport, il y a(vait) un signe de taille importante, avec une flèche de direction, qui li(sai)t MPLS -. Tous les bleubites en parlaient (au lieu du Mall of America); t'as vu le signe à l'aéroport ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Transparence aux VLANs sur offres CELAN/CE2O/DSLE ?
Merci pour vos réponses! Le reste de l'ODR DSL est hors scope. Donc tu exclus DSLE/CE2O (avec livraison sur porte GEth) pour faire la même chose? Sur les DSP (Axione, Covage, Altitude Infra...) vous savez si c’est systématiquement supporté? Autre question complémentaire, sur le set-up central: Si on cherche à interconnecter en Layer2 plusieurs sites, livrés sur des portes différentes toutes sur un même équipement, quelle est la techno la plus adaptée? Il faut une sorte de “virtual switch” : nous avons les virtual routers (mais layer 3, donc cela ne va pas) ou les VPLS qui sont un cran au dessus puisqu’ils reposent sur du MPLS et permettent cela si les portes sont réparties sur le réseau. Mais dans un cas simple ou tout arrive sur le même routeur, quel est le plus simple (Plutot sur Brocade, éventuellement sur Cisco) ? faut-il forcément passer sur un set up VPLS (qui demande à activer le MPLS ce qui n’a pas d’interet ici)? Alex Le 9 novembre 2014 07:59, Sebastien Lesimple slesim...@laposte.net a écrit : David a parfaitement raisons, CELAN permet ce genre de set-up sans aucuns soucis. En revanche, CEE ne permet que le VLAN de livraison et supprime tout marquage CoS et VLAN supplémentaire. Le reste de l'ODR DSL est hors scope. Le 09/11/2014 00:52, David Ponzone a écrit : Oui, le CELAN supporte le QinQ. Les STATS, chapitre 3.4, sont claires sur ce point. Je n’ai pas détecté d’anomalie côté MTU. Avec DF positionné, 1500 passe, 1501 ne passe pas, que cela soit sur le VLAN de livraison (pas de QinQ) ou sur un VLAN QinQ.. Le 8 nov. 2014 à 22:04, Alexandre Duprez alexandup...@gmail.com a écrit : Bonsoir, Sur les offres Orange CELAN (cuivre ou optique), CE2O et DSLE (Pour DSLE et CE2O je parle d’une livraison en GEth par Orange, et non pas directement en ATM), est-il possible d’après vous de transporter des VLAN? Et ainsi par exemple construire un Lan2Lan transparent aux Vlan (donc config en 802.1q à chaque extrémité), en connectant 2 circuits (ce qui demande évidement à avoir un équipement côté porte qui sache gérer cela). Est ce que, pour le trafic extrémitéporte, Orange “Stacke” bien les Vlan-ID en ajoutant le Vlan-ID de livraison, sans écraser un Vlan-ID qui aurait déjà été positionné? Est ce qu’il n’y a pas de limitation de MTU?... Je n'ai rien vu dans les Spécifications qui pourrait poser problème. Est ce que certains d’entre vous utilisent ces offres pour fournir ce type de service? Alex --- 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] Transparence aux VLANs sur offres CELAN/CE2O/DSLE ?
Tu veux pouvoir fournir une solution type multi sites pour un de tes clients en passant par plusieurs collectes de fournisseurs différents. (J'ai bon jusque là?) Pour faire ca tu penses marquer le trafic avec un VLAN dédié à ces différents accès. (Toujours Bon?) Tout ce que tu as a faire c'est gerer le marquage VLAN 802.1q sur des interfaces virtuelles dans tes routeurs gérant les Portes. C'est du VLAN Trunking vraiment pas de quoi se prendre le casque, c'est comme sur un switch tout con. Faire du MPLS, ouais bof, les routeurs ont assez de patate pour lire les trames à la volée aujourd’hui, c'est plus vraiment une question de vitesse. DSLE/CE2O ne permettent pas de faire ca (la collecte Completel non plus aux dernières news). Altitude, je n'ai plus de contacts, désolé. Axione, oui EVPL sur la fibre et du 802.1Q sur le cuivre (c'est du CELAN à la base). Covage, oui aussi. Le 09/11/2014 10:18, Alexandre Duprez a écrit : Merci pour vos réponses! Le reste de l'ODR DSL est hors scope. Donc tu exclus DSLE/CE2O (avec livraison sur porte GEth) pour faire la même chose? Sur les DSP (Axione, Covage, Altitude Infra...) vous savez si c’est systématiquement supporté? Autre question complémentaire, sur le set-up central: Si on cherche à interconnecter en Layer2 plusieurs sites, livrés sur des portes différentes toutes sur un même équipement, quelle est la techno la plus adaptée? Il faut une sorte de “virtual switch” : nous avons les virtual routers (mais layer 3, donc cela ne va pas) ou les VPLS qui sont un cran au dessus puisqu’ils reposent sur du MPLS et permettent cela si les portes sont réparties sur le réseau. Mais dans un cas simple ou tout arrive sur le même routeur, quel est le plus simple (Plutot sur Brocade, éventuellement sur Cisco) ? faut-il forcément passer sur un set up VPLS (qui demande à activer le MPLS ce qui n’a pas d’interet ici)? Alex Le 9 novembre 2014 07:59, Sebastien Lesimple slesim...@laposte.net a écrit : David a parfaitement raisons, CELAN permet ce genre de set-up sans aucuns soucis. En revanche, CEE ne permet que le VLAN de livraison et supprime tout marquage CoS et VLAN supplémentaire. Le reste de l'ODR DSL est hors scope. Le 09/11/2014 00:52, David Ponzone a écrit : Oui, le CELAN supporte le QinQ. Les STATS, chapitre 3.4, sont claires sur ce point. Je n’ai pas détecté d’anomalie côté MTU. Avec DF positionné, 1500 passe, 1501 ne passe pas, que cela soit sur le VLAN de livraison (pas de QinQ) ou sur un VLAN QinQ.. Le 8 nov. 2014 à 22:04, Alexandre Duprez alexandup...@gmail.com a écrit : Bonsoir, Sur les offres Orange CELAN (cuivre ou optique), CE2O et DSLE (Pour DSLE et CE2O je parle d’une livraison en GEth par Orange, et non pas directement en ATM), est-il possible d’après vous de transporter des VLAN? Et ainsi par exemple construire un Lan2Lan transparent aux Vlan (donc config en 802.1q à chaque extrémité), en connectant 2 circuits (ce qui demande évidement à avoir un équipement côté porte qui sache gérer cela). Est ce que, pour le trafic extrémitéporte, Orange “Stacke” bien les Vlan-ID en ajoutant le Vlan-ID de livraison, sans écraser un Vlan-ID qui aurait déjà été positionné? Est ce qu’il n’y a pas de limitation de MTU?... Je n'ai rien vu dans les Spécifications qui pourrait poser problème. Est ce que certains d’entre vous utilisent ces offres pour fournir ce type de service? Alex --- 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] Transparence aux VLANs sur offres CELAN/CE2O/DSLE ?
Tu veux pouvoir fournir une solution type multi sites pour un de tes clients en passant par plusieurs collectes de fournisseurs différents. (J'ai bon jusque là?) oui, tout bon. Pour faire ca tu penses marquer le trafic avec un VLAN dédié à ces différents accès. (Toujours Bon?) Là, je ne pense pas : Je laisse le client marquer son trafic (transparence aux vlan, il fait ce qu'il veut). L'opérateur ajoute un VlanID à la livraison sur la porte de collecte. Je vais te donner un exemple, ce sera plus simple: Site 1 livré sur porte1 par opérateur1, vlanID 1001 Site 2 livré sur porte1 par opérateur1, vlanID 1002 Site 3 livré sur porte2 par opérateur2, vlanID 1001 (l’opérateur choisissant parfois le vlan, je peux par hasard me retrouver avec le même vlan ID que celui qui m’a été livré sur la porte1 pour le site 1, j'ai pris cet exemple pour prendre un cas extrême). Côté sites, le client tagge en 802.1q avec les VlanID 2000, 2001, 1001... par exemple (j’ai mis 1001, car comme on lui offre un service transparent au vlan... le hasard peut faire que lui aussi utilise le même vlanID que l’opérateur ; le set up ne doit donc pas déprendre de ce qu'il utilise). Et donc moi je recois : - sur ma porte1 des paquets du site 1, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 - sur ma porte1 des paquets du site 2, avec les VlanID 2000, 2001 et 1001 + le VlanID 1002 - sur ma porte2 des paquets du site 3, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 Ce que je veux donc faire c’est supprimer les Vlan opérateurs (1001 et 1002), et switcher (layer2) tout cela. Comme ce client utilise certains vlanID (2000, 2001, 1001) qui peuvent se recouper avec les Vlan opérateurs (comme dans mon exemple pour le 1001), ou ceux d’autres clients dans des configs similaire, j’ai l’impression qu’il me faut une notion de “switch virtuel”, et que le vlan trunking classique (sur un switch tout con:-), ne me permettra pas de faire cela à cause de l’utilisation multiple possible d’un même VlanID? (ce type de config est faisable en VPLS/MPLS... Mais c'est hélas plus lourd, car si je centralise tout, le MPLS n'a aucun interet) Alex Le 9 novembre 2014 11:24, Sebastien Lesimple slesim...@laposte.net a écrit : Tu veux pouvoir fournir une solution type multi sites pour un de tes clients en passant par plusieurs collectes de fournisseurs différents. (J'ai bon jusque là?) Pour faire ca tu penses marquer le trafic avec un VLAN dédié à ces différents accès. (Toujours Bon?) Tout ce que tu as a faire c'est gerer le marquage VLAN 802.1q sur des interfaces virtuelles dans tes routeurs gérant les Portes. C'est du VLAN Trunking vraiment pas de quoi se prendre le casque, c'est comme sur un switch tout con. Faire du MPLS, ouais bof, les routeurs ont assez de patate pour lire les trames à la volée aujourd’hui, c'est plus vraiment une question de vitesse. DSLE/CE2O ne permettent pas de faire ca (la collecte Completel non plus aux dernières news). Altitude, je n'ai plus de contacts, désolé. Axione, oui EVPL sur la fibre et du 802.1Q sur le cuivre (c'est du CELAN à la base). Covage, oui aussi. Le 09/11/2014 10:18, Alexandre Duprez a écrit : Merci pour vos réponses! Le reste de l'ODR DSL est hors scope. Donc tu exclus DSLE/CE2O (avec livraison sur porte GEth) pour faire la même chose? Sur les DSP (Axione, Covage, Altitude Infra...) vous savez si c’est systématiquement supporté? Autre question complémentaire, sur le set-up central: Si on cherche à interconnecter en Layer2 plusieurs sites, livrés sur des portes différentes toutes sur un même équipement, quelle est la techno la plus adaptée? Il faut une sorte de “virtual switch” : nous avons les virtual routers (mais layer 3, donc cela ne va pas) ou les VPLS qui sont un cran au dessus puisqu’ils reposent sur du MPLS et permettent cela si les portes sont réparties sur le réseau. Mais dans un cas simple ou tout arrive sur le même routeur, quel est le plus simple (Plutot sur Brocade, éventuellement sur Cisco) ? faut-il forcément passer sur un set up VPLS (qui demande à activer le MPLS ce qui n’a pas d’interet ici)? Alex Le 9 novembre 2014 07:59, Sebastien Lesimple slesim...@laposte.net a écrit : David a parfaitement raisons, CELAN permet ce genre de set-up sans aucuns soucis. En revanche, CEE ne permet que le VLAN de livraison et supprime tout marquage CoS et VLAN supplémentaire. Le reste de l'ODR DSL est hors scope. Le 09/11/2014 00:52, David Ponzone a écrit : Oui, le CELAN supporte le QinQ. Les STATS, chapitre 3.4, sont claires sur ce point. Je n’ai pas détecté d’anomalie côté MTU. Avec DF positionné, 1500 passe, 1501 ne passe pas, que cela soit sur le VLAN de livraison (pas de QinQ) ou sur un VLAN QinQ.. Le 8 nov. 2014 à 22:04, Alexandre Duprez alexandup...@gmail.com a écrit : Bonsoir, Sur les offres Orange CELAN (cuivre ou optique), CE2O et DSLE (Pour DSLE et CE2O je parle d’une livraison en GEth par Orange, et non
[FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG -- ngont...@epitech.net sympav...@gmail.com *Aux hommes il faut un chef, et au* * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!* --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Un proto stateless pour de la synchro, superbe idée … Envoyé depuis Windows Mail De : Eugène Ngontang Envoyé : dimanche 9 novembre 2014 13:45 À : frnog@frnog.org Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG -- ngont...@epitech.net sympav...@gmail.com *Aux hommes il faut un chef, et au* * chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te voit on te juge!* --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Transparence aux VLANs sur offres CELAN/CE2O/DSLE ?
Regardes mes commentaires ci dessous mais voilà en ultra simplifié comment ça marche: (Je remercie mes camarades plus techniquement pointus de compléter/corriger l'exemple) L'opérateur te livre ca: (y'a que CELAN qui permette de faire ca): - sur ma porte1 des paquets du site 1, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 - sur ma porte1 des paquets du site 2, avec les VlanID 2000, 2001 et 1001 + le VlanID 1002 - sur ma porte2 des paquets du site 3, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 Toi tu dois détagger tes ifaces virtuelle avec ton routeur pour avoir ca: - sur ma porte1 des paquets du site 1, avec les VlanID 2000, 2001 et 1001 - sur ma porte1 des paquets du site 2, avec les VlanID 2000, 2001 et 1001 - sur ma porte2 des paquets du site 3, avec les VlanID 2000, 2001 et 1001 Après tu peux gérer les flux de plusieurs manières... Tu crées un bridge ou tu regroupes les ifaces virtuelles de chaque portes: Uplink Portes Bridge Portes Porte 1 Porte 2 Tu crées un second bridge sur lequel tu regroupes les Ifaces virtuelles: Uplink Portes Bridge Client X Site 1 Vlan 1001 Site 2 Vlan 1002 Site 3 Vlan 1001 Avec quelques règles tu permet a chaque Iface de communiquer entre elles sans te soucier de ce qui passe dedans. Si tu es coincé, il te reste du VLAN TAG Rewrite. Le 09/11/2014 12:23, Alexandre Duprez a écrit : Tu veux pouvoir fournir une solution type multi sites pour un de tes clients en passant par plusieurs collectes de fournisseurs différents. (J'ai bon jusque là?) oui, tout bon. Pour faire ca tu penses marquer le trafic avec un VLAN dédié à ces différents accès. (Toujours Bon?) Là, je ne pense pas : Si si, j'ai bon... Je laisse le client marquer son trafic (transparence aux vlan, il fait ce qu'il veut). L'opérateur ajoute un VlanID à la livraison sur la porte de collecte. Non, le tag VLAN est ajouté soit par le modem gérant l’accès soit par le DSLAM d'Orange. C'est a toi au niveau de ta porte de collecte de tagger/untagger le trafic, l'opérateur au niveau de la porte lui, il fait rien du tout. Il livre en vrac tous les VLAN dans un gros trunk (la version Switch tout con...) Je vais te donner un exemple, ce sera plus simple: Site 1 livré sur porte1 par opérateur1, vlanID 1001 Site 2 livré sur porte1 par opérateur1, vlanID 1002 Site 3 livré sur porte2 par opérateur2, vlanID 1001 (l’opérateur choisissant parfois le vlan, je peux par hasard me retrouver avec le même vlan ID que celui qui m’a été livré sur la porte1 pour le site 1, j'ai pris cet exemple pour prendre un cas extrême). Non normalement c'est toi qui choisis le No de VLAN a moins que tu ne passes par une revente de revente et ca c'est pas propre... Comme c'est a toi de virer le VLAN Tag à l'arrivée sur ta collecte, il ne reste que les VLANs Tag de tes client. C'est là que tu bridge les interfaces virtuelles correspondantes pour créer un gros LAN2LAN ou le client fait ce qu'il veut. Côté sites, le client tagge en 802.1q avec les VlanID 2000, 2001, 1001... par exemple (j’ai mis 1001, car comme on lui offre un service transparent au vlan... le hasard peut faire que lui aussi utilise le même vlanID que l’opérateur ; le set up ne doit donc pas déprendre de ce qu'il utilise). Et donc moi je recois : - sur ma porte1 des paquets du site 1, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 - sur ma porte1 des paquets du site 2, avec les VlanID 2000, 2001 et 1001 + le VlanID 1002 - sur ma porte2 des paquets du site 3, avec les VlanID 2000, 2001 et 1001 + le VlanID 1001 Ce que je veux donc faire c’est supprimer les Vlan opérateurs (1001 et 1002), et switcher (layer2) tout cela. Ben c'est le boulot de ton routeur, c'est le tout premier niveau de gestion d'une porte ca hein... C'est juste le B A BA du B A BA. Comme ce client utilise certains vlanID (2000, 2001, 1001) qui peuvent se recouper avec les Vlan opérateurs (comme dans mon exemple pour le 1001), ou ceux d’autres clients dans des configs similaire, j’ai l’impression qu’il me faut une notion de “switch virtuel”, et que le vlan trunking classique (sur un switch tout con:-), ne me permettra pas de faire cela à cause de l’utilisation multiple possible d’un même VlanID? Voir ci-dessus (ce type de config est faisable en VPLS/MPLS... Mais c'est hélas plus lourd, car si je centralise tout, le MPLS n'a aucun interet) Alex Le 9 novembre 2014 11:24, Sebastien Lesimple slesim...@laposte.net mailto:slesim...@laposte.net a écrit : Tu veux pouvoir fournir une solution type multi sites pour un de tes clients en passant par plusieurs collectes de fournisseurs différents. (J'ai bon jusque là?) Pour faire ca tu penses marquer le trafic avec un VLAN dédié à ces différents accès. (Toujours Bon?) Tout ce que tu as a faire c'est gerer le marquage VLAN 802.1q sur des interfaces virtuelles dans tes routeurs gérant les Portes. C'est du VLAN Trunking vraiment pas de quoi se prendre le casque,
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
On Sunday 09 November 2014 13:43:15 Eugène Ngontang wrote: Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG Bonjour Eugène, Quelques pistes pour toi: L'UDP ne garantissant pas ni la livraison des paquets, ni l'ordre des paquets ce n'est pas évident, mais heureusement il y a RTP à la rescousse. RTP offre la possibilité de détecter la perte de paquets, les problème de latence, les paquets dupliqués et tout ça en utilisant UDP. Si il ne s'agit pas d'un réseau dédié à cette application, il peut être judicieux de monitorer la latence et la montée en charge TCP pour les problèmes de congestion. Si ce n'est déjà le cas, tu peux tester en utilisant mplayer pour voir si le problème persiste avec une solution alternative: http://www.mplayerhq.hu/DOCS/HTML/en/networksync.html Un wireshark à chaque extremité au lieu de tcpdump. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour à tous. Merci pour vos réponses. Je tiens à préciser que je ne suis ni le concepteur, ni le développeur du programme réseau. Je connais très bien les différences entre UDP et TCP, et j'ai bien été le premier à faire remarquer que l'UDP était pas forcément un bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la diffusion que la synchro. Toujours est-il que ce pourquoi je suis sollicité c'est l'analyse et la détection de perte de paquets. Le client essaye de faire comprendre que c'est à notre niveau (ce qui serait donc un problème applicatif), ma boîte veut montrer que c'est sur le réseau du client. Moi je suis appelé à le montrer et j'ai des théoriciens au mileu qui ne font que émettre et me transmettre des demandes. Je n'ai pas toutes les billes mais j'essaye de réfléchir avec ma tête avant d'y consacrer du temps. Merci encore de votre aide, mon but est d'être le plus efficace et objectif possible. Cordialement, Eugène NG. Le 9 nov. 2014 14:50, technicien hahd technic...@hahd.fr a écrit : On Sunday 09 November 2014 13:43:15 Eugène Ngontang wrote: Bonjour la liste. J'ai un petit problème, beaucoup plus d'ordre stratégique que technique, mais j'aimerais avoir vos suggestions d'experts. En effet nous avons mis en place des systèmes sous Linux pour un client, avec un concept de synchronisation où l'on a un poste master, et deux slaves, le tout forme un groupe de synchronisation. Chacun des équipements est équipé d'un serveur X, pour la diffusion de contenus sur des écrans géants. Sur le principe, à des instants précis le master envoie des paquets de synchro en UDP pour qu'ils affichent en même temps (tous les trois ou tous les deux s'il n'a envoyé qu'à un seul slave. Bien le client constate des problèmes de synchro sur le terrain dans les groupes de synchro, et je suis appelé à prouver qu'il y a des pertes de paquets sur le réseau du clients. Les systèmes sont tous sur le même réseau local. ALors avec un *tcpdump* je ne peux rien voir d'important dans ce que je chercher vu que c'est de l'UDP, et les paquets que je capture n'ont aucun flag indicatif. J'ai utilisé *iperf* pour envoyé des paquet en udp depuis le master au slave à *10Mb/s* pendant *10 secondes*, et je n'ai vu aucune perte de paquets. J'envisage donc de planifier le test sur une plus longue période, et à des instants précis, où l'on est susceptible d'avoir de la désynchro. Vous, comment vous planifieriez un tel test? Et aussi vu que les machines sont sur le même LAN, est-ce pertinent de pencher sur une perte de paquets? Quels éléments réuniriez-vous pour une telle analyse? Merci beaucoup pour votre attention et votre aide. Cordialement, Eugène NG Bonjour Eugène, Quelques pistes pour toi: L'UDP ne garantissant pas ni la livraison des paquets, ni l'ordre des paquets ce n'est pas évident, mais heureusement il y a RTP à la rescousse. RTP offre la possibilité de détecter la perte de paquets, les problème de latence, les paquets dupliqués et tout ça en utilisant UDP. Si il ne s'agit pas d'un réseau dédié à cette application, il peut être judicieux de monitorer la latence et la montée en charge TCP pour les problèmes de congestion. Si ce n'est déjà le cas, tu peux tester en utilisant mplayer pour voir si le problème persiste avec une solution alternative: http://www.mplayerhq.hu/DOCS/HTML/en/networksync.html Un wireshark à chaque extremité au lieu de tcpdump. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour, On Sun, 9 Nov 2014 15:18:43 +0100 Eugène Ngontang sympav...@gmail.com wrote: bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la diffusion que la synchro. Ton traffic est envoye vers cette adresse ??? Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les CPU n'est pas a exclure. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH]Tester la perte de paquets réseaux.
Hello, As-tu vérifier qu'il n'y avait pas d'erreur au niveau des interfaces réseaux ? - un /sbin/ifconfig pour les machines - vérifie également au niveau des équipements réseaux (switch/routeur) sur toutes la chaines entre tes 2 machines. Concernant le broadcast, tu peux avoir des protections au niveau des switchs (limiter la diffussion en % d'utilisation de l'interface) ++ Sylvain Le 9 novembre 2014 15:40, Paul Rolland (ポール・ロラン) rol+fr...@witbe.net a écrit : Bonjour, On Sun, 9 Nov 2014 15:18:43 +0100 Eugène Ngontang sympav...@gmail.com wrote: bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la diffusion que la synchro. Ton traffic est envoye vers cette adresse ??? Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les CPU n'est pas a exclure. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
RE:[FRnOG] [TECH]Tester la perte de paquets réseaux.
Bonjour, selon la nature des switches, le broadcast local (255.255.255.255) peut être limité (ControlPlane policy) car considéré comme un DDOS. et comme l'on fait remarqué certain, UDP ne garantie rien, et de plus sur un réseau Ethernet non garantie. = il faut : - RTP et RTCP pour géré les retransmissions et les controle de flux - mettre de la QOS pour garantir un minimum (jitter et latence) et surtout, on ne met jamais 2 équipements de diffusion vidéo (type streaming) cote à cote pour comparer , car il y aura toujours une différence dans la diffusion.. (on dépend de chaque composant , exemple: composant éléctronique,..) Thierry Thierry Martin Senior Engineer Expert Dimension Data France Tel: +33 1 4975 8852 Mob: +33 6 6023 6611 Fax: +33 1 4975 8629 thierry.mar...@dimensiondata.com Zone Orlytech - 20 avenue Louis Blériot (adresse postale 91781 Wissous Cedex), Paray Vieille Poste, 91550, France. Dimension Data is an NTT Group company. For further information about Dimension Data, please go to www.dimensiondata.comhttp://www.dimensiondata.com/ Follow us on Social Media Bloghttp://blog.dimensiondata.com Facebookhttp://www.facebook.com/pages/Dimension-Data-Europe/208242309194429 LinkedInhttp://www.linkedin.com/company/dimension-data Twitterhttp://twitter.com/DimensionData P please consider the environment before printing this email [cid:488f8e.png@22364fc5.498ec296][cid:image8fdb15.PNG@261a1359.4ca6eaa1] De : frnog-requ...@frnog.org [frnog-requ...@frnog.org] de la part de Paul Rolland (ポール・ロラン) [rol+fr...@witbe.net] Envoyé : dimanche 9 novembre 2014 15:40 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH]Tester la perte de paquets réseaux. Bonjour, On Sun, 9 Nov 2014 15:18:43 +0100 Eugène Ngontang sympav...@gmail.com wrote: bon choix. Après j'ai pu voir que les paquets sont envoyer à l'adresse 255.255.255.255 sur le port 2325. Ils ont peut-être plus tabler sur la diffusion que la synchro. Ton traffic est envoye vers cette adresse ??? Il serait peut-etre utile de regarder dans ce cas ce que disent les switchs qui sont supposes faire passer ce traffic... Un petit coup de chaud sur les CPU n'est pas a exclure. Paul --- Liste de diffusion du FRnOG http://www.frnog.org/ itevomcid --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] ToS implémentée chez certains transitaires
Plop, TL;DR: Depuis au moins février 2014, Cogent prioritarise les paquets en fonction de classes de client sur certaines portions de son réseau. Histoire de bien commencer la semaine, un peu de lecture : http://www1.icsi.berkeley.edu/~srikanth/tos.html http://blog.streamingmedia.com/2014/11/cogent-now-admits-slowed-netflixs-traffic-creating-fast-lane-slow-lane.html Je trouve étrange que les marqueurs ne disparaissent pas au moment de sortir de leur réseau, mais on dirait bien que cette pratique n'est plus un tabou. Ca implique, entre autres, qu'elle pourrait se généraliser. Est ce que vous avez déjà remarqué ce genre de situations ? En tant que transitaires, envisagez vous de vendre du trafic prioritaire et du low-cost ainsi différencié ? Point de vue eyeball, est ce que ça a du sens de maintenir ces ToS jusqu'aux PE ? @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
