cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
Avisos

Routing y Switching Blogs

Etiquetas
187 Vistas
0 Comentarios

Selección de Multi VRF utilizando PBR

 

Diagrama VRF SELECTIVO MAIN.PNG

Por lo general cuando trabajamos con VRF (Virtual Routing and Forwarding) asignamos un único VRF a interfaces lógicas o físicas. Pero que sucede si nos encontramos con un esquema como el que se muestra arriba; Donde 2 clientes conectados en una arquitectura de broadcast, donde las interfaces que los conectan se encuentran en el mismo segmento de red. Lo siguiente que se debe observar es que la interface FastEthernet0/1 es utilizada para recibir el tráfico de clientes externos como es R4 hacia R2 y R3. Esto comienza a generar un 'brainstorming' donde la pregunta es: ¿Cómo hare pasar tráfico de 2 clientes distintos a través de una sola interface, si teóricamente solo puedo configurar un VRF bajo la interface FastEthernet 0/0 de R1? o es VRF CLIENTE-A o VRF CLIENTE-B pero no ambos. 

 

Una solución puede ser, utilizando sub-interfaces, pero esto viene a desarmar la topología, direccionamiento IP, agregar información a los protocolos de enrutamiento, solicitar X cantidad de ventanas de mantenimiento y pruebas, etc. Puede llegar a ser más complejo de lo que parece. 

La segunda solución puede llegar a ser más sencilla y es cuestión de aplicar ciertos comandos, de los cuales platicaremos a continuación. 

 

* Los equipos ya se encuentra pre-configurados con el direccionamiento IP, VLANs por defecto en el switch, respectivas rutas estáticas por defecto y protocolos de enrutamiento *

Observemos la configuración inicial:

 

Router 1VRF MULTI INICIAL 1.PNG

 

VRF MULTI INICIAL 1-2.PNG

 

Notemos que la interface FastEthernet0/0 no se encuentra en asociada a ningún VRF. 

 

Router 2VRF MULTI INICIAL 2.PNG

 

VRF MULTI INICIAL 2-2.PNG

 

Router 3VRF MULTI INICIAL 3.PNG

 

VRF MULTI INICIAL 3-2.PNG

 

Router 4

VRF MULTI INICIAL 4.PNG

 

VRF MULTI INICIAL 4-2.PNG

 

Verifiquemos adjacencias entre R1 y R4:

 

VRF MULTI INICIAL 1 TABLES.PNGVRF MULTI INICIAL 1 TABLES 2.PNG

 

Una vez verificada la conectividad entre R1 y R4 realizamos pruebas de ping para asegurarnos que no existe comunicación entre las redes de cada VRF.

VRF MULTI INICIAL 4  TEST1.PNG

 

Muy bien, podemos observar que no existe ninguna comunicación entre las redes del mismo VRF.

A continuación, incluimos los pasos a seguir para implementar Selección de Múltiples VRF's utilizando Policy Based Routing (PBR), toda la configuración se realizara en R1:

 

Paso 1) Crear rutas estáticas bajo su respectivo VRF para alcanzar las redes que se encuentran en la arquitectura de broadcast.

 

VRF MULTI INICIAL 1 STEP1.PNG

 

Observemos los distintos siguientes saltos (Next Hops), podemos hacer nuevamente la prueba del ping y no tendrémos conectividad aún:

 

VRF MULTI INICIAL 4  TEST2.PNG

 

Paso 2) Crear ACL's con los prefijos que deseamos alcanzar:

 

VRF MULTI INICIAL 1 STEP2.PNG

 

Paso 3) Crear un route-map, coincidir en el las ACL's previamente creada y asignarles sus respectivos VRF's:

 

VRF MULTI INICIAL 1 STEP3.PNG

 

Paso 4) 

           Paso 4.1) Aplicar el route-map en la interface que conecta con la arquitectura de broadcast, en este caso la interface FastEthernet 0/0.

 

VRF MULTI INICIAL 1 STEP41.PNG

 

          Paso 4.2) Configurar el siguiente comando bajo la interface FastEthernet 0/0, ip vrf receive <nombre del VRF>

 

VRF MULTI INICIAL 1 STEP42.PNG

 

VRF MULTI INICIAL 1 STEP422.PNG

 

Este comando es utilizado para indicar los nombres de los VRF's que se utilizaran en la selección, básicamente deben coincidir con los VRFs que están siendo aplicados, si esto no es configurado, los paquetes serán descartados.  

 

Paso 5) Redistribuimos las rutas estáticas en sus respectivos protocolos de enrutamiento, esto con la finalidad de que R4 sepa como alcanzar los prefijos detrás de R1:

 

VRF MULTI INICIAL 1 STEP5.PNG

 

Observemos las tablas de enrutamiento de R4:

 

VRF MULTI INICIAL 4 TABLAS NEW.PNG

 

Una vez hemos completado esta configuración podemos realizar la prueba de ping una vez más y observemos el resultado:

 

VRF MULTI INICIAL 4  TEST3.PNG

 VRF MULTI INICIAL 1  TEST1 final.PNG

 

La comunicación es existosa!. 

15777 Vistas
0 Comentarios


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

6433 Vistas
2 Comentarios

FUNDAMENTOS DE QoS - CALIDAD DE SERVICIO

Focus on Quality

Calidad de Servicio, por sus siglas en inglés QoS (Quality of Service), es una de las características que debe tener una red convergente moderna bien diseñada (junto con Seguridad, escalabilidad y tolerancia a fallas) debido a que las aplicaciones y servicios que requieren los usuarios finales necesitan de la transmisión de voz y video en vivo con un buen nivel de QoE (Quality of Experience). Pero con el uso de estas aplicaciones, es posible que ocurra congestión en la red, justamente por la demanda excesiva de ancho de banda que generan dichas aplicaciones para que funcionen correctamente al ejecutarse simultáneamente es necesario mecanismos de control de tráfico y no degradar la experiencia del usuario. 

QoS-Necesidad

Cuando el volumen del tráfico supera la capacidad de la red, los dispositivos empiezan a "encolar" el tráfico en una memoria intermedia (búfers) hasta que la información pueda ser procesada y despachada. Es obvio que este encolamiento de paquetes provoca retardos en la red.

Cuando los búfers llegan a su límite de espacio de memoria, los dispositivos empiezan a desechar paquetes.

QoS-Encolamientos

Terminología Básica de QoS

  • Ancho de Banda: Es la capacidad que posee un medio o un dispositivo para transmitir y procesar datos medidos en un tiempo determinado. El AB digital se mide en bps (bits por segundo).
  • Cuando existe Congestión de Red se genera retardos en la transmisión. Dichos retardos podrían dar lugar ajitter (variación del retardo) y pérdida de paquetes
  • Retardo o Latencia se refiere al tiempo que le toma a un paquete viajar desde un origen hasta un determinado destinado. Existen varias fuentes de retardo, por ejemplo el retardo del proceso de encapsulación de la información para salir a un medio (code delay y retardo de paquetización y serialización), retardo de encolamiento, propagación, etc.
  • Los puntos de embotellamiento en la red (mayor probabilidad de congestión) son los mejores candidatos para implementar QoS en dichas interfaces.

Características del tráfico empresarial moderno

Tráfico de Voz:

Tráfico de VozTal como se aprecia en la figura anterior, el tráfico de voz tiene un comportamiento predictivo y constante, es tolerante a pérdidas pequeñas de datos, además no consume todos los recursos de la red (benigno), no obstante, es muy sensible al retardo y mucho más al jitter. La voz emplea UDP en la capa de transporte por lo que no admite retransmisiones, lo que implica que debe tener prioridad sobre el resto de tráfico.

Tráfico de Video:

Tráfico de VideoComparando el tráfico de video con el de voz, el primero resulta ser impredecible, inconsistente y no constante. A diferencia de la voz, el video es menos tolerante a la pérdida de datos.

Datos:

Tráfico de Datos
Los datos empresariales que no son ni voz ni video pueden tener comportamiento predictivo o no y pueden ser muy consumidores de recursos o no, todo depende del tipo de aplicación que esté corriendo en la red, pero, a diferencia de Voz y Video es insensible al retardo (se debe considerar si los datos son interactivos o no para ello) e insensible a la pérdida de paquetes debido a sus mecanismos de retransmisión por TCP.

Técnicas de Encolamiento

Las políticas de QoS implementadas en una red se activan únicamente cuando ocurre algún tipo de congestión en la red. 

Las técnicas de encolamiento son una de las técnicas empleadas para administrar las congestiones que ocurren en una red, técnicas que permiten almacenar, priorizar y si se requiere, re ordenar los paquetes antes de ser transmitidos.

Existen algunos métodos de encolamiento, entre los más importantes están:

  • FIFO - Fist-Input-First-Output y Weighted Fair Queuing (WFQ)

Encolamiento 1

  • Class-Based WFQLow Latency Queuing (LLQ)

Encolamiento 2

Modelos de Implementación QoS

Modelos de Políticas QoS

Herramientas para Calidad de Servicio

Para implementar QoS se definen dos acciones:

  1. Clasificar tráfico
  2. Priorizar tráficos basándose en la marca empleada para clasificar dicho tráfico en momentos de congestión
  3. Alternativamente se podría usar técnicas para evitar la congestión antes de que esta ocurra.

QoS Tools

Classification and Marking Tools (C&M Tools)

En capa 2 (Trama 802.1Q)

C&amp;M Tools - L2

