30 de abril de 2019

Un poco más de CEF

Ya en varias oportunidades abordé la temática de cómo se ejecuta en los dispositivos el reenvío de tráfico IP, IP forwarding o enrutamiento IP.

Algunos de los posts ya publicados sobre este tema son:
En este sentido, la introducción de CEF ha sido una respuesta a las necesidades crecientes de throughput y de reducción la latencia de las conexiones.
Los mecanismos precedentes (process switching, fast switching) son mecanismos intensivos en recursos de cómputo con lo que requieren un mecanismo que permita aumentar su eficiencia y mejorar el aprovechamiento de los recursos de cómputo.

Para dar respuesta a estas necesidades CEF optimiza las dos tareas más complejas y demandantes de recursos que incluye el proceso de enrutamiento de un paquete IP:
  • La selección de la mejor ruta (lookup de la tabla de enrutamiento) para alcanzar el destino, incluyendo la interfaz de salida a utilizar para reenviar el paquete.
    A esto busca responder con la implementación de una FIB.
  • La construcción del encabezado de capa de enlace de datos que se debe utilizar, lo que también se conoce como la reescritura de la trama (frame rewrite).
    Para esto implementa la tabla de adyacencias.
El lookup de la tabla de enrutamiento
En el esquema tradicional de operación, para encontrar la mejor ruta a un destino específico para un paquete concreto, es necesario revisar la tabla de enrutamiento (RIB) completa, entrada por entrada, y encontrar la ruta con mejor coincidencia con la dirección IP destino.
La regla primaria de esta búsqueda es encontrar la ruta con la coincidencia más extensa (longer prefix match) que surge de la comparación entre las diversas entradas posibles en la tabla de enrutamiento. Una revisión de la tabla completa debiera ser suficiente para lograr esta respuesta.
Pero si la ruta seleccionada como la más precisa sólo contiene la dirección IP del próximo salto y no la interfaz de salida (a través de la cual se debe sacar el paquete), esta búsqueda no será suficiente y se deberá repetir el proceso hasta localizar una red directamente conectada a través de la cual se puede alcanzar la dirección IP del próximo salto para entonces tener una interfaz de salida.
Esta tarea requiere generalmente entre 2 y 3 revisiones (lookups) de la tabla de enrutamiento.

El lookup de la tabla de enrutamiento es ineficiente.
Para hacer más eficiente el proceso CEF aplica varios criterios:
  • Ordena la tabla de enrutamiento en función de la longitud de los prefijos partiendo por los prefijos /32, siguiendo por los /31 y así en forma decreciente hasta llegar a la ruta por defecto (0.0.0.0/0) al final de la tabla.
  • La tabla se revisa desde su primer entrada, entrada por entrada, realizando una operación AND entre la dirección IP destino del paquete y la longitud de los prefijos; el resultado se compara con la dirección de red de cada entrada y se detiene al alcanzar la primer coincidencia.
    Dado que la tabla está organizada desde lo más específico a lo más general, la primer coincidencia es automáticamente el prefijo más largo (longest prefix).
  • La información de la ruta proporciona la interfaz de salida para evitar realizar búsquedas recursivas.
  • Esto no es la tabla de enrutamiento, es una tabla diferentes que se almacena como una tabla independiente construida a partir de la información contenida en la tabla de enrutamiento.
    Esta tabla es la Forwarding Information Base (FIB).
La FIB es una base de datos construida dinámicamente a partir de la información proporcionada por la tabla de enrutamiento; en ella se almacenan los prefijos IP vinculados con sus próximos saltos ya resueltos. Esto permite resolver el reenvío del paquete en un único lookup sin necesidad de apelar a 2 o 3 búsquedas recursivas.

La idea básica es guardar los prefijos que corresponden a todas las redes destino conocidas de la RIB en la FIB.
Pero esta base de datos, no sólo almacena las decisiones de reenvío ya resueltas sino que también las ordena de modo de optimizar la velocidad y el uso de procesamiento en la búsqueda de la coincidencia más larga.

