Mostrando las entradas con la etiqueta Monitoreo. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Monitoreo. Mostrar todas las entradas

30 de noviembre de 2022

Introducción a Flexible NetFlow

En oportunidades anteriores me he referido a NetFlow, una herramienta para monitoreo de tráfico introducida por Cisco en IOS en el año 1996. El desarrollo inicial, con el paso de los años, dio lugar a herramientas semejantes desarrolladas por otros fabricantes (JFlow, sFlow, etc.) y una herramienta abierta como IPFIX (RFCs 5101, 5102, 5103, 5153, 5470,v5471, 5472).

Flexible NetFlow es una variante que habilita la posibilidad de definir el registro que considere óptimo para responder a las necesidades de una aplicación en particular seleccionando los elementos clave que se desean detectar a partir de una colección de campos predefinidos.

La herramienta monitorea flujos (flow):

  • Cada flujo de datos es unidireccional.
  • Un flujo se define por una misma interfaz de origen y un mismo conjunto de valores clave.
    Una clave es un valor identificado en un campo de un encabezado.
  • Todos los valores clave deben coincidir para que un paquete se considere parte de un flujo determinado.
  • Los flujos se almacenan en un caché de memoria específico para Flexible NetFlow.
Como ocurre con NetFlow, los datos recopilados pueden recopilarse mediante la implementación de un "exportador" (exporter) para enviarlos a un sistema remoto que se acceda por IPv4 o IPv6.

En la implementación o configuración hay 4 elementos que se deben considerar:

  • El registro de NetFlow que almacena los datos que se recogen.
  • El exportador que permite el envío de los datos a una herramienta remota.
  • El "monitor" que asocia un registro con un exportador específico.
  • El muestreo de los flujos que determina la frecuencia con que se captura la información
NetFlow original

  • Utiliza de modo fijo el valor de 7 campos de los encabezados IP para identificar los flujos.
  • Brinda comprensión de las actividades en las red, lo que permite optimizar el diseño y reducir los costos operativos.

Flexible NetFlow

  • Permite al Administrador definir los campos que identifican un flujo.
  • Nos permite comprender los comportamientos en la red con mayor eficiencia, con información específica adaptada a los diversos servicios de la red.
Beneficios:
  • Alta capacidad para gestionar la identificación de los flujos, lo que brinda escalabilidad y la posibilidad de agregar información de los flujos.
  • Mejora las posibilidades de utilizar esta infraestructura para monitoreo de seguridad y detección de ataques dDoD.
  • Permite agregar nueva información del paquete para adaptar la definición del flujo a un servicio u operación en particular.
  • Hace uso extenso de los formaos de exportación flexibles y extendidos de NetFlow v.9 y v.10 de Cisco.
  • Utilizando el formato de exportación de versión 10 se incorporan campos de longitud variables para incluir el SSID del tráfico de los clientes inalámbricos.
Ejemplos de aplicación de Flexible NetFlow:

  • Brinda una mejor herramienta de monitoreo de seguridad.
    Por ejemplo, se puede incluir como clave para identificar un flujo la longitud del paquete o la MAC.
  • Identifica rápidamente el volumen de tráfico de aplicaciones que se envía entre hosts ya que puede hacer seguimiento del tráfico en base al valor de CoS.
  • Permite contabilizar el tráfico entre una red MPLS o un core IP y los próximos saltos discriminados por clase de servicio. A partir de esto es posible luego generar una matriz de tráfico. 
Componentes

La implementación consta de una serie de componentes que se pueden combinar de diferentes formas para realizar el análisis del tráfico y la exportación de los datos.

Esta estructura de la herramienta facilita la generación de diferentes configuraciones en un mismo dispositivo de red, con un mínimo de comandos de configuración.

Los componentes son 4:

  • Los registros de NetFlow
  • Los exportadores de NetFlow
    Determina el destino al que se envían los datos capturados por el registro de flujos.
    Si se cambia el destino en un exportador, afecta a todos los monitores que utilizan ese exportador.
  • Los monitores de NetFlow
    Cada monitor de flujo puede tener una combinación diferente de registros, exportador y tipo de caché de memoria.
    El mismo monitor puede utilizar diferentes muestreadores de flujo para muestrear el mismo tráfico en diferentes interfaces.
  • Los muestreadores de NetFlow
    Determina la frecuencia con la que se capturan datos en una interfaz.

Registros de flujos

  • Combinación de campos clave y no clave que han de tomarse en consideración.
  • Los campos clave son los que se utilizan para identificar un paquete como parte de un flujo de datos.
    Los demás se incorporan como campos de interés que brandan información adicional sobre ese flujo.
  • Se puede definir cualquier combinación de campos clave y campos de interés.
  • También define los contadores que se recopilan por flujo.
  • Se pueden utilizar registros que vienen definidos de fábrica e implementar rápidamente la herramienta, 
  • También es posible generar registros a medida seleccionando los campos clave y no clave (de interés) que han de considerarse.
  • Los datos que se recopilan, se almacenan en un caché de memoria del dispositivo.