En el paquete IPv4

C&amp;M Tools - L3

En el paquete IPv6:

C&amp;M Tools - L3 - IPv6

DSCP se basa en un mecanismo llamado PHB (Per Hop Behavior) para definir la probabilidad de descarte de un paquete y prioridad de envío:

Categorías PHB

Cuando un dispositivo de red recibe información marcada, es importante definir si se confía en esa marca o se realiza un nuevo marcaje, esto se conoce como Límites de Confianza. Se recomienda que ese límite sea lo más cercano al origen del tráfico.

 QoS Trust Boundary

Implementación Básica de QoS (MQC) en Routers

Una técnica generalizada para implementar mecanismo de QoS en equipos Cisco se denomina MQC - Modular QoS CLI, el cual define tres fases:

  1. Clasificación del tráfico usando técnicas como ACLs o NBAR (Network - Based Application Recognition) 

    class-map NBAR

  2. Definiendo acciones mediante policy-maps 

    Policy-map - Definiendo acciones (marcaje y reserva de AB)

  3.  Aplicando la política a una interfaz service-policy 

    service-policy - Aplicando la Política de QoS

Espero haya sido de su agrado este tema, simplemente fueron los fundamentos básicos pero al grano sobre Calidad de Servicio en equipos L3 que operan con IOS.

Sigan implementando topologías con QoS, en un próximo blog, explicaré cómo se configura QoS en equipos L2 como switches Catalyst.

Saludos de Quito, Ecuador.

Gustavo

1243 Vistas
1 Comentario

Dynamic Multipoint VPN

Evolución de la conectividad

La conectividad en redes WAN ha evolucionado con el fin de que se vuelva más sencilla y segura, más ahora que el Internet es un método común para unir sectores empresariales distantes, como la matriz con sus sucursales.

Matriz y Sucursales

Un método para lograr una conectividad segura en entornos públicos es mediante VPNs y en el mundo de Cisco,GRE (Generic Routing Encapsulation) ha sido sin duda una excelente opción debido a sus características que permiten la transmisión de comunicaciones broadcastsmulticasts, sin embargo tenía un problema de escalabilidad, mantenimiento y creación de los túneles, pues es necesario establecer manualmente la VPN por cada uno de las conexiones Matriz-Sucursal que exista.

Con el fin de sobrellevar esa dificultad se creó DMVPN.

Definición de DMVPN

DMVPN, por sus siglas Dynamic Multipoint VPN, usa un método para dinámicamente descubrir los destinos de los túneles creados mediante GRE (mGRE - multipoint GRE) y aprendidos por NHRP - Next-Hop Resolution Protocol, sin descuidar a la seguridad como eje transversal de las comunicaciones a través de IPsec. Con todo ello, IPsec puede escalar muy bien en entornos hub-and-spoke, así como soportar la segmentación de tráfico a través de VPNs y VRFs.

En una típica implementación hub-and-spoke IPsec, el router Hub debe tener crypto-maps, crypto ACLs, túneles GRE y configuraciones de pares ISAKMP por separado para cada router Spoke, en general un problema de escalabilidad que DMVPN sobrellevó sin dificultad.

En entornos DMVPN, la información de los routers Spoke no es explícitamente configurada en el router Hub, en su lugar, dicho Hub posee una simple interfaz mGRE configurada y un conjunto de perfiles que aplican a los routers Spokes, mientras los Spokes podrían apuntar a uno o varios Hubs dando lugar a redes redundantes que fomentan el balanceo de carga del tráfico, además sin quitar las características de GRE como el hecho de soportar tráfico multicast desde el Hub hacia los Spokes. 

Mediante NHRP es posible determinar la dirección de destino de los Spoke mediante un formato de pregunta/respuesta entre clientes (NHC - Next-Hop clients) y servidores (NHS - Next-Hop Servers). Los NHC se "registran" en los NHS.

NHRP - NHC/NHS

Fases de DMVPN

Existen tres fases de DMVPN:

  1. Fase 1 (Phase 1): Conectividad solo Hub a Spoke.
  2. Fase 2 (Phase 2): Capacidad de comunicación directa entre Spokes
  3. Fase 3 (Phase 3): Mejora las capacidades de comunicación entre Spokes

Configuración de DMVPN

Con el fin de entender rápidamente la configuración en las diferentes fases de DMVPN, se empleará la siguiente topología simple:

DMVPN Topology

La dirección IPv4 de las interfaces mGRE serán de la red 192.168.1.0/24, donde:

  • La Matriz empresarial tendrá la dir. IPv4 192.168.1.1/24
  • La Sucursal 1 tendrá la dir. IPv4 192.168.1.2/24
  • La Sucursal 2 tendrá la dir. IPv4 192.168.1.3/24

Cabe recalcar que las interfaces físicas de la Matriz y Sucursales (10.1.1.1, 10.10.10.1 y 10.20.20.1) conectadas al ISP deben tener conectividad entre ellas previo a la configuración de DMVPN.

Fase 1: Conectividad sólo Hub a Spoke

NHS - Next-Hop Server (HUB)

NHS-Fase1

NHC - Next-Hop Client (Spoke)

NHC-Fase1

NHC - Next-Hop Client (Spoke2)

NHC-2-Fase1

Al momento de configurar el Hub con OSPF como protocolo de enrutamiento sobre la DMVPN para alcanzar las redes de la Matriz y las Sucursales, se debe incluir los siguientes comandos:

HUB-FASE1

Y en los spokes:

Spoke-Fase1

Una vez realizado ello, los túneles DMVPN dinámicos en el Hub y estáticos en los spokes se han levantado

Show dmvpn HUB

Show dmvpn SPOKE

Cabe recalcar que para la comunicación Spoke a Spoke, siempre el tráfico pasará por el Hub en la Fase 1, por ejemplo para alcanzar la Sucursal 2 (172.16.3.1) desde Sucursal 1, habrá 2 saltos y no solo uno:

traceroute spoke a spoke fase1

Fase 2: Conectividad Spoke a Spoke Directamente

La configuración del Hub es exactamente igual en la Fase 1 como en la Fase 2, la única diferencia radica en que la interfaz mGRE del túnel DMVPN debe ser de tipo Broadcast en caso de usar OSPF como protocolo de enrutamiento sobre dicha DMVPN.

Únicamente se mostrará la configuración de los Spokes (Spoke - Sucursal 1), considerando que también la interfaz mGRE debe ser de tipo Broadcast al momento de configurar OSPF como protocolo de enrutamiento sobre la DMVPN:

NHC - Next-Hop Client (Spoke)

NHC-Fase2

Al configurar el Spoke, éste tendrá un túnel estático hacia el Hub (NHS) y un túnel dinámico hacia el resto de Spokes (NHC), por lo que la conectividad ahora será directa Spoke con Spoke (un sólo salto, sin pasar por el Hub)

Show dmvpn spoke fase2

traceroute spoke a spoke fase2

IPSec en Fase 2:

DMVPN no puede ser concebido sin seguridad en la transmisión de datos, por lo que IPSec es parte fundamental de esta forma de conexión, ya que así es posible dar a la conexión Confidencialidad, Integridad, Autenticación y Anti repudio (CIA)

La configuración y funcionalidad de IPSec es simular a la realizada con túneles GRE-IPsec (IKE Fase 1, IKE Fase 2 e implementación en una interfaz), pero la dirección de los pares destino es 0.0.0.0 y se emplea perfiles IPSec. 

La configuración mostrada para el Hub, debe ser la misma en los Spokes:

IPSec-FASE2-HUB

Como se dieron cuenta, DMVPN es una excelente opción al momento de escoger una forma segura y escalable de transmitir información entre sitios empresarial con arquitectura tipo Hub-and-Spoke. 

Espero haya sido de su agrado este tema, sigan implementando topologías con DMVPN, en un próximo blog, explicaré cómo se configura la Fase 3 de DMVPN

Saludos de Quito, Ecuador.

Gustavo

14804 Vistas
0 Comentarios

Direccionamiento IPv6

IPv6-1

Si bien IPv6 ha estado con nosotros por algún tiempo, muchos ingenieros en redes desconocen cómo realizar esquemas de direccionamiento en entornos, por ejemplo, Dual-Stack (funciona tanto IPv4 como IPv6 en la misma arquitectura), o en entornos con sólo direcciones IPv6, por ello, en este blog haré una breve, pero concisa explicación sobre el direccionamiento IPv6

//diocesanos.es/blogs/equipotic/2015/06/01/ipv6-como-activarlo-o-desactivarlo/ //www.worldipv6launch.org/   

Necesidad de IPv6

IPv6 es el protocolo sucesor de IPv4. La creación de IPv6 fue motivada principalmente por el agotamiento de direcciones IPv4, es más, muchas predicciones indican que entre el año 2015 y 2020 las direcciones IPv4 de los cinco RIRs se habrán acabado completamente, ya que tendencias tecnologías como BYOD (Bring Your Own Device - Trae tu propio dispositivo) en las empresas, IoE (Internet of Everything) en el hogar, oficina e industrias, disminución de las brechas tecnologías en la población, convergencia a redes todo IP en las comunicaciones y aumento demográfico mundial han consumido casi en su totalidad las direcciones IPv4 públicas.

//www.indexeb.co.uk/news/

Métodos para alargar la vida de IPv4 se han creado, como NAT (Traducción de direcciones Privadas a Públicas), pero debido a los problemas en las comunicaciones que presentan, la transición a IPv6 llegó.

