Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
bonsoir le block est bien sécu mais moins que le shutdown ;-) Bonnes fêtes Florent NOLOT Université de Reims Champagne-Ardenne Le 30/12/2014 22:40, Antoine Durant a écrit : 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 florent.no...@univ-reims.fr *À :* frnog-t...@frnog.org frnog-t...@frnog.org *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 olivier.bengh...@wifirst.fr mailto:olivier.bengh...@wifirst.fr À : frnog-t...@frnog.org mailto:frnog-t...@frnog.org frnog-t...@frnog.org mailto: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#portfastcommandhttp://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 mailto: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
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
Bonjour à tous, Justement j'ai désactivé le spanning-tree sur les deux switchs pour que le port soit UP immédiatement 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#portfastcommandhttp://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
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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
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 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#portfastcommandhttp://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
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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 florent.no...@univ-reims.fr À : frnog-t...@frnog.org frnog-t...@frnog.org 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 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#portfastcommandhttp://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
[FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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/
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/
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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/
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/
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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/
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
sur les uplinks ça sert à rien, ce sont des commandes qu'on passe sur les ports host (ceux qui sont en portfast / edge) sachant que si tu as des mécanismes de clustering style NLB si tu bloques l'unknown unicast ou le multicast le cluster ne fonctionnera plus... Le 29/12/2014 21:00, Antoine Durant 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/
Re: [FRnOG] [TECH] Cisco commande block multicast/unicast phénomène étrange
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/
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/
