CCNP TSHOOT: Introducción al mantenimiento de redes

El mantenimiento de la red es un componente fundamental en las responsabilidades de un administrador de redes. Sin embargo, algunos administradores ejecutan las labores de mantenimiento sólo cuando algún problema es reportado, ya sea por algún usuario o por falla de algún dispositivo/enlace etc. Este método de mantenimiento es llamado “interrupt-driven”, y como es evidente, no es el más recomendable usarlo. Un buen mantenimiento se lleva a cabo ejecutando regularmente tareas programadas en la red, por ejemplo copias de seguridad de archivos de configuración e imágenes IOS, o actualizaciones de software. Tareas que no son urgentes pero sí importantes son las que debemos programar para ejecutar regularmente. Este segundo método se llama mantenimiento estructurado o tareas estructuradas (structured tasks) y es la forma recomendada a seguir en cuanto a mantenimiento de red.Cada red es diferente, en cuanto a tamaño, organización, objetivos, prioridades, tráfico etc. Por lo tanto cada red tendrá sus propios requisitos de mantenimiento. Sin embargo, algunas tareas deberían ser imprescindibles en todo mantenimiento, algunos ejemplos son:

Instalación y configuración de hardware y software. Solución de problemas reportados. Monitorizar y mejorar el rendimiento de la red. Planear futuras expansiones de la red. Documentar la red y cualquier cambio que se haga en ella. Asegurarse que se cumplen con los reglamentos y políticas de la empresa. Asegurar la red de amenazas internos y externos.

Interrupt-Driven vs structured tasksComo ya se ha mencionado al inicio, el mantenimiento de redes se divide en dos categorías: interrupt-driven y structured tasks.Con interrupt-driven lo que hacemos es resolver los problemas cuando estos sean avisados por algún usuario de la red. Por ejemplo, un usuario que llama quejándose de que el acceso a Internet le va demasiado lento, u otro usuario que llama advirtiendo que no puede acceder a x servidor. Se espera a la llamada para solucionar el problema.Con Structured tasks lo que hacemos son labores de mantenimiento predefinidas y programadas a ejecutar cada cierto tiempo. Con esto obtenemos beneficios como prevenir y corregir fallos de red antes de que estos se lleguen a producir, tener un conocimiento mucho mayor sobre el tráfico y las condiciones en la que está la red, dar mayor seguridad y rendimiento a la red, reducir de forma considerable las caídas de la red, conocer el estado de todos los dispositivos, planear de forma más eficiente futuros cambios en la red, y lo que es más importante, reducir de forma considerable los tiempos de resolución de averías cuando las haya.Usar el modelo Structured tasks también implica utilizar el modelo interrupt-driven, ya que aunque llevemos un buen mantenimiento de la red es inevitable que se produzca algún fallo o caída (sobre todo en redes grandes). Lo que si nos aseguramos es tener un menor número de problemas reportados y que dichos problemas reportados sean solucionados más rápidamente.

Modelos de Mantenimiento de la RedComo ya nombramos, cada red es diferente por lo tanto cada red necesitará una forma de mantenimiento diferente a las otras. Sin embargo, puedes basar dicho mantenimiento en modelos ya definidos y a partir de ahí hacer los ajustes necesarios para tu red.

Los modelos definidos más conocidos y usados son: FCAPS: Es un modelo de mantenimiento de redes definido por ISO que se basa en 5

categorías, Fault management, Configuration management, Accounting management, Performance management y Security management.

ITIL: El método IT Infrastructure Library (ITIL) define las mejores prácticas y recomendaciones para trabajar en equipo y lograr objetivos.

TMN: Más orientada al sector de las telecomunicaciones (ITU-T) es una variación del modelo FCAPS.

Cisco Lifecycle Services: El modelo de mantenimiento de cisco que incluye las distintas fases en la vida de los dispositivos cisco en una red. Estas fases son: Prepare, Plan, Design, Implement y Optimize. También conocido y estudiado como modelo PPDIOO.

Procedimientos comunes en mantenimiento de la red.A las diferentes tareas de mantenimiento se le deben aplicar prioridades a cada una de ellas, las tareas que no necesiten una respuesta inmediata pueden ser programadas para efectuarse cada cierto tiempo, por ejemplo copias de seguridad de archivos de configuración, mientras que las que sí que hace falta una respuesta inmediata, como puede ser una caída de un router o switch principal deben tener una prioridad urgente:Los procedimientos más comunes y que deberían formar parte de todas las redes son:

Cambios en la configuración: las redes de producción están en constante cambio, documentar esos cambios y dar respuesta a las necesidades presentes y futuras de la red es imprescindible. Esto implica cambios en la configuración, en el software/hardware etc. Este proceso también es conocido como “mover, añadir y cambiar”.

Reemplazar hardware antiguo o con fallas: Con el tiempo, la fiabilidad y rendimiento de los dispositivos se va deteriorando, tenerlo en cuenta y reemplazarlo antes de que falle también es una tarea imprescindible.

Copias de Seguridad: Hacer copias de seguridad de archivos de configuración e imágenes IOS, con el fin de que en caso de fallo del dispositivo, la recuperación sea muchísimo más rápida.

Actualizar Software: Se debe mantener el software de los dispositivos actualizado con los parches y/o actualizaciones que provee el fabricante. Estos parches corrigen problemas y a veces añaden características nuevas.

Monitorizar el rendimiento de la red: Monitorizar tanto el tráfico como los dispositivos (uso de memoria, cpu etc.) nos ayuda a reconocer cualquier posible problema y solucionarlo antes de que se produzca.

Documentación de la red:La documentación influye directamente sobre los tiempos de resolución y de localización de un problema. En una red bien documentada estos tiempos son muy inferiores comparados con los de una red que no lo está. La documentación de la red normalmente se crea durante el diseño inicial y montaje de la red, sin embargo, es prioritario que se mantenga actualizada cada vez que se produzca algún cambio en la red, por pequeño que sea.Los elementos más importantes en la documentación de red son:

Diagrama de topología lógica: Un diagrama que incluya las interconexiones de los diferentes segmentos de red, protocolos usados.

Diagrama de topología físico: Diagrama que incluya cómo las diferentes áreas físicas de la red se interconectan, indicando donde se encuentra situado físicamente cada elemento. Por ejemplo, varias plantas de un edificio conectadas entre sí.

Listado de conexiones: Un listado donde se incluya la conexione de ambos extremos de cada puerto de cada switch. Por ejemplo, el puerto 47 del switch “Planta1” conecta con el puerto 48 del switch “Planta2”.

Inventario de todos los elementos de la red: Tener inventariado todos los elementos de la red y su ubicación exacta dentro de la red.

Asignaciones de IP: Documentar todas las IPs de gestión y las consideradas importantes. Por ejemplo, ips de gestión de switchs/routers, ips de interfaces de routers, ips de servidores, ips de puntos de acceso etc.

Información de la configuración: Tener documentada la configuración de cada dispositivo y mantenerla actualizada ante cualquier cambio. Cuando se vaya a realizar un cambio en la configuración es importante primero realizar una copia de seguridad de la configuración actual para luego proceder al cambio, de esta forma si algo falla se puede volver al estado anterior de forma rápida.

Mantener una copia de los documentos originales: Mantener una copia de la documentación inicial de la red nos ayuda a ver el crecimiento y cambios que esta ha tenido y a calcular el crecimiento futuro que ésta tendrá.

Kit de herramientas básicas para el mantenimiento de una redUna vez planeada, montada y definido los procesos de mantenimiento de la red, el siguiente paso es identificar las herramientas necesarias para llevar a cabo el mantenimiento. Estas herramientas que ayudan en la resolución de problemas pueden ser adquiridas a los propios fabricantes o a terceros que desarrollan sus propias aplicaciones, y su coste suele ser desde gratis hasta miles de euros. Aún así, sin recurrir a ningún software adicional podemos encontrar herramientas fundamentales de mantenimiento en la CLI de los dispositivos cisco.Las herramientas de la CLI más básicas son:

Comandos show y debug:Los comandos show y debug ofrecen gran cantidad de información que nos ayuda a la resolución de problemas, por ejemplo, con show podemos ver el estado de todo lo que tengamos configurado en el dispositivo, por ejemplo interfaces, archivos de configuración, protocolos de enrutamiento, qos, usuarios configurados, mensajes de log etc.Mientras que con el comando debug ordenamos al router a mostrarnos los paquetes que se están enviando y recibiendo para cierta comunicación (especificada por nosotros), lo que nos ayuda a averiguar por qué está fallando algo. Por ejemplo un “debug ip ospf events” nos mostrará en pantalla todos los paquetes que se envían y reciben del protocolo de enrutamiento OSPF. Con el comando debug hay que tener cierto cuidado y especificar exactamente lo que queremos que muestre, de lo contrario podemos sobrecargar la memoria y procesador del dispositivo causando una bajada de rendimiento en la red.

Comandos de Copias de seguridad y recuperación.Como ya hemos visto, una tarea imprescindible en el mantenimiento de la red son las copias de seguridad. La CLI nos ofrece el comando copy y el comando archive para realizar las copias del archivo de configuración de forma manual o programada, además, podemos usar varios protocolos para efectuar dichas copias.

Con copy lo que hacemos es indicar el archivo que queremos copiar y el destino donde se copiará. Para el destino podemos usar varios protocolos, que son TFTP, FTP, HTTP, HTTPS o SCP. Aunque TFTP sea de los más usados para éste propósito es poco recomendable ya que no admite autenticación y los datos viajan en texto plano. FTP y HTTP sí admiten autenticación, aunque los datos también viajan en texto plano, mientras que con HTTPS o SCP podemos configurar autenticación y además los datos viajarán cifrados.