Métodos de transición IPv4-IPv6

IPv4 tiene un máximo de aproximadamente 4300 millones de direcciones (bastante menos que la cantidad de población mundial hoy por hoy), pero IPv6 tiene al rededor de 340 sextillones de direcciones, es decir, casi la misma cantidad que el total de direcciones IPv4 para cada ser humano sobre la Tierra!!!!, además en el momento de la creación de IPv6 se eliminaron ciertas deficiencias en la estructura de las direcciones IPv4 y se incluyeron mejoras tanto en seguridad como eficiencia.

//www.ipv6ve.info/project-definition/direccionamiento-ipv6

Representación de Direcciones IPv6

Las direcciones IPv6 tienen una longitud de 128-bits y se escriben en formato Hexadecimal.

Están compuestas por 32 dígitos agrupados en lo que se suele denominar como "Hexteto" (4 dígitos hexadecimales), es decir, en 8 hextetos separados por dos puntos (:) cada hexteto

Dirección IPv6

Cada Hexteto tiene 16 bits (4 dígitos Hexadecimales, cada dígito hexadecimal se representa con 4 bits - Nibble)

Reglas de Compresión en Direcciones IPv6

Debido a la gran extensión de una dir. IPv6, hay dos reglas básicas para comprimirlas:

  • Eliminar los ceros INICIALES de cada hexteto
  • Hextetos consecutivos compuestos solo por 0s, pueden ser comprimidos con ::, pero sólo puede hacerse una vez por dirección y por sentido.

//sites.google.com/site/redeslocalesyglobales/6-arquitecturas-de-redes/6-arquitectura-tcp-ip/7-nivel-de-red/8-direccionamiento-ipv6/2-direccionamiento-ipv6/3-representacion-de-las-direcciones-ipv6

Longitud de Prefijo en IPv6

Debido a la extensión de una dir. IPv6 no se tiene una máscara de subred en formato de dirección IPv6, es por ello que solamente se emplea la longitud o duración de prefijo para delimitar la porción de red y de host en este tipo de direcciones. La longitud de prefijo pude ir desde /0 hasta /128, siendo la longitud de prefijo típica en un host /64.

Longitud de Prefijo en direcciones IPv6 - Tomada de Cisco Networking Academy

Tipos de Direcciones IPv6

Existen tres tipos de direcciones IPv6

  1. Unicast: Comunicación de uno a uno. Las direcciones IPv6 de origen y de destino en el paquete IP representan una interfaz de un dispositivo en particular.
  2. Multicast: Comunicación de uno a varios, donde esos varios deben pertenecer a un grupo multicast
  3. Anycast: Comunicación de uno al más cercano. Empleado por lo general con servidores (por ejemplo DNS) que se agrupan con la misma dirección IPv6.

En IPv6 NO existe Broadcast ya que es una comunicación considerada como ineficiente e insegura, es por eso que fue reemplazado por multicast en IPv6.

Direcciones IPv6 Unicast

Dir. IPv6 Unicast - Tomado de Cisco Networking Academy

Para que un host, pueda salir al Internet con IPv6, requiere de dos direcciones:

  • Unicast Global: Direcciones públicas y enrutables.

IPv6 Unicast Global - Tomado de Cisco Networking Academy

Consta de Tres partes:

  1. Prefijo Global: Tres primeros hextetos, entregados por un ISP a una empresa. Actualmente los ISP entregan en el rango 2000::/3, es decir el primer hexteto va de 2000 a 3FFF
  2. ID de subred: Cuarto hexteto dedicado para subnetear dentro de una organización
  3. ID de Interfaz: Cuatro últimos hextetos (64 bits) que identifican a un host en particular

Prefijo Global IPv6 - Tomado de Cisco Networking Academy

  • Link-Local: Empleada para comunicaciones con dispositivos en el mismo segmento/enlace o LAN. Para identificarlas, el primer hexteto de este tipo de direcciones va en el rango FE80::/10 (de FE80 a FEBF)

IPV6 Unicast Link-Local - Tomada de Cisco Networking Academy

Direcciones IPv6 Multicast

Las direcciones IPv6 multicast se reconocen ya que tienen la forma FFxx::/8

Hay dos tipos de direcciones IPv6 multicast:

  • Multicast Asignada: Existen dos tipos
  1. Multicast de todos los nodos - FF02::1. Multicast que ha reemplazado a broadcast en IPv6, todos los equipos (routers, switches, PC, Laptops) con IPv6 habilitados contestan a este tipo de multicast.
  2. Multicast de todos los routers - FF02::2. Multicast que emplean para comunicarse entre routers IPv6, es decir aquellos que se han configurado con el comando (config)#ipv6 unicast-routing
  • Multicast de Nodo Solicitado

Funcionalmente similar al multicast de todos los nodos, aunque se emplea principalmente con el protocolo NDP (Neighbor Discovery Protocol) transportado en ICMPv6 para reemplazar al protocolo ARP en IPv6.

Se crean al combiar el prefijo FF02:0:0:0:0:FF00::/104 y los 24 bits menos significativos de la dirección unicast global

Multicast IPv6 de nodo solicitado - Tomada de Cisco Networking Academy

Configuración de direcciones IPv6

Para configurar direcciones unicast globales IPv6 en un equipo ISR (Integrated Service Router) de Cisco, los comandos son simulares a los usados en IPv4 solo que en lugar de ip, se debe escribir ipv6

Configuración dir. IPv6 - Tomada de Cisco Networking Academy

Para configurar manualmente un dirección Link-local, hay que especificar que se trata de ese tipo de dirección de la siguiente manera:

Configuración dir. IPv6 Link-local  - Tomada de Cisco Networking Academy

Como se puede apreciar, es posible configurar la misma dirección Link-Local a cada interfaz del mismo router, esto debido a que las direcciones Link-local sólo tienen significado dentro de una LAN o enlace.

Configuración Dinámica de Hosts en IPv6

Las direcciones IPv6 pueden ser asignadas tanto manual como dinámicamente, pero a diferencia de IPv4, no en todas las ocasiones es necesario de un servidor DHCP para conseguir una configuración automática de direcciones.

Existen tres opciones para la configuración dinámica de Hosts en IPv6

SLAAC IPv6 - Tomada de Cisco Networking Academy

Para que esta configuración dinámica funcione correctamente, en IPv6 se emplea a ICMPv6 para transportar 4 tipos de mensajes, dos para la autoconfiguración de direcciones y dos para reemplazar las funciones de ARP y para el proceso de detección de direcciones duplicadas (DAD)

  1. RS - Solicitud de router: Enviado por los dispositivos con IPv6 habilitado (como PCs, Laptops, servers, etc) hacia su gateway (por lo general) solicitando le asignen una dirección. Emplean como dirección de destino una multicast de todos los routers.
  2. RA - Anuncio de Router: Respuesta del router ante la recepción de un RS. Le envía tanto el prefijo global, ID de subred, longitud de prefijo y Gateway por defecto, pero no se incluye ninguna información sobre servidores DNS, en caso de requerir ello, se debe emplear un servidor DHCPv6. Para completar la parte del ID de interfaz, es posible acudir al proceso EUI-64 o a la asignación aleatoria en la porción de host (depende del sistema operativo del host)
  3. NS - Solicitud de Vecino: Al igual que en comunicaciones IPv4, se debe formar la trama, para lo cual el equipo emisor debe tener la dirección física o MAC-Address del equipo de destino o del Gateway en caso que el destino esté fuera de la LAN local. En IPv6 se emplea el potocolo NDP previamente mencionado, para ello el host emisor, en caso de no tener la dirección física de destino, envía un mensaje NS con la dirección Multicast de nodo solicitado esperando que el dispositivo responda con su MAC-Address. Además este mensaje se utiliza para saber si en el momento de la autoconfiguración de direcciones, su dirección es única e irrepetible.
  4. NA - Anuncio de Vecino: Respuesta del equipo de destino antes un NS. El contenido de NS por lo general es la MAC-Address y que el dispositivo emisor pueda actualizar su caché ARP y termine de formar la trama.

El proceso de autoconfiguración de direcciones de hosts en IPv6 se llama SLAAC (Stateless Address AutoConfiguration), la diferencia con tener un servidor DHCPv6, es que esta característica la puede generar cualquier router o dispositivo de capa 3 que esté configurado con el comando ipv6 unicast-routing mediante el intercambio de mensaje RS y RA a través de ICMPv6. Es una autoconfiguración sin estado ya que no existe un equipo dedicado a mantener el arrendamiento de dichas direcciones, ni hace seguimiento de esta auto asignación, mientras el uso de DHCPv6 es con estado, ya que un equipo dedicado se usa para mantener y controlar dichas asignaciones de direcciones. Como se mencionó hace poco, con SLAAC se obtiene tanto el prefijo Global, el ID de subred, Longitud de prefijo y Gateway por defecto (no se obtiene información adicional como Servidores DNS, en caso que se requiera, se usa la opción 2, es decir SLAAC más DHCPv6, procedimiento llamado como DHCP sin estado), el ID de interfaz se genera automáticamente en el host mediante el proceso EUI-64 o a través de una asignación aleatoria de números hexadecimales (por motivos de seguridad)