Para esto la tabla tiene una estructura lógica de árbol de decisiones en la que la dirección de destino es analizada dígito a dígito (bit a bit, nodo a nodo) hasta encontrar la mejor coincidencia.
Dado que las direcciones IPv4 tienen 32 bits de longitud, estos registros tienen una profundidad máxima de 32 nodos o bits (33 si contamos el nodo root).

Consecuentemente, para realizar un lookup:
  • Parte de un nodo raíz como "current node".
  • Se intenta avanzar buscando un nodo del siguiente nivel que coincida con el siguiente dígito.
  • Si no hay una siguiente coincidencia , la búsqueda se detiene y la última coincidencia alcanzada representa la mayor longitud de prefijo encontrada.
  • Si hay una siguiente coincidencia, se define esta nueva posición como current node y se repite el proceso hasta completar la búsqueda o hasta que no haya nuevas coincidencias.
Así, la selección de la ruta a utilizar para una dirección IP destino demandará como máximo 32 comparaciones consecutivas para alcanzar la definición de la interfaz de salida, sin importar cuál sea la cantidad total de rutas o de prefijos IP almacenados en la tabla.

Si tomamos como ejemplo una dirección destino (para simplificar consideraré un solo octeto) de un octeto con valor 112 (01110000).




  • Current node inicial: el nodo raíz.
  • Revisa el primer bit no procesado de la dirección destino, un cero (0).
  • Se busca en el siguiente nivel de la tabla (A) un bit en cero (0) y como existe, este es ahora el current node.
  • Revisa el siguiente bit no procesado, es un uno (1).
  • Se busca en el nivel B de la tabla un bit en uno derivado del 0 en el nivel A, y como existe, este será el nuevo current node.
  • Nuevamente se toma el siguiente bit sin procesar, en este caso un uno (1).
  • Se busca nuevamente en la tabla si hay un bit en uno (1) en el nivel C asociado al 1 del nivel B, y como existe, se toma este como siguiente current node.
  • El siguiente bit no procesado es otro uno (1).
  • Se revisa la tabla para verificar la presencia de un bit en uno (1) en el nivel D asociado al 1 del nivel C. Existe y por lo tanto se toma este como current node.
  • El siguiente bit no procesado es ahora un cero (0).
  • Busca entonces en la tabla, en el nivel E, un 0 como asociado al 1 del nivel D. Existe y este pasa a ser ahora el current node.
  • Así se continúa hasta completar el análisis del prefijo y definir cuál es la entrada de la tabla FIB que da respuesta al requerimiento de definir un destino para alcanzar la dirección IP destino del paquete.
De esta manera se localiza la ruta con mejor correspondencia (longest matching prefix) con la dirección IP destino del paquete, y con ella la interfaz a través de la cual debe ser reenviado hacia el próximo salto.
El próximo paso es obtener la información necesaria para reescribir el encabezado de la trama, y para eso necesitamos la tabla de adyacencias.

La tabla de adyacencias
La FIB sólo proporciona la información referida a la interfaz a través de la cual se debe reenviar el paquete, pero no cuenta aún con la información necesaria para construir el nuevo encabezado de la trama o completar el frame rewrite.
Encapsular el paquete con el encabezado de trama correcto es un requisito para poder finalmente enviar el paquete hacia su próximo salto y esto debe repetirse para cada paquete que se envía al mismo próximo salto o vecino.

El dispositivo puede conocer cientos de miles de rutas a diferentes destino, pero en general está conectado a un número reducido de dispositivos vecinos que ofician como próximos saltos de cada ruta. 
Por este motivo múltiples entradas de la FIB utilizan el mismo próximo salto, la misma interfaz de salida y por lo tanto el mismo encabezado de la trama para el reenvío de los paquetes.
Esto hace que lo más eficiente sea que la información necesaria para concretar el envío del paquete se complete aún antes de que haya algún flujo de datos.
Los próximos saltos se conocer a partir de la RIB y sus direcciones de capa 2 se pueden obtener de mecanismos como ARP. 