La sintaxis de copy es la siguiente: copy [archivo a copiar] [protocolo://usuario:contraseña@ip_servidor]. Por ejemplo:                R1# copy startup-config ftp://cisco1:ciscopass1@192.168.1.30

Con el comando hemos copiado el archivo startup-config al servidor ftp 192.168.1.30 y con autenticación, en este caso el usuario es cisco1 y el password ciscopass1.Si el protocolo a usar es FTP y con autenticación, cada vez que introduzcamos el comando copy deberemos poner el usuario y contraseña, si siempre usamos el mismo usuario y contraseña podemos configurarlo para guardarlo en la configuración y de esa forma no tener que escribirlo siempre. Para ello usamos el comando ip ftp username [nombre usuario] y ip ftp password [password] desde el modo de configuración global. Por ejemplo.                R1(config)#ip ftp username cisco1                R1(config)#ip ftp password ciscopass1

De ahora en adelante, al copiar cualquier archivo al servidor ftp bastará con usar el comando sin indicar el usuario y contraseña, que al tenerlo guardado en la configuración, lo usará automáticamente. Siguiendo el ejemplo anterior, el comando a usar sería “copy startup-config ftp://192.168.1.30”.Como vemos, el comando copy nos ayuda a hacer copias de archivos de configuración o imágenes IOS de forma manual, pero y si queremos que se ejecuten las copias de forma automática. Para ello la CLI de cisco nos ofrece el comando archive, que ejecutado desde el modo de configuración global nos lleva a un sub-modo de configuración donde debemos especificar los parámetros para las copias de seguridad, Con un ejemplo se explica mejor.                R1(config)# archive                R1(config-archive)#path ftp://192.168.1.30/R1-config                R1(config-archive)# time-period 1440                R1(config-archive)# write-memory

Vayamos por partes: El comando path indica donde se copiará el fichero, en este caso en el servidor

192.168.1.30, que si recordamos usará la autenticación cisco1, ciscopass1. R1-config es el nombre con el que se guardarán los archivos, al ser copias periódicas, y

para que no se sobreescriban, a este nombre se le va añadiendo una numeración, por ejemplo la primera copia recibirá el nombre “R1-config-1”, la segunda “R1-config-2” y así sucesivamente…

time-period indica el tiempo que ha de pasar entre copia y copia en minutos, en este caso 1440 minutos.

write-memory indica que, aunque no hayan pasado los minutos establecidos en time-period, si en el dispositivo se ejecuta un “copy run start”, automáticamente se guarda

una copia del startup config, antes de sobreescribirlo con el running config actual. Por ejemplo, en este ejemplo, si han pasado 1000 minutos desde la última copia, todavía faltarían 440 minutos para hacer la siguiente copia, pero si hacemos algún cambio de configuración en el router y para guardar los cambios ejecutamos el comando “copy run start”, aunque faltasen 440minutos para la siguiente copia, se hace una copia del startup config actual, antes de ser modificado por el comando copy.

Con el comando show archive obtendremos un listado de todas las copias hechas hasta el momento.Una vez hechas las copias de seguridad, cuando nos interese  reestablecer alguna lo podemos hacer con el comando  configure replace, que lo que hace es comparar el archivo running config del router con el archivo que indiquemos en el comando y una vez comparado modifica el archivo del router añadiendo o eliminando los cambios necesarios. Esto es importante ya que con configure replace NO reemplazamos el archivo, sólo los compara y modifica el running config del router para aplicar cambios. La sintaxis del comando es la siguiente:                R1# configure replace [protocolo://ip_servidor/nombrearchivo]

Que aplicado al ejemplo anterior y suponiendo que queramos restaurar la copia número 3, sería:                R1#configure replace ftp://192.168.1.30/R1-config-3

Herramientas de logging:Saber lo que sucede en el router/switch y sobre todo, que todos los sucesos sean guardados es extremadamente importante a la hora de resolver, prevenir o investigar problemas y/o ataques.La CLI de cisco nos ofrece la posibilidad de generar mensajes de log de los diferentes sucesos que ocurran en los dispositivos. Estos sucesos se miden por niveles de seguridad, que van del 0 al 7, y cuanto menor sea el número, mayor es el riesgo en la seguridad. Los niveles son:

0-Emergencies 1-Alert 2-Critical 3-Errors 4-Warnings 5-Notifications 6-Informational 7-Debugging

Tenemos varias formas de almacenar los mensajes de logs. Una es almacenándolos en la memoria del dispositivo y otra guardándolos en un servidor syslog.Almacenarlos en el dispositivo implica un gasto de memoria y recursos innecesarios, además, al ser la memoria limitada, cuando se llega al límite de la memoria, se sobreescriben los logs mas antiguos para ir guardando los nuevos que se van generando. Para guardar los logs en la memoria del dispositivo se usa el comando logging buffered [memoria] donde memoria indica el máximo de memoria a usar para logs, una vez llegado al máximo, los logs mas antiguos se sobreescribirán.Los logs son una fuente inmejorable de detección y resolución de problemas, pero a veces también puede ser una tarea complicada encontrar los logs que nos interesan debido a la gran cantidad de éstos que se pueden generar. Por ejemplo, del nivel 6 y 7 se generan muchísimos

logs que pueden ser innecesarios. Para solucionar este problema, podemos especificar a partir de que nivel queremos que los logs sean guardados, lo que ayuda al uso de la memoria y a encontrar los logs que busquemos con mayor rapidez. Para indicar desde que nivel queremos guardar los logs sólo tenemos que añadir al comando el nivel desde el cual queremos que se guarden. Indicar un nivel implica que los niveles de mas seguridad también serán guardados, por ejemplo si indicamos el nivel 4, los logs de los niveles 3,2,1 y 0 también serán guardados. Un ejemplo de guardar logs en la memoria del dispositivo sería:                R1(config)#logging buffered 4096 warnings

El ejemplo indica que se usaran 4 megas de RAM para guardar logs y que se guardarán a partir del nivel 4, es decir, los niveles 0, 1, 2,3 y 4Otra forma más usual y lógica de usar el logging es habilitando un servidor syslog y configurando el dispositivo para que los logs sean enviados a dicho servidor. Esto tiene beneficios como que no se sobreescriben logs antiguos ya que la memoria de almacenamiento es muchísimo mayor, a parte, tendremos todos los logs de todos los dispositivos de la red en el mismo servidor, lo que crea una administración centralizada.El comando de configuración de dispositivos cisco para el envío de logs a un servidor es bastante sencillo, logging [ip servidor], y para seleccionar el nivel desde el cual queremos que se envíen los logs lo hacemos con el comando logging trap [nivel], desde el modo de configuración global, por ejemplo:

                R1(config)#logging 192.168.1.40                R1(config)#logging trap 4

 NTP (Network Time Protocol): Un protocolo que va bastante unido al logging y que sin duda es necesario configurar es NTP. Con NTP lo que hacemos es configurar todos los dispositivos para que tengan exactamente la misma hora, de esta forma a la hora de buscar correlaciones en mensajes de logs de diferentes dispositivos estaremos seguros que la hora indicada en los logs en ese momento era exactamente la misma en todos los dispositivos de la red. Para usar NTP deberemos primero configurar un servidor para que actúe como NTP, y luego configurar los dispositivos de la red con el comando ntp server [ip servidor], desde el modo de configuración global, por ejemplo.                R1(config)# ntp server 192.168.1.40

CCNP TSHOOT: Introducción a los procesos de resolución de problemas de red

La resolución de problemas o troubleshooting se puede definir como el proceso de respuesta a un problema reportado, diagnosticando dicho problema y dándole una solución. Como es de imaginar es una tarea implícita en las responsabilidades de un administrador de red. Los problemas normalmente son el resultado de un error humano (por ejemplo un error en configuración), fallo de dispositivos, un error en el software (bug) o por patrones de tráfico (por ejemplo ataque DDOS). Estos problemas pueden ser resueltos de diferentes maneras, es más, cada administrador tendrá sus formas de resolución. Lo que si es recomendable es seguir

siempre el mismo método cuando surja un problema, ya que nos ayudará a resolverlo de manera más eficiente y rápida.Lo primero que debemos hacer cuando se nos presenta un problema es aclarar lo que está pasando, obtener una definición clara del error, luego obtener toda la información necesaria y que nos sea útil. Con estos datos ya podemos formular hipótesis sobre las causas del error y las posibles soluciones. Una vez identificado el error se procede a repararlo. En algunas ocasiones el error no puede ser reparado de inmediato, por ejemplo cuando es necesario reemplazar alguna pieza de hardware, en estos casos hay que buscar alguna solución temporal hasta que el que el problema pueda ser reparado correctamente.

Resumiendo, los pasos principales a seguir en la resolución de problemas son:1.- Reporte del problema.2.-Diagnóstico del problema, donde se incluye recolectar información, examinar la información recolectada, eliminar posibles causas y crear hipótesis sobre la posible causa del problema.3.- Resolver el problema.

Métodos de resolución de problemas más usadosLos métodos más usados a la hora de resolver problemas son 6, dependiendo del administrador o del problema a resolver se optará por seguir uno u otro, lo que no es recomendable es, para el mismo tipo de problema usar cada vez un método diferente.Los 6 métodos más comunes son:

Método “Top-Down” Método “Bottom-Up” Método “Divide and Conquer” Método “Following the traffic Path” Método “Comparing Configurations” Método “Component Swapping”

Método Top-DownCon éste método lo que hacemos es empezar a buscar el problema en la capa 7, aplicación, e ir desplazándonos hacia abajo en las capas del modelo OSI hasta dar con la capa donde reside el problema. La teoría de este modelo dice que desde que encuentres una capa que funcione completamente quiere decir que todas las capas inferiores también están funcionando correctamente. Por ejemplo, si un ping tiene un resultado exitoso, como el ping es un test de capa 3 se puede concluir que las capas 1 y 2 también funcionan correctamente. Por lo contrario, si el ping falla nos desplazamos una capa más abajo para seguir buscando el problema, en este caso en la capa 2.

Método Bottom-UpCon Bottom-Up lo que hacemos es lo contrario que con Top-Down, es decir, comenzamos con la búsqueda del problema desde la capa 1 hacia arriba. Este método es menos efectivo en redes grandes, ya que comenzar testeando la capa 1 en estas redes lleva demasiado tiempo.

Método Divide and ConquerDivide and Conquer se basa en una mezcla entre Top-Down y Bottom-Up ya que se teoría dice que debemos empezar a testear en una capa intermedia y luego dependiendo de los resultados movernos hacía arriba o hacia abajo en las capas del modelo OSI. Por ejemplo, comenzamos en la capa 3 testeando con un ping, si el ping es exitoso quiere decir que las capas 1 y 2 están funcionando correctamente por lo que nos moveremos hacia la capa 4 en busca del problema. Si por lo contrario el ping no es exitoso deberemos movernos hacia la capa 2 para seguir buscando el problema.

Método Following the Traffic Path

Como su nombre indica este método consiste en seguir el enlace de un problema reportado hasta dar con el problema. Por ejemplo. Un usuario reporta un problema de conexión de su ordenador con el servidor. Supongamos que ese ordenador está conectado a un switch, el switch a un router, y este router a otro switch que conecta con el servidor… Con Following the traffic path lo que hacemos es comprobar el enlace del ordenador con el switch, si funciona, comprobamos el enlace del switch con el router, si funciona, comprobáramos el enlace del router con el switch que conecta con el servidor…y así sucesivamente hasta dar con el problema.

Método Comparing ConfigurationsEs el método que consiste en comparar configuraciones para ver dónde está el error. Por ejemplo, dos routers conectados por una VPN, en un extremo falla la VPN y no sabemos porque…Usando este método compararemos la configuración del router que está funcionando bien con la del router que está fallando en busca de diferencias. Dejando la configuración igual en los dos extremos probablemente se solucione el problema. Este método es usado a menudo por administradores de red con poca experiencia en resolución de problemas.

Método Component SwappingEl último método consiste en el cambio de componentes para localizar el problema. Cambiando componentes se puede llegar a la conclusión de que el error estaba en el componente reemplazado. Por ejemplo, un equipo está conectado a un switch y no tiene conectividad. Usando este método lo primero que haríamos sería cambiar el cable que conecta el ordenador con el switch, si el error continua, el siguiente paso sería conectar el cable a otro puerto del switch, por si acaso el error estuviera en el puerto. Si aún así el error continúa, habría que probar con otro ordenador, por si acaso el error estuviera en el ordenador… y así sucesivamente hasta dar con el problema.Este método sólo es conveniente usarlo cuando estemos seguros que el error es debido a algún componente físico y no de configuración etc.

Ejercicio práctico sobre el uso de métodos de resolución.Una empresa tiene 48 pcs conectados a dos switchs de 24 puertos cada uno. Actualmente 24 pcs no tienen acceso a Internet, sin embargo ayer si tenían acceso. Los otros 24 pcs conectan a Internet sin problema. Resolviendo el problema desde los diferentes métodos.

Top-Down: Como la capa de aplicación funciona correctamente en algunos pcs situados en la misma localización (los 24 que si tienen acceso), este método no sería muy efectivo usar en este caso. Aún así, es posible que la conexión a Internet se realice mediante un proxy y que se haya desconfigurado en los 24 equipos que no conectan. De todas formas es muy poco probable porque todos los equipos funcionaban ayer y hoy de repente 24 no funcionan.

Bottom-Up: Basándonos en los síntomas, 24 pcs no funcionan, es muy probable que sean los 24 que conectan a un mismo switch por lo que empezar con éste método (que comienza en la capa física) sería una buena opción.

Divide and Conquer: Puede ser una buena opción comenzar con este método, por ejemplo haciendo un ping a la puerta de enlace de los equipos que fallan. Si el ping falla podemos movernos a capa 2, comprobando el switch donde conectan esos 24 equipos.

Following the path: En este caso seguir el path de los 24 equipos llevaría demasiado tiempo y sería poco efectivo. En este caso es mejor comenzar con otros métodos e ir

eliminando posibles causas del error. Aún así es posible que usando éste método los 24 pcs lleguen a un punto donde pierden la conectividad. En ese caso nos centraremos en ese punto para resolver el problema.

Comparing Configurations: Sería un buen método a seguir en el caso de que los 24 pcs que fallan estén conectados al mismo switch y los 24 que funcionan a otro switch. En este caso podemos comprar las configuraciones de ambos switch y buscar diferencias y la causa del error.

Component Swapping: Si ninguno de los otros métodos resuelve el error es posible que tengamos que usar este. Como el fallo fue de un día para otro es muy poco probable que el error esté en los 24 cables de los pcs, así que podemos centrarnos en cambiar el switch donde conectan los 24 pcs y ver si así se resuelve el problema.

Procedimientos en la resolución de problemasAl principio nombrábamos los pasos principales en la resolución del problema, que recordándolos son: reporte del problema, diagnóstico del problema y resolución del problema.

El reporte del problema es simplemente el aviso de algún usuario indicando una incidencia, ya sea vía telefónica, vía web, personalmente etc. En muchas ocasiones la información suministrada por el usuario será insuficiente, como por ejemplo una incidencia reportada como “La red esta caída”. En estos casos deberemos llamar a dicho usuario y pedirle más detalles sobre el error que tiene, una vez la incidencia esté totalmente aclarada pasaremos al siguiente paso...

El diagnóstico del problema se divide en varias fases, que incluyen: Recolectar información: Obtener información sobre los dispositivos de la red donde

pueda estar el problema. Esta información normalmente se obtiene con los comandos show y/o debug.

Examinar la información recolectada: Hacer una evaluación de los datos obtenidos con el show y debug en busca de posibles causas del error.

Eliminar posibles causas: Basándose en los datos, eliminar causas del error. Un ejemplo muy sencillo, si un switch tiene un puerto en up/up, podemos eliminar la causa de que el puerto esté en down.

Formular hipótesis: Basándose en los resultados, formular hipótesis sobre cual o cuales pueden ser las causas del error.

Verificar hipótesis: De las hipótesis formuladas, seleccionar la o las que más se acerquen al problema para centrarnos en ellas.

Teniendo ya las posibles causas aclaradas, debemos centrarnos en solucionar el problema. Si una hipótesis no soluciona el problema, se deshacen los cambios y se busca otra hipótesis, y así sucesivamente hasta dar con la solución. Una vez solucionado, documentarlo y hacer una copia de seguridad de la antigua y la nueva configuración. También debemos informar a las personas implicadas que el problema ha sido resuelto (usuario, jefe, compañeros…y en algunas ocasiones otros departamentos a los que también les afectaba el problema).

Establecer una línea baseUn punto importante en la resolución de problemas es la de establecer una línea base sobre el funcionamiento de nuestra red. Esto significa hacer mediciones y estado de los dispositivos

(uso de cpu, memoria etc.) durante un uso normal de la red, documentar los resultados y repetir las pruebas cada cierto tiempo, de esta forma comparando los resultados de las mediciones podemos deducir si el uso que está teniendo la red es normal o está pasando algo.Establecer una línea base debe incluirse en los procedimientos de tareas programadas en el mantenimiento de las redes ya que es de gran ayuda para prevenir problemas, ataques, fallos de hardware etc.

CCNP TSHOOT: Herramientas de mantenimiento y resolución de problemas

Después de que un problema haya sido claramente definido, el siguiente paso en el diagnóstico es el de recolectar la información necesaria. Esta tarea es de las que más tiempo consume en el proceso de la resolución del problema, por lo que la habilidad para recolectar la información apropiada nos ayudará a resolver el problema con mayor rapidez. El comando más útil en cisco para recolectar información es el “show”, sin embargo el resultado de muchas de las opciones que nos ofrece producen una gran cantidad de información la cual nos puede hacer demorar tiempo buscando la información que realmente necesitamos. Por ejemplo, con un “show processes cpu” obtenemos este resultado.

Como vemos se genera una lista de aproximadamente 180 líneas (puede ser mucho mayor dependiendo de los procesos que tengamos cargados en el dispositivo), sin embargo, sólo nos interesa saber qué cantidad de cpu está usando el proceso llamado “Check heaps”… Buscar ese proceso entre las 180 líneas nos llevará un tiempo, que podemos acortar considerablemente si pudiéramos indicar sólo el proceso que buscamos.

Para esto podemos usar el comando “include [texto]” que indica que sólo se muestre en pantalla las líneas que contengan el texto que indicamos en [texto]. Volviendo al ejemplo anterior, ejecutaremos el siguiente comando:              R1# show processes cpu | include Check heaps

Con lo que conseguimos que show sólo nos muestre las líneas donde aparezca la palabra Check heaps, que es el proceso que buscamos, ganando así bastante tiempo para la resolución del problema.En otras ocasiones lo que nos interesará será excluir algunas líneas del resultado generado por el show, para ello usaremos el comando “exclude [texto]”, lo que hará que no se muestren en pantalla las líneas que contengan el texto que indicamos en [texto]. Por ejemplo, con un “show interfaces brief” obtendremos este resultado.

Sin embargo, si lo que nos interesa son sólo las interfaces con IP asignada, podemos usar el comando exclude para conseguirlo, indicando que no se muestren las líneas que contengan la palabra unassigned, con el comando.                R1# show ip interface brief | exclude unassigned

Con lo que logramos centrarnos directamente en lo que necesitamos.

Enviando los resultados a un fichero de texto:A veces nos puede interesar enviar los resultados de cualquier comando a un fichero de texto, por ejemplo cuando estemos documentando la red y pongamos la configuración base de cada dispositivo en la documentación, ganaremos muchísimo mas tiempo exportando los resultados

a un fichero que copiando y pegando en todos los dispositivos. Mirándolo por el lado de resolución de problemas, enviar un debug a un fichero de texto nos ayudará bastante a analizarlo mejor ya que entre otras cosas podemos hacer búsquedas de algún texto específico.Para usar esta característica tenemos que añadir al comando que queramos enviar a un fichero de texto las opciones redirect, tee o append incluyendo luego la ruta del fichero. Con redirect lo que hacemos es enviar el resultado a un fichero de texto sin mostrarlo en pantalla. Con tee logramos enviar el resultado a un fichero de texto y además muestra el resultado del comando en pantalla, y con append lo que hacemos es a un fichero de texto ya existente, agregarle el resultado del comando al final del archivo. Append tampoco muestra el resultado en pantalla. Ejemplos de cada uno:               R1# show ip interface brief | redirect tftp://192.168.1.30/interfaces.txt

R1# show ip interface brief | tee tftp://192.168.1.30/interfaces.txt R1# show ip interface brief |append tftp://192.168.1.30/interfaces.txt

Capturas de paquetes en la redSi con los comandos show o debug no conseguimos obtener toda la información necesaria para resolver un problema sería buena idea usar un capturador de paquetes para así poder analizar con más detalle lo que está pasando. Podemos usar como capturador de paquetes algún servidor dedicado a ello o algún PC con algún software capturador pero hay que tener en cuenta que la cantidad de paquetes que se van a capturar va a ser demasiado grande, dificultando así encontrar los paquetes que realmente necesitamos analizar, por lo tanto a la hora de seleccionar el software capturador de paquetes debemos decantarnos por alguno que permita configurar filtros, por el ejemplo el wireshark. Otro aspecto a tener en cuenta es de qué comunicación queremos capturar los paquetes ya que si el capturador de paquetes y el pc se encuentran en el mismo switch se configurará un método llamado SPAN, pero si se encuentran en diferentes swichts se configurará otro método llamado RSPAN. La idea principal es que se envíe una copia de todos los paquetes tanto enviados como recibidos en un puerto  hacia el puerto donde está conectado el capturador de paquetes.

Usando SPANSPAN es usado cuando queremos que se envíe una copia de todos los paquetes que se envían y reciben de un puerto del switch hacía otro puerto del mismo switch, donde tendremos conectado el capturador de paquetes. Por ejemplo, queremos capturar el todo el tráfico que pasa por el puerto Gi0/1 de un switch, que conecta con un servidor, y enviar dicha copia al puerto Gi03 que conecta con el capturador de paquetes.

Para configurarlo tenemos que seguir los siguientes pasos…1.       Indicar el puerto o puertos de origen de SPAN, los puertos origen son aquellos de los cuales

se enviará copia de todo el tráfico que pase por el/ellos. Para hacerlo usamos el comando monitor session [id] source interface [interface], desde el modo de configuración global. ID indica un número de identificación, ya que podemos configurar varios monitor session, en ese caso a cada uno lo identificaremos con un id.

2.       Indicar el puerto destino al cual se enviará la copia de todo el tráfico de el/los puertos origen, con el comando monitor session [id] destination interface [interface], desde el modo de configuración global. Se debe configurar el mismo ID que en el paso 1.Volviendo al ejemplo de la imagen anterior, la configuración sería la siguiente.

SW1(config)# monitor session 1 source interface Gi  0/1SW1(config)# monitor session 1 destination interface Gi  0/3

Usando RSPANRSPAN tiene la misma finalidad que SPAN, con la diferencia de que el capturador de paquetes y el equipo del que queremos capturar están conectados en switchs diferentes, por lo que la configuración también cambia. En este caso tendremos que configurar una VLAN en cada switch, y configurar los switchs para que en uno la copia del tráfico se envíe a través de la VLAN, y en el otro, donde estará conectado el capturador de paquetes, se reciba el tráfico en esa VLAN. Veámoslo con un ejemplo:

En el Switch 1, Puerto Gi0/1 tenemos el servidor, del cual queremos capturar todos los paquetes que genera y recibe, y en el Switch 2, puerto Fa5/2 tenemos el capturador de paquetes. Para configurar ambos switchs debemos seguir los siguientes pasos:Switch 11.- Crear una VLAN que usaremos para enviar la copia de paquetes al switch 2, con el comando vlan [num], desde el modo de configuración global. A la VLAN podemos asignarle un nombre con el comando name.2.- Indicar que la vlan será usada para rspan con el comando remote-span, dentro del modo de configuración de la VLAN.

3.- Indicar el puerto origen (donde conecta el servidor) del cual se copiará todo el tráfico, con el comando monitor session [id] source interface [interface], desde el modo de configuración global.4.- Indicar el destino del tráfico que en este caso será la vlan que creamos en el paso 1. Lo hacemos con el comando monitor session [id] destination remote vlan [num de vlan] reflector port [interface], desde el modo de configuración global. Reflector port indica el puerto por el cual saldrá la VLAN, que es el puerto que conecta con el switch 2. En este caso Gi 0/3. El puerto reflector port tiene que estar configurado en ambos switchs como trunk, para que permita el paso de varias vlans.Switch 21.- Crear una VLAN que usaremos para recibir la copia de los paquetes, la vlan tiene que ser la misma que la creada en el switch 1. La creamos con el comando vlan [num], desde el modo de configuración global. A la VLAN podemos asignarle un nombre con el comando name.2.- Indicar que la vlan será usada para rspan con el comando remote-span, dentro del modo de configuración de la VLAN.3.- Indicar el origen de los paquetes, que en este caso será la VLAN creada en el paso 1. Lo hacemos con el comando monitor session [id] source remote vlan [num vlan], desde el modo de configuración global.4.- Indicar el puerto del switch al cual se enviará la copia de los paquetes, con el comando monitor session [id] destination interface [interface], desde el modo de configuración global.Con todo esto, la configuración de RSPAN en ambos switchs quedaría de la siguiente forma:             Switch1# conf t             Switch1(config)# vlan 20             Switch1(config-vlan)# name SPAN             Switch1(config-vlan)# remote-span             Switch1(config-vlan)#exit             Switch1(config)#monitor session 1 source interface Gi  0/1             Switch1(config)# monitor session 1 destination remote vlan 20 reflector-port Gi  0/3             Switch1(config)#end

Switch2# conf t             Switch2(config)# vlan 20             Switch2(config-vlan)# name SPAN             Switch2(config-vlan)# remote-span             Switch2(config-vlan)#exit             Switch2(config)#monitor session 1 source remote-vlan 20             Switch2(config)# monitor session 1 destination interface fa5/2             Switch2(config)#end

CCNP TSHOOT: Resolución de problemas básicos en Switchs Cisco

Como ya sabemos los switchs son dispositivos de capa 2 encargados del reenvío de tramas a los dispositivos que conectan con él. En esta entrada veremos problemas básicos relacionados con varias funciones importantes de un Switch como son La MAC Adress Table, las VLANs y STP.

MAC Adress Table y VLAN Troubleshooting:

Como ya sabemos, la forma de trabajar de los switchs es diferente a la de los Hubs, éstos últimos cada vez que reciben una trama la reenvían por todos sus puertos creando así un solo dominio de colisión y por lo tanto aumentando las posibilidades de colisión entre diferentes tramas. Cuando ocurre una colisión en un hub, los afectados tienen que volver a reenviar sus tramas. Esto no ocurre en los switchs, ya que éstos cuando reciben una trama examinan la MAC a la que va dirigida dicha trama y la reenvían sólo por el puerto que conecta con esa MAC, creando así un dominio de colisión para cada puerto del switch y eliminando las colisiones entre diferentes tramas. Para lograr esto los Switchs aprenden la MAC de cada dispositivo que está conectado a sus puertos y los guarda en una tabla llamada “MAC Adress Table”, de esa forma cuando llega una trama lee la MAC, busca dicha MAC en la MAC Adress Table y reenvía la trama por el puerto al que esté asociado esa MAC, pero que pasa cuando un switch aún no ha aprendido la o las MAC de uno o varios puertos. Cuando esto pasa, el switch recibe una trama, lee su MAC y la busca en la MAC Adress Table, pero no hay ninguna coincidencia. Entonces el Switch reenvía la trama por todos los puertos excepto por el puerto que la recibió. Una vez reenviada, si existe algún dispositivo con esa MAC, obtendrá la respuesta de esa trama a través de un determinado puerto. El Switch entonces asocia su MAC Adress Table esa MAC con ese puerto. La próxima trama que llegue con esa MAC será reenviada directamente a ese puerto.Veámoslo con un ejemplo paso por paso.PC 1 quiere iniciar una sesión Telnet con  Server, sin embargo el switchs no han rellenado aún su Tabla de MACs. El proceso sería el siguiente…

Paso 1: Para iniciar una sesión Telnet, PC1 envía una solicitud de ARP a la IP del servidor, ya que PC1 no conoce la MAC del servidor y es necesaria para la comunicación.

Paso 2: El switch recibe la trama de PC 1 a través de la interfaz Gi 0/1. Como el switch aún no ha rellenado su tabla de MACs lo primero que hace es asociar la MAC de PC1 que es

1111.1111.1111.1111 al puerto Gi 0/1. Después reenvía el paquete ARP por todas las interfaces excepto por la que lo recibió y por las interfaces que pertenezcan a otra VLAN. Por lo tanto, reenviará la solicitud ARP por los puertos Gi0/3 y Gi0/5.

Paso 3: La solicitud a ARP llega al equipo PC2 y Server, pero sólo el server responderá a la solicitud ya que la dirección IP con la que el ARP corresponde a la del servidor.

Paso 4: La respuesta llega al switch. En primer lugar el switch rellena su tabla de macs con la mac del servidor y la asocia al puerto Gi0/5. En segundo lugar el Switch examina el paquete y la mac de destino y la busca en su tabla de macs. La mac de destino es la del PC1 y ya la tiene asociada al puerto Gi0/1, por lo tanto el switch reenviará el paquete sólo por la interfaz Gi0/1. Si el switch no tuviera asociada esa MAC a ningún puerto, lo reenviaría por todos.

Paso 5: En este paso ya el switch tiene registrados en su tabla de macs al PC1 y al server. Por lo tanto toda la comunicación entre ellos a partir de ahora será directamente a través de los puertos Gi0/1 y Gi0/5, sin tener que reenviar paquetes de esta comunicación a los demás puertos.

Nota: Cuando el switch reciba algún paquete del PC2 y PC3 asociará sus MACs a los puertos donde están conectados. Completando así su tabla de MACs.

Una vez entendido el procedimiento de cómo se rellena la Tabla de MACs en un Switch cuando tengamos que resolver un problema relacionado con la capa 2 nos será más fácil identificar el problema, debiendo considerar alguna de las siguientes 3 causas:

Problemas con el hardware: Algún cable dañado o mal grimpado, algún puerto del switch dañado.

Configuración de VLANs: Para que dos VLANs diferentes se puedan comunicar, el tráfico debe ser enrutado. Si dos dispositivos que pertenecen a la misma VLAN no se pueden comunicar habría que comprobar la configuración de los puertos a los que se

conectan, comprobar que el switch está aprendiendo bien las MACs de los dispositivos y si hay algún enlace trunk entre los dos dispositivos, comprobar que está configurado para transportar esa VLAN.

Configuración de los enlaces Trunk: Un enlace trunk es aquel que es capaz de transportar varias vlans. Cuando dos dispositivos dentro de la misma VLAN pero separados por un enlace trunk no se pueden comunicar lo más probable es que el error se encuentre en el trunk. Comprobar que ambos extremos del trunk usan la misma encapsulación (802.1q o ISL), que ambos extremos usan la misma VLAN nativa y que se está permitiendo el tráfico de esa VLAN a través del trunk.

Comandos básicos de resolución de problemas en un Switch

Algunos comandos básicos que nos ayudarán a resolver o nos mostrarán información relevante sobre problemas de conectividad en un Switch son:

Clear mac address-table dynamic: Borra todas las MAC aprendidas dinámicamente y almacenadas en la MAC Adress Table. De esta forma obligamos al switch a volver a aprender todas las macs de todos sus puertos. Este comando es bastante útil cuando algún dispositivo conectado a algún puerto no tenga comunicación con el resto de dispositivos y examinando la Mac adress table nos demos cuenta de que no está aprendiendo la MAC de dicho dispositivo.

Show mac address-table: Nos muestra en pantalla todas las MACs aprendidas dinámicamente, asociándolas al puerto y a la VLAN a la que pertenecen.

Show Vlan: Muestra las VLANs existentes y los puertos asociados a cada una de ellas. Show interfaces trunk: Muestra los puertos configurados como trunks, y que VLANs

están permitida en dichos trunks. Show interfaces switchport: Muestra un resumen con información de tos puertos del

switch, incluyendo información de trunks y vlans. Traceroute mac [mac origen] [mac destino]: Hace un traceroute entre dos MACs,

mostrando en pantalla los switchs que hay entre un dispositivo y otro. Para ello se usa el protocolo CDP (Cisco Discovery Protocol)

Spanning Tree Troubleshooting

Sabemos que Spanning Tree Protocol (STP) es el protocolo de capa 2 encargado de mantener una topología con enlaces redundantes libre de loops de enrutamiento. Los paquetes en capa 2 no usan el campo TTL (time to live) por lo que se si producen loops los paquetes nunca “mueren”, siempre estarán recorriendo la red, disminuyendo así la disponibilidad y el ancho de banda disponible. Una red sin STP configurado tendrá resultados no deseados como tormentas de broadcast o tablas de Mac corruptas. Para lograr una topología libre de loops STP se encarga de que cada switch tome un rol en la red, y a su vez de que cada enlace en cada switch también tome un rol.Los roles de los switchs en STP son:

Root Bridge: Es el switch elegido para actuar como punto de referencia en STP, sólo puede haber un Root Bridge por cada instancia de STP y será elegido en base al valor “Bridge ID” (BID) del switch (este valor se puede configurar manualmente). El switch que tenga el valor más bajo será el elegido como root bridge. Si existe más de un

switch con el mismo valor BID, se elegirá al que tenga la MAC más baja en cualquiera de sus interfaces.

Nonroot Brigde: Son todos los switchs restantes en la topología STP.

Los puertos que conectan cada enlace entre switchs también tendrán un rol, que puede ser:

Root Port: Cada switch designado como nonroot bridge tendrá un único puerto que actuará como root port. El root port es el puerto “más cercano” (basado en el coste de los enlaces) al root bridge. En otras palabras, es el puerto cuya velocidad de transmisión sea la más rápida para llegar hasta el root bridge (la velocidad de transmisión es la suma de la velocidad de todos los enlaces por los que hay que pasar para llegar hasta el root bridge). Si dos puertos tienen la misma velocidad y es la mejor para llegar hasta el root bridge se escogerá el puerto con la numeración más baja (ver ejemplo).

Designated Port: Son los puertos de cada segmento de red con el coste más bajo hasta el root bridge. Es decir, de cada enlace entre dos switchs sólo un puerto actuará como designated port, y es el que tenga el coste más bajo hasta el root bridge. Todos los puertos del Root Bridge tienen el rol de designated port.

Nondesignated Port: son los puertos bloqueados para no crear loops de enrutamiento. Los puertos no designados no envían ni reciben tráfico normal en la red , pero sí que reciben y examinan paquetes BPDU (bridge protocol data units) que son los paquetes que usa el protocolo STP. De esta forma si hay algún cambio en la topología y hay que activar un puerto no designado se activaría sin problema (por ejemplo que se caiga un enlace que actuaba como root port). Antes de que un puerto no designado cambie su estado a forwarding debe pasar por 4 estados: Blocking (permanece bloqueado 20 segundos recibiendo BPDUs para determinar que rol tendrá el puerto en la nueva topología), Listening (el puerto permanece en escucha durante 15 segundos, durante este tiempo envía BPDUs informando de las adyacencias y switchs vecinos que tiene), Learning ( Permanece 15 segundos en este estado, durante este tiempo va rellenando su tabla de MACs) y Forwarding (El puerto empieza a funcionar con normalidad enviando y recibiendo paquetes).

Para calcular los costes STP usa los siguientes valores:

Velocidad del enlace Coste STP 10 Mb (ethernet) 100 100Mb (Fast Ethernet) 19 1 Gbps (Gigabit ethernet) 4 10 Gbps (Ten gigabit ethernet) 2

Ejemplos de STP:

Ejemplo 1: Tenemos dos switchs con enlaces redundantes, para que no se creen loops de enrutamiento se ha configurado STP. SW1 es el root bridge porque se le ha configurado un Bridge ID menor que el de SW2,  mientras que SW2 es el nonroot bridge, que rol tendrá cada puerto en cada switch.

Gi0/1 y Gi0/2 en SW1: Como SW1 es el root Bridge, ambos puertos actuarán como puertos designados porque todos los puertos en el Root Bridge toman ese rol.

Gi0/1 en SW2: SW2 es el non-root bridge por lo tanto tiene que tener un puerto que tome el rol de root port, si recordamos el root port es el puerto cuyo coste hasta el root bridge sea el menor. En este caso los dos puertos tienen el mismo coste (coste 19 porque son enlaces fast ethernet). Cuando se da esta circunstancia el root port será aquel cuya numeración sea más baja. Gi0/1 es menor que Gi0/2 por lo tanto Gi0/1 tomará el rol de root port.

Gi0/2 en SW2: Este puerto tendrá el rol de no designado (bloqueado) con el fin de evitar loops de enrutamiento. Si nos fijamos tenemos dos segmentos de red. El segmento de red número 1 está enviando y recibiendo tráfico con normalidad porque un puerto está actuando como root port y otro como puerto designado (por lo tanto ningún puerto está bloqueado). Si no se bloqueara ningún puerto en el segmento de red número 2 se crearían loops de enrutamiento, por eso se bloquea este puerto. Pero ¿porqué toma el rol de no designado el puerto del SW2 y no el del SW1? Porque el SW1 es el root bridge y todos los puertos del root bridge toman el rol de puertos designados, por lo tanto hay que bloquear el puerto del otro extremo, en este caso el Gi0/2 de SW2.

Ejemplo 2: Tenemos dos switchs con enlaces redundantes, para que no se creen loops de enrutamiento se ha configurado STP. SW1 es el root bridge porque se le ha configurado un Bridge ID menor que el de SW2,  mientras que SW2 es el nonroot bridge, que rol tendrá cada puerto en cada switch.

Gi0/1 y Gi0/2 en SW1: Como SW1 es el root Bridge, ambos puertos actuarán como puertos designados porque todos los puertos en el Root Bridge toman ese rol.

Gi0/2 en SW2: SW2 es el non-root bridge por lo tanto tiene que tener un puerto que tome el rol de root port…si recordamos el root port es el puerto cuyo coste hasta el root bridge sea el menor.  El segmento de red número 1 tiene un coste de 100 porque es un enlace ethernet, mientras que el segmento número 2 tiene un coste de 19 porque es fast ethernet. Por lo tanto el root port será el puerto que conecte con el segmento 2 porque tiene un coste menor, en este caso es el Gi0/2

Gi0/1 en SW2: Este puerto tendrá el rol de no designado (bloqueado) con el fin de evitar loops de enrutamiento, por la misma razón que lo explicado en el ejemplo 1.

Posibles problemas con STP:

Tabla de MACs corrupta:Un STP mal configurado o simplemente no configurado dará como consecuencia una tabla de macs corrupta en los switchs que forman parte de una comunicación. Esto se debe a que al haber enlaces redundantes en ambos switchs, la trama llegará dos veces por puertos diferentes, y cada switch sobreescribirá una y otra vez la Tabla de Macs para actualizar la entrada. Se ve más fácil con un ejemplo. Veámoslo paso por paso con un ejemplo sencillo:

Paso 1: El PC 1 envía un paquete a PC2  en una red con enlaces redundantes y sin STP configurado. El paquete llega a ambos switchs y éstos añaden la MAC de PC1 a sus tablas de MACs, asociando la MAC con el puerto por donde se recibió.

Paso 2: Aquí surge el problema. SW1 y SW2 comparten el mismo segmento a través de sus enlaces Gi0/2, al no tener STP configurado ninguno de estos puertos se bloquea por lo tanto cuando SW1 reenvíe el paquete a través de su interfaz Gi0/2 el paquete llegará a PC2 y SW2. SW2 al recibir el paquete en su puerto Gi0/2 leerá la MAC de origen (que es la de PC1) y la asocia al puerto por donde la recibió, es decir, asocia la MAC de PC1 a su puerto Gi0/2, dando origen a una tabla de MACs corrupta. Lo mismo pasa con SW1 al recibir el paquete de SW2. Además el paquete llegará duplicado a PC2.

Tormentas de broadcast:Otra consecuencia de STP mal configurado o no configurado son las tormentas de broadcast. Cuando se envía un broadcast en una red con enlaces redundantes sin STP configurado los paquetes llegan en la misma cantidad que enlaces redundantes tengamos (por ejemplo, 3 enlaces, 3 paquetes a cada switch) lo que implica que el broadcast sea reenviado por todos los enlaces excepto por el que se recibió. Como existen enlaces redundantes y los broadcasts se reenvían siempre por todos los puertos, los paquetes se irán multiplicando creando un bucle infinito entre los switchs, lo que hace que el ancho de banda y rendimiento de la red sea cada vez peor.Veámoslo con un ejemplo.

Paso 1: El PC1 envía un paquete de broadcast a la red, que será recibido por SW1 y SW2.Paso 2: SW1 y SW2 reciben el paquete broadcast y lo reenvían por todos los puertos excepto por el que lo recibió. En este caso SW1 lo reenvía por el puerto Gi0/2, lo que implica que el paquete le llegará a PC2 y SW2. Lo mismo hace SW2, reenvía el paquete por su interfaz Gi0/2 y el paquete le llegará a PC2 y SW2. Además el paquete llegará duplicado a PC2.Paso 3: SW1 y SW2 reciben el paquete broadcast por sus interfaces Gi0/2. Como es un paquete broadcast lo reenvían por todos sus puertos. En este caso SW1 lo reenvía por Gi0/1 haciendo que el paquete llegue a SW2 y al PC1. Mientras, SW2 también reenvía el paquete

por su interfaz Gi0/2, lo que hace que llegue a SW1 y PC1. Además el paquete llegará duplicado a PC1.Loop creado: Llegados a este punto se repetirían los pasos 2 y 3 de forma infinita, creando un loop y una tormenta de broadcast.

Posibles problemas con Etherchannels:Como ya sabemos un etherchannel es la capacidad de crear un enlace lógico a través de varios enlaces físicos. En otras palabras, usar varios enlaces y hacer que trabajen como si fuera uno solo, de esta manera sumamos el ancho de banda de todos los enlaces para obtener uno de mayor velocidad. Por ejemplo 4 enlaces de 1gb cada uno. Creando un etherchannel obtendremos un enlace de 4gb. Este enlace es lógico, físicamente siempre tendremos 4 enlaces, como es de suponer. Los etherchannels se usan mayormente para interconexiones entre switchs, haciendo que el enlace entre dos switchs sea mucho más rápido de lo que nos ofrecería un solo enlace. En el funcionamiento de STP los etherchannels funcionan como un solo puerto lógico, y aunque también ofrezcan redundancia, no es posible que se creen loops de enrutamiento entre los diferentes puertos físicos que forman el etherchannel.Cuando nos encontremos con problemas con los etherchannels deberemos comprobar los siguientes aspectos:

Configuraciones de puertos desiguales: La configuración de los puertos que forman el etherchannel debe ser idéntica en ambos switchs, por ejemplo, todos los puertos deben tener la misma velocidad, modo de duplex, configuración de trunk y vlans nativas.

Configuración desigual del etherchannel: Los switchs que formen el etherchannel deben ser configurados con el mismo protocolo de negociación de etherchannel, que debe ser LACP o PAgP.

En el CCNP Tshoot se hace un breve repaso a los conceptos básicos de routing y switching que ya se han visto en CCNA, CCNPR o CCNPS. El objetivo principal de Tshoot es indicar como recolectar toda la información necesaria para reparar los errores que como ya hemos visto es a través de los comandos show o debug. Una vez localizado el error se tiene que reparar con los comandos que ya hemos aprendido en los anteriores módulos (CCNPR o CCNPS).

CCNP TSHOOT: Ejercicio Troubleshooting STP

En los ejercicios de troubleshooting se nos presenta una topología de red y se nos reporta una incidencia que debemos resolver. Para resolverla primero compararemos la configuración base con la configuración actual usando los comandos show y debug, los cuales nos darán la información necesaria para localizar el problema. Una vez localizado, solucionarlo con los comandos de configuración aprendidos en CCNA, CCNPR o CCNPS.

 

Topología 

Incidencia: Los usuarios de la red 192.168.1.0 /24 están experimentando mucha latencia cuando intentan acceder a la red 10.1.2.0 /24. Haciendo un seguimiento del tráfico desde la red 192.168.1.0 hasta la red 10.1.2.0 se ha percibido que en los enlaces entre los switchs hay pérdidas de paquetes y altos niveles de condensación de tráfico, por lo que se decide investigar el problema en los enlaces entre los switchs. PASO 1: Comprobar la configuración Base de la Red Toda red bien documentada tiene que tener una configuración base. La configuración base es la configuración inicial de la red, antes de que se haya aplicado cualquier cambio y cuando todo funcionaba correctamente.  Configuración Base de SW2 (BaseLine):

Configuración Base de SW1 (BaseLine):

Comprobando la configuración base de ambos switchs nos damos cuenta de existe una instancia de STP para la VLAN 1 donde el SW2 es el root bridge y en el SW el puerto Gi  0/9 actúa tiene el rol de root y está enviando y el Gi  0/10 de alternate y está bloqueado.A parte podemos ver los valores establecidos para los paquetes hello etc…que tienen el mismo valor en ambos switchs.Ésta es la configuración de cuando la red funcionaba correctamente. Ahora entramos a buscar el problema actual.  PASO 2: Analizar la configuración actual de los switchs Habiendo analizado y entendido la configuración base de los switchs procedemos a conectarnos al SW1 para comprobar la configuración actual y nada más conectarnos a la consola del SW1 nos aparece este mensaje.

 Sólo con este mensaje ya nos podemos hacer una idea de donde está el error ya que nos indica que varias MACS están “saltando” entre los puertos pertenecientes a STP, por lo que se está generando un loop. Este error es debido a una tabla de MACs corrupta en STP y la tabla de MACs corrupta es debida a un fallo de configuración de STP. El mensaje que estamos recibiendo nos indica que esas MACs pertenecen a la instancia de la VLAN1, así que lo primero que tenemos que comprobar es la configuración de STP para la VLAN1 en ambos switchs, por lo que ejecutamos un show spanning-tree vlan 1 en SW1 y SW2, obteniendo estos resultados. 

 

Ups, algo falla!!!! En la configuración base de ambos switchs estaba configurada la instancia de STP para la VLAN1, sin embargo actualmente ambos switchs nos indican que no hay instancia para esa VLAN… ¿Será por eso que se está creando un loop de enrutamiento? Si nos fijamos en la topología existen enlaces redundantes entre SW1 y SW2, al haber enlaces redundantes se pueden crear loops de enrutamiento ya que un mismo paquete puede ser

enviado por los dos enlaces siendo recibido una y otra vez en ambas interfaces, para eso existe STP, para controlar los enlaces redundantes enviando por uno y bloqueando el otro. Si no existe instancia para la VLAN1 en STP significa que los paquetes enviados desde cualquier host perteneciente a esa VLAN no están siendo controlados, de ahí que “salten” entre un enlace y otro generando loops y sobrecarga en los enlaces.Configurando STP para la VLAN1 conseguimos que STP bloquee un puerto redundante evitando así los loops y la sobrecarga en los enlaces. PASO 3: Solucionar el problema. Ya examinamos la configuración base de ambos switchs y la configuración actual y nos dimos cuenta del problema que había en la red. Ahora sólo hay que solucionarlo. Para ello debemos crear la instancia de STP para la VLAN 1 en ambos switchs. 

PASO 4: Comprobar la nueva configuraciónUna vez hayamos aplicado la nueva configuración para resolver el problema debemos comprobar que esa configuración se ha aplicado correctamente y con los resultados que nosotros buscábamos. En este caso ejecutamos un show spanning-tree vlan 1 en ambos switchs para comprobar que los cambios se han realizado con éxito.

Como vemos la configuración que hemos aplicado ha creado una instancia en STP para la VLAN1. Con esto logramos bloquear un puerto de los redundantes, más concretamente el Gi  0/10 en el SW1. En el SW2 aparecen todos como Forwardng porque es el root bridge.Bloqueando un puerto de los redundantes logramos no crear loops de enrutamiento en STP y por consiguiente no congestionar los enlaces, que era el origen de la incidencia. 

CCNP TSHOOT: Resolución de problemas avanzados en Switchs Cisco

Anteriormente analizábamos como resolver problemas básicos de switchs, basados todos en capa 2, como son la tabla de macs, las vlans, Stp o los etherchannels. En esta entrada nos adentraremos un poco más y analizaremos los problemas más frecuentes de capa 3 que nos podemos encontrar en switchs, veremos el enrutado entre vlans, la redundancia en ruteo y la lógica de los switchs multicapa para poder enrutar paquetes… Enrutado entre VLANs Para que dos VLANs diferentes se puedan comunicar tiene que haber algún dispositivo capaz de enrutar tráfico, ya que las vlans no comparten el mismo rango de red. Como hemos visto en entradas anteriores enrutar tráfico entre dos vlans se puede hacer de dos formas, o bien a través de un router creando sub-interfaces (una por cada vlan) o bien a través de un switch de capa 3 (o multicapa) creando interfaces virtuales. Hagamos un repaso rápido a los dos métodos para luego ver los posibles problemas con los que nos podamos encontrar… Enrutamiento de vlans a través de un router Para enrutar vlans a través de un router lo que tenemos que hacer es conectar el switch que tiene las vlans con una interfaz de un router a través de un enlace trunk (recordamos que el trunk es capaz de transportar todas las vlans que queramos). Luego en la interfaz del router habría que configurar una sub-interfaz por cada vlan que queramos enrutar. Por ejemplo si queremos enrutar dos vlans, crearemos dos sub-interfaces. Veámoslo con un ejemplo.  

Paso 1: PC1 pertenece a la VLAN 100 y envía un paquete a PC 2, que pertenece a la VLAN 200. PC1 envía el paquete etiquetado como vlan 100 y a la IP de la interfaz Fa0/1.100 del router, ya que es la IP que tiene configurada como puerta de enlace predeterminada, el paquete llega al switch y éste lo reenvía a través de su enlace trunk hacia el router.Paso 2: El router mira la dirección de destino del paquete, examina su tabla de rutas y comprueba que debe reenviarlo a través de su interfaz Fa0/1.200. Este paquete ya sale etiquetado como vlan 200 (debido a la configuración que hemos puesto en la interfaz).Paso 3: El paquete llega al switch etiquetado como VLAN 200 y el switch lo reenvía al PC2. Cada vez que PC1 y PC2 se comuniquen será el router el encargado de enrutar los paquetes. Nota: En esta entrada no se explican los comandos para configurar las sub-interfaces en routers porqué no es el objetivo de este post. En esta entrada nos centraremos sólo en Switchs de capa 3. Enrutamiento de vlans a través de un Switch de capa 3 : Los switchs de capa 3 o multicapa tienen la capacidad de enrutar tráfico de capa 3 sin la necesidad de un router de por medio, esto da beneficios como la velocidad que es mucho mayor. Los switchs de capa 3 puede enrutar tráfico de dos formas, creando puertos de ruteo, que son puertos físicos que habilitamos para que funcionen en capa 3 o  bien creando interfaces virtuales dentro del propio switch. Para enrutar vlans se usan las interfaces virtuales, llamadas SVI, y tenemos que crear una SVI por cada vlan que queramos enrutar. De esta forma cuando un paquete llega al switch y el destino sea una vlan diferente que la de origen, el switch comprueba sus SVIs y si la red de destino coincide con la de alguna SVI, lo enruta hacia esa red y etiqueta el paquete con la nueva VLAN.Para crear y configurar SVIs se usa el siguiente comando: 

-          Interface vlan[num de vlan]: Crea la interfaz virtual para la vlan que indiquemos.-          Ip address [ip] [mascara]: Asigna una ip a la interfaz, como es lógico la IP tiene que estar

en el mismo rango que los equipos que pertenezcan a esa vlan. Ejemplo:

 Paso 1: PC1 pertenece a la VLAN 100 y envía un paquete a PC 2, que pertenece a la VLAN 200. PC1 envía el paquete etiquetado como vlan 100 a la IP de la SVI  de la VLAN 100, ya

que es la IP que tiene configurada como puerta de enlace predeterminada, el paquete llega al switch.Paso 2: El switch mira la dirección de destino del paquete, examina su tabla de rutas y comprueba que debe reenviarlo a través de su interfaz virtual SVI VLAN 200. Este paquete ya sale etiquetado como vlan 200.Paso 3: El paquete llega al PC2.

Configuración de SW1:                 SW1(config)# interface Gi  0/1                SW1(config-if)# switchport access vlan 100                SW1(config-if)#switchport mode access                SW1(config-if)#exit

SW1(config)# interface Gi  0/2                SW1(config-if)# switchport access vlan 200                SW1(config-if)#switchport mode access                SW1(config-if)#exit                SW1(config)# interface VLAN100                SW1(config-if)# ip address 172.10.0.1  255.255.0.0

SW1(config-if)#exit SW1(config)# interface VLAN200

                SW1(config-if)# ip address 172.20.0.1  255.255.0.0 SW1(config-if)#exit

  De esta forma las vlans estarían enrutadas a través de un switch de capa 3. Como hemos nombrado antes, estos switchs también tienen la capacidad de tráfico a través de puertos físicos habilitados para ello. Estos puertos desde que se configuran para operar en capa 3 pierden todas las características de capa 2, por ejemplo no se podrá meter en una vlan, ni operan en STP ni mucho menos se puede agregar ese puerto a un portchannel. Para configurar un puerto de un switch como puerto de ruteo se usa el comando no switchport, dentro del modo de configuración de la interfaz. Desde que introduzcamos ese comando el puerto se comportará como un puerto de un router, pudiendo configurarle una IP, protocolos de enrutamiento como OSPF etc. Lo que no podremos crear son sub-interfaces.Un router port podremos usarlo por ejemplo para crear un enlace con otros routers que conecten otras redes o con algún firewall.Por ejemplo. 

En el ejemplo vemos una red con un router que es usado para la conexión a Internet, un firewall que examina todo el tráfico que llega desde Internet y sale hacia Internet y luego tenemos un Switch de capa 3 que es el punto central de la red interna, ya que conecta con el firewall, dos routers y un punto de acceso. Los puertos del switch que conectan con el firewall, routers y punto de acceso tienen que estar configurados como routed ports porque su función es la de enrutar tráfico, comunicar diferentes rangos de red, por lo tanto sólo trabajaran en capa 3…pero….¿porque hacerlo a través de un switch de capa 3 y no de un router? ¿No es lo mismo? Sí, las funciones son las mismas, funcionaría perfectamente con un router, pero la velocidad no sería la misma. Los switchs de capa 3 enrutan a través de hardware, más concretamente gracias a unos circuitos integrados en cada puerto llamados ASIC, mientras que los routers lo hacen a través de software. La diferencia entre uno y otro es que la velocidad de enrutamiento es muchísimo más rápido a través de hardware, por lo tanto el rendimiento y capacidad de la red aumentan usando un switch de capa 3. El inconveniente es que son muchísimo más caros que un router. Por último nombrar que los switchs catalyst de capa 3 toman sus decisiones de ruteo en base a una tecnología de cisco llamada CEF (Cisco Express Forwarding). CEF lo que hace es crear una tabla llamada Forwarding Information Base (FIB) en la cual va almacenando los prefijos de las diferentes redes, el siguiente salto y la interfaz por la cual debe salir el paquete que se dirija a esa red y otra taba llamada tabla de adyacencias donde vincula cada interfaz con las redes accesibles desde esa interfaz. Básicamente es lo mismo que la tabla de rutas usada por los routers, pero esta vez aplicado a los switchs. Para lograr mayor velocidad CEF copia información de la tabla FIB y la taba de adyacencias en una memoria especial del switch, llamada “Ternary content addressable Memory” (TCAM), que lo que hace es usar un algoritmo matemático bastante rápido para tomar decisiones de enrutamiento.La tabla cef se puede visualizar con el comando show ip cefLa tabla de adyacencias con el comando show adjacencyMientras que el contenido de la memoria TCAM con el comando show platform o show mls cef, dependiendo del modelo del switch. Posibles problemas de enrutamiento en capa 3: El enrutamiento en capa 3 es bastante sencillo, como vimos para enrutar vlans sólo tenemos que crear interfaces virtuales y asignarles una IP dentro del rango de la VLAN, mientras que para activar un puerto como routed port sólo tenemos que aplicar el comando “no switchport” en la configuración del puerto. Aún así, debemos tener en cuenta varios aspectos:

Si equipos de diferentes vlans no se pueden comunicar tenemos que fijarnos en que la IP de la interfaz virtual tiene que estar dentro del rango de red de la vlan, y todos los equipos pertenecientes a esa vlan tienen que tener configurado como puerta de enlace la IP de la interfaz virtual, sino no se podrán comunicar con los equipos de otra vlan.

Una interfaz virtual se considera en estado “down” cuando ninguno de los puertos asociados a su vlan están activos, es decir, cuando no existe ningún puerto con la misma vlan o estén caídos por cualquier razón.

Un routed port se considera en estado “down” si no está operando a nivel de capa 1 y capa 2.

Los routed ports no soportan protocolos de capa 2 como STP o DTP.  Redundancia en Routing. Puerta de enlace redundante.La puerta de enlace o default gateway configurada en PCs o diferentes dispositivos hace referencia a la dirección IP a la cual se enviarán los paquetes. El PC envía el paquete a esa dirección IP, que será un dispositivo capaz de enrutar tráfico, este dispositivo ya se encarga de enrutar el paquete hacia su destino. Las puertas de enlace son un punto crítico en una red, la mayoría de las redes sólo tienen un dispositivo que actúa como puerta de enlace, por lo que si ese dispositivo cae sea cual sea la razón, ningún equipo que use esa puerta de enlace tendrá conexión con otras redes. Para solucionar este problema existen diferentes protocolos que ofrece el servicio de puerta de enlace redundante, esto quiere decir que usando siempre la misma IP de puerta de enlace en los equipos, si un dispositivo de enrutamiento cae, otro dispositivo tomará su rol y el enrutamiento seguirá llevándose a cabo, sin necesidad de hacer ningún cambio en la configuración de los PCs.Existen 3 protocolos de puerta de enlace redundante, son HSRP, VRRP y GLBP. Los 3 protocolos ya se han explicado a fondo en entradas anteriores así que sólo haremos un breve repaso a cada uno de ellos. HSRP (Hot standby router protocol)HSRP es un protocolo propietario de Cisco cuya finalidad es ofrecer puertas de enlace redundantes en la red, el funcionamiento se basa en que dos routers sean configurados de tal manera que uno actúe como puerta de enlace y en el caso de que caiga, el otro tome su rol y siga enrutando los paquetes de la red, todo esto sin hacer ningún cambio de configuración en los hosts.Para lograr esto se configura un router “virtual” en cada router (o switch de capa 3) al cual se le asignará una IP virtual (se configura la misma en ambos routers). Esta IP virtual es la que se configurará en los hosts de la red como puerta de enlace predeterminada. HSRP no ofrece balanceo de carga, lo que significa que sólo un router actuará como puerta de enlace (router activo) y en caso de que caiga el otro router tomará su rol (standby router)…pero…. ¿que router actúa primero como activo? El que nosotros queramos ya que a ambos routers les podemos dar una prioridad, el router con mayor prioridad es el que se convertirá en activo. La prioridad por defecto es de 100 y si no la cambiamos en ningún router se convertirá en activo aquel que tenga la IP más alta configurada en su interfaz.  HSRP se configura dentro del modo de configuración de la interfaz, dicha interfaz tendrá una IP configurada para la interfaz física y otra IP virtual que será la usada por HSRP. Para configurarlo se usa el comando standby [parámetros], una configuración básica incluye los siguientes parámetros: 

standby [grupo] ip [ip]: Indica la IP virtual que se usará para HSRP. La IP que se configure aquí es la IP que se tiene que poner en los equipos como puerta de enlace. [grupo] indica el grupo de HSRP que estamos configurando. El grupo es un número (el que nosotros queramos) pero debe ser el mismo en ambos routers donde configuremos HSRP con la misma IP virtual.

standby [grupo] priority [prioridad] : Indica la prioridad que tendrá el router para ese grupo de HSRP. Si no se configura tendrá una prioridad por defecto de 100. Si

se le configura una prioridad más alta que los demás routers, actuará como router activo.

standby [grupo] preempt: el parámetro preempt se suele usar en el router que marquemos como activo e indica que si el router cae por la razón que sea, cuando vuelva a estar operativo volverá a ser el router activo. Si no lo configuramos y el router cae, cuando vuelva a estar operativo tomará el rol de standby router.

 Ejemplo: 

*  “Router Virtual de HSRP” NO es un router físico. Configuración de Router 1 y Router 2                 Router1(config)# interface fa0/0                Router1(config-if)#ip address  172.20.1.2  255.555.0.0                Router1(config-if)# standby 10 ip 172.20.1.1                Router1(config-if)# standby 10 priority 150                Router1(config-if)# standby 10 preempt                  Router2(config)# interface fa0/0                Router2(config-if)#ip address  172.20.1.3  255.555.0.0                Router2(config-if)# standby 10 ip 172.20.1.1                Con la configuración actual Router 1 tomaría el rol de router activo porque se le ha configurado una prioridad mayor que al Router 2. Router 1 tiene una prioridad de 150 mientras que el 2 tiene una prioridad de 100, que es la que toma por defecto. Además si el router uno dejara de ser activo por lo que sea, cuando vuelva a estar operativo volvería a tomar el rol de router activo porque tiene el preempt configurado.  Por defecto los routers que forman parte del mismo grupo de HSRP se envían mensajes hello cada 3 segundos. Si el router en standby no recibe algún hello por parte del router activo espera 10 segundos y si pasados esos 10 segundos aún no ha recibido ningún hello el router standby da por caído al router activo y por lo tanto toma su rol. Estos 10 segundo se esperan

cuando el fallo del router activo es inesperado como por ejemplo un apagado no programado o una falla en el enlace, si por el contrario la interfaz del router activo es apagada administrativamente (que la apagamos nosotros) los 10 segundos no se esperan, lo que hace que la convergencia sea mucho más rápida.Si después de la caída del router activo éste vuelve a estar operativo y además tiene el preempt configurado el router envía un mensaje “coap” que lo que hace es informar al otro router que el tiene una prioridad mayor y por lo tanto se va a convertir otra vez en activo.Aplicando todo esto al ejemplo anterior…El Router1 tiene el rol de activo pero se apaga de repente por un fallo de electricidad…. El Router2 deja de recibir los mensajes hello de Router1 y espera 10 segundos, pasado este tiempo el Router2 toma el rol de activo. El router1 recupera la electricidad y se enciende, volviendo a estar operativo, entonces el router1 envía un mensaje “coap” al router2 advirtiendo de que tiene una prioridad de 150 y que va a volver a ser el router activo del grupo. El router1 vuelve a ser el router activo.  MAC del router Virtual:Hasta ahora hemos visto como se configura la IP del router virtual. Al participar en la comunicación en la red este router también tiene que tener una MAC, que como es lógico también será virtual. La MAC no la configuramos manualmente, ya que se crea de forma automática y está basada en el número de grupo que configuremos en HSRP. Todas las MACs de routers virtuales pertenecientes a HSRP siguen éste patrón. Los 6 primeros dígitos hexadecimales corresponden al código de vendedor. Cada vendedor de router tendrá un código asignado para usar en HSRP, por ejemplo, Cisco: 0000.0cLos 4 siguientes dígitos corresponden a un código establecido para HSRP, estos 4 dígitos siempre serán los mismos en todas las direcciones MAC de HSRPA sea cual sea el vendedor: 07.acLos dos últimos dígitos corresponden al número de grupo HSRP, en hexadecimal al que pertenece ese grupo, siguiendo con el ejemplo anterior el grupo era el 10, por lo tanto 10 en hexadecimal: 0a Con todo esto, la MAC de nuestro router virtual HSRP es la siguiente: 0000.0c07.ac0a0000.0c: Código vendedor.07. ac: Código HSRP.0a: El grupo 10 en hexadecimal.

Posibles problemas con HSRP: Cuando nos encontremos con problemas en HSRP tenemos que comprobar la configuración y tener bien claro que router está actuando como router activo, qué router o routers tienen configurada la opción preempt y cuales son la IP y la MAC del router virtual. A parte, comprobar que el router virtual está funcionando en capa 3 haciendo un ping a su dirección y que la MAC es la correcta haciendo un arp –a en cualquier equipo de la red.Teniendo estos datos delante usaremos comandos de verificación para ver dónde está el error, los comandos más útiles y de ayuda para la resolución de problemas en HSRP son: 

show standby brief: Muestra en pantalla información sobre la configuración de HSRP en ambos routers. Interfaces usadas, prioridad de cada router, preempt, estado, ip de las interfaces y la ip virtual.

Show standby [interfaz]: Muestra en pantalla información de HSRP de una determinada interfaz. Estado, IP virtual, preempt, y también la MAC virtual.

Debug standby terse: Muestra en tiempo real paquetes recibidos y enviados de HSRP, entre otras cosas muestra los cambios de estado de un router cuando van sucediendo.

. 

 VRRP (Virtual Router Redundancy Protocol)La finalidad de VRRP es la misma que la de HSRP, dar servicio de redundancia de puerta de enlace, con varias diferencias.

HSRP es propietario de Cisco, VRRP es un IEEE estándar. En HSRP se pueden configurar 16 grupos como máximo, en VRRP 255. HSRP usa un switch como activo y otro como standby, VRRP usa un switch como

master, y todos los demás como backups. Los tiempos de hello y holdtime son más cortos en VRRP. VRRP soporta encriptación en la autenticación (HMAC/MD5).

Cuando el switch que esta como master cae, uno de los que está en backup toma el rol de master, para determinar que switch toma el control, se lleva a cabo un cálculo entre todos ellos en los que entran en juego diferentes intervalos de tiempo como el “skew time” la prioridad etc… En definitiva, todos los switchs hacen un cálculo, y el que menos tiempo obtenga, es el primero en enviar paquetes al resto de switchs, por lo cual se convierte en master.Los intervalos de tiempo de hello también se pueden configurar en VRRP, a diferencia de HSRP, en VRRP se configuran en el master y los backups aprenden esos intervalos del master. 

 GLBP (Global Load Balancing Protocol)GLBP es otro protocolo capaz de ofrecer puerta de enlace redundante, la gran diferencia respecto a HSRP y VRRP es que GLBP sí es capaz de hacer balanceo de carga por lo que el ancho de banda es utilizado de mejor manera y el rendimiento aumenta.Para lograrlo, todos los routers que formen parte del mismo grupo de BLGP usarán la misma IP virtual pero a cada uno se le otorga una MAC virtual diferente. De esta forma, cuando los equipos hagan un ARP a la dirección IP de la puerta de enlace, cada equipo obtendrá una dirección MAC diferente, por lo tanto enviarán los paquetes a la misma dirección IP pero diferente Router.Por ejemplo, tenemos 3 router (A, B y C) y 3 equipos. Los 3 routers están configurados con GLBP dentro del mismo grupo usando la misma IP virtual pero diferente MAC virtual. Cuando el primer equipo solicite la MAC de la IP de la puerta de enlace, GLBP responderá con la MAC virtual del router A, cuando el segundo equipo la solicite, se le dará la MAC virtual del router B y al tercer equipo se le dará la MAC virtual del router C. De esta forma los 3 equipos salen por la misma puerta de enlace pero diferentes routers.Cuando los equipos envían la solicitud de ARP a la ip virtual, sólo se encarga de responder un router, el que tenga el rol de AVG (Active virtual gateway) (comparándolo con HSRP viene a ser el router activo) el cual va respondiendo a las solicitudes arp con las MACs de los routers

pertenecientes a su grupo de ARP. Los otros routers del grupo tendrán el rol de AVF (active virtual forwarder).¿Y qué pasa si el AVG se cae? Al igual que con HSRP otro router tomaría su rol, es decir, un AVF pasaría a ser AVG… ¿y la mac virtual que usaba el router caído? También la usa el router que toma su rol. Usaría dos macs virtuales (la suya y la del router que cayó) hasta que el otro router vuelva a estar operativo. 

CCNP TSHOOT: Ejercicio Troubleshooting HSRP

En los ejercicios de troubleshooting se nos presenta una topología de red y se nos reporta una incidencia que debemos resolver. Para resolverla primero compararemos la configuración base con la configuración actual usando los comandos show y debug, los cuales nos darán la información necesaria para localizar el problema. Una vez localizado, solucionarlo con los comandos de configuración aprendidos en CCNA, CCNPR o CCNPS. Topología  

 Incidencia: Se ha configurado HSRP en los routers BB1 y BB2 para ofrecer redundancia de puerta de enlace a los usuarios de la red 10.1.2.0. BB1 tenía y debe tener el rol de router activo. BB1 parece estar funcionando correctamente sin embargo BB2 es el que está actuando como router activo. Comprobar que está pasando y reparar el error.  PASO 1: Comprobar la configuración Base de la Red 

Toda red bien documentada tiene que tener una configuración base. La configuración base es la configuración inicial de la red, antes de que se haya aplicado cualquier cambio y cuando todo funcionaba correctamente.Configuración Base de BB1 (BaseLine): 

 Configuración Base de BB2 (BaseLine): 

 

Examinando la configuración base podemos ver como el router BB1 tiene el rol de router activo para el grupo de HSRP 1. Es activo porque tiene una prioridad configurada manualmente de 150, mientras que BB2 tiene la prioridad por defecto que es de 100. La ip del router virtual es 172.16.1.4.Como vemos, cuando creamos la configuración base funcionaba todo correctamente, sin embargo estudiando esta configuración también nos podemos dar cuenta de donde está el posible error. El router BB1 no tiene configurada la opción preempt, si recordamos preempt lo que hace es que si el router BB1 sufriera alguna caída al recuperarse volvería a tomar el rol de router activo. Con la configuración actual si BB1 hubiera tenido alguna caída o micro caída BB2 tomaría el rol de activo y cuando BB1 se recuperara NO volvería a tomar el rol de activo.   PASO 2: Analizar la configuración actual de los switchs Comprobamos que efectivamente actualmente el router BB2 está actuando como activo mientras que el BB1 como standby. 

 

El problema está claro, el router BB1 o alguno de sus enlaces debió sufrir una caída o micro caída, lo que hizo que BB2 tomara el rol de router activo. Como BB2 no se ha caído y BB1 no tiene la opción preempt configurada BB1 no ha vuelto a tomar el rol de router activo. Localizado el error procedemos a repararlo.

 PASO 3: Solucionar el problema.Ya conocemos el problema, ahora lo único que queda es solucionarlo. En este caso tenemos dos opciones de solucionarlo. Una es haciendo que el router BB2, o su enlace con la red se caiga, de esta forma BB1 tomaría el rol de activo y cuando BB2 se recupere BB1 seguiría siendo activo.La segunda opción sería configurar la opción preempt en el router BB1, lo que haría que automáticamente tomara el rol de router activo ya que tiene una prioridad más alta.Obviamente la segunda opción es la más lógica y recomendada así que procedemos a aplicarla y comprobar que efectivamente se han aplicado los cambios correctamente.

 

 Como vemos, nada más aplicar el preempt para el grupo 1 de hsrp en el router BB1 nos ha aparecido un mensaje de consola que nos indica un cambio de estado de standby a activo para el grupo 1….Aún así hacemos un “show standby brief” para asegurarnos de que BB1 es ahora el router activo. Comprobamos que efectivamente lo es y además de ahora en adelante si BB1 sufre una caída, cuando se recupere volverá a tomar el rol de activo para el grupo 1 de HSRP.

CCNP TSHOOT: Introducción a protocolos de enrutamiento - EIGRP

Todas las redes que estén compuestas por varias redes o subredes necesitan dispositivos capaces de enrutar tráfico, esto es un router o un switch de capa 3 y para enrutar el tráfico tienen que conocer las redes a las que pueden acceder. Para ello se pueden configurar todas las redes de forma estática en cada dispositivo o configurarlo para que se transmitan las redes de forma dinámica mediante algún protocolo. En esta entrada repasaremos un poco el proceso de routing básico junto con los comandos de ayuda para la resolución de problemas, además, repasaremos por encima el protocolo EIGRP junto con los comandos que más nos ayudaran para la resolución de problemas de este protocolo. Repasando el proceso de Routing BásicoPara  que dos dispositivos pertenecientes a diferentes redes puedan comunicarse es necesario que dispositivos intermedios sean capaces de enrutar el tráfico, estos dispositivos tienen que ser de capa 3 como un router o un switch de capa 3. Pero, ¿Cómo se enruta el tráfico? Pues fácil, cuando el paquete llega al router o switch multicapa éste comprueba la dirección de destino y la busca en su tabla de rutas. En la tabla de rutas se asocian las redes a las que se pueden llegar con la interfaz de salida por la que tiene que salir el paquete para llegar a dicha red. Si la red de destino coincide con alguna red en la tabla de rutas el paquete se enviará por la interfaz asociada. Si no existe coincidencia en la tabla de rutas con la red de destino, el paquete se descartará.Veámoslo paso por paso más detalladamente. PC1 envía un paquete a PC2, ubicado en otra red.

  

Paso 1: PC 1 envía un paquete a PC2. Para ello PC1 compara su propia IP 172.10.1.2 y máscara con la IP y máscara de destino. PC1 llega a la conclusión de que el destino se encuentra en una red diferente por los que envía el paquete a la puerta de enlace, que en este caso es 172.10.1.1. La puerta de enlace tuvo que ser configurada manualmente en el PC o bien aprendida dinámicamente mediante DHCP.Paso 2: El paquete llega a la puerta de enlace que es la interfaz Fa0/1 del router R1. Lo primero que hace el router es examinar la cabecera del paquete IP y restarle 1 al campo TTL (time to live). Como ya sabemos este campo mide el número de saltos que puede hacer un paquete IP a lo largo de una red…Si el campo estuviera con valor 0, el router descartaría el paquete porque ya ese paquete IP no puede dar más saltos. En este caso el router resta uno a el valor del campo TTL. Después examina la dirección de destino y busca en su tabla de rutas el mejor camino para llegar a esa red, que en este caso es a través de el enlace serial Se0/1. El router envía el paquete a través de esa interfaz.Paso 3: El paquete llega a la interfaz Se0/1 del router R2 y el proceso es el mismo. Primero resta en uno el valor del campo TTL y luego examina la dirección de destino del paquete, busca en su tabla de rutas el mejor camino para llegar a esa red. Comprueba que la red está conectada directamente a través de su interfaz Fa0/0, así que envía el paquete a través de esa interfaz. El paquete llega a PC2.Los dispositivos capaces de enrutar tráfico usan varias tablas para poder llevar a cabo el enrutamiento, estás son: 

Ip routing table: Ya la hemos nombrado, es la tabla usada para determinar el camino más corto hacía la red de destino. En la tabla de rutas se guardan las redes remotas a las que se puede acceder y todos los caminos para poder llegar a dichas redes. Para una misma red remota pueden existir varios caminos. Se examina ésta tabla y se elige el camino más corto.

Layer 3 to Layer 2 mapping: Toda comunicación IP tiene que pasar por capa 2. Esta tabla lo que hace es asociar las MACs de cada dispositivo con la IP. En el ejemplo anterior R1 tendrá asociado a la IP 192.168.1.2 de R2 la MAC de la interfaz Se  0/1 de R2.

A parte de estas dos tablas los routers y switchs cisco usan una tecnología propia llamada CEF (Cisco express forwarding) que lo que hace es que el reenvío de paquete sea más rápido y eficiente, para ello CEF crea y usa dos tablas propias que son:

Forwarding Information Base (FIB): La tabal FIB contiene información de capa 3, es muy similar a la tabla de rutas pero aparte añade información como rutas multicast o host conectados directamente.

Adjacency table: Contiene la información necesaria por el router para crear los paquetes que van a ser enviados por cada una de sus interfaces.

 Comandos de ayuda para resolución de problemas de rounting básico:Lo primero que tenemos que hacer cuando hay algún problema de routing es comprobar en que punto de la comunicación está el problema, o lo que es lo mismo, averiguar que router no está reenviando el paquete como debería, para ello podemos hacer un traceroute desde el pc de origen y con la ip de destino y ver en que salto se está deteniendo el paquete, el salto en el que se detenga es el router que no está reenviando el paquete. Una vez en ese router, aparte de

comprobar la conexión en capa 1 (cablex etc..) y la configuración de la interfaz donde está el problema (ip, máscara, que no esté down…) podemos usar estos comandos que nos servirán de ayuda:

Show ip route: Muestra las rutas para llegar a las diferentes redes. Si nuestra red de destino no se encuentra en el listado tendremos que comprobar la configuración de protocolos de enrutamiento o crear la entrada manualmente con el comando ip route.

Show ip route [ip]: Muestra en pantalla la mejor ruta para llegar a la dirección IP especificada.

Show ip route [red] [máscara]: Muestra la mejor ruta para llegar a la red especificada. Show ip cef [ip]: Parecido al show ip route [ip], muestra la mejor ruta para llegar a esa

dirección IP, además el siguiente salto, IP de la interfaz de salida… Show ip cef [red] [máscara]: muestra información obtenía de la tabla fib para la mejor

ruta hacia la red que especifiquemos. Show ip arp: Muestra la tabla ARP del router donde se asocian las MACs con cada IP. Show frame-realy map: En redes frame relay muestra cada DLCI asociado con la IP del

siguiente salto. Repaso básico a EIGRP:EIGRP  (Enhanced Interior Gateway Protocol Routing Protocol), es un protocolo de enrutamiento dinámico el cual podemos usar en nuestra topología para que las diferentes redes configuradas en nuestros routers sean conocidas y accesibles desde cualquier punto de la red, sin tener que irlas configurando una por una en cada router. Resumiendo, los routers se comunican entre ellos y se envían automáticamente sus redes para que todos conozcan la topología, y así poder elegir las mejores rutas hacia los destinos que necesiten enrutar. Las características más significativas de EIGRP son:

Es un protocolo de vector distancia, aunque usa algunas características de estado de enlace como por ejemplo el no usar temporizadores.

Es un protocolo propietario de Cisco, por lo que en un entorno con routers de varias marcas, mejor usar otro protocolo como puede ser OSPF.

La distancia administrativa es de: 90 en EIGRP interno y de 170 en EIGRP externo. Admite VLSM. Admite un número máximo de saltos de 224 routers. La comunicación entre routers se hace a través de la dirección multicast 224.0.0.10,

aunque en muchas ocasiones se usa comunicación unicast. El protocolo de transporte usado en EIGRP es RTP. Es multiprotocolo, admite IP, IPX, AppleTalk… Mantiene 3 tipos de tablas: Tabla de vecinos, tabla de enrutamiento y tabla de

topología. La configuración básica de eigrp en un router se hace mediante los siguientes comandos:

R1(config)#router eigrp [asn]

Donde asn (número de sistema autónomo) hace referencia al proceso de eigrp que se ejecuta, para que dos routers puedan formar una adyacencia, deben tener configurado el mismo número de asn                R1(config-router)# network [red] [wildcard]

Por cada red que queramos publicar, aplicamos el comando network añadiendo la red a publicar y su wildcard (la inversa de la máscara de red).  Como se ha nombrado en las características, EIGRP soporta redes VLSM y por defecto se hace sumarización de rutas. Esto puede ser un problema cuando tengamos redes discontinuas dentro del mismo rango de red principal. Cuando nos encontremos con este problema debemos deshabilitar la sumarización automática con el comando no auto-summary.Otro aspecto a tener en cuenta es que EIGRP admite balanceo de carga en rutas con igual coste (usado por defecto) y en rutas de coste desigual (configurado manualmente) Para configurar el balanceo de carga con rutas de coste desigual se usa el comando variance [multiplicador] que lo que hace es multiplicar el coste de la mejor ruta por el número de queramos y de esa forma usar todas las rutas dentro del rango de ese coste. Por ejemplo, tenemos una ruta de coste 2000 y ejecutamos el comando variance 2 , lo que hace es multiplicar 2000*2 = 4000 por lo que conseguimos que se haga un balanceo de carga entre todas las rutas cuyo coste este en el rango de 2000 a 4000.  Comandos de ayuda para problemas con EIGRP:La resolución de problemas tanto en EIGRP como en cualquier aspecto se basa en recolectar toda la información posible del problema y buscar donde está el error. Recolectar información se hace básicamente con los comandos show y debug y para EIGRP estos son los más útiles: 

Show ip eigrp interfaces: Muestra todas las interfaces que están participando en eigrp excepto las configuradas como interfaces pasivas.

Show ip eigrp neighbors: Muestra los vecinos eigrp de ese router. Show ip eigrp topology: Muestra todas las rutas aprendidas mediante eigrp. Show ip route eigrp: Muestra las rutas de eigrp que se han agregado a la tabla de rutas. Debug ip routing: Muestra en tiempo real los cambios que se van realizando en la tabla

de rutas. Este comando no es específico de eigrp. Debug eigrp packets: Muestra en tiempo real los paquetes recibidos y enviados que

tengan que ver con el protocolo eigrp. Debug ip eigrp: Muestra en tiempo real todos los paquetes recibidos y enviados que

tengan que ver con el protocolo eigrp. 

CCNP TSHOOT: OSPF y Redistribución de rutas

En esta entrada haremos un breve repaso a los conceptos básicos de OSFP y la redistribución de rutas para luego centrarnos en los comandos útiles para obtener toda la información necesaria para la resolución de problemas… OSPF Como ya hemos visto en CCNA y CCNP Route, OSPF (Open shortest path first), es, al igual que eigrp, un protocolo de enrutamiento dinámico con el cual podemos hacer que los

diferentes routers de la topología intercambien y comuniquen sus redes de forma automática. Las características básicas de OSPF son: 

Usa el algoritmo de Diskjtra Para calcular las métricas, se basa en el estado del link (link state – LS). La métrica

total es la suma de todos los enlaces hasta el destino. Admite subredes y VLSM. Es un protocolo no propietario de cisco, por lo que es ideal para implantarlo en una

topología con routers de varios fabricantes. La distancia administrativa es de 110. Mensajes multicast a la dirección 224.0.0.5 Admite dos tipos de autenticación, en texto plano y usando md5. OSPF se configura mediante áreas. Pueden existir varias áreas de ospf dentro de una

misma topología, los routers que conectan varias aéreas se les llaman routers ABR. Para enviar actualizaciones OSPF usa un solo router, llamado router designado (DR),

teniendo a otro como respaldo, llamado Backup DR (BDR). El funcionamiento es el siguiente, todos los routers envía sus actualizaciones sólo al router BR, y este se encarga de hacérselas llegar a los demás routers, de esta forma se ahorra ancho de banda y se gana en seguridad.  Si el router BR cae, el BDR asume el papel de BR. Todos los demás routers asumen el rol de DR Other.

Cada router en OSPF tiene un ID, este ID es una IP que puede ser seleccionada de 3 formas, siguiendo el siguiente orden:

    1. La ip configurada con el comando router id [x.x.x.x] dentro de la configuración de OSPF. Si no se configura este parámetro….

    2. La ip más alta configurada en las interfaces loopback y que dichas interfaces estén operativas (up/up). Si no tenemos interfaces loopback configuradas o están caídas.

    3. La ip más alta configurada en cualquiera de las interfaces no loopback y que dichas interfaces estén up/up. 

          El router BR de un área será aquel que tenga el ID mayor (la ip más alta). La configuración básica de OSPF se hace con los siguientes comandos: 

R1(config)#router ospf [process-id]

Donde process-id (id de proceso) hace referencia al proceso de ospf que se ejecuta, no hace falta que los routers sean configurados con el mismo process- id para que formen adyacencia.                R1(config-router)# network [red] [wildcard] [area]

Por cada red que queramos publicar, aplicamos el comando network añadiendo la red a publicar y su wildcard (la inversa de la máscara de red).  Luego añadimos el área de ospf a la que formará parte esa red. Para que dos routers puedan formar una adyacencia tienen que tener configurada el mismo área. Para lograr un funcionamiento óptimo la estructura de datos de OSPF se basa en 4 tablas, que son las siguientes:

OSPF Interface table: Todas las interfaces de router configuradas para participar en OSPF están listadas en esta tabla.

OSPF Neighbor table: Todos los vecinos de OSPF de los que se han recibido paquetes hello están listados en esta tabla. Los vecinos son eliminados cuando se dejan de recibir paquetes hello y expira el tiempo configurado en “dead interval”.

OSPF Link-State database: En esta tabla se guarda la topología para cada una de las áreas de OSPF en las que participa el router, también guarda información sobre como enrutar tráfico hacía otra área o otros sistemas autónomos. Por cada área en la que participe el router existirá una tabla de estado de enlace. Todos los routers pertenecientes a la misma área tienen que tener exactamente la misma tabla de estado de enlace.

OSPF Rounting Information Base: Esta tabla, también llamada RIB, guarda el resultado más óptimo (el camino más corto) hacia cada ruta mediante los cálculos de OSPF (algoritmo Diskjtra).

De todas estas tablas, la que nos ofrece una información más comprensiva y de ayuda para la resolución de problemas es la tabla de Link-State ya que contiene la información de toda la topología del área. Tipos de Routers en OSPFA parte de los roles que tiene cada router en OSPF, que ya se han nombrado al principio y que son el DR (designated router) BDR (backup designated router) y DROther (el resto de routers) también se pueden definir qué tipo de router será cada uno dependiendo de la ubicación y áreas que conecte…estos son:

Internal Router: Router interno a algún área de OSPF, sólo perteneciente a esa área. Area Border Router (ABR): Un router que conecta con más de un área y por lo tanto

mantiene más de una tabla de estado de enlace. La principal función de este router es la de intercambiar información de topologías entre varias áreas.

Backbone Router: Todos los routers que pertenezcan al área  0  de OSPF (backbone área).

Autonomous system boundary router (ASBR): Es un router que tiene configurados y pertenece a varios protocolos de enrutamiento o sistemas autónomos e intercambia información de topología entre ellos.

 Veamos un ejemplo de tipos de los diferentes tipos de routers: 

 

¿Qué tipo de router será cada uno en la topología? 

R1 es un router Interno porque sólo pertenece a un área de OSPF, el área 1. R2 es un router ABR y backbone. ABR porque pertenece a dos áreas de OSPF y las

conecta entre sí, el área 1 y el área 0. También es Backbone porque pertenece al área 0.

R3 es un router Interno y backbone. Interno porque sólo pertenece al área  0 y backbone porque el área a la que pertenece es la backbone (área 0).

R4 es un router ASBR y backbone. ASBR porque pertenece a dos protocolos de enrutamiento diferentes y los interconecta, que son OSFP y EIGRP. Backbone porque pertenece al área 0 de OSPF.

R5 pertenece a EIGRP así que no se le define ningún tipo.  El intercambio de información entre routers de OSPF se hace mediante mensajes LSA, existen 7 tipos de mensajes LSA y dependiendo de la función y tipo de router enviará LSAs de un tipo o de otro. Los LSAs son un tema amplio y ya se han visto en el CCNP Route así que se dan por aprendidos.Por otro lado cuando los routers pertenecientes a OSPF forman una adyacencia (se hacen vecinos) lo hacen a través de paquetes hello, estos paquetes hello contienen información que debe ser exactamente igual en ambos router para que se forme la adyacencia, esto es importantísimo a la hora de la resolución de problemas, debemos comprobar que todos los parámetros de los paquetes hello de ambos routers sean iguales (si no están configurados en alguno o en ambos routers se toman los valores por defecto). Los parámetros que deben coincidir son: 

Hello Timer: Por defecto son 10 segundos para redes broadcast y 30 segundos para redes nonbroadcast.

Dead timer: Por defecto 40 segundos para redes broadcast y 120 para redes nonbroadcast.

Area Number: El número de área de OSPF debe ser el mismo en ambos routers. Area type: el área tiene que ser la misma (stub o nssa). Subnet: Ambos routers deben estar en la misma subred en redes broadcast,

nonbroadcast y point-to-multipoint. Sin embargo en redes point-to-point los routers pueden estar en subredes diferentes.

Authentication Information: Si la autenticación está configurada en un router, el router del otro extremo tiene que tener los mismos parámetros de autenticación.

 Durante el proceso de formar una adyacencia con algún vecino los routers pasan por varios estados, a la hora de resolución de problemas comprobar el estado en el que se encuentra el router también es un paso importante ya que nos ayuda a saber en que punto de la comunicación está fallando el proceso. Los estados por los que se pasa para formar una adyacencia son:

 

Estado Significado

Down No se han recibido hellos durante un tiempo mayor que el intervalo dead. Por lo tanto el vecino esta caído.

Attemp Estado del router normalente cuando se configura el comando “neighbor”, y ha enviado el mensaje hello pero aún no ha recibido respuesta.

Init Se ha recicibido el hello del vecino pero se está analizando el contenido para ver si se puede formar una adyacencia. Este estado es permanente cuando dos vecinos se intercambian hellos pero no pueden formar adyacencia (requisitos para formar adyacencia ya se han

mencionado).

2Way Se ha verificado el mensaje hello y pueden formar adyacencia.

ExStart Los vecinos estan negociando la secuencia de intercambio de DD y quién sera el maestro y quién esclavo.

Exchange Cuando ya empiezan a intercambiar paquetes DD.

Loading Todos los paquetes DD se han enviado y ahora intercambiando mensajes LSR, LSU u LSAck. Cada router va rellenando su tabla de link state con las entradas que va recibiendo

del vecino y que no tenía anteriormente.

Full Se ha completado la adyacencia y ambos vecinos tienen exactamente la misma base de datos LSDB.

  Por último recordar que OSPF utiliza 4 tipos de redes, dependiendo de las características de cada red OSPF operará de una forma u otra. Los tipos de redes en OSPF y las características de cada una son: Tipo de Red Características

Broadcast Red OSPF por defecto en interfaces LAN

Los vecinos son descubiertos

automáticamente.

Los routers tienen que pertenecer a la misma

subred

Usa un router designado (DR)

Nonbroadcast Red OSPF por defecto en interfaces serial

Frame Relay

Los vecinos se configuran

manualmente

Routers tienen que estar en la misma

subred

Usa un router designado (DR)

Point-to-Point Red OSPF por defecto en interfaces serial non-Frame Relay

Solo los routers de ambos extremos del

link forman adyacencia

Cada enlace point-to-point pertenece a redes

diferentes

No usan un router designado

Point-to-Multipoint Puede ser configurado en cualquier interfaz

Los vecinos se determinana

automáticamente

Router tienen que estar en la misma subred

No usan un router designado

  Comandos para la resolución de problemas en OSPF Hecho el repaso a los conceptos básicos de OSPF veamos los comandos útiles para recolectar información en busca de errores. 

Show ip ospf interface brief: Muestra un resumen de todas las interfaces que participan en OSPF.

Show ip ospf neighbor: Muestra el estado de los vecinos  aprendidos desde una interfaz activa de OSPF.

Show ip osfp database: Muestra la tabla de link-state. Show ip ospf staistics: Muestra cada cuanta frecuencia se ejecuta el algoritmo SPF. Debug ip ospf monitor: Muestra información en tiempo real cuando el algoritmo

SPF se ejecuta. Debug ip routing: Muestra en tiempo real las actualizaciones que va sufriendo la

tabla de rutas. Este comando no es específico de ospf. Show ip route OSPF: Muestra en pantalla las rutas aprendidas desde OSPF que se

han añadido a la tabla de rutas. Debug ip ospf packet: Muestra los paquetes recibidos que tengan que ver con

OSPF en tiempo real. Debug ip ospf adj: Muestra información en tiempo real sobre adyacencias en

OSPF. Debug ip ospf events: Muestra información en tiempo real sobre paquetes OSFP,

incluyendo los paquetes hello y las LSAs. Show ip ospf virtual-links: Da información sobre el estado de los link virtuales en

OSPF.  Redistribución de rutasLa redistribución de rutas consiste en importar rutas desde un dominio de enrutamiento a otro diferente, en otras palabras, que un protocolo pueda aprender rutas importadas de otro protocolo diferente, por ejemplo que una red con EIGRP importe rutas de otra red que usa OSPF, o viceversa.  Los motivos por los que es necesario usar la redistribución de rutas pueden ser por ejemplo:

Dos empresas que se unen, una con una red OSPF y otra con una red EIGRP. Dos empresas que se unen, usando el mismo protocolo pero diferente configuración.

Por ejemplo, dos empresas con EIGRP, una usa el asn 5 y otra el asn 30. En una misma compañía, redes divididas, cada una con un protocolo (sobre todo en

empresas grandes). Para permitir operabilidad entre diferentes fabricantes (por ejemplo EIGRP, que es

propietario Cisco, con OSPF). Conexiones entre empresas socias.

 Para que la redistribución de rutas se pueda llevar a cabo, se debe cumplir lo siguiente… 1.-  Que el router donde lo configuremos tenga al menos una conexión física con cada dominio de enrutamiento.2.- Que el router donde lo configuremos tenga configurado ambos protocolos de enrutamiento. Por ejemplo… 

La métrica que se asigna a una ruta que es inyectada dentro de otro dominio de enrutamiento recibe el nombre de “seed metric”. Esta métrica es necesaria para comunicar con fiabilidad rutas entre diferentes protocolos, para configurar la “seed metric” se puede hacer de tres formas: 

Con el comando default-metric Con el parámetro metric del comando redistribute Creando un route-map

 Si la seed metric no es configurada se coge el valor por defecto pero hay que tener cuidado con esto, ya que el valor por defecto para redes RIP y EIGRP es de inalcanzable, por lo que si no configuramos la seed metric para redes rip y eigrp éstas no serán accesibles. Posibles problemas con la redistribución de rutas:Algunos pasos recomendables a seguir cuando nos encontremos con problemas en la redistribución de rutas son: 

Protocolo de enrutamiento de origen: Si alguna ruta no está siendo redistribuida de un protocolo a otro lo primero que tenemos que hacer es fijarnos si esa ruta ha sido aprendida por el protocolo de origen y si está en la tabla de rutas del router que la tiene que distribuir. Si no es así debemos centrarnos en porqué ese protocolo no está aprendiendo esa ruta.

Configuración de la redistribución: Si la ruta ha sido aprendida por el protocolo pero aún así no se está redistribuyendo debemos fijarnos en la configuración de la redistribución. Esto implica comprobar la métrica que se ha aplicado en la redistribución, comprobar que el número de sistema autónomo o ID de proceso es el correcto y si existe algún filtro (como por ejemplo alguna ACL, route-map etc…) que esté bloqueando la redistribución.

Protocolo de enrutamiento de destino: Si la ruta ha sido redistribuida pero aún así no ha sido aprendida por los routers vecinos tenemos que fijarnos en el protocolo de destino, comprobar con el comando debug si la está recibiendo, con los comandos show si se está aprendiendo pero no añadiendo a la tabla de rutas etc… También hay que tener en cuenta que la ruta aprendida es marcada como ruta externa.

  

Comandos útiles para resolución de problemas en la redistribución :  Para recolectar la información necesaria en caso de problemas con la redistribución de rutas usamos los comandos propios de los protocolos que estemos redistribuyendo, por ejemplo los comandos show y debug de OSPF (listados un poco más arriba) o los de EIGRP. A parte debemos tener muy claro que protocolos vamos a redistribuir y asegurarnos que el número de sistema autónomo o ID de proceso de OSPF que estamos indicando en la redistribución son los correctos. Con un “show run | begin router” tendremos en pantalla la configuración de los protocolos de enrutamiento y de la redistribución.Es muy importante recordar configurar la métrica y que cuando importemos rutas de eigrp a otro protocolo por ejemplo OSPF añadir el parámetro subnets al comando redistribute.