Port Aggregation (EtherChannel)

 

Por Oscar Gerometta

La escalabilidad en la capacidad de las redes LAN es un elemento crítico para la evolución de las mismas. En un área dominada por Ethernet se escala básicamente de 10 en 10: 10 Mbps, 100 Mbps, 1 Gbps…

 
Escalar en la capacidad de los enlaces Ethernet requiere actualización de hardware y esto es un costo significativo. Este es el lugar para el desarrollo e implementación de recursos como Port Aggregation, también conocido como EtherChannel.

EtherChannel es la tecnología propietaria de Cisco derivada de un desarrollo inicial de Kalpana (empresa de switching adquirida por Cisco) para dar respuesta a esta necesidad de escalabilidad y puesta de operación en los años ‘90.

 
Con el paso del tiempo dio lugar a la publicación por parte de la IEEE del estándar 802.3ad denominado Link o Port Aggregation.

Ambos protocolos no son compatibles entre sí, uno es claramente estándar mientras el otro no, sin embargo, muchas veces los términos EtherChannel, Port Aggregation y Link Aggregation se utilizan como sinónimos lo que puede dar lugar a confusiones.

Características del port aggregation
Al configurar port aggregation es conveniente tener presentes algunos puntos:

• El canal port aggregation está conformado por cada uno de los enlaces físicos (entre 2 y 8) que lo integran y una interfaz virtual (interface port-channel).
• El port aggregation conforma una conexión uno a uno. Esto significa que conectan un dispositivo individual a otro dispositivo individual, no uno a varios.
• Una vez configurado un port aggregation cualquier configuración que se aplica a la interfaz port-channel afecta a la operación de todo el canal.
  Cualquier modificación de configuración que se realiza sobre un puerto físico afecta exclusivamente a ese puerto físico.
• Todas las interfaces físicas que se integran en el port-channel deben ser de iguales características físicas (medio físico, capacidad).
• Todas las interfaces físicas deben estar operando a la misma velocidad y en el mismo modo dúplex (por eso se sugiere no dejar estos aspectos librados a la autonegociación).
• Todas las interfaces físicas deben estar asignadas a la misma VLAN o estar configuradas como troncales con iguales características (VLAN nativa, VLANs permitidas, tec.).
• Las interfaces físicas que conforman un un canal pueden tener asignado diferente costo de STP.
• En los switches Catalyst ME, solamente los puertos NNI y ENI soportan negociación dinámica con LACP o PAgP.

Mecanismos de negociación
Hay 2 mecanismos básicos para la definición de un port-channel:

• Configuración estática.
• Negociación dinámica.
  Independientemente del protocolo elegido introduce carga de tráfico y demora en la inicialización de los puertos.
  - PAgP
    Es el protocolo propietario de Cisco.
  - LACP
    Es el protocolo estándar definido por la IEEE.

Link Aggregation Control Protocol

• Corresponde a la especificación IEEE 802.3ad.
• Permite agrupar varios puertos físicos en un único canal lógico.
• Permite la negociación automática del canal.
• Al ser estándar permite interoperabilidad entre fabricantes.
• Verifica la consistencia de configuración de los puertos y gestiona el agregado de enlaces los posibles fallos entre los 2 switches.
• Si se modifica la configuración de un puerto físico ese cambio se traslada automáticamente a los demás puertos físicos que forman el canal.
• Ambos dispositivos intercambian paquetes LACP sobre los puertos del canal.
• El switch con menos prioridad define cuáles son los puertos físicos que participan del canal.
• Los puertos son miembros activos del canal de acuerdo a su prioridad; menor valor de prioridad indica una prioridad más alta.
• Se pueden asociar hasta 16 enlaces físicos a un canal lógico, solamente 8 de esos enlaces serán activos de modo simultáneo.
• LACP permite 2 modos de operación:
  - Activo
    Se activa LACP incondicionalmente.
  - Pasivo
    Sólo se activa LACP si detecta otro dispositivo LACP.

Port Aggregation Protocol

• Proporciona servicios semejantes a los de LACP.
• Es un protocolo propietario de Cisco por lo que no permite interoperabilidad con otras marcas.
• Los paquetes se intercambian a través de los puertos que componen el canal.
• Se comparan las capacidades de los puertos y se establece el canal con aquellos puertos que tienen iguales características.
• Sólo se integran en el canal puertos con idéntica configuración de VLANs o troncales.
• Cuando se modifica uno de los puertos que componen el canal, se modifican automáticamente esos parámetros en todos los puertos del canal.
• No es compatible con LACP.
• PAgP presente 2 modos de operación:
  - Desirable
    Activa PAgP sin condiciones.
  - Auto
    Activa PAgP solamente si detecta en el otro extremo un dispositivo PAgP. 

 

 Tomado de: http://librosnetworking.blogspot.com/2019/05/port-aggregation-etherchannel.html

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

 

