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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> À : Antoine Durant <[email protected]> >> Cc : "[email protected]" <[email protected]> >> 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 <[email protected]> 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 <[email protected]> >>> À : Antoine Durant <[email protected]> >>> Cc : "[email protected]" <[email protected]> >>> 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 <[email protected]> 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/
