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 la protection des ports de commutation n'a pas d'importance, et que la monodiffusion des blocs de commutation serait toujours nécessaire pour empêcher les inondations .
switchport protectedest utilisé pour appliquer la confidentialité dans un vlan ... la commande empêche les ports de parler aux autres ports configurés avec switchport 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 protectedest 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 unicastarrête les inondations unicast inconnues; cependant, voyez ci-dessous pourquoi je pense que vous ne devriez pas avoir besoin de cette commande.
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.
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:
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.
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.
3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast