Le 30/12/2014 10:28, Antoine Durant a écrit :
Bonjour à tous,
Justement j'ai désactivé le spanning-tree sur les deux switchs pour que le port soit UP immédiatement....
Salut,
Pour être plus précis, le portfast ne désactive pas le spanning tree
(heureusement) mais permet juste de passer le port en forward dès qu'une
connexion est détectée et ainsi gagner les 50 s. d'attente en STP ou les
35 en RSTP.
Comme rien n'est précisé sur le spanning tree, c'est une attente de 50s
que tu dois avoir. Si le temps est inférieur, cela doit provenir du
temps de propagation des ARP. Fait un show span vlan 10 pour voir l'état
de tes ports quand tu fais une modification et faire du show mac ou show
mac add vlan 10 pour vérifier les MAC connus sur le vlan 10.
Effectivement il faut éviter, comme là dit David, le switch block sinon,
l'apprentissage des MAC n'aura lieu que si l'hôte envoie une trame.
Bon courage dans ton tshoot
F. Nolot
Donc voici la configuration des ports host des switchs (est-ce que la conf est foireuse ?) :
!
interface FastEthernet0/3
switchport access vlan 10
switchport mode access
switchport nonegotiate
ip arp inspection limit rate 100
storm-control broadcast level 60.00
storm-control multicast level 60.00
storm-control action shutdown
spanning-tree portfast
spanning-tree bpduguard enable
!
interface FastEthernet0/45
switchport access vlan 10
switchport mode access
switchport nonegotiate
switchport port-security
switchport port-security mac-address bc40.5adb.b120
ip arp inspection limit rate 100
storm-control broadcast level 60.00
storm-control multicast level 60.00
storm-control action shutdown
spanning-tree portfast
spanning-tree bpduguard enable
ip verify source port-security
!
-> 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.
Ok donc je ne vais plus utiliser le block mais garder le storm-control...
Tu peux facilement vérifier en faisant un show mac address-table juste avant de
modifier un port et juste après.
Je vais regarder ça !!
De : Olivier Benghozi <olivier.bengh...@wifirst.fr>
À : "frnog-t...@frnog.org" <frnog-t...@frnog.org>
Envoyé le : Mardi 30 décembre 2014 3h51
Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène
étrange
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/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
