Bonsoir,
 
Merci pour vos retours et pistes. 
 
J'ai désactivé les switch block unicast/multicast et je n'ai plus le problème 
que j'avais au début !!!
Après quelque test de modification de port plus de soucis si les uplinks ne 
sont plus en block uni/multi cast...
 
Donc faut pas croire tout ce que l'on trouve sur le net concernant les méthodes 
sécurisation...
 
Bonne fête de fin d'année !!!!!!
 
 De : Florent Nolot <[email protected]>
À : "[email protected]" <[email protected]> 
Envoyé le : Mardi 30 décembre 2014 14h19
Objet : Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène 
étrange
  

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

Répondre à