4 réponses
Je ne croi pas que cela soit possible...
Par contre si tu ajoute un switch Vlan sur une de tes Vlan tu poura créer plusieur Vlan sur ce second switch qui ce trouve déjà dans un Vlan!
Mais bon ca fait un peut bricolage... donc je ne te le conseil pas!
Par contre si tu ajoute un switch Vlan sur une de tes Vlan tu poura créer plusieur Vlan sur ce second switch qui ce trouve déjà dans un Vlan!
Mais bon ca fait un peut bricolage... donc je ne te le conseil pas!
Houla,
très peu de switchs sont capable de gérer QinQ, cette encapsulation ne concerne pas grand monde, si on veut l'utiliser il faut bien choisir ses partenaires .
très peu de switchs sont capable de gérer QinQ, cette encapsulation ne concerne pas grand monde, si on veut l'utiliser il faut bien choisir ses partenaires .
Bonjour brupala.
Avec tout le respect que je te dois, je m'autorise à (fortement) nuancer ton propos ;)
Tous les constructeurs de switch pro proposent des équipements supportant une encapsulation qinq. J'irai même à dire que c'est un outil d'usage courant et indispensable chez tous les opérateurs de service aux entreprises.
Si je suis d'accord avec toi sur le fait qu'on ne rencontre pas du qinq partout où l'on met les pieds, OBS, SFR, Colt, Completel et bien d'autres, utilisent couramment cet 'outil' pour construire leurs offres
Après, si l'on souhaite une transparence aux protocoles de niveau 2 alors il est effectivement nécessaire d'avoir les mêmes equipementiers aux 2 extrémités (encapsulation et desencapsulation)
Avec tout le respect que je te dois, je m'autorise à (fortement) nuancer ton propos ;)
Tous les constructeurs de switch pro proposent des équipements supportant une encapsulation qinq. J'irai même à dire que c'est un outil d'usage courant et indispensable chez tous les opérateurs de service aux entreprises.
Si je suis d'accord avec toi sur le fait qu'on ne rencontre pas du qinq partout où l'on met les pieds, OBS, SFR, Colt, Completel et bien d'autres, utilisent couramment cet 'outil' pour construire leurs offres
Après, si l'on souhaite une transparence aux protocoles de niveau 2 alors il est effectivement nécessaire d'avoir les mêmes equipementiers aux 2 extrémités (encapsulation et desencapsulation)
Salut Nico,
je sais que tu es bien renseigné et c'est pourtant mon domaine d'activité les CPE, et les accès opérateurs (côté accès seulement, pas du tout les peering et transports) , mais je n'ai pas de souvenir de configuration ethernet trunk d'un client connectée au réseau opérateur.
D'une autre façon, il est très rare d'avoir des accès pontés aujourd'hui (un accès Q-in-Q étant forcément ponté si je ne m'abuse) mais pourquoi pas, la démocratisation des très hauts débits explosant de jour en jour .
Cependant, je suppose que ces transports sont en priorité réservés aux flux multicast plus faciles à contrôler par pontage que par routage .
Merci tout de même pour tes informations que je ne connaissais pas .
je sais que tu es bien renseigné et c'est pourtant mon domaine d'activité les CPE, et les accès opérateurs (côté accès seulement, pas du tout les peering et transports) , mais je n'ai pas de souvenir de configuration ethernet trunk d'un client connectée au réseau opérateur.
D'une autre façon, il est très rare d'avoir des accès pontés aujourd'hui (un accès Q-in-Q étant forcément ponté si je ne m'abuse) mais pourquoi pas, la démocratisation des très hauts débits explosant de jour en jour .
Cependant, je suppose que ces transports sont en priorité réservés aux flux multicast plus faciles à contrôler par pontage que par routage .
Merci tout de même pour tes informations que je ne connaissais pas .
Bonjour,
Aujourd'hui, le VPN L2 sont aussi courant que les L3 : dans ce type de config, tu fournis un 'simple' port ethernet au client : celui ci est alors libre d'y faire transiter du trafic tagué (simple ou double tag (qinq)) ou non.
Jusque là, et je suis d'accord avec toi, seules quelques sociétés souhaitent véhiculer des flux doublement tagués. Mais coté opérateur, avant de transporter cela via des tunnels EoMpls (ou en emulation bridge type vpls), il est classiquement utilisé une couche d'agrégation sous la forme de switch.
Comme tu ne peux et veux évidemment pas dépendre des tags utilises par les clients (et vis versa), tu encapsules le trafic client dans un svlan opérateur jusqu'à pouvoir le livrer à un point de collecte mpls (pe) où le svlan devient alors inutile.
Aujourd'hui, le VPN L2 sont aussi courant que les L3 : dans ce type de config, tu fournis un 'simple' port ethernet au client : celui ci est alors libre d'y faire transiter du trafic tagué (simple ou double tag (qinq)) ou non.
Jusque là, et je suis d'accord avec toi, seules quelques sociétés souhaitent véhiculer des flux doublement tagués. Mais coté opérateur, avant de transporter cela via des tunnels EoMpls (ou en emulation bridge type vpls), il est classiquement utilisé une couche d'agrégation sous la forme de switch.
Comme tu ne peux et veux évidemment pas dépendre des tags utilises par les clients (et vis versa), tu encapsules le trafic client dans un svlan opérateur jusqu'à pouvoir le livrer à un point de collecte mpls (pe) où le svlan devient alors inutile.
Que Dieu te bénisse!!
Merci d'en tenir compte.