Exportadores de flujos
  • Exportan los datos almacenados en la memoria caché a un sistema remoto de análisis y almacenamiento.
  • Se pueden agregar a un monitor de flujos para agregarle a este capacidades de exportación.
  • El mismo exportador de flujos puede ser asignado a diferentes monitores.
  • La exportación puede realizarse en diferentes formatos. El formato de exportación más reciente es el que se conoce como versión 9.
    Su característica básica es que se basa en plantillas que brindan un diseño adaptable.
Monitores de flujos
  • Es el componente que se aplica a la o las interfaces en las que se desea monitorear tráfico.
  • Los datos se colectan en la interfaz a partir del tráfico y se almacenan en el caché de memoria en base a los campos clave y no clave definidos en el registro.
  • Puede tener asociados uno o más exportadores de flujos.
  • Hay 3 tipos de cachés de memoria de los monitores de flujos:
    - Normal
      Es el predeterminado.
      Las entradas de datos caducan de acuerdo con el tiempo de espera configurado. Cuando una entrada caduca se elimina del caché y se exporta.
    - Inmediato
      Las entradas vencen tan rápido como se crean. El resultado es que cada flujo representa un único paquete.
      Proporciona poca latencia entre que se detecta el paquete y se exportan los datos.
    - Permanente
      Los datos de un flujo no tienen vencimiento.
      Es útil cuando la cantidad de flujos que se espera es baja y es necesario mantener estadísticas en el dispositivo.
Muestreadores de flujos
  • Limitan la cantidad de paquetes que se seleccionan para el análisis.
  • Permiten reducir la carga de procesamiento en el dispositivo.
  • Priorizan la performance del dispositivo por sobre la precisión en el monitoreo.
Enlace de referencia



Estás invitado a seguirnos en Instagram:
https://www.instagram.com/libros.networking/

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

O si preferís redes sociales con mayor respeto de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

O también puedes 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.



13 de agosto de 2022

Monitoreo de switches Catalyst en el portal Meraki (2)

Hace ya algunos meses Cisco ofrece la posibilidad de utilizar el portal (dashboard) de Meraki para monitorear los switches Catalyst de la serie C 9000.
Por esto, ahora es posible monitorear switches Catalyst desde la nube de Meraki.
Este post, junto al anterior, pretende describir el procedimiento necesario para incorporar los switches Catalyst 9000 de la infraestructura corporativa en el tablero de Meraki. Lo descripto en este post supone una primera parte que puedes revisar aquí.

Procedimiento para la incorporación de los switches
Una vez descargada e instalada la aplicación de "onboarding" es necesario proceder a incorporar los switches Catalyst en el tablero Meraki.
La aplicación es un desarrollo independiente que se ejecuta localmente en una terminal corriendo sistema operativo Windows, MacOS o Linux (en Linux tenga presente que es una herramienta GUI que actualmente no incluye una versión CLI).
  • Sugerencia:
    Antes de iniciar el procedimiento realice una copia de seguridad de la configuración de cada uno de los switches que va a incorporar al tablero de Meraki.
Al iniciar la aplicación por primera vez la misma realizará una verificación de la versión y si corresponde ofrecerá descargar la última versión. A continuación presenta los términos y condiciones del servicio que deberán ser aceptados por el operador.

A continuación se abre la página principal en la que encontrará sobre la derecha una ventana para ingresar la "clave de API" que generó en el paso 4 de las acciones de preparación que realizó previamente en el tablero de Meraki con un acceso de usuario Administrador (ver aquí).
Ingrese la clave API en la ventana y seleccione el botón "Start". Completada la tarea recibirá en pantalla un mensaje de confirmación "Successfuly logged in".