Esta información se almacena en otra base de datos conocida como tabla de adyacencias.

La tabla de adyacencias es una base de datos que contiene la lista de todos los dispositivos adyacentes conocidos por nuestro router y la información correspondiente.
Una adyacencia es la información completa necesaria para reenviar el paquete a otro dispositivo que está directamente conectado: la interfaz de salida junto con el encabezado de trama que se puede utilizar para enviar los paquetes a ese vecino.

Supongamos un router conectado a otros routers vecinos a través de interfaces GigabitEthernet.
Para revisar su tabla de adyacencias debemos utilizar el comando show adjacency detail


Router# show adjacency detail
Protocol Interface            Address

...
IP       GigabitEthernet0/2   192.168.3.3(7)
                              0 packets, 0 bytes
                              epoch 0
                              sourced in sev-epoch 0
                              Encap length 14
                              005079666802CA0320A4003D0800
                              ARP

Lo que se muestra es la información necesaria para prefabricar el encabezado Ethernet.

En particular el encabezado completo:

005079666802CA0320A4003D0800

005079666802   Dirección MAC destino
CA0320A4003D   Dirección MAC origen
0800                     Ethertype del paquete que se encapsula


El contenido es semejantes cuando se trata de subinterfaces 802.1Q ya que incluye el valor del campo clase de servicio y el ID de VLAN.

Router# show adjacency detail
Protocol Interface               Address

...
IP       GigabitEthernet0/2.100  192.168.3.3(7)
                                 0 packets, 0 bytes
                                 epoch 0
                                 sourced in sev-epoch 0
                                 Encap length 14
                                 005079666802CA0320A4003D81000064
                                 0800
                                 ARP

005079666802CA0320A4003D81000064

005079666802   Dirección MAC destino

CA0320A4003D   Dirección MAC origen
8100           Ethertype para un encabezado 802.1Q
0              Clase de servicio (0)
064            Etiqueta de VLAN 100 (64 en hexadecimal)
0800           Campo Ethertype original de la trama antes del etiquetado

La FIB y la tabla de adyacencia son 2 componentes clave de CEF.

La FIB contiene los prefijos IPv4 que identifican todas las redes destino conocidas y los organiza de modo de acelerar el proceso de lookup. El resultado de la búsqueda en la FIB apunta a una entrada en la tabla de adyacencias.
La tabla de adyacencias contienen los encabezados de trama a utilizar con cada uno de los próximos saltos de modo de aplicarlos inmediatamente a los paquetes para su envío a los dispositivos adyacentes.


Podés participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


25 de abril de 2019

El modelo OSI en funcionamiento

Siempre es bueno volver a lo esencial, y eso en el estudio de las redes de datos es volver a revisar el modelo OSI.

Recordemos.
El modelo OSI es un modelo estándar desarrollado por la ISO y publicado en el año 1984. Gestado a partir de modelos precedentes (DecNet, SNA y TCP/IP). No es el adoptado por la IETF para Internet (el modelo adoptado por Internet es TCP/IP) pero sí el utilizado masivamente por la industria del networking para su desarrollo, documentación y entrenamiento.
De aquí surgen expresiones tales como "switch capa 3" o "protocolo de capa 4". Y también su importancia para el diseño de redes y la resolución de problemas. 

Es el modelo de arquitectura primaria para redes de datos que describe de manera pormenorizada el flujo de la información desde un dispositivo de origen, a través de los medios de conexión, hasta un dispositivo destino.
Divide el proceso global en agrupaciones lógicas más pequeñas que reciben la denominación de capas o layers en inglés. en cada una de las cuales se desarrolla una operación diferente.
Para la transferencia de información entre las diferentes capas se definen interfaces estándar de intercambio tanto hacia las capas superiores como inferiores.
Cada capa proporciona diferentes servicios a las capas que están por encima y por debajo de ella para establecer y sostener una conexión extremo a extremo con la misma capa en el sistema destino.



A medida que la información desciende o asciende a través de las diferentes capas durante el proceso de transmisión, cada protocolo implementa información adicional específica que permite asegurar la recuperación de la integridad de la información en su formato original luego de completar la transmisión.

