¿Se supone que 'switchport protegido' bloquea las inundaciones de unidifusión?


9

¿Haber switchport protectedconfigurado en una interfaz evita la inundación de unidifusión para una dirección MAC que el switch no ha aprendido?

La información que veo está en conflicto: la página de wikipedia sobre inundaciones de unidifusión cita el modo protegido como un mecanismo para bloquear las inundaciones, mientras que la documentación de Cisco dice que eso switchport protectedno importa y que switchport block unicastaún sería necesario para evitar inundaciones.

Sin embargo, recientemente me encontré con un problema en el que en un 2950G que ejecutaba un código 12.1 (22) relativamente antiguo, la inundación de unidifusión parecía estar completamente rota para un puerto protegido: el tiempo de envejecimiento en el conmutador era de 5 minutos, mientras que el tiempo de espera ARP del enrutador fueron 30 minutos, y la única conexión TCP que utiliza esta interfaz tenía una tendencia a permanecer inactiva durante 10 minutos a la vez, y no funcionar al despertarse después de 10 minutos en este caso.

Las capturas realizadas en el host no mostraron una inundación de unidifusión cuando se esperaba, y el aumento del temporizador de envejecimiento MAC en el conmutador para que coincida con ARP resolvió por completo el problema.

¿Es este comportamiento indefinido o inconsistente en versiones anteriores de IOS, o es solo un error en este código antiguo?


1
Hola Shane, la solución correcta para esta situación es hacer que tu temporizador ARP sea ligeramente más bajo que el temporizador CAM . Es una pregunta razonable sobre el puerto de conmutación protegido, pero probablemente no sea la mejor manera de conquistar el problema ...
Mike Pennington

@ MikePennington Gotcha, tiene sentido. Todo funciona muy bien con los temporizadores que coinciden en este momento, solo me pregunto por qué la inconsistencia entre la documentación y el comportamiento observado.
Shane Madden

¿Se switchport protectedconfiguró en todos los puertos de conmutación en el vlan? ¿Hay alguna posibilidad de que podamos ver las configuraciones y un diagrama de la ruta entre los dos hosts?
Mike Pennington

@ MikePennington Sí, está configurado en todos los puertos de esa vlan, excepto el enlace ascendente. El enrutador del próximo salto (a través del cual fluye el tráfico problemático) es el conmutador al que se vincula este conmutador. Las configuraciones serían complicadas, pero puedo obtener partes específicas de interés si es necesario.
Shane Madden

Respuestas:


4

La información que veo está en conflicto: la página de wikipedia sobre inundaciones de unidifusión cita el modo protegido como un mecanismo para bloquear las inundaciones, mientras que la documentación de Cisco dice que el puerto de conmutación protegido no importa, y que la unidifusión de bloqueo de puerto de conmutación aún sería necesaria para evitar inundaciones .

switchport protectedse usa para imponer la privacidad dentro de un vlan ... el comando evita que los puertos hablen con otros puertos configurados con switchport protected. Este comando reduce las inundaciones como efecto secundario de usarlo en todos los puertos en un Vlan, pero hace mucho más que "simplemente" eliminar las inundaciones de un puerto de conmutación. Honestamente, creo que hay mejores maneras de lograr tus objetivos.

switchport protectedes útil si está agregando clientes de colocación en la misma vlan; Este comando es una forma de ofrecer privacidad entre los clientes sin las complicaciones de vlans privados. El artículo de Wikipedia que mencionó dice que puede "rebotar" el tráfico de la puerta de enlace predeterminada (que no debe estar en un puerto de conmutación protegido) para llegar a esos otros destinos ...

switchport block unicastdetiene las inundaciones de unidifusión desconocidas; sin embargo, vea a continuación por qué creo que no debería necesitar este comando.

Sin embargo, recientemente me encontré con un problema en el que en un 2950G que ejecutaba un código 12.1 (22) relativamente antiguo, la inundación de unidifusión parecía estar completamente rota para un puerto protegido: el tiempo de envejecimiento en el conmutador era de 5 minutos, mientras que el tiempo de espera ARP del enrutador fueron 30 minutos, y la única conexión TCP que utiliza esta interfaz tenía una tendencia a permanecer inactiva durante 10 minutos a la vez, y no funcionar al despertarse después de 10 minutos en este caso.

Como mencioné en mi comentario, si existe la posibilidad de una ruta enrutada asimétrica en esta red, o necesita una inundación de unidifusión desconocida, o necesita hacer coincidir los temporizadores CAM y ARP para asegurarse de que las entradas CAM no caduquen antes del Entradas ARP.

En la mayoría de los casos, hacer coincidir los temporizadores ARP y CAM es la forma correcta de solucionar la situación , pero la elección es suya ...

EDITAR para responder a los comentarios:

Configurar los temporizadores para que funcionen funciona muy bien como una solución alternativa: simplemente no entiendo por qué la inundación no está ocurriendo como se esperaba.

Citando de "CCIE Practical Studies, Volumen 2", página 115 por Karl Solie, Leah Lynch, Charles Ragan:

Si el tráfico desconocido de unidifusión y multidifusión se reenvía a un puerto protegido, puede haber problemas de seguridad. Para evitar que se reenvíe el tráfico unicast o multicast desconocido de un puerto a otro, puede configurar un puerto (protegido o no protegido) para bloquear el tráfico unicast y multicast desconocido.

3550_switch(config-if)#switchport block unicast
3550_switch(config-if)#switchport block multicast

Permítanme aclarar: switchport protectedse implementa en este caso como un mecanismo de aislamiento entre sistemas que no deberían poder comunicarse. El tráfico en cuestión ingresa al conmutador en un puerto no protegido, y no está logrando que la unidifusión inunde los puertos protegidos en el vlan, y debido a eso se producen fallas de conexión. Configurar los temporizadores para que funcionen funciona muy bien como una solución alternativa: simplemente no entiendo por qué la inundación no está ocurriendo como se esperaba.
Shane Madden

@ShaneMadden, tenía razón al esperar inundaciones de unidifusión en el puerto de conmutación protegido. Mira mi edición.
Mike Pennington

Correcto: ¿alguna idea sobre qué está causando la falla de inundación? No se me ocurren muchas ideas aparte del error de IOS.
Shane Madden
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.