A partir de este momento siga paso a paso las instrucciones para asociar sus switches al tablero de Meraki que aparecerán en la columna de la izquierda:
  1. Confirme la organización asociada con la clave API y a la que han de agregarse los switches.
    Si tiene que agregar switches a diferentes organizaciones se debe ejecutar la misma aplicación por separado para cada organización.
  2. Ingrese la dirección IP de gestión (management) de los switches que se quieren incorporar en el tablero. Esta dirección debe ser accesible desde la computadora en la cual se está ejecutando la aplicación.
    Se utilizará para establecer una sesión SSH. Si el switch tiene configurado un puerto específico diferente del puerto por defecto (TCP 22) debe ser especificado utilizando los dos puntos como separador. Ejemplo: 192.168.1.100:3522
  3. Ingrese las credenciales de acceso remoto SSH de los switches.
    Tenga presente que estas credenciales se ingresan una sola vez para todos los switches que se ingresaron en la lista anterior, por lo que deben ser las mismas credenciales en todos los switches que estamos asociando al portal de Meraki.
    Si los switches tienen diferentes credenciales este procedimiento deberá ser repetido individualmente para cada switch.
  4. La aplicación realizará una serie de comprobaciones para verificar que el hardware y la configuración son elegibles para su incorporación en el tablero.
  5. A continuación debemos seleccionar a qué red de la organización ha de asociarse cada uno de los switches a incorporar.
    Para esto las redes debieron ser creadas previamente (paso 7 de las acciones de preparación previa). Las redes deben ser tipo "Hardware combinado" o "Switch".
    Cada switch puede ser agregado en una red diferente utilizando el menú desplegable de la derecha.
  6. La incorporación de los switches en el tablero de Meraki requiere de cambios en la configuración del switch que serán realizados automáticamente por la aplicación.
    Antes de realizarlos la aplicación requiere la confirmación de esos cambios.
    En la pantalla se muestran los switches a incorporar y permite verificar los cambios que se harán en cada uno. Para confirmarlos, es necesario seleccionar el checkbox que está a la izquierda de la dirección IP de gestión de cada switch.

    Los cambios pueden ser verificados seleccionando el enlace "Show details" en el extremo derecho de la fila correspondiente a cada switch.
  7. Seleccione el botón "Next" para que se apliquen los cambios.
    La aplicación le permite ver en pantalla a medida que se realiza los cambios el avance de las tareas. El proceso llevará algunos minutos y puede que el resultado final con la información adicional correspondiente demore en mostrarse.
  8. Una vez concluida la operación, usted verá los switches Catalyst en el tablero de Meraki. La información puede demorar varios minutos en actualizarse.

De esta forma, se completa el procedimiento.


Enlaces útiles


Estás invitado a seguirnos en Instagram:
https://www.instagram.com/libros.networking/

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

O si preferís redes sociales con mayor respeto de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

O también puedes 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.



1 de agosto de 2022

Monitoreo de switches Catalyst en el portal Meraki (1)

Desde hace unos meses Cisco ofrece la posibilidad de utilizar el portal (dashboard) de Meraki para monitorear los switches Catalyst de la serie C 9000.
De esta manera podemos afirmar que ahora es posible monitorear switches Catalyst desde la nube de Meraki.
Por eso me pareció oportuno revisar en qué consiste esta posibilidad y cómo se implementa.

¿Qué dispositivos se pueden monitorear?
Esta posibilidad aplica a switches Catalyst que se encuentran dentro de estas condiciones:
  • Switches Catalyst Serie 9200
  • Switches Catalyst Serie 9300
  • Switches Catalyst Serie 9500
  • Sistema operativo IOS-XE 17.3.x o posterior
  • Con licencia activa DNA Essentials o DNA Advantage
También es necesario contar con una cuenta de acceso al tablero de Meraki. Para esto puede crearse una cuenta gratuita.

Acciones de preparación
  1. Ingrese al tablero de Meraki: https://dashboard.meraki.com/
  2. Obtenga la clave API del tablero de la organización a la cual se desea asociar los switches Catalyst.
    Para esto, acceda a "Organización">"Ajustes">"Configurar".
    Busque la sección "Acceso de API al panel" y seleccione la opción "Permitir acceso a la API de Cisco Meraki Dashboard".
  3. Guarde los cambios antes de abandonar la página.
  4. A continuación ingrese en "Mi Perfil" y busque la sección "Acceso de API" y seleccione el botón "Generar nueva clave de API" o utilice la clave existente si ya se ha creado una antes.
    Para esto debe contar con una cuenta de usuario Administrador.
  5. Para operar deberá descargar la "Aplicación de Onboarding" en una terminal. Antes de proceder verifique que pueda acceder a api.meraki.com puerto TCP 443.

    C:>ping api.meraki.com
    C:>telnet api.meraki.com 443


    Tenga en cuenta que los proxys HTTPS que modifican el certificado digital no son compatibles con esta aplicación.
  6. También los switches Catalyst necesitan acceso a la nube de Meraki a través de Internet.
    En este caso es necesario prever que los firewalls permitan establecer comunicación con el punto de acceso correspondiente a cada región:

    América:                       us.tlsgw.meraki.com
    EMEA:                          eu.tlsgw.meraki.com
    Asia Pacífico y Japón:  ap.tlsgw.meraki.com

  7. La red en la que se incorporen los switches Catalyst deberá ser tipo "Hardware combinado" o "Switch".

Requisitos para la conectividad desde los switches
  • La conexión a la nube de Meraki se realiza desde un puerto de datos, no desde el puerto de management.
  • Solo se admite el VRF predeterminado.
  • Se debe habilitar el enrutamiento IP (ip routing) en el dispositivo.
  • Debe existir ruta para llegar a las direcciones externas. Puede ser una ruta por defecto, no se admite el uso de ip default-gateway.
  • Debe estar asignado un servidor DNS en el dispositivo (ip name-server).
  • Se debe implementar un servidor NTP y asegurarse que fecha y hora en el switch sean correctas.
  • Debe activarse aaa new-model.
  • Debe estar habilitado el acceso SSH a la CLI del dispositivo a través de la terminal que se utilice para la incorporación.
    El acceso debe ser con un usuario con nivel de privilegios 15.
Se sugiere realizar una copia de seguridad de la configuración del switch antes de iniciar el proceso de incorporación al portal de Meraki.

Descarga de la aplicación de "onboarding"
La aplicación de onboarding necesaria se puede descargar del tablero de Meraki.
Para descargarla ingresar a "Toda la red" > "Añadir dispositivos" y seleccionar el enlace contenido en la frase "Para agregar switches Cisco Catalyst al panel, haga clic aquí."

Esta aplicación es la que se utiliza para incorporar el switch Catalyst al tablero de Meraki. Ejecuta una verificación de compatibilidad y recopila la información de la cuenta de Meraki para crear una conexión encriptada a la nube a través de la cual se enviará la telemetría del dispositivo hacia la nube de Meraki.
La aplicación se puede ejecutar en Microsoft Windows, MacOS o Linux (no hay una versión para CLI de Linux, solo funciona sobre GUI).


Enlaces útiles


Estás invitado a seguirnos en Instagram:
https://www.instagram.com/libros.networking/

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

O si preferís redes sociales con mayor respeto de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

O también puedes 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.



9 de agosto de 2021

¿Qué es Netflow?

 En los últimos años ha ganado relevancia, de modo creciente, una herramienta muy particular: NetFlow.
Originalmente creada para monitorear comunicaciones individuales, hoy es una herramienta utilizada para el análisis tanto de prestaciones de calidad de servicio como de seguridad.
Es por esto que consideré conveniente preguntarnos, ¿qué es NetFlow?

NetFlow es una herramienta de monitoreo desarrollada por Cisco e introducida en las diferentes formulaciones de IOS a partir del año 1996 (Cisco IOS 11.x). Esta herramienta permite relevar información estadística referida al tráfico en la red cuando ingresa o sale a través de una interfaz.
Si bien inicialmente estaba incorporada en la imagen de IOS solamente de algunos dispositivos, progresivamente se ha incorporado a nuevas plataformas de modo que en la actualidad, en redes que utilizan IOS XE, está disponible prácticamente en toda la infraestructura de la red corporativa.
Responde a 2 premisas básicas:
  • Es completamente transparente a las aplicaciones y dispositivos que operan en la red.
  • No es necesario que sea soportada en todos los dispositivos de la infraestructura de la red.
Su implementación tiene múltiples aplicaciones posibles, las más frecuentes son:
  • Registro estadístico de tráfico para realizar un análisis de línea base.
  • Facturación de servicios de red a usuarios.
  • Monitoreo y análisis del tráfico y aplicaciones que están corriendo en la red.
  • Diseño general de seguridad de la red.
  • Detección y prevención de ataques DoS o DDoS.
  • Monitoreo de tráfico malicioso en la red.
Con este propósito NetFlow releva estadística de comunicaciones utilizando el concepto de flujo (flow).
¿Qué es un flujo? Un stream o cadena unidireccional de paquetes entre un sistema de origen y un sistema destino específicos que es identificada tomando como base de referencia 7 parámetros específicos:
  • Dirección IP origen.
  • Dirección ID destino.
  • Puerto TCP o UDP de origen.
  • Puerto TCP o UDP de destino.
  • Tipo de protocolo (campo del encabezado IP).
  • Tipo de servicio (campo del encabezado IP).
  • Interfaz lógica de ingreso.
Esta misma definición de flujo se aplica a tráfico IPv4 e IPv6.
A esta información básica se puede agregar información complementaria a partir de NetFlow versión 9. Los registros NetFlow solo contienen información estadística, no contenido de los paquetes.

