La switchport protected
configuration sur une interface empêche-t-elle l'inondation d'unicast pour une adresse MAC que le commutateur n'a pas apprise?
Les informations que je vois sont en conflit - la page wikipedia sur les inondations unicast cite le mode protégé comme mécanisme pour bloquer les inondations, tandis que la documentation de Cisco dit que cela switchport protected
n'a pas d'importance, et que cela switchport block unicast
serait toujours nécessaire pour empêcher les inondations.
Cependant, j'ai récemment rencontré un problème où sur un 2950G exécutant un code 12.1 (22) relativement ancien, l'inondation unicast semblait être complètement interrompue pour un port protégé - le temps de vieillissement sur le commutateur était de 5 minutes, tandis que le délai d'expiration ARP du routeur était de 30 minutes, et la seule connexion TCP utilisant cette interface avait tendance à rester inactive pendant 10 minutes à la fois - et à ne pas être fonctionnelle au réveil après 10 minutes dans ce cas.
Les captures exécutées sur l'hôte n'ont montré aucune inondation unicast quand cela était prévu, et l'augmentation de la temporisation de vieillissement MAC sur le commutateur pour correspondre à ARP a complètement résolu le problème.
Ce comportement est-il indéfini ou incohérent dans les anciennes versions d'IOS, ou s'agit-il simplement d'un bogue dans cet ancien code?
la source
switchport protected
configuré sur tous les ports de commutation dans le vlan? Une chance que nous pourrions voir les configs et un diagramme du chemin entre les deux hôtes?Réponses:
switchport protected
est utilisé pour appliquer la confidentialité dans un vlan ... la commande empêche les ports de parler aux autres ports configurés avecswitchport protected
. Cette commande réduit l'inondation comme effet secondaire de son utilisation sur tous les ports d'un Vlan, mais elle fait bien plus que "simplement" supprimer l'inondation d'un port de commutation. Honnêtement, je pense qu'il existe de meilleures façons d'atteindre vos objectifs.switchport protected
est utile si vous regroupez des clients de colocation dans le même vlan; cette commande est un moyen d'offrir une intimité entre les clients sans les complications des vlans privés. L'article de wikipedia que vous avez mentionné dit que vous pouvez "renvoyer" le trafic de la passerelle par défaut (qui ne devrait pas être sur un port de commutation protégé) pour atteindre ces autres destinations ...switchport block unicast
arrête les inondations unicast inconnues; cependant, voyez ci-dessous pourquoi je pense que vous ne devriez pas avoir besoin de cette commande.Comme je l'ai mentionné dans mon commentaire, s'il existe un potentiel pour un chemin routé asymétrique dans ce réseau, vous avez besoin d'une inondation unicast inconnue, ou vous devez faire correspondre les temporisateurs CAM et ARP pour vous assurer que les entrées CAM ne vieillissent pas avant la Entrées ARP.
Dans la plupart des cas, faire correspondre les temporisateurs ARP et CAM est la bonne façon de résoudre la situation , mais le choix vous appartient ...
EDIT pour répondre aux commentaires:
Extrait de "CCIE Practical Studies, Volume 2", page 115 de Karl Solie, Leah Lynch, Charles Ragan:
Si le trafic unicast et multicast inconnu est transféré vers un port protégé, il peut y avoir des problèmes de sécurité. Pour empêcher le trafic unicast ou multicast inconnu d'être transféré d'un port à un autre, vous pouvez configurer un port (protégé ou non protégé) pour bloquer le trafic unicast et multicast inconnu.
la source
switchport protected
est implémenté dans ce cas comme un mécanisme d'isolement entre les systèmes qui ne devraient pas être en mesure de communiquer. Le trafic en question pénètre dans le commutateur sur un port non protégé et ne parvient pas à inonder unicast les ports protégés sur le vlan - et des échecs de connexion se produisent à cause de cela. La définition des minuteries pour correspondre fonctionne très bien comme solution de contournement - je ne comprends tout simplement pas pourquoi l'inondation ne se produit pas comme prévu.