> Sébastien a écrit : > car côté 802.1q je ne vois pas spécialement de problématique sur l'usage....
C'est plutôt la data-plane ou le chipset qui va perdre les pédales, voir plus bas. > Thierry Chich a écrit : > Je confirme que c’est dangereux. Je l’ai eu fait, et ça a très > bien marché. Et je l’ai eu refait, et ça a bien foiré. Pas de surprise. > Pourtant, du strict point de vue 802.1q, c’est dans les clous. Mais on est > jamais à l’abri > d’un STP qui fonctionne pas comme on le pense (et dieu sait que c’est > quasiment une > caractéristique du STP - ne pas fonctionner comme on pense), ou d’un > reparametrage innocent > qui va tout exploser. Le fait est que jamais je ne tenterais cette opération > à distance, > sans avoir le switch sous la main. C’est un signe que c’est pas hyper > sécurisé comme opération. Ce n'est pas tellement STP ou 802.1q qui me chagrine dans cette combine, c'est la gestion de la table CAM dans le switch. Rappel de base : la CAM est construite en écoutant l'adresse MAC source et en l'associant au port sur lequel le trafic est arrivé. Il peut y avoir plusieurs MAC par port, mais pas plusieurs ports par MAC. Port A reçoit le trafic en provenance de la MAC xyzt, donc le switch construit la CAM en associant cette adresse au port A. Le cable entre le port A et le port B envoie ce même trafic vers le port B, et maintenant le switch mets à jour la CAM en associant xyzt avec le port B, possiblement en effaçant l'association avec le port A. Quand le trafic de retour a destination de xyzt est reçu par le port B, le switch ne sait pas quoi faire : en regardant la CAM il se rend compte que xyzt est associé au port qui a reçu le trafic, ce qui ne devrait pas arriver. En suivant la logique, çà ne devrait même pas marcher. Cà marche par accident, avec possiblement du ré-apprentissage de MAC permanent, ou du flooding. Michel. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