Proceso EUI-64 (Extended Unique Identifier) Este proceso trata de emplear la propia MAC-address del equipo y usarla como ID de interfaz en la dir. IPv6, pero si recordamos, la dirección física de un host sólo posee 48-bits y el ID de interfaz requiere de 64, por lo tanto se adjunta los número 0xFFFE entre el OUI (Identificador único Organizacional) de la MAC address y el serial de la misma, con ello se completa los 64-bits, además al ser una dirección generada dinámicamente por un equipo, se cambia el 7 bit más significativo de dicha dirección MAC de 0 lógico a 1 lógico. En la siguiente imagen podemos ver dicho procedimiento:

Proceso EUI-64 - Tomada de Cisco Networking Academy

Una vez que se asignó a un Host con la opción 1 (SLAAC) o la opción 2 (DHCP sin estado), empieza el proceso DAD (detección de direcciones duplicadas), una vez se verificó que la dirección es única, puede ser empleada por el dispositivo.

Espero haya sido de su agrado este tema, sigan implementando topologías con IPv6, en un próximo blog, explicaré cómo se configuran las tres opciones de auto asignación de direcciones de host en IPv6.

Saludos de Quito, Ecuador.

Gustavo

8383 Vistas
1 Comentario

Operación de DMVPN


Una Dynamic Multipoint VPN (Red privada virtual multipunto dinámica) es una iteración evolucionada de los túneles "Hub and Spoke" (Note que DMVPN por si misma no es un protocolo, mas bien un concepto de diseño).

En una topología genérica "Hub and Spoke" se implementan túneles estáticos (usando típicamente GRE o IPSEC) entre un router "hub" ubicado en el centro y sus "Spokes" o satélites, los cuales generalmente conectan oficinas sucursales a la sede central. 

Cada nuevo "Spoke" requiere que se haga una configuración adicional en el router "Hub" y el tráfico entre los "Spokes" debe ser desviado a través del "HUB" para que salga de un túnel y luego ingrese en otro. Mientras que esta podría ser una solución aceptable a pequeña escala, se vuelve difícil de manejar cuando los "Spokes" van multiplicándose y creciendo en número.

DMVPN ofrece una solución elegante a este problema: Túneles GRE multipunto.

Recordemos que un túnel GRE encapsula paquetes IP con un encabezado GRE y un nuevo encabezado IP para poder transportar el paquete a través de una red no confiable.

Los túneles GRE punto a punto tienen exactamente dos extremos y cada túnel en el router requiere una interface virtual separada con su propia configuración independiente. 

Contrariamente, un túnel multipunto GRE permite que existan mas de dos extremos y es tratado como una red de acceso múltiple sin broadcast (NBMA).

Usemos esta topología de ejemplo:


Formación de túneles GRE multipunto:


Mientras que una configuración típica de "Hub and Spoke" requeriría tres túneles separados expandiéndose desde el router R1 hacia cada uno de los router "Spoke", el GRE multipunto permite que los cuatro routers puedan comunicarse usando una sola única interface túnel en la misma subred IP (192.168.0.0/24). Esta configuración NBMA es habilitada por el Next Hop Resolution Protocol el cual permite que los túneles multipunto sean construidos dinámicamente.

Next Hop Resolution Protocol (NHRP)


NHRP (definido en el RFC 2332) es el "catalizador" que facilita el establecimiento del túnel dinámico, al proveer una resolución de direcciones "túnel a interface física". Los clientes NHRP (los router "Spoke") realizan una solicitud al "next hop server" (NHS) (el router HUB) para obtener la dirección física de otro router "Spoke".


Es interesante notar que, en nuestro escenario, la designación como el NHS es el único atributo que distingue al router R1 como el router "Hub".

Configuración DMVPN


Comencemos por examinar la configuración del router R1:

interface FastEthernet0/0
 ip address 172.16.15.2 255.255.255.252
!
interface Tunnel0
 ip address 192.168.0.1 255.255.255.0
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 tunnel source 172.16.15.2
 tunnel mode gre multipoint


La primera cosa que seguramente notaremos es que el túnel no tiene un destino especificado explícitamente. Esto es porque los túneles multipunto son construidos dinámicamente desde los "Spokes" DMVPN hacia el router "Hub"; el router "Hub" no necesita tener preconfigurada las direcciones de los "Spokes".

También note que el modo de túnel ha sido designado como "GRE multipoint".

El comando ip nhrp network-id 1 identifica de manera única la red DMVPN, los túneles no se formarán entre routers con un ID diferente de red.

El comando ip nhrp map multicast dynamic habilita el reenvío de tráfico multicast a través del túnel a los "Spoke" dinámicos (lo cual es requerido por la mayoría de los protocolos de enrutamiento dinámico). 

La configuración de los router "Spoke" es muy similar a la del router "Hub". A continuación se presenta aquí la configuración tomada del router R2:

interface FastEthernet0/0
 ip address 172.16.25.2 255.255.255.252
!
interface Tunnel0
 ip address 192.168.0.2 255.255.255.0
 ip nhrp map 192.168.0.1 172.16.15.2
 ip nhrp map multicast 172.16.15.2
 ip nhrp network-id 1
 ip nhrp nhs 192.168.0.1
 tunnel source 172.16.25.2
 tunnel mode gre multipoint 


Ahora vemos dos nuevos comandos en comparación con los usados en el router "Hub". El comando ip nhrp nhs 192.168.0.1 designa a router R1 como el NHS (que es la única funcionalidad única del router "Hub"), y ip nhrp map 192.168.0.1 172.16.15.2 que mapea estáticamente la dirección NHS hacia la dirección física del router R1.


El comando ip nhrp multicast también difiere ligeramente de como está aplicado en el router "Hub" en que el tráfico de multicast está solamente permitido desde los "Spokes" hacia el "Hub", no desde un "Spoke" a otro "Spoke".


Después de completar la configuración de túnel en cada router, podemos verificar que las sesiones DMVPN se han establecido entre el router "Hub" y cada "Spoke":

R1# show dmvpn
Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete
    N - NATed, L - Local, X - No Socket
    # Ent --> Number of NHRP entries with same NBMA peer

Tunnel0, Type:Hub, NHRP Peers:3, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1     172.16.25.2     192.168.0.2    UP 00:57:47 D    
 1     172.16.35.2     192.168.0.3    UP 00:45:56 D    
 1     172.16.45.2     192.168.0.4    UP 00:45:46 D 

Tunelización Dinámica


Mientras que DMVPN sin duda provee una configuración ordenada, lo que resulta brillante  es su habilidad para establecer dinámicamente túneles "Spoke" a "Spoke". 

En una configuración típica de una topología "Hub and Spoke", un paquete destinado desde R2 a R4 necesitaría ser enrutado a través del router R1, salir del túnel R2 y ser re-encapsulado para ingresar en el túnel R4.

Claramente un mejor camino se encuentra a través de R5 y DMVPN nos permite tomar esta ventaja.

Vea en esta captura de paquetes el tráfico desde R2 a R4. El tráfinco inicialmente sigue el camino a través de R1 como se describió previamente, mientras un túnel dinámico se esta construyendo desde R2 a R4 usando NHRP. Luego que el nuevo túnel se ha establecido, el tráfico fluye a través de él, obviando completamente el router R1. Podemos ver que un nuevo túnel se ha establecido luego que se ha detectado tráfico destinado para R4:

R2# show dmvpn
...

Tunnel0, Type:Spoke, NHRP Peers:1, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1     172.16.15.2     192.168.0.1    UP 01:08:02 S

R2# ping 192.168.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/37/56 ms

R2# show dmvpn
...

Tunnel0, Type:Spoke, NHRP Peers:2, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1     172.16.15.2     192.168.0.1    UP 01:08:27 S    
 1     172.16.45.2     192.168.0.4    UP 00:00:03 D 

Note que el túnel a R4 ha sedo marcado como dinámico, en contraste con el túnel estático hacia el Hub/NHS.

Añadiendo cifrado

Hasta este punto los túneles han sido configurados como texto plano por simplificar el ejemplo, pero en el mundo real probablemente quisiéramos incluir protección IPsec a los túneles que atraviesan rutas no confiables.

Afortunadamente, la solución es tan simple como aplicar una política de protección IPsec a la interface túnel en cada router. Aquí se presenta un perfil IPsec usando una llave ISAKMP pre-compartida para demostración:

crypto isakmp policy 10
 authentication pre-share
crypto isakmp key P4ssw0rd address 172.16.0.0 255.255.0.0
!
crypto ipsec transform-set MyTransformSet esp-aes esp-sha-hmac
!
crypto ipsec profile MyProfile
 set transform-set MyTransformSet
!
interface Tunnel0
 tunnel protection ipsec profile MyProfile


Después de reiniciar las interfaces de túnel, podemos ver que las sesiones DMVPN ha sido reconstruidas mostrando esta vez encriptación. 

R1# show dmvpn
...

Tunnel0, Type:Hub, NHRP Peers:3, 
 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
 1     172.16.25.2     192.168.0.2    UP 00:02:28 D    
 1     172.16.35.2     192.168.0.3    UP 00:02:26 D    
 1     172.16.45.2     192.168.0.4    UP 00:02:25 D

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
172.16.15.2     172.16.35.2     QM_IDLE           1002    0 ACTIVE
172.16.15.2     172.16.25.2     QM_IDLE           1001    0 ACTIVE
172.16.15.2     172.16.45.2     QM_IDLE           1003    0 ACTIVE



 ----------------------------------------------------------
Post basado en http://packetlife.net/blog/2008/jul/23/dynamic-multipoint-vpn-dmvpn/
con aportes del editor del blog.