El formato, contenido y extensión de esta información es determinada por los diferentes protocolos que se implementan en cada capa, de acuerdo a su función.

Al agregar en cada capa información complementaria necesaria para la transmisión se generan unidades de transmisión de datos (PDUs) que reciben denominaciones específicas de acuerdo al nivel de la capa OSI en la que se encuentran: segmento, paquete, trama, bit.



Los encabezados se agregan en el transmisor al pasar de una capa superior a una inferior (encapsulado), y se retiran en el receptor al pasar de una capa inferior a una capa superior (desencapsulado).



Un ejemplo.
Al intentar navegar un sitio web, esta navegación se establece utilizando el protocolo HTTP. Para eso utilizamos una aplicación que es un cliente HTTP como puede ser un navegador web; el navegador web permite interactuar utilizando el protocolo HTTP con un servicio HTTP hospedado en un servidor web.
La negociación de HTTP se realiza directamente (peer to peer) entre cliente en servidor. Pero para poder establecer esta negociación es necesario pasar por una serie de capas intermedias que permiten localizar el servidor, establecer un circuito virtual y transferirle la información de modo seguro y en un formato adecuado. Esto se realiza utilizando diferentes protocolos en cada una de las diferentes capas a fin de lograr esa transferencia.








Podés participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


20 de abril de 2019

768k day

He visto varias publicaciones, algunas de ellas bastante confusas, respecto de un nuevo hito en el desarrollo de Internet que debiera alcanzarse dentro de los próximo 30 días según prevén algunos especialistas: el 768k Day.
Como he notado cierta imprecisión en algunas de estas publicaciones me pareció conveniente revisar algunos aspecto desde una perspectiva más técnica, para comprender de qué se trata.

Algo sobre Internet
Internet es hoy una realidad muy diferente de lo que se concibió inicialmente.
En sus inicios a fines de los años '60 no sólo la población mundial era menos de la mitad de la población actual sino que el acceso a la tecnología y a la conectividad era claramente minoritario. Nadie podía en aquellos inicios anticipar que hoy Internet contaría con más de 4.200.000.000 de usuarios conectados y más de 2.400.000.000 de usuarios en una sola red social (Facebook).
Uno de los cimientos sobre los que se asienta este crecimiento actual de Internet es el protocolo de direccionamiento puesto en operación a inicios de la década de los '80, el protocolo IPv4 cuyo agotamiento se anunció en el año 1994 y que está aún en proceso de reemplazo por IPv6 (al momento de escribir este post, casi el 75% del tráfico de Internet aún circula utilizando IPv4).
El otro, no menos relevante, es BGPv4. El protocolo de enrutamiento que sostiene toda la infraestructura de Internet y que permite localizar y alcanzar cualquier red remota (IPv4 o IPv6) dentro de la red global.

Algo sobre BGPv4
BGPv4 es el protocolo de enrutamiento diseñado específicamente para mantener el enrutamiento de Internet.
  • Apunta primariamente a la estabilidad de las tablas de enrutamiento.
  • Requiere muchos ciclos de procesamiento y espacio de memoria RAM.
    Es un protocolo intensivo en el uso de recursos.
  • Sobre él descansa toda la infraestructura de enrutamiento de Internet.
  • Transporta tanto rutas IPv4 como IPv6.
  • Mantiene tablas independientes para el enrutamiento IPv4 y el enrutamiento IPv6.
  • Propone la mejor ruta a cada destino posible a la tabla de enrutamiento del dispositivo.
Y aquí está la base del "problema".
Las tablas TCAM en las que se mantienen las tablas de reenvío rápido del tráfico tienen un tamaño limitado.