Estos datos se exportan como registros de NetFlow hacia un servidor que concentra esos datos y en donde se analizan.
El registro de una comunicación se genera cuando una comunicación TCP llega a su fin, o por un contador de inactividad de la comunicación, o se puede definir por configuración que periódicamente se genere el registro aún cuando la comunicación no ha terminado. 
Transporte de los registros
Los registros de NetFlow se transportan utilizando segmentos UDP que suelen estar dirigidos al puerto 2055 del collector, pero que también puede utilizar otros puertos. 
El dispositivo que genera los registros, en general, no retiene los datos correspondientes a los registros que se envían al collector. Esto no permite realizar un seguimiento del transporte de los registros con lo que, si se produjera la pérdida de algún segmento, no se puede recuperar la información.
Por este motivo algunas implementaciones de NetFlow utilizan SCTP para asegurar el envío de los registros. Particularmente cuando se trata de NetFlow versión 8 o 9.
El inconveniente de este tipo de implementaciones es que se requiere interacción entre cada exporter y cada collector definido; esto puede tener un impacto significativo en la performance de ambos componentes.

Arquitectura de NetFlow
La implementación de NetFlow supone una arquitectura específica:
  • Exporter
    Uno o varios dispositivos que tienen Netflow habilitado.
  • Collector
    Una consola que recolecta y concentra la información.
  • Aplicación de análisis
    Aplicación que procesa los datos generados por el exporter y concentrados en el collector para obtener información significativa.
    Cisco StealthWatch es un ejemplo de este tipo de aplicaciones.

Versiones de NetFlow

Desde su lanzamiento NetFlow ha tenido diferentes versiones.
La versión implementada en los dispositivos Cisco actuales es NetFlow v9. Adicionalmente, la herramienta se abrió con múltiples RFCs de la IETF, lo que dio lugar a IPFIX: 
  • RFC 3954 - NetFlow versión 9.
  • RFC 5101 - Especificación del protocolo de IPFIX para el intercambio de información de flujo de tráfico.
  • RFC 5102 - Modelo de información para IPFIX.
  • RFC 5103 - Exportación bidireccional usando IPFIX.
  • RFC 5153 - Directrices para la aplicación de IPFIX.
  • RFC 5470 - Arquitectura de IPFIX.
  • RFC 5471 - Pautas para las pruebas de IPFIX.
  • RFC 5472 - Pertinencia de IPFIX.
NetFlow es una marca registrada de Cisco.
Pero muchos otros fabricantes han desarrollado herramientas semejantes que cumplen la misma tarea:
  • Argus 
  • Jflow o cflowd de Juniper Networks
  • NetStream de 3Com/HP
  • NetStream de Huawei Technologies
  • Cflowd de Nokia
  • Rflow de Ericsson
  • AppFlow de Citrix
  • sFlow implementado por varios fabricantes: Alcatel Lucent, Allied Telesis, Arista Networks, Brocade, Dell, D-Link, Enterasys, Extreme, F5, Fortinet, Hewlett-Packard, Hitachi, Huawei, IBM, Juniper, LG-Ericsson, ZTE, ZyXEL, etc.


Estás invitado a participar de nuestro grupo en Facebook:

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

O si preferís redes sociales con mayor control de tu privacidad,
podés participar de nuestro grupo en VKontakte
https://vk.com/libros.networking

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.

14 de enero de 2019

LLDP - Link Layer Discovery Protocol

Protocolo de descubrimiento de dispositivos vecinos utilizado en dispositivos de red para publicar información a otros dispositivos de red.
  • Protocolo estándar.
  • Opera en capa de enlace de datos.
  • Independiente de los protocolos de capa de red.
  • Utiliza cambos TLV para intercambiar información.
  • Puede enviar información de capacidad del dispositivo, identidad, configuración, etc.
                                  CDP                              LLDP
Estándar                   Propietario de Cisco      IEEE 802.1AB
Nivel de operación   Capa de enlace de datos   Capa de enlaces de datos
Beneficio                    Más liviano                      Muy ajustable
Configuración            Activo por defecto             Inactivo por defecto

Configuración
Los dispositivos Cisco tienen activado por defecto CDP pero no LLDP, por lo que su uso requiere la activación del protocolo
  • Es unidireccional, opera sólo en modo publicación hacia los vecinos.
  • No solicita información de los vecinos.
  • Envía actualizaciones periódicas utilizando una dirección de multicast.
  • Se activa globalmente y se puede desactivar por cada interfaz.
Switch#configure terminal
Switch(config)#lldp run
  • Activa la operación de LLDP en el dispositivo.
  • Se publican actualizacioens de LLDP por todas las interfaces.
Switch(config)#interface GigabitEthernet0/1
Switch(config-if)#no lldp enable
  • Desactiva la operación de LLDP a través de esta interfaz únicamente. Ya no se publican actualizaciones LLDP a través de la interfaz.
Switch(config-if)#no lldp receive
  • Desactiva la recepción y procesamiento de actualizaciones de vecinos LLDP a través de esta interfaz.
Switch(config-if)#no lldp transmit
  • Bloquea el envío de actualizaciones LLDP a los vecinos directamente conectados. La interfaz aún sigue procesando las actualizaciones que recibe de dispositivos vecinos.

Monitoreo

