Filtrado BPDU (BPDU Filter)

 

 

Uso del Filtrado BPDU para desactivar STP en un puerto.

Normalmente, STP opera en todos los puertos de Switch en un esfuerzo por eliminar todos los Bridging Loops (bucles) antes de que puedan formarse. 

Las BPDUs se envían a todos los puertos del switch, incluso en los puertos donde Portfast ha sido habilitado. Las BPDUs también pueden ser recibidas y procesadas si algunas son enviadas por switches vecinos.

Siempre debería permitir a STP funcionar en un switch para prevenir loops. Sin embargo, en casos especiales, cuando necesite prevenir BPDUs que se envíen o procesen en uno o más puertos del switch, se puede usar el Filtrado BPDU para desactivar STP de forma efectiva en esos puertos.

Por defecto, el Filtrado BPDU está deshabilitado en todos los puertos del switch, se puede configurar el Filtrado BPDU como un valor global por defecto que afecta a todos los puertos del switch, el comando es el siguiente:

switch(config)# spanning-tree Portfast bpdufilter default

La palabra “default” indica que el Filtrado BPDU se activará automáticamente en todos los puertos que tienen habilitado Portfast. Si Portfast está deshabilitado en un puerto, entonces el filtrado BPDU no se activará.

También se puede habilitar o deshabilitar el Filtrado BPDU en puertos específicos del switch mediante el siguiente comando:

switch(config-if)# spanning-tree bpdufilter { enable | disable }

Tenga cuidado con habilitar el Filtrado BPDU, solo bajo circunstancias en las que usted esté seguro que un puerto del switch tendrá un solo host conectado y que un loop será imposible. 

Habilite el Filtrado BPDU solo si el dispositivo conectado no puede permitir que BPDU sea aceptado o enviado, de lo contrario, debe permitir que STP funcione en los puertos del switch como una precaución.

Nota: no confunda BPDU Filtering con BPDU Guard. BPDU Guard se usa para detectar BPDU entrante en el puerto donde las BPDUs no se esperan ver, entonces protege la estabilidad de STP previniendo que esas BPDUs sean procesadas.

 Tomado de: https://www.lesand.cl/foro/filtrado-bpdu

 

Variedades de Spanning Tree Protocol (STP)

Sabores de STP

Existen múltiples versiones de Spanning Tree Protocol:

• STP: Es la especificación original de STP, definida en 802.1D. STP es algunas veces llamado Spanning Tree común (Common Spanning Tree - CST) debido a que el protocolo asume una instancia de Spanning Tree para toda la red conmutada, independientemente de la cantidad de  VLANs.
• PVST+: Per-VLAN Spanning Tree Plus es una mejora realizada por Cisco  sobre el STP que proporciona una instancia de 802.1D spanning tree  para cada VLAN configurada en la red.
• RSTP: Rapid STP, ó IEEE 802.1w, es una evolución del STP que provee rápida convergencia en comparación con STP. De todas maneras, RSTP aún proporciona solamente una instancia de STP.
• Rapid PVST+: Es otra mejora de Cisco del RSTP que utiliza PVST+. El Rapid PVST+ proporciona una instancia separada de 802.1w para cada VLAN.
• Multiple Spanning Tree Protocol: MSTP es un estandar IEEE inspirada en la implementación del protocolo propietario de Cisco Multiple Instance STP (MISTP). El MSTP puede mapear multiples VLANs dentro de una instancia de  spanning tree. La implementación Cisco de MSTP se llama MST, la cual provee hasta 16 instancias de RSTP y combina muchas VLANs dentro de la misma topología física y lógica de una instancia de RSTP común. 

 

Tomado de: https://www.networkplayroom.com/2017/09/stp-flavors.html

Traducido al español por Ing. José Torrico Gumucio, Instructor Cisco CCNA/CCNA CyberOps/CCNAS/CCNP - Instructor trainer

IPv6: Y después del 4..... ¿Va el 6?

 

Para todos debe quedar más o menos claro que la evolución del Protocolo  de Comunicación de Internet (IP) y su creciente gama de dispositivos  interconectados lleva la tendencia de buscar un mayor número de  direcciones disponibles. 

 

Esta situación (entre otras) conlleva a la  migración desde la versión 4 de dicho protocolo hacia la versión 6. 

 

A lo  largo del último par de años he tenido la fortuna de dar entrenamientos  y pláticas sobre IP versión 6 a distintos grupos y una de las preguntas  más recurrentes es: ¿Qué pasó con la versión 5? 

 

Eso es lo que vamos a  platicar brevemente en esta entrada del Blog, más con el afán de aportar  un dato curioso e interesante que por la importancia que llegó a tener  dicho protocolo.

El 7 de septiembre de 1979, James Forgie del Instituto Tecnológico de  Massachussetts (MIT) publicó el documento IEN119 (Internet Experiment  Note 119) para la IETF describiendo la función y operación del Internet  Stream Protocol (ST). Forgie y su grupo de colaboradores buscaban crear  una extensión del protocolo IP cuya finalidad fuera la de entregar de  manera eficiente flujos de tráfico con una tasa de transmisión  garantizada y poco retraso (http://www.ietf.org/rfc/ien/ien119.txt).  

 

A grandes rasgos, este protocolo es muy parecido a la manera en la que  opera RSVP (Reservation Protocol) en donde las características de  calidad de servicio son mantenidas por cada equipo en la red.

Varios años después, en octubre de 1990, se revisitó este concepto a  través del "Experimental Internet Stream Protocol Version 2" ó ST-II en  el RFC1190 (http://www.ietf.org/rfc/rfc1190.txt).  

 

La intención de esta revisión era atacar áreas que no se habían  trabajado, facilitar su implementación y aumentar el número de  aplicaciones a soportar en este protocolo. 

 

El protocolo ST-II se manejó  siempre de manera experimental y hubo varios intentos de aplicarlo por  grupos de trabajo en IBM, NeXT, Apple y Sun (http://www.oreillynet.com/onlamp/blog/2003/06/what_ever_happened_to_ipv5.html) sin llegar nunca a un estándar.

En octubre de 1994, a través del RFC1700 (http://www.ietf.org/rfc/rfc1700.txt)  se le asignó el número de protocolo 5 (IPv5) para ser utilizado en el  encabezado de IP con el fin de apoyar en la detección del canal que  ST-II utilizaba para dar un trato preferencial al tráfico. 

 

Es decir, si  en el apartado de versión del paquete IP recibíamos un 5, este tráfico  tenía ciertas características de ancho de banda y retraso que debían ser  atendidas por ST-II.

Al final, esta extensión del protocolo IPv4 no pasó nunca de la etapa  experimental. 

 

Se requerían de muchos recursos (espacio en memoria y  ciclos de trabajo del CPU) para mantener los estados de operación de los  flujos de tráfico. 

 

Por si esto no fuera suficiente, no se tenía un  estándar o una solución para varios problemas en su implementación  (mantenimiento de estados, redundancia, soporte a reinicio de equipos,  etc.).

Have fun learning!!!

Rick.

Tomado de:  https://supportforums.cisco.com/community/spanish/core/blog/2013/02/15/ipv6-y-despu%C3%A9s-del-4-va-el-6