Cisco Unified Access Data Plane (UADP) ASIC 2.0

Por Oscar Gerometta

Al introducir los switches Catalyst 9000 hice referencia a que una de sus características distintivas me referí a la introducción en su hardware de los nuevos UADP ASIC 2.0 (UADP - Unified Access Data Plane).

Los switches Cat 9K se basan en estos nuevos circuitos ASIC (Application Specific Integrated Circuit) que agregan flexibilidad a la configuración de los mecanismos de reenvío de tráfico del plano de datos flexibilidad en la asignación de las tablas de información tanto SRAM (Static Random Access Memory) como TCAM (Ternary Content Addressable Memory). 

 

Estas innovaciones convierten a estos ASICs en una excepcional herramienta de hardware ajustable a los requisitos de implementación de cada red. Para esto Cisco ofrece un conjunto de plantillas ya probadas para su adaptación.

La característica destacable de estos circuitos en su versión 1.0 fue la convergencia completa del tráfico cableado e inalámbrico. Este fue el primer ASIC programable que constituyó la base de los switches Catalyst 3650 y 3850.

UADP 2.0

Se trata de la última generación de ASICs.

 

 

 

Entre sus características destacan:

• 7460 millones de transistores (la versión 1 utilizaba 1300 millones de transistores).
• Hasta cuadruplica el rendimiento de otro hardware de la industria.
• Soporta tablas SRAM y TCAM flexibles de 384000 contadores que se adaptan a diferentes implementaciones.
• Las tablas de búsqueda se intercambian entre diferentes núcleos.
• Microcontroladores integrados para gestionar cifrado, fragmentación y NetFlow.
• Soporta hasta 240 Gbps de tráfico agregado.
• Un búfer de paquetes de hasta 32 MB.
• Hasta 64000 x2 registros de NetFlow.

Su programabilidad permite incorporar nuevas tecnologías sin necesidad de implementar nuevo hardware y sin sacrificar performance.

 

Entre las mejoras que permiten está la implementación de SD-Access y programabilidad. Una muestra de su flexibilidad ha sido la incorporación de VXLAN sin necesidad de reemplazo de hardware con solamente una actualización del microcódigo. 

 

Estos circuitos (en algunos casos en su versión 1 o 1.1) están presentes en los switches Cisco Catalyst despachados desde 2013.

 

Tomado de: http://librosnetworking.blogspot.com/2020/06/cisco-uadp-asic-20.html

 

Verificación de troncales en switches Catalyst

Verificación de enlaces troncales en switches Catalyst

Por Oscar Gerometta

La operación y mantenimiento de enlaces troncales en switches Cisco Catalyst, respecto de su operación específica como troncal, requiere también de herramientas a nivel del sistema operativo que permiten verificar y monitorear la operación de los enlaces troncales que operamos.
 
En este sentido Cisco IOS y Cisco IOS XE proporcionan una serie de comando show que aplican a este propósito:

• show interfaces status
• show interfaces trunk
• show interfaces switchport

show interfaces status

Se trata de un comando poco utilizado en el monitoreo de enlaces troncales que proporciona una rápida visibilidad de cuáles son los puertos que se encuentran operando en modo troncal.
 
No da mayor información sobre la operación.

Switch> show interfaces status

 Port   Name     Status     Vlan      Duplex Speed Type
 Fa0/1           disabled   routed      auto  auto 10/100BaseTX
 Fa0/2           disabled   routed      auto  auto 10/100BaseTX
 Fa0/3           disabled   routed      auto  auto 10/100BaseTX
 Fa0/4           disabled   routed      auto  auto 10/100BaseTX
 Fa0/5           disabled   routed      auto  auto 10/100BaseTX
 Fa0/6           connected  10        a-full a-100 10/100BaseTX
 Fa0/7           connected  10        a-full a-100 10/100BaseTX
 Fa0/8           connected  200       a-half a-100 10/100BaseTX
 Fa0/9           connected  trunk     a-full a-100 10/100BaseTX
 Fa0/10          disabled   routed      auto  auto 10/100BaseTX
 Fa0/11          disabled   routed      auto  auto 10/100BaseTX
 Fa0/12          disabled   routed      auto  auto 10/100BaseTX
 [se omiten líneas]

show interfaces trunk

 Este comando permite verificar múltiples elementos de la operación de los enlaces troncales:

• Modo en que el puerto se establece como troncal.
  El puerto puede establecerse como troncal a través de una negociación de DTP o por configuración manual.
  En este caso se indica modo "on", esto es configuración manual en modo troncal.
• Protocolo de etiquetado de VLANs utilizado.
  En el ejemplo de abajo es 802.1Q
• Estado operativo del puerto.
  En el ejemplo el estado es "trunking".
• VLAN nativa definida en el puerto.
  En nuestro ejemplo, la VLAN 99.
• VLANs permitidas en ese puerto troncal.
  En el ejemplo son las VLANs 10 y 99.
• VLANs permitidas y activas en ese troncal. Puede ocurrir que en un enlace troncal una VLAN esté permitida pero no se encuentre creada en el switch, con lo que estará permitida pero no activa. Es el caso habitual de puertos con configuración por defecto que tienen todas las VLANs posibles permitidas, pero activas solamente las que están creadas en el switch.
  En el ejemplo son las VLANs 10 y 99.
• VLANs que en este enlace troncal están en modo forwarding (el troncal es parte de la topología activa de STP) y por lo tanto están permitiendo el tráfico de esa VLAN.
  En este ejemplo ambas VLANs utilizan este enlace troncal para el reenvío de tráfico. No hay VLANs bloqueadas.

Switch# show interfaces trunk
Port        Mode    Encapsulation    Status    Native vlan
Gi0/1       on      802.1q           trunking  99

Port        Vlans allowed on trunk
Gi0/1       10,99

Port        Vlans allowed and active in management domain
Gi0/1       10,99

Port        Vlans in spanning tree forwarding state and not pruned

Gi0/1       10,99

Si se indica un puerto específico muestra solamente la información correspondiente a ese puerto. Si no se indica un puerto, muestra todos los puertos troncales del dispositivo.
 
En el caso del ejemplo el switch tiene un solo puerto troncal.

show interfaces switchport

El comando nos permite verificar el estado operativo del puerto en cuanto a su operación en capa 2.

• Modo administrativo: Muestra la configuración realizada en el puerto.
  En este caso se ha configurado como troncal estáticamente utilizando el comando switchport mode trunk.
• Modo operativo: Muestra el modo en que el puerto está operando. Cuando se utiliza DTP muestra el resultado de la negociación del protocolo.
  En este caso el modo en que está operando es troncal.
• Encapsulación administrativa: Refiere a la configuración de encapsulación del puerto.
  En el ejemplo, está configurado para operar utilizando IEEE 802.1Q que es el protocolo por defecto y el único disponible en este caso.
• Encapsulación operativa: Es la encapsulación que de hecho se está utilizando en el enlace.
  En este caso es 802.1Q.
• Negociación: Indica si está operativa la negociación de DTP en el puerto.
  En el ejemplo muestra que la negociación está activa.
• VLAN en modo acceso: Es la VLAN en la cual se colocará el puerto en caso de estar operando en modo acceso si no se indica otra cosa.
• VLAN nativa en modo troncal: Es la VLAN que se asume como VLAN nativa en caso de que el puerto esté operando en modo troncal, si no se indica otra cosa.
• Voice VLAN: Indica si se ha definido una VLAN de voz en ese puerto, y en caso de que se haya definida cuál es el ID de VLAN.
  En el caso del ejemplo no hay VLAN de voz definida.
• A continuación se presenta la información correspondiente a la definición de private VLANs.

Switch# show interfaces GigabitEthernet1/0/1 switchport
 Name: Gig0/1
 Switchport: Enabled
 Administrative Mode: trunk
 Operational Mode: trunk
 Administrative Trunking Encapsulation: dot1q
 Operational Trunking Encapsulation: dot1q
 Negotiation of Trunking: On
 Access Mode VLAN: 1 (default)
 Trunking Native Mode VLAN: 1 (default)
 Voice VLAN: none
 Administrative private-vlan host-association: none
 Administrative private-vlan mapping: none
 Administrative private-vlan trunk native VLAN: none
 Administrative private-vlan trunk encapsulation: dot1q
 Administrative private-vlan trunk normal VLANs: none
 Administrative private-vlan trunk private VLANs: none
 Operational private-vlan: none
 Trunking VLANs Enabled: ALL
 Pruning VLANs Enabled: 2-1001
 Capture Mode Disabled
 Capture VLANs Allowed: ALL

 Protected: false
 Appliance trust: none

Mensaje CDP

Cuando hay diferencia en la definición de la VLAN nativa entre los 2 puertos que componen un enlace troncal, no hay un mensaje de error directo del puerto; sin embargo en los switches Catalyst que tienen activo CDP, la diferencia de configuración entre ambos extremos del troncal genera un mensaje de evento CDP que indica esa falta de coincidencia.

*Mar 1 06:45:26.232: %CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (2), with S2 GigabitEthernet0/1 (99).

El mensaje indica que:

• El puerto GigabitEthernet0/1 de este switch utiliza la VLAN 2 como VLAN nativa.
• El puerto GigabitEthernet0/1 del switch vecino (S2) utiliza la VLAN 99 como VLAN nativa.

Esta diferencia de configuración genera el mensaje "NATIVE VLAN MISMATCH".

Tomado de: http://librosnetworking.blogspot.com/2018/09/verificacion-de-enlaces-troncales-en.html

Otros post sobre el tema

• Configuración de enlaces troncales en swtiches Catalyst
• Comandos: show interfaces status

Que es el Power over Ethernet? (PoE)

Por Oscar Gerometta


Una tecnología a la que no prestamos siempre la debida atención es la que popularmente denominamos de modo genérico PoE.
 
Es decir, el suministro de alimentación eléctrica a través del cableado Ethernet tradicional (UTP).
 
Hoy ya no lo podemos considerar un "opcional" que puede o no estar presente en un switch corporativo. Teléfonos, cámaras IP, access points e incluso terminales pueden recibir su suministro de energía a través del cableado de red. Y este "pueden" toma mayor fuerza cuando consideramos que para el despliege de dispositivos conectados puede ser suficiente el cableado de datos y que por lo tanto no exigiría despliegue de tendido eléctrico.
 
El tema es que no todo PoE es PoE.
 
Es decir... lo que llamamos genéricamente PoE es un conjunto de tecnologías diferentes, cada una de las cuales da prestaciones específicas y diferentes.
 
En dispositivos Cisco hay al menos 5 categorías que debemos considerar:

• Inline Power
• PoE (IEEE 802.3af)
• Enhanced PoE
• PoE+ (IEEE 802.3at)
• Universal PoE

 

Paso a continuación a revisar cada una de estas opciones.

Cisco Inline Power

• Pre-estándar propietario de Cisco.
• Proporciona hasta 6,3 Watts por puerto.
• Diseñado para dar soporte a teléfonos IP como los Cisco 7906G, 7911G, 7941G, etc.

IEEE 802.3af (PoE)

• Primer estándar definido por la IEEE en el junio de 2003.
• Proporciona hasta 15,4 W por puerto.
• Son 12,95 W al dispositivo considerando la pérdida de 100 m. de UTP.
• Utiliza solamente 2 pares del cable UTP categoría 5e.
• Permite dar alimentación eléctrica a  teléfonos 7941G-GE, 7985G y access points.

Enhanced PoE

• Extensión del estándar 802.3af propietaria de Cisco.
• Proporciona hasta 20 W por puerto.

IEEE 802.3at (PoE+)

• Nuevo estándar presentado por la IEEE en el año 2009.
• Proporciona hasta 30 W por puerto.
• Son 25,5 W al dispositivo considerando la pérdida de 100 m. de UTP.
• Utiliza solamente 2 pares del cable UTP categoría 5e.
• Extiende la posibilidad de suministro eléctrico a access points 802.11n, cámaras de seguridad, etc.

Universal PoE

• Desarrollo propietario presentado por Cisco en el año 2011.
• Proporciona hasta 60 W por puerto.
• Son 51 W al dispositivo considerando la pérdida de 100 m. de UTP.
• Utiliza los 4 pares del cable UTP categoría 5e.
• Puede implementarse en sistemas cableados estándar que soportan 802.3at.
• Soporta la alimentación eléctrica de switches Catalyst compactos, sistemas de telepresencia personales, etc.

Más allá de la variante de PoE que implemente cada switch, es importante considerar la capacidad de alimentación eléctrica del dispositivo ya que no depende exclusivamente de la cantidad de puertos con capacidad PoE, sino también de la fuente de alimentación eléctrica implementada.

Tomado de: http://librosnetworking.blogspot.com/2017/04/power-over-ethernet.html

Características avanzadas de SpanningTree: PortFast, BPDU Guard y BPDU Filter

Las características avanzadas del protocolo STP es, posiblemente, uno de los temas menos comprendidos en cualquiera de los niveles de estudio de certificación Cisco. Por lo que se ha podido ver, estas características no han sido claramente documentadas o incluso la documentación existente presenta errores. En este post se describe la operación de PortFast, BPDU guard, y BPDU filter en detalle.

PortFast

La característica de PortFast fue originalmente desarrollada para resolver una situación donde una PC no logra obtener una dirección mediante DHCP debido a que el puerto del Switch no logra una transición al estado de reenvío (Forwarding) a tiempo. Esto se debe al STP que pasa por los estados de escuchar (Listening) y apreder (Learning), los cuales normalmente toman 30 segundos.

 

PortFast permite que el puerto entre en un estado de Forwarding inmediatamente, pasando por alto los estados Listening y Learning. 

Debido a que el objetivo del PortFast es minimizar el tiempo que el puerto debe esperar a que el STP converja pasando por alto los estados de la transición normal solo debe ser configurado en puertos de borde (Edge ports) conectados a dispositivos finales.

Si PortFast está conectada a una interface conectada otro Switch, un bucle (loop) temporal de STP puede crearse. Esto es potencialmente perjudicial para la red. Por eso, el IOS de Cisco muestra un mensaje de advertencia cuando PortFast es habilitado.

Existe mucha desinformación sobre los detalles operacionales de PortFast circulando por la Internet.

Uno de los errores mas comunes es que el PortFast efectivamente deshabilita el STP y no se envían, ni reciben, BPDUs . Absolutamente todo en esta declaración es equivocado. 

El puerto habilitado con PortFast no solamente TRANSMITE BPDUs, sino que el estado operacional del PortFast de hecho depende de los BPDUs de entrada. Si el puerto recibe BPDUs, la característica de PortFast queda deshabilitada.

Ahora, es importante entender la diferencia entre el estado administrativo y operacional del PortFast. El estado administrativo se refiera a que es lo que está configurado en el dispositivo y el estado operacional define si la característica realmente está habilitada o deshabilitada.

Existen básicamente dos formas de habilitar el PortFast: Globalmente (spanning-tree portfast default) o por interface (spanning-tree portfast). Ambos comandos habilitan el PortFast en puertos que están operacionalmente como puertos de acceso. Por ejemplo, un puerto que es configurado administrativamente para negociar un enlace troncal pero falla en hacerlo, entonces opera en modo acceso.

Demos un vistazo a la línea de comandos. Una PC está conectada al Switch S1 en Eth0/2. El puerto está configurado en modo dynamic desirable y el PortFast está configurado en esa interface. Este es el estado administrativo. El Switch S1 no va a establecer un enlace troncal con la PC, entonces el puerto va a volver a modo de acceso y el PortFast va a estar habilitado. Este es el estado operacional.

S1#show run interface eth0/2
interface Ethernet0/2  
switchport mode dynamic desirable
spanning-tree portfast

S1#show interface eth0/2 switchport
Name: Et0/2
Switchport: Enabled
Administrative Mode: dynamic desirable
Operational Mode: static access

S1#show spanning-tree interface eth0/2 portfast
VLAN0001            enabled  

Y que acerca de los BPDUs? Todavía son enviados desde este puerto? Vamos a averiguarlo!.

S1#show spanning-tree interface eth0/2 detail | include BPDU

  BPDU: sent 580, received 0

Claramente el puerto está enviando BPDUs. El STP está activo y corriendo.

Y que pasa si conectamos temporalmente un Switch Root a este puerto? El puerto va a recibir BPDU y la característica PortFast es efectivamente deshabilitada.

S1#show spanning-tree interface eth0/2 detail | include BPDU

BPDU: sent 724, received 10   

S1#show spanning-tree interface eth0/2 portfast

VLAN0001            disabled

Para el siguiente ejemplo, la PC es nuevamente conectada al S1 Eth0/2. Que ocurre si explícitamente configuramos la interface como troncal?  La característica de PortFast ya no va a estar habilitada.

S1#show run interface eth0/2
interface Ethernet0/2               
switchport trunk encapsulation dot1q                                         
switchport mode trunk

spanning-tree portfast 

S1#show interface eth0/2 switchport               
Name: Et0/2
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk

S1#show spanning-tree interface eth0/2 portfast

VLAN0001            disabled

Existe un comando adicional de nivel de interface, spanning-tree portfast trunk, el cual habilita PortFast en enlaces troncales. La documentación puede ser un poco engañosa respecto de este comando. El documento dice, "Este comando habilita PortFast en la interface incluso en modo troncal," y luego dice, "Este comando permite configurar PortFast en enlaces troncales.". La primera frase es precisa. La segunda podría ser interpretada como habilitar PortFast solo en enlaces troncales, lo cual no es cierto y, de hecho, no es posible. No existe un comando para configurar PortFast solamente en puertos troncales operacionales.

S1(config)#interface eth0/2
S1(config-if)#no spanning-tree portfast

S1(config-if)#spanning-tree portfast trunk   

S1#show interface eth0/2 switchport
Name: Et0/2
Switchport: Enabled
Administrative Mode: trunk
Operational Mode: trunk

S1#show spanning-tree interface eth0/2 portfast

VLAN0001            enabled

Si se cambia la interface a modo acceso, la característica PortFast va a permanecer habilitada.

S1#show run interface eth0/2
interface Ethernet0/2
switchport mode access
spanning-tree portfast trunk

S1#show interface eth0/2 switchport       
Name: Et0/2
Switchport: Enabled
Administrative Mode: static access                     
Operational Mode: static access

S1#show spanning-tree interface eth0/2 portfast   

VLAN0001            enabled

Una convergencia más rápida es, posiblemente, el principal beneficio de la característica PortFast, pero no es la única. El Switch nunca genera una Notificación de Cambio de Topología (TCN) cuando el estado de un puerto habilitado con PortFast cambia. En redes muy grandes (y planas) se puede llegar a un punto en el que la red está en un constante cambio de topología. Esto puede derivar en grandes problemas como una inundación excesiva de tráfico unicast, el cual puede hacer que la red se ponga lenta. Por eso es importante implementar correctamente el PortFast en la red.

BPDU Guard

 

BPDU guard previene que un puerto reciba BPDUs. Si el puerto recibe un BPDU, el puerto es colocado en un estado de error-disabled como una manera de proteger el puerto.

De la misma manera que la característica PortFast, el BPDU Guard tiene dos opciones de configuración: Global (spanning-tree portfast bpduguard default) y por interface (spanning-tree bpduguard enable). Como ya se puede observar de la sintaxis del comando, si es configurado globalmente  BPDU Guard dependerá del estado operacional del  PortFast. Sin importar como PortFast fue configurado, a partir de que ha sido habilitado el BPDU Guard va a estar activo. En el caso de la configuración por interface esta habilita incondicionalmente  BPDU Guard en el puerto, independientemente del PortFast o del modo access/trunk.

Vamos a ver este comportamiento en la línea de comandos.

Los Switches S1 (root) y S2 estan directamente conectados en ambos extremos en el puerto Eth0/0. Vamos a verificar que el comando global no tiene efecto a no ser que esté relacionado con la característica con el PortFast.

Las interfaces están configuradas en modo de acceso, el BPDU Guard está habilitado globalmente, y portfast no está configurado. La configuración es idéntica en ambos switches.

S2#show interface eth0/0 switchport

Name: Et0/0

Switchport: Enabled

Administrative Mode: static access                  

Operational Mode: static access

S2#show spanning-tree interface eth0/0 portfast

VLAN0001            disabled

S2(config)#spanning-tree portfast bpduguard default

S2#show spanning-tree summary

Switch is in pvst mode

Root bridge for:            none

Extended system ID          is enabled

Portfast Default            is disabled

PortFast BPDU Guard Default is enabled

Como puede verse, el BPDU Guard está habilitado globalmente. Solamente mirando el resultado de este comando podría sacarse una conclusión equivocada porque podría esperarse que el puerto esté en err-disabled después de recibir BPDUs. De todos modos, se están recibiendo BPDUs, pero el puerto todavía está transmitiendo. En este caso el PortFast no está habilitado, entonces el BPDU Guard nunca dispara el puerto hacia el estado de err-disable.

S2#show spanning-tree interface eth0/0 detail | include BPDU
  BPDU: sent 0, received 136    

S2#show spanning-tree interface eth0/0 portfast
VLAN0001            disabled

S2#show spanning-tree | begin Interface           
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- ------
Et0/0              Root FWD 100      128.1    Shr

Vamos a activar el PortFast globalmente en S1.

S1(config)#spanning-tree portfast default

S1#show spanning-tree summary
Switch is in pvst mode          
Root bridge for: VLAN0001
Extended system ID           is enabled   
Portfast Default             is enabled
PortFast BPDU Guard Default  is enabled                                       

S1#show spanning-tree interface eth0/0 portfast   
VLAN0001            enabled

S1#show spanning-tree | begin Interface

Interface          Role Sts Cost      Prio.Nbr Type     
------------------- ---- --- --------- -------- ----------
Et0/0              Desg FWD 100      128.1 Shr Edge       

En este punto pueden surgir algunas preguntas: Porque el puerto está todavía reenviando tramas después que la característica PortFast ha sido habilitada? Porque no hay mensajes de log?. La respuesta recae en la operación normal del STP. El Switch está corriendo PVST+, y solamente el root switch envía BPDUs a cada intervalo Hello a no ser que ocurra un cambio en la topología. Debido a que S1 el el root switch y no han ocurrido eventos que provoquen que el S2 envíe un TCN, el S1 no ha recibido ningún BPDUs.

S1#show spanning-tree interface eth0/0 detail | include BPDU|Bpdu 
  Bpdu guard is enabled by default                      BPDU: sent 631, received 0

Ejecutemos el mismo comando en el S2.

S2(config)#spanning-tree portfast default

Tan pronto como el S2 ha recibido el siguiente BPDU del S1, el puerto cambia a err-disabled y los mesajes de error se presentan en la consola.

*Mar  3 11:26:15.503: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Ethernet0/0 with BPDU Guard enabled. Disabling port.
*Mar  3 11:26:15.503: %PM-4-ERR_DISABLE: bpduguard error detected on Et0/0, putting Et0/0 in err-disable state
*Mar  3 11:26:16.504: %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to down
*Mar  3 11:26:17.503: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to down

S2#show interface status err-disabled
Port      Name    Status        Reason      Err-disabled Vlans

Et0/0              err-disabled  bpduguard

Existen dos formas de recuperar un puerto en estado de err-disabled, una es ingresando manualmente los comandos shutdown y no shutdown y la otra forma es con el comando errdisable recovery cause bpduguard. El intervalo de recuperación por defecto es de 300 segundos, pero puede cambiarse con el comando errdisable recovery interval.

S2#show errdisable recovery
ErrDisable Reason           Timer Status
-----------------           --------------
arp-inspection               Disabled
bpduguard                    Enabled
channel-misconfig (STP)      Disabled       

--- output omitted ---                                       
                                                                               
Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:

Interface      Errdisable reason      Time left(sec)
---------      -----------------      --------------
Et0/0                  bpduguard          275