Traducción por: José R. Torrico Gumucio - Instructor Cisco Networking Academy- Bolivia

1220 Vistas
0 Comentarios


Backbone Fast es una función propietaria de Cisco que, una vez habilitada en todos los switches de una red de Bridge, permite que un Switch ahorre hasta 20 segundos (max_age, intervalo máximo) cuando se recupera de una falla de link indirecto. 

Después de una revisión rápida de algunos fundamentos de STP (Spanning-Tree Protocol), podrá ver el escenario de falla exacto al que se aplica la función Backbone Fast y cómo configurarlo para los switches Catalyst que ejecutan el software CatOS y Cisco IOS®. 

Switches Cisco Catalyst que usan esta característica

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

  • Catalyst 2950 Series Switch que funcionan con el Cisco IOS Software Release12.1(6)EA2 y posterior
  • Catalyst 3550 Series Switch que funcionan con el Cisco IOS Software Release12.1(4)EA1 y posterior
  • Catalyst 4000 Series Switch que ejecutan CatOS 5.1(1a) y posterior
  • Switches de las 4500/4000 Series del Catalyst que funciona con el Cisco IOS Software Release 12.1(8a)EW y Posterior
  • Series Switch del Catalyst 5500/5000 que funcionan con la versión CatOS 4.1(1) y posterior
  • Catalyst 6500/6000 Series Switch que funcionan con la versión CatOS 5.1(1)CSX y posterior
  • Catalyst 6500/6000 Series Switch que funcionan con el Cisco IOS Software Release 12.0-7XE y Posterior 

BPDUs y como compararlos

Las Unidades (BPDU) se pueden clasificar estrictamente por los campos que llevan. 

Entre estos campos están el Root Bridge ID, el costo del trayecto a la raíz, y el ID de Bridge de envío. Un BPDU se considera mejor que otro BDPU por estas razones:

  • Cuando un BPDU lleva un mejor Root Bridge ID que otro. Cuanto más bajo es el valor, mejor.
  • Cuando los valores de ID del puente raíz son iguales, entonces es mejor el BPDU con el costo de trayecto más bajo a la raíz.
  • Cuando los valores de ID de Root Bridge son iguales y los costes a la raíz son lo mismo, después el BPDU con el mejor ID de Bridge de envío es mejor. Cuanto más bajo es el valor, mejor.

Hay otras variables que entonces pueden actuar como elementos para desempate. 

Sin embargo, cuanto mejor sea un BPDU, mejor es el acceso al Root Bridge.

Un Bridge que recibe un mejor BPDU en un puerto que el que él envía, pone este puerto en el modo de bloqueo a menos que sea su puerto raíz. 

Esto significa que en el segmento conectado a este puerto existe otro puente que constituye un puente designado. Un Bridge guarda el valor del BPDU en un puerto enviado por el Bridge designado actual.  

¿Cómo se recupera STP de una falla de link indirecto?


A continuación se ilustra cómo el STP se comporta cuando tiene que recalcular después de una falla de link indirecto, es decir, cuando un Bridge tiene que cambiar el estatus de algunos de sus puertos debido a un error en un link que no está directamente conectado a él.  


Considere este diagrama, que implica tres Switches R, B, y S en una topología de malla completa. Asuma que R es el Root Bridge y B es el Root Bridge de backup. S bloquea su puerto P y B es el Bridge designado para el link L3. 

  1. Si link L1 se interrumpe, el switch B detecta inmediatamente el error y asume que es el puente raíz. Comienza a enviar los BPDU a S y demanda ser la nueva raíz de la topología. 
  2. Cuando S recibe esta nueva BPDU desde B, se da cuenta de que es inferior a la que ya tiene almacenada para el puerto P y la ignora.
  3. Después de que expire el temporizador del max_age (20 segundos por defecto), el BPDU almacenado en S para el puerto P expira. El puerto cambia  inmediatamente al estado STP "escuchar" y S comienza a enviar su mejor BPDU a B.
  4. Tan pronto como B recibe el BPDU de S, detiene el envío de su BPDU.
  5. El puerto P pasa al estado de "reenvío" a través de los estados de "escuchar" y "aprender". Esto requiere el doble del valor fw_delay, un tiempo adicional de 30 segundos. La conectividad total entonces se restablece.

El tiempo que total que fue necesario para recuperarse de esta falla de link indirecto fue el valor del max_age (20 segundos) más dos veces el valor fw_delay (2x15 segundos ) . Esto es 50 segundos con los parámetros predeterminados. 

La característica del Backbone Fast propone ahorrar el max_age (20 segundos). 

Para hacer esto, expira el temporizador inmediatamente después que el puerto recibe los BPDU inferiores.

Mejoras en Backbone (Troncal principal) rápidas en STP estándar