Switch#show lldp
  • Permite verificar si el protocolo se encuentra activo en el dispositivo y cómo está operando.
Global LLDP information:
    Status: ACTIVE
    LLDP adcertisements are sent every 30 seconds
    LLDP hold time advertised is 120 seconds
    LLDP interface reinitialization delay is 2 seconds
  • Muestra adicionalmente los temporizadores de operación del protocolo.
    En este caso se muestran los temporizadores por defecto.

Switch#show lldp neighbors
  • Muestra de modo sintético la información correspondiente a los dispositivos adyacentes descubiertos por LLDP.
Capability codes:
    (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
    (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other

Device ID   Local Intf   Hold-time   Capability   Port ID
AccessSw      Gi0/11       120           B        Gi0/22
Branch1       Gi0/23       120           R        Gi0/0
Total entries displayed: 2


Switch#show lldp neighbors GigabitEthernet 0/11 detail
  • Muestra la información detallada obtenida de cada uno de los vecinos adyacentes que se obtuvo con LLDP.
  • El resultado se puede filtrar indicando la interfaz a la cual está conectado el dispositivo vecino.
Chassis id: 0010.156e.23fa
Port id: ENLACE A AccessSw
Cuando se ha configurado una descripción para el puerto, la misma se muestra junto al parámetro “Port id”.
Port Description: GigabitEthernet0/22
System Name: AccessSw.cisco.com

System Description:
Cisco IOS software, C29960 Software (C2960-LANBASEK9-M), Version 15.2(44)SE6, RELEASE SOFTWARE (fcl)
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Mon 09-Mar-12 18:10 by gereddy

Time remaining: 94 seconds
System capabilities: B, R
Enabled Capabilities: B
Management Addresses:
    IP: 10.1.1.12
Auto Negotiation – supported, enabled
Physical media capabilities:
    10base-T(HD)
    10base-T(FD)
    100base-T(HD)
    100base-T(FD)
    1000base-T(HD)
Media Attachment Unit type: 16
----------------------------------------------

Total entries displayed: 1


Switch#show lldp traffic
  • Muestra las estadísticas de intercambio de tramas LLDP entre el dispositivo y los dispositivos vecinos adyacentes.
LLDP traffic statistics:
    Total frames out: 42
    Total entries aged: 0
    Total frames in: 11
    Total frames received in error: 0
    Total frames discarded: 1
    Total TLVs unrecognized: 0


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.


17 de noviembre de 2018

Comandos: show ip ospf database

Desde hace unas semanas estamos revisando los comandos de monitoreo de OSPF versión 2. Uno particularmente importantes pero también complejo es  show ip ospf database. 

Este comando permite revisar la base de datos de información de enrutamiento que utiliza OSPF para calcular la ruta a proponer a la tabla de enrutamiento. 
Pero para comprenderlo acabadamente es necesario tener presente que OSPF es un protocolo de estado de enlace y que por lo tanto no intercambia rutas sino información de esos enlaces, lo que llamamos información de enrutamiento.
Esas unidades de información son los denominados LSAs y es la información recolectada que se puede verificar en la base de datos de OSPF. En conclusión, en esta base de datos, no encontramos rutas sino unidades de información de diferente tipo que luego utiliza el algoritmo de Dijkstra para reconstruir la topología de la red y luego calcular la ruta más corta.

Como otros comandos vinculados al protocolo, ha sido introducido en IOS 10.0 y a partir de allí se ha mantenido en sucesivas versiones y releases del sistema operativo, con algunas pequeñas variantes.
El comando tiene una cantidad importante de variantes que mencionaré al final de este post.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show ip ospf database
            OSPF Router with ID (1.1.1.1) (Process ID 1)

                Router Link States (Area 0)

Link ID     ADV Router      Age       Seq#       Checksum Link count
1.1.1.1     1.1.1.1         1070      0x80000006 0x001b09 3
1.1.1.3     1.1.1.3         880       0x80000005 0x0028ef 3
1.1.1.2     1.1.1.2         880       0x80000005 0x00c559 3
1.1.1.4     1.1.1.4         880       0x80000005 0x008889 3

                Net Link States (Area 0)
Link ID      ADV Router      Age      Seq#       Checksum
172.16.2.2   1.1.1.3         1070     0x80000001 0x0075a1
172.16.4.2   1.1.1.4         880      0x80000001 0x001bfd
172.16.3.2   1.1.1.4         880      0x80000002 0x000b7b
172.16.1.2   1.1.1.2         185      0x80000002 0x007d6c


Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show ip ospf database
            OSPF Router with ID (1.1.1.1) (Process ID 1)

  • Router with id - Muestra el router ID de OSPF del dispositivo en el cual se ejecuta el comando.
  • Process ID - Identificador del proceso de OSPF al cual corresponde la información que se presenta a continuación

                Router Link States (Area 0)

  • Inicio de la sección de la bases de datos que contiene la información obtenida utilizando LSAs tipo 1.
    Muestra cuáles son los otros dispositivos en el área.
    En este caso nos indica que hay 4 dispositivos OSPF en el área
  • Esta información corresponde al área 0.
    Si se tratara de un router de borde de área (ABR), esta sección se repite para cada área en la que se encuentra el dispositivo.

Link ID     ADV Router      Age       Seq#       Checksum Link count
1.1.1.1     1.1.1.1         1070      0x80000006 0x001b09 3
1.1.1.3     1.1.1.3         880       0x80000005 0x0028ef 3
1.1.1.2     1.1.1.2         880       0x80000005 0x00c559 3
1.1.1.4     1.1.1.4         880       0x80000005 0x008889 3

  • Link ID - Router ID.
  • ADV Router - Router ID del dispositivo que publicó el LSA.
  • Age - Tiempo en segundos desde que se recibió la información correspondiente a este LSA.
  • Seq# - Número de secuencia del LSA, permite detectar información vieja o duplicada.
  • Checkum - Valor de verificación del contenido completo del LSA.
  • Link count - Cantidad de interfaces que participan del área, detectadas en el dispositivo.

                Net Link States (Area 0)

  • Inicio de la sección de la base de datos que contiene la información correspondiente a los LSAs tipo 2 recibidos.
    Indica cuáles son los dispositivos DR para el área y qué segmento de red representa cada uno.
  • Esta información corresponde al área 0.
    Si se tratara de un router de borde de área (ABR), esta sección se repite para cada área en la que se encuentra el dispositivo.

Link ID      ADV Router      Age      Seq#       Checksum
172.16.2.2   1.1.1.3         1070     0x80000001 0x0075a1
172.16.4.2   1.1.1.4         880      0x80000001 0x001bfd
172.16.3.2   1.1.1.4         880      0x80000002 0x000b7b
172.16.1.2   1.1.1.2         185      0x80000002 0x007d6c
  • Link ID - Dirección IP de la interfaz del router DR correspondiente al enlace que se reporta.
    Por ejemplo: 172.16.2.2 es la dirección IP de la interfaz del router 1.1.1.3 que conecta al segmento 172.16.2.0.
  • ADV Router - Router ID del dispositivo que publicó el LSA.
  • Age - Tiempo en segundos desde que se recibió la información correspondiente a este LSA.
  • Seq# - Número de secuencia del LSA, permite detectar información vieja o duplicada.
  • Checkum - Valor de verificación del contenido completo del LSA.
Variantes del comando 
El comando permite requerir información detallada de cada tipo de SLA indicando a continuación del mismo de qué tipo de SLA se desea obtener.

Router#show ip ospf database asbr-summary

  • Muestra la información detallada de los LSAs tipo 3 (summary) generada por el router de borde de área.

Router#show ip ospf database external

  • Presenta la información detallada de los LSAs tipo 5 (external) generados a partir de rutas redistribuidas dentro del protocolo en un router de borde de sistema autónomo (ASBR).

Router#show ip ospf database network

  • Permite verificar la información correspondiente a los LSAs tipo 2 recibidos por el dispositivo.
También es posible solicitar una síntesis detallada de cuántos LSAs de cada tipo y cuántos en total para cada área se contienen en la base de datos de OSPF.

Router#show ip ospf database database-summary

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


10 de noviembre de 2018

Comandos: show ip ospf interface

En las redes corporativas actuales OSPF versión 2 ocupa un lugar relevante. Es por eso muy importante que conozcamos los principales comandos de diagnóstico que nos permiten verificar la operación, definir potenciales mejoras y detectar la posible fuente de fallos.
Revisemos ahora uno de esos comandos básicos:  show ip ospf interface [int]. 

Este comando permite verificar la operación de OSPF sobre cada una de las interfaces asociadas al proceso del protocolo de enrutamiento.

Como otros comandos vinculados al protocolo, ha sido introducido en IOS 10.0 y a partir de allí se ha mantenido en sucesivas versiones y releases del sistema operativo, con algunas variantes.
En IOS 12.0(25)S se introdujo el keyword "brief" que permite revisar una tabla sintética de las interfaces asociadas al proceso del protocolo en la que se puede verificar dirección IP de la interfaz/longitud de prefijo, costo, estado y cantidad de vecinos que negocian a través de esa interfaz.

Consideremos en primer lugar un ejemplo tomando como base el resultado de la ejecución en un router Cisco IOS para luego revisarlo con mayor detalle.

Router# show ip ospf interface GigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up
 Internet Address 192.168.254.202/24, Area 0
 Process ID 1, Router ID 192.168.99.1, Network Type BROADCAST, Cost: 10
 Topology-MTID    Cost    Disabled    Shutdown      Topology Name
       0           10        no          no            Base
 Transmit Delay is 1 sec, State DR, Priority 1
 Designated Router (ID) 192.168.99.1, Interface address 192.168.254.202
 Backup Designated router (ID) 192.168.254.10, Interface address 192.168.254.10
 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
   oob-resync timeout 40
   Hello due in 00:00:05
 Supports Link-local Signaling (LLS)
 Cisco NSF helper support enabled
 IETF NSF helper support enabled
 Can be protected by per-prefix Loop-free FastReroute
 Can be used for per-prefix Loop-free FastReroute repair paths
 Index 1/1, flood queue length 0
 Next 0x0(0)/0x0(0)
 Last flood scan length is 1, maximum is 1
 Last flood scan time is 0 msec, maximum is 0 msec
 Neighbor Count is 1, Adjacent neighbor count is 1 
   Adjacent with neighbor 192.168.254.10  (Backup Designated Router)
 Suppress hello for 0 neighbor(s)

Si se especifica una interfaz en concreto se muestra la información correspondiente sólo a esa interfaz; si en cambio no se indica una interfaz particular se mostrará la información correspondiente a todas las interfaces asociadas al proceso del protocolo.

Lectura del comando
Revisemos ahora el resultado de la ejecución del comando:

Router# show ip ospf interface GigabitEthernet 0/0

GigabitEthernet0/0 is up, line protocol is up
  • Estado de operación de la interfaz en capa física y en capa de enlace de datos.
 Internet Address 192.168.254.202/24, Area 0
  • Dirección IP y máscara de subred asignadas a la interfaz.
  • Area - ID de área OSPF a la que está asociada esta interfaz. En el caso del ejemplo es el área 0 (backbone).
 Process ID 1, Router ID 192.168.99.1, Network Type BROADCAST, Cost: 10
  • Process ID - identificador del proceso de OSPF. Es un requisito para la configuración del protocolo.
  • Router ID - identificador asumido por el dispositivo para el intercambio de información de enrutamiento con este protocolo.
  • Network Type - Tipo de red asumido por el protocolo respecto del enlace del que es parte la interfaz que se está analizando. En este caso se asume un enlace tipo broadcast.
  • Costo - Costo asumido para este enlace para el cálculo de la métrica de las rutas aprendidas a través de esta interfaz.
 Topology-MTID    Cost    Disabled    Shutdown      Topology Name
       0           10        no          no            Base
  • Topology-MTID - Número asignado a la topología (ID) de modo que el protocolo puede identificar la topología asociada con la información enviada por sus vecinos.
  • Cost - Costo asociado al enlace para el cálculo de la métrica de la ruta.
 Transmit Delay is 1 sec, State DR, Priority 1
  • Transmit Delay - Demora para la transmisión expresada en segundos.
  • State - Estado de negociación DR/BDR de la interfaz que está asociada a una red tipo broadcast. En este caso el dispositivo ha sido seleccionado como DR para ese segmento de red.
  • Priority - Prioridad del dispositivo para la definición de la elección de DR/BDR.
 Designated Router (ID) 192.168.99.1, Interface address 192.168.254.202
  • Designated Router (ID) - Router ID del dispositivo elegido como DR.
  • Interface address - Dirección IP de la interfaz del router DR conectado al enlace.
 Backup Designated router (ID) 192.168.254.10, Interface address 192.168.254.10
  • Backup Designated Router (ID) - Router ID del dispositivo elegido como BDR para el enlace de red tipo broadcast al que conecta esta interfaz.
  • Interface address - Dirección IP de la interfaz del router BDR conectado al enlace.
 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  • Timer intervals configured - Valor de los temporizadores con los que opera el protocolo OSPF sobre este enlace expresado en segundos.
  • Hello - Temporizador que controla el intervalo de tiempo para el envío de paquetes hello a través de la interfaz. En este caso es de 10 segundos.
  • Dead - Temporizador que controla el intervalo de tiempo para dar por no-presente a un dispositivo vecino detectado a través de la interfaz. En este caso es de 40 segundos.
   oob-resync timeout 40
   Hello due in 00:00:05

   [se omiten líneas...]

 Neighbor Count is 1, Adjacent neighbor count is 1 
  • Neighbor Count - Cantidad de vecinos que se detectan como adyacentes a través de esta interfaz. En este caso se detecta un único vecino a través de la interfaz.
   Adjacent with neighbor 192.168.254.10  (Backup Designated Router)
 Suppress hello for 0 neighbor(s)
  • RID del vecino que se ha detectado a través de esta interfaz.
  • El vecino OSPF detectado a través de esta interfaz ha sido elegido como BDR para el enlace de red tipo broadcast al que conecta la interfaz.

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