Bien vu pour le Spanning-Tree. Je crois que je date d’une époque où cela n’était pas activé par défaut sur les Catalyst :)
Le 30 déc. 2014 à 03:51, Olivier Benghozi <olivier.bengh...@wifirst.fr> a écrit : > Pourquoi pas normal? > J'imagine qu'il y a du spanning-tree (par défaut, bonne idée d'ailleurs), > donc il faut RTFM: > http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#portfastcommand > > <http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/12013-17.html#portfastcommand> > > 1) un nouveau port (non-edge) est up dans le vlan, un TCN est généré, les MAC > sont expirées. > 2) en principe il y a donc pendant quelques secondes de l'unknown unicast en > masse, c'est rapidement réappris, et c'est réglé. > Sauf qu'ont été configurés moults filtrages peu pertinents, du coup cet > unknown unicast est filtré et donc le réapprentissage se passe mal (comme > expliqué par David). > > Conclusion la conf est mauvaise et par conséquent: > -> sur les ports access vers des hosts, il faut configurer un spanning-tree > portfast. J'imagine que ce ne doit pas être le cas. > -> quand on filtre unknown-unicast, on a des ennuis. switchport block est à > virer. > -> storm-control ET switchport block ? Le storm-control est la bonne > démarche, pas le block. > > > >> Le 30 déc. 2014 à 00:52, David Ponzone <david.ponz...@gmail.com> a écrit : >> >> Ben à y regarder de plus près, le block unicast pourrait être responsable de >> ton problème en fait. >> >> Par défaut, les unknown unicast sont forwardés sur tous les ports d’un >> Catalyst, ce qui permet de trouver rapidement les hôtes « silencieux » dont >> l’adresse MAC n’est plus dans la table des adresses MAC (car expirée). >> Avec le block, les unknown unicast sont filtrés. >> Donc pour que le paquet soit forwardé, il faudra attendre que l’adresse MAC >> de l’hôte destination soit de nouveau présente dans la table MAC. >> Cela ne pourra arriver que quand l’hôte destination aura essayer d’envoyer >> un paquet unicast (pas unknown) ou broadcast. >> En fonction de ce que font tes machines, il se peut que tu aies à attendre 2 >> ou 3 secondes avant qu’un tel paquet soit émis. >> >> Dans ton cas précis, pourquoi cela arrive quand tu modifies la conf d’un >> port ? >> Cela semblerait signifier que quand tu changes la conf d’un port, le switch >> fait un clear mac address-table. >> A priori, pas normal. >> Tu peux facilement vérifier en faisant un show mac address-table juste avant >> de modifier un port et juste après. >> >> En espérant que ça te donne des pistes. >> >> Le 29 déc. 2014 à 21:00, Antoine Durant <antoine.duran...@yahoo.fr> a écrit : >> >>> Je connais pas CCO, je vais regarder... >>> >>> Et d'après toi il faut utiliser ou pas le block multi/uni cast sur les >>> uplinks ? >>> >>> De : David Ponzone <david.ponz...@gmail.com> >>> À : Antoine Durant <antoine.duran...@yahoo.fr> >>> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> >>> Envoyé le : Lundi 29 décembre 2014 20h25 >>> Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène >>> étrange >>> >>> Faut plutôt utiliser les outils CCO en fait. >>> >>> >>> >>> Le 29 déc. 2014 à 20:21, Antoine Durant <antoine.duran...@yahoo.fr> a écrit >>> : >>> >>>> Non je trouve rien sur google... >>>> >>>> Oupss ! switch 2960 avec IOS 15 (les deux avec le même IOS) >>>> >>>> Cisco IOS Software, C2960 Software (C2960-LANBASEK9-M), Version >>>> 15.0(2)SE5, RELEASE SOFTWARE (fc1) >>>> >>>> De : David Ponzone <david.ponz...@gmail.com> >>>> À : Antoine Durant <antoine.duran...@yahoo.fr> >>>> Cc : "frnog-t...@frnog.org" <frnog-t...@frnog.org> >>>> Envoyé le : Lundi 29 décembre 2014 20h15 >>>> Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast >>>> phénomène étrange >>>> >>>> Quels switchs ? >>>> Quel IOS/CatOS ? >>>> T’as vérifié sur le site de Cisco s’il y avait un bug connu ? >>>> >>>> Le 29 déc. 2014 à 20:06, Antoine Durant <antoine.duran...@yahoo.fr> a >>>> écrit : >>>> >>>>> Bonjour, >>>>> >>>>> J'utilise la conf ci-dessous sur deux switch Cisco. J'ai un phénomène >>>>> étrange qui se produit !!! >>>>> >>>>> ip dhcp snooping vlan 10-12 >>>>> no ip dhcp snooping information option >>>>> ip dhcp snooping >>>>> ! >>>>> interface GigabitEthernet0/1 >>>>> switchport trunk allowed vlan 10,11,12 >>>>> switchport mode trunk >>>>> switchport nonegotiate >>>>> switchport block multicast >>>>> switchport block unicast >>>>> ip arp inspection trust >>>>> storm-control broadcast level 80.00 >>>>> storm-control multicast level 80.00 >>>>> ip dhcp snooping trust >>>>> ! >>>>> >>>>> Lorsque je configure un port sur le switch N°1 le ping ne passe plus >>>>> (pendant quelque seconde) sur les machines du second switch. En gros les >>>>> machines sur le second switch ne sont plus joignable pendant quelque >>>>> seconde ! >>>>> >>>>> Même phénomène si je configure un port sur le switch N°2, les machines du >>>>> switch N°1 tombent... >>>>> >>>>> Le problème survient lorsque j'active les commandes suivantes sur les >>>>> uplink : >>>>> >>>>> switchport block multicast >>>>> switchport block unicast >>>>> >>>>> Sans, je n'ai pas de problème tout fonctionne... J'ai l'intention de >>>>> désactiver cela de mes uplinks mais en revanche de le laisser sur les >>>>> ports ou il y a pas de trunk (machines). >>>>> >>>>> Est-ce un comportement normal ?? > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