Un primer antecedente: 512k Day
El 512k Day tuvo lugar el 12 de agosto de 2014.
En ese día las tablas TCAM de los routers responsables del mantenimiento del enrutamiento de Internet alcanzaron el límite del espacio reservado para el mantenimiento de rutas IPv4 a diferentes destinos: 524.288 registros o rutas (512k). Hasta ese momento el espacio asignado se consideraba más que suficiente y no se advirtió que las tablas TCAM estaba llegando a su límite.
En esa fecha Verizon publicó 15.000 nuevas rutas BGP lo que provocó que las tablas de enrutamiento superaran rápidamente y sin previo aviso el límite que tenían asignado. Como consecuencia de esto los dispositivos de los principales proveedores de conectividad de Internet comenzaron a presentar dificultades para actualizar sus tablas de enrutamiento.
Esto requirió en algunos casos el reemplazo de hardware, pero en la mayoría se solucionó con una actualización de sistema operativo o firmware para ampliar la porción de memoria TCAM asignada para mantener la tabla de enrutamiento global.

Ahora, el 768k Day
En el año 2014, cuando se decidió ampliar la porción de memoria asignada a las tablas de enrutamiento IPv4 la mayoría de los administradores siguieron la recomendación que se hizo en el momento y que sugería llevar esa capacidad hasta 786.432 registros (768k).
Ahora, los especialistas que siguen la evolución del enrutamiento de Internet acaban de realizar una advertencia el pasado 17 de abril debido a que las tablas de enrutamiento IPv4 han alcanzado los 767.392 registros.
Una cifra nuevamente próxima al límite establecido.
El estado actual puede sintetizarse en estos números:
  • 767.392 prefijos IPv4.
  • 57,37% son prefijos /24.
  • 64.222 sistemas autónomos en total, de esos 47.607 están publicando solamente prefijos IPv4.
Los especialistas estiman que al ritmo actual de crecimiento de las tablas, en los próximos 30 días se alcanzará el límite de los 768k prefijos. Pero más allá del conteo de prefijos, esperan que no provoque inconvenientes globales como ocurrió en el año 2014.
La mayoría de los grandes proveedores de conectividad tienen el equipamiento adecuado, están prevenidos y pueden tomar las medidas necesarias para evitar inconvenientes; sin embargo, es de esperar que proveedores de servicios locales, pequeños, y algunas empresas u organizaciones que no están preparados se vean afectados.

Para tener en cuenta:
  • Los dispositivos obsoletos deberán ser reemplazados con equipamiento nuevo que permite el ajuste necesario de las tablas TCAM.
  • Los ajustes de las tablas TCAM son posibles en la medida en que no se esté utilizando todo el espacio reservado para rutas IPv6 (la tabla TCAM es físicamente una única tabla que se utiliza para almacenar tanto rutas IPv4 como rutas IPv6, la tablas de rutas IPv6 son mucho más cortas).
  • Los cambios de configuración de las tablas TCAM requiere el reinicio de los dispositivos.
  • No se cuenta con información que permita estimar la cantidad y ubicación de los routers que puedan ser afectados por esta situación.


Podés participar de nuestro grupo en Facebook:

https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


16 de abril de 2019

IDs de VLANs en switches Catalyst

Cada VLAN en la red es identificada a través de un VLAN ID (VID) que puede tener hasta 12 bits de longitud. 
De ahí que el rango de IDs utilizables para troncales 802.1Q es de 0 a 4096, pero no todos esos valores son igualmente utilizables.
La siguiente tabla presenta los diferentes rangos dentro de ese espacio de 10 bits que se utilizan con diferente propósito.




Podés participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.


2 de abril de 2019

Error disabled

Cuando el puerto de un switch se encuentra activo es posible que por diferentes motivos el sistema operativo del dispositivo detecte diferentes situaciones de error que requieren que el puerto se inactive. En estos casos el sistema operativo desactiva el puerto automáticamente.

Este estado de un puerto desactivado automáticamente por el sistema operativo es el que se identifica como error disabled (errdisable).

En los switches Catalyst, cuando un puerto es colocado en estado de error disabled:
  • El puerto no envía ni recibe tráfico.
  • El LED del puerto se coloca en color naranja.
  • Cuando se verifica el estado del puerto se reporta como err-disabled.