Obviamente, la recuperación automática no arregla la causa del problema. Después de 300 segundos el puerto debe ser rehabilitado por un breve periodo de tiempo hasta que entre nuevamente en estado de err-disabled cuando el siguiente BPDU desde el root switch sea recibido.

Ahora probemos rápidamente que la configuración de nivel de interface BPDU Guard es de hecho independiente del estado operacional PortFast o el modo access/trunk.

S2(config)#no spanning-tree portfast default
S2(config)#no spanning-tree portfast bpduguard default
S2(config)#interface Eth0/0
S2(config-if)#spanning-tree bpduguard enable

S2#show spanning-tree interface eth0/0 portfast
VLAN0001            disabled  

S2#show spanning-tree interface eth0/0 detail | include Bpdu|BPDU
Bpdu guard is enabled
BPDU: sent 0, received 140

Cuando el primer BPDU es recibido, la interface se coloca en err-disabled.

*Mar  3 12:55:33.953: %SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port Et0/0 with BPDU Guard enabled. Disabling port.
*Mar  3 12:55:33.953: %PM-4-ERR_DISABLE: bpduguard error detected on Et0/0, putting Et0/0 in err-disable state
*Mar  3 12:55:35.325: %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to down

S2#show interface status err-disabled

Port      Name    Status        Reason      Err-disabled Vlans
Et0/0            err-disabled  bpduguard

BPDU Filter

La función BPDU Filter previene que ciertos puertos específicos envíen o reciban  BPDUs. 

Nuevamente, existen dos metodos para configurar esta característica: Globalmente (spanning-tree portfast bpdufilter default) y por interface (spanning-tree bpdufilter enable). La configuración por interface filtra incondicionalmente BPDUs en ambos sentidos, de ingreso y de salida - Independientemente del estado operacional del PortFast o del modo access/trunk.

Este es efectivamente el equivalente a apagar el STP. Pero hacer esto puede ser muy peligroso porque se puede crear fácilmente un loop permanente. Llama la atención que el IOS no muestre un mensaje de advertencia cuando este comando se aplica. Habilitar PortFast en la interface equivocada no representa un gran riesgo como en el caso del BDPU Filter, pero el IOS en ese caso si manda una advertencia al administrador.

Vamos a ver esto en acción. Los Switches S1 (root) y S2 están conectadas con los enlaces. Eth0/1 en S2 está bloqueado.

S1#show spanning-tree | begin Interface
                                       
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------
Et0/0              Desg FWD 100      128.1    Shr
Et0/1              Desg FWD 100      128.2    Shr

S2#show spanning-tree | begin Interface
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------
Et0/0              Root FWD 100      128.1    Shr

Et0/1              Altn BLK 100      128.2    Shr

Que ocurre si se habilita BPDU Filter en el S2?

S2(config)#interface range eth0/0 - 1
S2(config-if-range)#spanning-tree bpdufilter enable

S1#show spanning-tree
                                     
VLAN0001                                          
  Spanning tree enabled protocol ieee
  Root ID   Priority    32769 
            Address aabb.cc00.1f00                  
            This bridge is the root
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
                                                                               
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
            Address    aabb.cc00.1f00
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
            Aging Time  300 sec
                                                                               
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- -----------------------
Et0/0              Desg FWD 100      128.1    Shr                   
Et0/1              Desg FWD 100      128.2    Shr

S2#show spanning-tree
VLAN0001                                                                       
  Spanning tree enabled protocol ieee                        
  Root ID    Priority    32769                  
             Address    aabb.cc00.2000
            This bridge is the root
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
                                                                               
  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
            Address    aabb.cc00.2000
            Hello Time  2 sec  Max Age 20 sec  Forward Delay 15 sec
            Aging Time  300 sec
                                                                               
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- -----------------------
Et0/0              Desg FWD 100      128.1    Shr
Et0/1              Desg FWD 100      128.2    Shr

Ambos Switches ahora piensan que son el root y todas sus interfaces están en estado de forwarding. Las BPDUs no se envían ni reciben en S2.

S2#show spanning-tree interface eth0/0 detail | include Bpdu|BPDU
  Bpdu filter is enabled
  BPDU: sent 0, received 0

S2#show spanning-tree interface eth0/1 detail | include Bpdu|BPDU
  Bpdu filter is enabled
  BPDU: sent 0, received 0

Demos un vistazo a la utilización del ancho de banda. Son muchos paquetes!.

S2#show interface eth0/0
Ethernet0/0 is up, line protocol is up (connected)
  30 second input rate 12481000 bits/sec, 20262 packets/sec
  30 second output rate 12482000 bits/sec, 20264 packets/sec

S2#show interface eth0/1 
Ethernet0/1 is up, line protocol is up (connected)
  30 second input rate 12477000 bits/sec, 20256 packets/sec
  30 second output rate 12474000 bits/sec, 20250 packets/sec