Con el ejemplo anterior, el STP invalida la información que llega a ser incorrecta debido a una falla de link indirecto. Para hacer esto, espera pasivamente el max_age. Para librarse del retardo del max_age, el Backbone Fast introduce dos mejoras:

    1. La capacidad de detectar una falla de link indirecto lo antes posible. Esto se logra siguiendo los BPDU inferiores que un Bridge designado envía cuando experimenta una falla de link directo.
    2. Introduce un mecanismo que permite un control inmediato si la información de BPDU almacenada en un puerto es todavía válida. Esto se implementa mediante una nueva unidad de datos del protocolo (PDU) y el Root Link Query, explicados en este documento, el RLQ PDU.

      Detección de fallas de link indirecto


      Si un BPDU inferior se recibe en un puerto de nuestro Bridge designado, después este Bridge se tiene:

      1. Perdió el enlace hacia el puente raíz y comienza a publicar una raíz con un Bridge ID más alto, una raíz peor que las almacenadas en los otros equipos.
      2. O bien, el trayecto a la raíz ha aumentado por encima del valor almacenado.

      1 - En este caso, el Switch B pierde conexión al Root R y envía un BPDU con su propio BID como Root, costo del enlace en 0 y el BridgeID en B. Este es inferiór al que el Switch S tenía almacenado, porque el BID de R es mejor que B.



      2 - En este caso, B todavía tiene a R como Root, pero la falla implica que el costo del enlace crezca de 10 a 100. Entonces el BPDU enviado es, nuevamente, inferior al que estaba almacenado en S.


      La conducta habitual según las especificaciones del Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) es simplemente : ignorar cualquier BPDU inferior

      El Backbone Fast lo utiliza porque tan pronto como se reciba uno, es cierto que un error ocurrió en la trayectoria a la raíz y que se debe expirar por lo menos un puerto.

      Nota: Una falla de link indirecto puede suceder sin ninguna generación del BPDU inferior en la red. Simplemente agregue un hub en el diagrama anterior: 


      La falla de link ocurre entre el Root Bridge R y el concentrador. B no detecta que el link va abajo y espera el max_age antes de que demande ser la nueva raíz. 

      Recuerde que el mecanismo trabaja solamente si un Bridge detecta una falla de link directo.

      Sólo realiza el seguimiento de BPDU inferiores enviadas por el puente designado. Dado que ésta es la BPDU que está almacenada en el puerto. 


      Si, por ejemplo, un Bridge nuevamente insertado comienza a enviar el BPDU inferior, no comienza la característica del Backbone Fast. 

      Reacción frente a fallas de links indirectas 

      Cuando un BPDU inferior se detecta en un puerto no designado, la segunda fase de Backbone Fast se acciona. En vez del max_age pasivo que espera para expirar los puertos que se pueden afectar por la falla, participan de un modo proactivo y los prueban inmediatamente mediante el RLQ PDU. 

      RLQ se utiliza para lograr un tipo de "ping" para la raíz en un puerto no designado y permite rápidamente confirmar si la BPDU almacenada en un puerto aún es válida o necesita ser descartada. 


      Al recibir una BPDU inferior desde un puente designado, se envía una PDU de RLQ en todos los puertos no designados, excepto el puerto donde recibió la BPDU inferior y los puertos de loop intrínseco. 

      Éste es para indicar que usted todavía oye de la raíz en los puertos donde se solían recibir los BPDU. El puerto en donde usted recibió el BPDU inferior se excluye porque usted ya está consciente que sufrió un error, volver a colocar y señalar los puertos no es útil, pues no llevan a la raíz.
       

      Al recibir una respuesta RLQ en un puerto, si la respuesta es negativa, el puerto perdió la conexión a la raíz y usted puede expirar de la table su BPDU. 

      Además, si el resto de los puertos no designados recibieron ya una respuesta negativa, el Bridge del conjunto pierde la raíz y puede comenzar el cálculo de STP desde el principio.

      Si la respuesta confirma que usted puede todavía acceder el Root Bridge vía este puerto, usted puede expirar inmediatamente el puerto en el cual recibimos inicialmente el BPDU inferior.

      En este ejemplo, tenemos A hacia el lado de izquierdo, B, D, y E son puertos no designados para el Switch S. A es el puerto raíz y lo otros están bloqueados. 


      Cuando E recibe un BPDU (1) inferior, la estructura básica rápida comienza a acelerar el cálculo STP.

      S envía una petición RLQ, que busca la raíz R en todos los puertos no designados excepto por E (2). 


      Las respuestas especifican qué la raíz es accesible a través de estos puertos. La respuesta RLQ que recibe D especifica que D perdió su trayecto a la raíz R. Entonces hace que su BPDU expire inmediatamente (3). 


      Los Puertos A y B reciben confirmación de que aún cuentan con un trayecto a R (4). 


      Por consiguiente, como el switch S aún tiene conectividad con la raíz, hace que el puerto E expire inmediatamente y continúa con las reglas STP habituales (5).

      En un caso donde el Switch recibe solamente las respuestas con una raíz diferente de R, considere la raíz como perdida desde el principio y se recalcula el STP inmediatamente. Observe que este caso también ocurre cuando el único puerto no señalado (y no auto colocado) en el Bridge es el puerto raíz y usted recibe un BPDU inferior en este puerto. 

      PDU de consulta de link raíz

      Las dos formas de RLQ son consulta RLQ y respuestas RLQ.

      La consulta RLQ se envía en un puerto en donde usted recibe generalmente los BPDU, para marcar que usted todavía tiene Conectividad a la raíz a través de este puerto. Se especifica en la petición que el Bridge es su raíz y la respuesta RLQ se vuelve eventual con un Root Bridge que se pueda acceder a través de este puerto. Si las dos raíces son lo mismo, se pierde la Conectividad está todavía viva, él.

      Un Bridge que recibe una Consulta RLQ responde inmediatamente si sabe que ha perdido la conexión a la raíz consultada porque tiene un Root Bridge diferente al que está especificado en la consulta RLQ, y si es este el ROOT. 

      En caso contrario, entonces, él reenvía la interrogación hacia la raíz a través de su puerto raíz.


      Las respuestas RLQ son inundadas a los puertos designados. 


      El emisor de la solicitud RLQ coloca su identificador de puente BID en la PDU. Esto es para garantizar que, cuando reciba una respuesta a su consulta, no se inunde la respuesta en sus puertos designados.


      El RLQ PDU tiene la misma estructura de paquete que un STP BPDU normal. La única diferencia es que dos diferentes direcciónes SNAP especificadas por Cisco son usadas: una para la solicitud y otra para la respuesta.
       
      Esto el formato BPDU estándar: 

      DA SA Longitud DSAP SSAP CNTL SNAP PDU



      El campo PDU contiene: 

      Identificador de Protocolo Versión Tipo de mensaje Indicadores ID de raíz Costo de trayecto raíz
      ID del emisor Identificación del puerto Antigüedad del mensaje max age tiempo de saludo demora de reenvío



      El Tipo de mensaje usado en el PDU es también diferente del BPDU estándar. 
      Los únicos campos usados son el ID de RAÍZ y el ID de Bridge de envío.
       
      Esta característica de Cisco tiene que ser configurada en todos los Switches en la red para que puedan procesar estas PDUs.

      Ejemplo de situación con la función Backbone Fast habilitada

      Este escenario se basa en el primer ejemplo, pero, este vez con el Backbone Fast habilitado en los tres Switches.

      1. La primera etapa es igual a la que se explicó anteriormente. 
      2. Tan pronto como S reciba el BPDU inferior de B, comienza a reconfirmar sus puertos no designados en vez del esparar el temporizador max_age. Envía una Consulta RLQ en su puerto raíz para el Root Bridge R. 
      3. El Root Bridge R recibe la Consulta RLQ y la contesta inmediatamente con una respuesta RLQ que especifica que allí sigue existiendo un Root Bridge R en esa dirección. 
      4. S ya ha verificado todos sus puertos no designados y aún posee conectividad a la raíz. Puede entonces expirar inmediatamente la información salvada en las transiciones de P. El puerto P cambia al estado "escuchar" y comienza a enviar los BPDU. En esa etapa, ya se ha ahorrado los segundos del max_age, y el Algoritmo del Spanning-Tree (STA) estándar es aplicado. 
      5. B recibe un mejor BPDU de S (una mejor ROOT BID R que B) y ahora considera los puertos que llevan al L3 como su puerto raíz.

      Configurar el Backbone Fast para CatOS y el Cisco IOS

      Cuando está utilizado, el Backbone Fast se debe habilitar en todo el Switches en la red porque el Backbone Fast requiere el uso del mecanismo de la petición y de la contestación RLQ para informar al Switches la estabilidad del trayecto raíz.

      El protocolo RLQ es activo solamente cuando el Backbone Fast se habilita en un Switch. Además, la red puede también ejecutarse en los problemas con la inundación RLQ, si el Backbone Fast no se habilita en todo el Switches. Por abandono, se inhabilita el Backbone Fast.

      El Backbone Fast no se soporta en los Catalyst 2900XL y 3500XL Switches. Usted necesita generalmente habilitar el Backbone Fast si el dominio del Switch contiene este Switches además de otros switches de Catalyst que soportan.

       Cuando usted implementa el Backbone Fast en los entornos con los switches XL, bajo topologías estrictas, usted puede habilitar la característica donde está el Switch más reciente de la línea y está conectado solamente el switch XL con la base en dos lugares. No implemente esta característica si la arquitectura de los switches XL está en la manera de la cadena margarita.

      Usted no necesita configurar el Backbone Fast con el RSTP o el IEEE 802.1W porque el mecanismo se incluye nativo y se habilita automáticamente en el RSTP. Para más información sobre el RSTP o el IEEE 802.1W, refiera al Spanning-tree del PVST+ al ejemplo de configuración de la migración Rápido-PVST.

      Configuración para CatOS

      Para los Catalyst 4000, 5000 y 6000 Series Switch que ejecutan CatOS, utilice estos comandos para habilitar el Backbone Fast global para todos los puertos y verificar la configuración.

      Console> (enable) set spantree backbonefast enable
      Backbonefast enabled for all VLANs
      Console> (enable) show spantree backbonefast 
      
      ! This command show that the backbonefast feature is enabled.
      
      Backbonefast is enabled.
      Console> (enable)
       

      Para visualizar las estadísticas del Backbone Fast:

      Console> (enable) show spantree summary 
      Summary of connected spanning tree ports by vlan
      Uplinkfast disabled for bridge.
       
      Backbonefast enabled for bridge. 
       
      Vlan  Blocking Listening Learning Forwarding STP Active
      ----- -------- --------- -------- ---------- ----------
       1      0        0          0         1         1
      
            Blocking Listening Learning Forwarding STP Active
      ----- -------- --------- -------- ---------- ----------
      Total   0        0         0        1           1
      
      BackboneFast statistics 
      
      ! The show spantree summary command displays all backbonefast statistics.
      
      -----------------------
      Number of inferior BPDUs received (all VLANs): 0
      Number of RLQ req PDUs received (all VLANs): 0
      Number of RLQ res PDUs received (all VLANs): 0
      Number of RLQ req PDUs transmitted (all VLANs): 0
      Number of RLQ res PDUs transmitted (all VLANs): 0    
      Console> (enable)
       

      Configuración para el Cisco IOS

      Para los switches de Catalyst que se ejecutan con el Cisco IOS Software, utilice estos comandos para habilitar el Backbone Fast global para todas las interfaces. 

      CAT-IOS# configure terminal
      CAT-IOS(config)# spanning-tree backbonefast
      CAT-IOS(config)# end
      CAT-IOS#
       

      Para verificar que el Backbone Fast esté habilitado y mostrar las estadísticas: 

       
      CAT-IOS# show spanning-tree backbonefast
      
      BackboneFast         is enabled
      
      BackboneFast statistics
      -----------------------
      Number of transition via backboneFast (all VLANs)           : 0
      Number of inferior BPDUs received (all VLANs)               : 0
      Number of RLQ request PDUs received (all VLANs)             : 0
      Number of RLQ response PDUs received (all VLANs)            : 0
      Number of RLQ request PDUs sent (all VLANs)                 : 0
      Number of RLQ response PDUs sent (all VLANs)                : 0
      CAT-IOS#


      Tomado de: http://www.cisco.com/cisco/web/support/LA/102/1024/1024740_18.html con aportes del editor del BLOG ccnabolivia.blogspot.com

      21008 Vistas
      13 Comentarios

      El DHCP Snooping es una característica de seguridad que provee seguridad filtrando los mensajes DHCP "no confiables" y construyendo y manteniendo una tabla de asociaciones DHCP Snooping.

      Un mensaje "no confiable" es un mensaje que es recibido desde fuera de la red o del Firewall y que puede ser parte de un ataque contra tu red.

      La tabla de asociaciones DHCP Snooping contiene las direcciones MAC, direcciones IP, tiempo de arrendamiento, Tipo de asociación, número de VLAN e Interface que corresponde a las interfaces locales "no confiables" de un Switch, no contiene información de los hosts conectados a una interface "confiable".



      En términos de seguridad una interface "no confiable" es una interface que está configurada para recibir mensajes desde fuera de la red local o actúa como un Firewall. Una interface "confiable" es una interface configurada para recibir solamente mensajes desde dentro de la red.

      El DHCP Snooping actúa como un firewall entre los hosts "no confiables" y los servidores DHCP. 

      También nos permite contar con una forma de diferenciar entre interfaces "no confiables" conectadas a usuarios finales e interfaces "confiables" conectadas a los servidores DHCP o a otro Switch.

      Es posible configurar DHCP Snooping por Switch y por VLANs. Cuando se habilita el DHCP Snooping en un switch, una interface actúa como un bridge de capa 2 interceptando y salvaguardando los mensajes DHCP que se dirigen a una VLAN de capa 2. Cuando se habilita DHCP Snooping en una VLAN, el Switch actúa como un puente de capa 2 dentro del dominio de la VLAN.

      El DHCP Snooping es necesario para prevenir los ataques de tipo "man-in-the-middle" en nuestras redes.  

      Las redes modernas tienen el potencial para que un atacante intente instalar un DHCP Server falso y responder a los mensajes DHCPDISCOVER antes de que lo haga una servidor DHCP legítimo. El DHCP Snooping permite a los Switches en la red "confiar" en el puerto (la interface) al que está conectado el servidor DHCP legítimo (podría ser un puerto troncal) y "desconfiar" de los demás puertos.



      También se mantiene una lista de asociaciones de direcciones DHCP que se logra inspeccionando el tráfico que fluye entre los clientes y el servidor DHCP, el cual provee certeza de quienes son los verdaderos hosts. La información de asociación recolectada por el DHCP Snooping es usada por otras características de seguridad como IPSG y DAI.


      Los clientes se conectan a puertos "no confiables" (untrusted), todos los puertos son "no confiables" por defecto cuando se habilita el DHCP Snooping. Cuando la PC del cliente envía un mensaje DHCPDISCOVER y el DHCP Snooping está habilitado, el Switch solamente va a enviar el mensaje de broadcast DHCP a los puertos "confiables" (trusted).

      En el ejemplo de la topología el Switch de distribución está actuando como DHCP Server. Un puerto "confiable" es el único puerto que tiene permitido enviar mensajes de repuesta DHCP como el DHCPOFFER.

      Configurando DHCP Snooping en el Switch

      Cuando se configura DHCP Snooping en el Switch, se está configurando el Switch para diferenciar entre interfaces "no confiables" e interfaces "confiables". Es necesario habilitar globalmente el DHCP Snooping antes de poder usarlo en una VLAN. Es necesario habilitar el DHCP Snooping independientemente de otras características de DHCP.
      Una vez que está habilitado el DHCP Snooping, todos los comandos de configuración de opciones DHCP relay quedan deshabilitados, esto incluye a los siguientes comandos:
      •ip dhcp relay information check
      •ip dhcp relay information policy
      •ip dhcp relay information trusted
      •ip dhcp relay information trust-all


      Para configurar DHCP Snooping puede usar estos comandos:


      Comando

      Propósito


      Switch(config)# ip dhcp snooping 
      

      Habilita DHCP snooping globalmente. Puede usar la palabra clave no para deshabilitar el DHCP snooping.


      Switch(config)# ip dhcp snooping vlan number 
      [number] | vlan {vlan range}]
      

      Habilita DHCP snooping en una VLAN o en un rango VLAN


      Switch(config-if)# ip dhcp snooping trust
      

      Configura la interface como "confiable".

      Puede usar la palabra clave no para configurar una interface para recibir mensajes como cliente "no cofiable".


      Switch(config-if)# ip dhcp snooping limit rate 
      rate
      

      Configura el numero de paquetes DHCP por segundo (pps) que una interface puede permitir.1


      Switch(config)# end 
      

      Sale del modo de configuración.


      Switch# show ip dhcp snooping 
      

      Verifica la configuración de DHCP Snooping.

      -----------------------


      Post basado en el artículo: http://www.networksbaseline.in/search/label/DHCP Con aportes del editor del Blog y de las páginas:

      http://www.cisco.com/c/en/us/products/collateral/switches/catalyst-6500-series-switches/prod_white_paper0900aecd802ca5d6.html

      http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/dhcp.html#wp1073418

      Traducido por José R. Torrico - Instructor Cisco Networking Academy

      11349 Vistas
      0 Comentarios

      En este capítulo o sección se describe como configurar EIGRP para IPv6 en routers usando como herramienta de ayuda Packet Tracer. 

      Para configurar EIGRPv6 se debe hacer, al igual que RIPng a nivel de interfaz.
      Y después con este comando:

      ipv6 eigrp sistema autónomo

      Veremos como ejemplo, la siguiente topología.

      Como ya sabemos configurar los routers, asignaremos las siguientes direcciones

      Y en las PC’s las siguientes:

      Para configurar las PC, es entrando igual que para IPv4, pero dejamos vacío ese espacio, y pasamos a llenar el de abajo, el que corresponde a IPv6, agregando la puerta de enlace.

      Para configurar EIGRP solo basta con establecer estos comandos

      Lo mismo en el router 2, cambiando la dirección del router-id

      La dirección de router-id se requiere en este caso ya que no tenemos ninguna interfaz activa con alguna dirección IPv4. El valor del router-id puede ser el que sea, solo tiene que ser un formato de IP de 32 bits.

      Justo en ese orden para tener al menos la conectividad, puedes incluir el no passive interface según lo requieras.

      Ingresando el comando de show ipv6 eigrp neighbors podemos observar los vecinos descubiertos por EIGRPv6.

      Dejo el archivo de la práctica para su descarga, aquí. 

      Obtenido de: http://ipv6curso.890m.com/, de la sección "Configurar EIGRP para IPv6", autor: Daniely Flores.

      5317 Vistas
      0 Comentarios

      Esta sección o capítulo describe como configurar RIPng en routers. 

      RIPng se habilita en una interfaz y no en el modo de configuración del router. De hecho no hay un comando network network-address disponible en RIPng. En lugar de eso para habilitar RIPng se debe ingresar a la interfaz en donde sea desea publicar RIPng y enseguida escribimos el comando ipv6 ripdomain-name enable.

      El domain-name puede ser un número o una palabra, esto para identificar un proceso. Este identificador puede ser el mismo o diferente en toda la red RIP, sin embargo es necesario que en el router todas las interfaces pertenezcan al mismo proceso.

      Es importante decir que este comando se debe de habilitar en todas las interfaces que se deseen publicar aunque no estén conectadas con ninguna otra, esto para que puedan ser publicadas.

      Ahora veremos un ejemplo de como configurar RIPng en la siguiente topología

      Ejemplo:

      Construiremos la siguiente topología y configuraremos ipv6, así como lo hicimos en la sección "Habilitar IPv6 en routers".

      No olvides configurar el Tiempo de reloj(clock rate) en el R3 ya que es DCE, yo lo establecí en 64000.

      Para configurar RIPng, basta con el comando ipv6 rip id1 enable. Establecemos id1 como el nombre del dominio al que pertenecerán.
      Esto se hace en cada interfaz que se quiera publicar, como queremos publicar todas,estableceremos este comando.

      Lo mismo con todas las demás interfaces faltantes
      R1 --> Fa 0/1

      R2 --> Fa 0/0 y Se 0/0/0

      R3 --> Fa 0/1 y Se 0/0/0

      Es muy importante que previamente hayan habilitado el reenvío de tráfico IPv6 con el comando ipv6 unicast-routing, de lo contrario saldrá un error.

      De lo contrario, cuando configuramos RIPng en todas las interfaces de todos los routers, vemos que ya en la tabla de enrutamiento lo reconoce.

      Dejaré la práctica aquí por si lo quieren descargar.

      Obtenido de: http://ipv6curso.890m.com/, de la sección "Configurar RIPng", autor: Daniely Flores.

      30675 Vistas
      0 Comentarios

      Este capítulo o sección indica como activar IPv6 en los routers. 

      Hay dos pasos básicos para activar IPv6 en un router.

      1. Activar el reenvío de tráfico IPv6 en el router
      2. Configurar cada una de las interfaces que requiere IPv6

      El reenvío de tráfico IPv6 esta deshabilitado en los routers de forma predeterminada. Para activarlo, basta con el comando:

      comando routing unicast

      El comando ipv6 address puede configurar una dirección IPv6 global. Debe especificar la dirección IPv6 completa de 128 bits o debe especificar el uso de un prefijo de 64 bits con la opción eui-64. La variable prefix-length es un valor decimal que muestra cuantos bits contiguos de alto nivel de la dirección comprende el prefijo.

      En IPv6, la dirección de red se denomina “prefijo” y la máscara de subred se denomina “longitud de prefijo”.

      Para reenviar tráfico IPv6 en una interfaz, se debe de configurar una dirección IPv6 global en esa interfaz. Configurando una dirección IPv6 en una interfaz se configura automáticamente una dirección de enlace local y activa IPv6 para la interfaz.

      Para dejarlo un poco más claro, haremos un ejercicio simple de como configurar dos routers.

      Ejemplo:

      topología

      Empezaremos a configurar las interfaces de cada router. Y no olvidemos el comando no shutdown para levantar la interfaz.

      asignación de IP para R1

      asignación de IP para R2

      Deberá de aparecer el cambio de estado de la interfaz.

      Resultado:

      topología

      Ahora podemos ver que aparecen en las tablas de enrutamiento de cada router

      tabla de enrutamiento

      Como pueden ver al momento de dar de alta la dirección IPv6, se levantó automaticamente una dirección de enlace local.

      tabla de enrutamiento R2

      Comprobamos la conectividad con un ping de extremo a extremo.

      Ping de R1 a R2

      ping

      Esto solo es un ejemplo de lo fácil que es configurar ipv6.

      Dejaré el archivo del ejercicio por si lo quieren checar, lo pueden descargar aquí.

      Obtenido de: http://ipv6curso.890m.com/ de Daniely Flores Lara, Sección: "Habilitar IPv6 en routers". 

      46 Vistas
      0 Comentarios

      hola disculpa tengo un switch SF300-24  lo que quiero realizar en este switch es:

      1.                  crear las vlans 15 y 25 con sus respectivas IPs
      2.                  Crear un puerto de acceso por cada vlan uno para la vlan 15 y uno para la vlan 25
      3.                  Crear un puerto troncal asociando las dos vlans, este puerto troncal debe conectarse al puerto Ge1 del equipo huawei.

       

      y la verdad es qure no puedo espero me puedas ayudar de ante mano muchas gracias..
       

      115 Vistas
      0 Comentarios

      Buenas tardes,

      El equipo WS-C2960-24PC-L  actualmente ya posee anuncio de EOS y de acuerdo con cisco el modelo recomendado seria el WS-C2960+24PC-L, alguien conoce la cantidad maxima de IPv4 IGMP groups (Default,QoS,Dual) y la cantidad maxima de Unicast MAC addresses (Default,QoS,Dual) para WS-C2960+24PC-L debido a que la información no esta disponible o clara en la hoja de datos de CISCO y adicionalmente si el equipo WS-C2960+24PC-L  soportar Clustering de hasta 16 dispositivos en 15.0(2)SE and Later.

      8930 Vistas
      0 Comentarios

         Con el fin de entender un poco más la forma en la que IPv6 trabaja a diferencia de IPv4, debemos ver cómo es que se agrega información en un paquete de IPv6 por medio de su encabezado. Revisemos primero un encabezado de IPv4 que es con lo que estamos más familiarizados:

       

         Todas las secciones que aparecen en color ROJO son elementos que se eliminaron del encabezado de IPv6. Lo que está en AZUL, cambió de nombre y posición. Lo que está en AMARILLO se mantiene igual.

         Veamos qué secciones se eliminaron:

      • IHL (IP Header Length - 4 bits). En IPv4 el tamaño del encabezado es variable. Este valor combinado con el Total Length del paquete le permite al equipo saber cuántos bytes hay de carga útil o payload (Payload = Total Length - IHL). Con un tamaño de encabezado variable, se requiere de alguna rutina o algoritmo para que los equipos determinen en dónde empieza la información dentro del paquete lo que hace un poco más complejo el manejo y proceso de paquetes.
      • Identification/Flags/Fragment Offset (32 bits). Estos elementos se utilizan para el manejo de fragmentación de paquetes.
      • Header Checksum (16 bits). Utiliza un algoritmo para determinar si el encabezado no está corrupto o ha sido modificado incorrectamente. Tecnologías como NAT que modifican parámetros del encabezado también deben modificar esta sección de manera adecuada. IPv6 elimina el uso de esta sección y deja la revisión de la integridad de los paquetes a CRC en capa 2 y checksums de capa 4.
      • Options. Es una sección de tamaño variable y contiene datos sobre la información del paquete que no se pudieron integrar en otros campos del encabezado. Es esta sección la que hace que el encabezado de IPv4 sea de tamaño variable.
      • Padding. Es una serie de bits con un valor de '0' que sirve para alinear el encabezado a un múltiplo de palabras de 32 bits.

       

         Esta es la forma de un encabezado de IP versión 6:

       

       

         Como se puede observar, las secciones de Versión (4 bits) y Direcciones de Origen y Destino (128 bits) permanecen igual. Además existe una sección nueva de 20 bits, Flow Label, que es para un uso futuro basado en el RFC 3697. Esta sección servirá para identificar un flujo específico y hacerle un tratamiento (QoS) idéntico a todos los paquetes que pertenezcan al flujo (aún no está implementado).

         Veamos ahora las secciones modificadas:

      • Traffic Class (8 bits). Tiene la misma funcionalidad que el Type of Service, sirve para almacenar la información de precedencia, DSCP o clase de servicio dependiendo de la implementación de QoS.
      • Payload Length (16 bits). En IPv6 tenemos un encabezado fijo de 40 bytes por lo que solo necesitamos saber el tamaño de la información útil del paquete. Esto también nos quita la necesidad de implementar rutinas de búsqueda como en IPv4. Ya estamos utilizando 4 veces el tamaño de buffers para el manejo de direcciones de 128 bits, cualquier cosa que disminuya el procesamiento extensivo de los paquetes es preferible.
      • Next Header (8 bits). Esta sección nos puede indicar el protocolo al que pertenece la información que estamos acarreando (TCP, UDP, ICMPv6, etc.). También se utiliza para indicarnos si existe información de opciones para los datos que se transportan. En lugar de manejar Opciones en el encabezado como IPv4, éstas las integramos dentro de la carga útil de los paquetes para mantener el encabezado en un tamaño fijo. Esta sección nos indicaría si hay opciones que revisar dentro del paquete.
      • Hop Limit (8 bits). Sirve exactamente la misma función que el TTL de IPv4. Solo se cambió el nombre ya que este parámetro es un contador de saltos (equipos capa 3) y no un contador de tiempo como parece indicar el nombre en IPv4.

       

         Have fun learning!!!

       

      Rick.

       

       

      4155 Vistas
      4 Comentarios

         Una de mis mejores amigas también ha sido asistente a muchos de mis entrenamientos en el TAC.  Cuando teníamos alguna sesión de entrenamiento avanzado de algún protocolo o tecnología nueva, ella a veces empezaba la lección con una pregunta de broma: "Sí, aprendamos algo nuevo... ¿Qué es IP?". Y después de varios años, por fin podremos comentar algo brevemente (espero que ella esté leyendo esto). IP no es más que un conjunto de reglas o instrucciones que nos dice cómo se lleva a cabo la comunicación entre dos equipos dentro de una red interconectada. El protocolo TCP/IP define entre muchas otras cosas cómo vamos a identificar dichos equipos dentro de la red (direcciones), qué información se intercambia entre ellos (paquetes, encabezados) y cómo es que dicha información va a ser intercambiada (modo de comunicación, enrutamiento, etc.). Sobre esta última parte vamos a comparar las diferencias en modos de comunicación que tienen IP versión 4 e IP versión 6.

         IPv4 maneja 3 modos principales de comunicación: Unicast, Broadcast y Multicast.

      Unicast - En este modo de comunicación, un equipo manda información a otro equipo de manera única e independiente. Si este equipo quisiera mandarle la misma información a otro diferente, tendría que mandar una copia de esta información por separado al segundo receptor y así sucesivamente. Haciendo un simil con la comunicación humana, digamos que vamos a tener una fiesta y para que la gente vaya necesitamos pasar los detalles de la reunión a otras personas. En un modo de comunicación Unicast, iríamos con cada uno de nuestros conocidos y les contaríamos los detalles de la fiesta a cada uno por separado. Esto por supuesto sería muy pesado de realizar y sobre todo agotador (ocupamos más ciclos de CPU para una actividad repetitiva a la vez que ocupamos un mayor ancho de banda), pero el mensaje final es entregado.

      Broadcast - En IP se define una dirección de Broadcast como la dirección que todos los equipos deben procesar además de la dirección IP configurada en la tarjeta de red. Cuando se manda tráfico a la dirección Broadcast de una red, todos los equipos de la misma la reciben, la procesan y trabajan con ella de ser necesario. Continuando con el ejemplo de la fiesta, en lugar de hablar con cada uno de nuestros conocidos, vamos a la oficina, tomamos un altavoz y gritamos a todos los presentes los detalles de la reunión. El mensaje solo se manda una vez, pero todos los presentes lo reciben y lo procesan. Por supuesto, aunque nuestro mensaje fue entregado de manera correcta, habrá mucha gente a la que no le interesa saber de la fiesta y sin embargo tuvieron que enterarse, es decir, estas personas usaron ciclos de CPU y ancho de banda para procesar información que no les era de interés.

      Multicast - En este método de comunicación, el equipo con la información interesante manda una sola copia del mensaje, pero esta vez lo hace a un grupo selecto de equipos destino, es decir, solo se mandan los datos a los equipos que lo requieren. En esta ocasión, resulta que nosotros tenemos un programa de radio o de televisión que todos nuestros conocidos sintonizan diariamente. Es en este programa donde damos los detalles de la fiesta y solo las personas que están interesadas reciben la información final.

         En IPv6, se observó que la comunicación tipo Broadcast no era la más óptima para intercambiar información ya que se ocupa mucho ancho de banda y recursos de los sistemas para tráfico que no es de utilidad para dichos sistemas. Por esta razón, el modo de comunicación tipo broadcast se eliminó en IPv6 y todas los procesos que antes utilizaban Broadcast, ahora utilizan Multicast solamente. Por supuesto IPv6 todavía trabaja en modo Unicast pero además tiene un nuevo modo de comunicación que fue una idea tomada de algunas implementaciones de Multicast en IPv4:

      Anycast - Aunque todavía no está definida una aplicación específica que trabaje con Anycast en IPv6, este método de comunicación es muy interesante. La idea es que varios equipos trabajen con la misma dirección IP y con esto cuando se requiera mandar o recibir información se hace con el equipo más cercano de acuerdo con la tabla de ruteo. Imaginen tener 4 ó 5 servidores de DNS en una red corporativa, todos con la misma dirección IP, esto nos daría redundancia y cada servidor sería contactado solo por los equipos en las subredes más cercanas lo cual evitaría que las peticiones de DNS atraviesen toda la red. En nuestro simil de la fiesta, siempre hay alguna persona más comunicativa que las demás, solo tendríamos que contactar a dicha persona (la que esté más cerca de nuestro lugar) para asegurarnos que él o ella dispersen los detalles de la reunión a los demás .

         Have fun learning!!!

         Rick.

      CrearPor favor para crear contenido
      Top de Expertos
      Pregunte al Experto- Implementación y Operación redes inalámbricas WLCA