Cuando un puerto es automáticamente colocado en modo error disabled se generan mensajes de notificación de eventos como este:

%SPANTREE-SP-2-BLOCK_BPDUGUARD: Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.
%PM-SP-4-ERR_DISABLE: bpduguard error detected on Gi4/1, putting Gi4/1 in err-disable state

El mensaje que completa la notificación depende de la razón que ha generado la condición de error.

La condición de error disabled apunta a 2 propósitos:
  • Poner en conocimiento del Administrador que hay un problema en ese puerto.
  • Eliminar la posibilidad de que el problema registrado en ese puerto pueda generar una falla en otros puertos del dispositivo..
Causas de un estado error disabled
Las siguientes condiciones provocan que el puerto sea colocado en error disabled por defecto.
  • La detección de un número excesivo de colisiones (más de 16) en el medio o de colisiones tardías (late collisions).
    Una de las causas de colisiones tardías puede ser un error de configuración en el modo dúplex de las interfaces.
  • Dúplex mismatch.
  • Error de configuración de port channel.
  • Condición unidireccional con UDLD
  • Detección de flapeo de un enlace.
  • Violación de seguridad port-security.
  • Flapeo con PAgP.
  • L2TP guard.
  • Límite de tasa en DHCP snooping.
  • GBIC o SFP incorrecto.
  • Violación de ARP inspection
  • Inline power.
Para desactivar la detección de errores en alguna causa específica, se utiliza el comando

Switch(config)# no errdisable detect cause [causa]

Verificación de puertos en estado error disabled
Los siguientes comando permiten verificar el estado de los puertos del switch:

Switch# show interfaces gigabitethernet 0/1 status 

Port   Name          Status        Vlan   Duplex  Speed Type

Gi0/1                err-disabled  100    full    1000  1000BaseSX

Es posible implementar la recuperación automática de la operación del puerto utilizando el comando errdisable recovery. En este caso se puede utilizar el siguiente comando para determinar cuál ha sido la causa de que un puerto entre en modo error disabled.

Switch# show errdisable recovery
ErrDisable Reason    Timer Status
-----------------    --------------
udld                 Enabled
bpduguard            Enabled
security-violatio    Enabled
channel-misconfig    Enabled
pagp-flap            Enabled
dtp-flap             Enabled
link-flap            Enabled
l2ptguard            Enabled
psecure-violation    Enabled
gbic-invalid         Enabled
dhcp-rate-limit      Enabled
mac-limit            Enabled
unicast-flood        Enabled
arp-inspection       Enabled

Timer interval: 300 seconds

Interfaces that will be enabled at the next timeout:
Interface      Errdisable reason      Time left(sec)
---------    ---------------------    --------------

  Gi0/1                bpduguard          273

El comando show error disabled detect permite verificar en un dispositivo particular las situaciones que pueden colocar un puerto en modo error disabled.

Switch> show errdisable detect
ErrDisable Reason    Detection    Mode
-----------------    ---------    ----
arp-inspection       Enabled      port
bpduguard            Enabled      vlan
channel-misconfig    Enabled      port
community-limit      Enabled      port
dhcp-rate-limit      Enabled      port
dtp-flap             Enabled      port
gbic-invalid         Enabled      port
inline-power         Enabled      port
invalid-policy       Enabled      port
l2ptguard            Enabled      port
link-flap            Enabled      port
loopback             Enabled      port
lsgroup              Enabled      port
pagp-flap            Enabled      port
psecure-violation    Enabled      port/vlan
security-violatio    Enabled      port
sfp-config-mismat    Enabled      port
storm-control        Enabled      port
udld                 Enabled      port


Los comandos presentados en este post
aplican tanto a IOS como a IOS XE.




Podés participar de nuestro grupo en Facebook:
https://www.facebook.com/groups/librosnetworking/

O seguir las principales novedades en el grupo de Telegram:

https://t.me/LibrosNetworking


Las abreviaturas y siglas utilizadas en este post puede encontrarlas desarrolladas en
que está disponible en la Librería en Línea de EduBooks.