Este es un ejercicio emulado en IOL. Además de los dos switches, no existen otros dispositivos y ningún otro tráfico. Entonces usted se puede imaginar como esta configuración podría rápidamente colapsar la red. Use con mucha precaución este comando.

La configuración global es mas intrincada. De manera similar a la característica BPDU Guard, el BPDU Filter global es habilitado en las interfaces que tiene el estado PortFast operational. En modo global, el switch no filtra los BPDUs de entrada, pero la mayoría (aunque no todas) las BPDUs de salida son filtradas. Cuando un puerto se enciende, se mandan 11 BPDUs. Si se reciben BPDUs las características PortFast y BPDU Filter se deshabilitan.

Vamos a ver como trabaja esto. Ambas interfaces en S1 han sido configuradas con BPDU Filter de interface. Ambas interfaces en S2 tienen el spanning-tree portfast trunk configurado entonces PortFast va a estar operacional y BPDU Filter está habilitado globalmente.

S1#show spanning-tree interface eth0/0 detail | include Bpdu|BPDU
  Bpdu filter is enabled
  BPDU: sent 0, received 0
                                                                         
S1#show spanning-tree interface eth0/1 detail | include Bpdu|BPDU
  Bpdu filter is enabled
  BPDU: sent 0, received 0

S2#show spanning-tree summary
Switch is in pvst mode
Root bridge for: VLAN0001
Extended system ID           is enabled
Portfast Default             is disabled
PortFast BPDU Guard Default  is disabled        

Portfast BPDU Filter Default is enabled

El puerto manda 11 BPDUs y se detiene.

S2#show spanning-tree interface eth0/0 detail | include Bpdu|BPDU
  Bpdu filter is enabled by default
  BPDU: sent 11, received 0

S2#show spanning-tree interface eth0/1 detail | include Bpdu|BPDU
  Bpdu filter is enabled by default

  BPDU: sent 11, received 0

Note lo que ocurre en S2 cuando el BPDU Filter de interface es deshabilitado en S1.

S1(config)#interface range eth0/0 - 1
S1(config-if-range)#no spanning-tree bpdufilter enable

S2#debug spanning-tree events
*Mar  3 15:01:09.027: STP: VLAN0001 heard root 32769-aabb.cc00.1f00 on Et0/1
*Mar  3 15:01:09.027: supersedes 32769-aabb.cc00.2000
*Mar  3 15:01:09.027: STP: VLAN0001 new root is 32769, aabb.cc00.1f00 on port Et0/1, cost 100 *Mar  3 15:01:09.027: STP: VLAN0001 new root port Et0/0, cost 100
*Mar  3 15:01:09.027: STP: VLAN0001 sent Topology Change Notice on Et0/0
*Mar  3 15:01:09.027: STP[1]: Generating TC trap for port Ethernet0/1

*Mar  3 15:01:09.027: STP: VLAN0001 Et0/1 -> blocking

El S2 escucha BPDUs superiores, deshabilita efectivamente el BPDU Filter y retorna el STP a su operación normal. El Eth0/0 se convierte en root port y Eth0/1 queda bloqueado.

S2#show spanning-tree | begin Interface
Interface          Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------
Et0/0              Root FWD 100      128.1    Shr

Et0/1              Altn BLK 100      128.2    Shr

Resumen

En este artículo hemos presentado características avanzadas de STP de manera extensa, pero a continuación nos gustaría resaltar los puntos más importantes:

• PortFast mueve inmediatamente el puerto al estado de forwarding, pasando por alto los estados listening y learning.
• Un puerto con PortFast habilitado continua enviando BPDUs.
• Si se recibe un BPDU, PortFast se deshabilita.
• El switch nunca genera un TCN cuando un puerto habilitado con PortFast cambia entre up o down.
• Existe diferencia entre estado administrativo y estado operacional.
• El comando spanning-tree portfast trunk habilita PortFast en puertos de acceso y troncales.
• BPDU Guard y BPDU Filter en modo global son dependientes de PortFast operacional.
• BPDU Guard y BPDU Filter en modo interface es incodicional.
• Un BPDU Filter mal configurado es mucho mas peligroso que un PortFast mal configurado, aun así el IOS no genera un mensaje de advertencia acerca de esto.
• PortFast puede crear un loop temporal de maximo 2 segundos (intervalo por defecto del Hello) hasta que el siguiente BPDU se recibe y el PortFast queda deshabilitado. El BPDU Filter puede crear un loop permanente porque todos los BPDUs son ignorados.
• Recuerde la operación del STP - en que casos los BPDUs son enviados y cuando no

Tomado de: https://learningnetwork.cisco.com/blogs/vip-perspectives/2016/03/10/advanced-stp-features-portfast-bpdu-guard-and-bpdu-filter
Traducido por José R. Torrico Gumucio, Instructor Cisco Networking Academy