CCNP TSHOOT: Introduccin 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 slo cuando algn problema es reportado, ya sea por algn usuario o por falla de algn dispositivo/enlace etc. Este mtodo de mantenimiento es llamado interrupt-driven, y como es evidente, no es el ms recomendable usarlo. Un buen mantenimiento se lleva a cabo ejecutando regularmente tareas programadas en la red, por ejemplo copias de seguridad de archivos de configuracin e imgenes IOS, o actualizaciones de software. Tareas que no son urgentes pero s importantes son las que debemos programar para ejecutar regularmente. Este segundo mtodo 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 tamao, organizacin, objetivos, prioridades, trfico etc. Por lo tanto cada red tendr sus propios requisitos de mantenimiento. Sin embargo, algunas tareas deberan ser imprescindibles en todo mantenimiento, algunos ejemplos son: Instalacin y configuracin de hardware y software. Solucin 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 polticas de la empresa. Asegurar la red de amenazas internos y externos. Interrupt-Driven vs structured tasks Como ya se ha mencionado al inicio, el mantenimiento de redes se divide en dos categoras: interrupt-driven y structured tasks. Con interrupt-driven lo que hacemos es resolver los problemas cuando estos sean avisados por algn usuario de la red. Por ejemplo, un usuario que llama quejndose 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 trfico y las condiciones en la que est la red, dar mayor seguridad y rendimiento a la red, reducir de forma considerable las cadas de la red, conocer el estado de todos los dispositivos, planear de forma ms eficiente futuros cambios en la red, y lo que es ms importante, reducir de forma considerable los tiempos de resolucin de averas cuando las haya. Usar el modelo Structured tasks tambin implica utilizar el modelo interrupt-driven, ya que aunque llevemos un buen mantenimiento de la red es inevitable que se produzca algn fallo o cada (sobre todo en redes grandes). Lo que si nos aseguramos es tener un menor nmero de problemas reportados y que dichos problemas reportados sean solucionados ms rpidamente. Modelos de Mantenimiento de la Red

Como 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 ms conocidos y usados son: FCAPS: Es un modelo de mantenimiento de redes definido por ISO que se basa en 5 categoras, Fault management, Configuration management, Accounting management, Performance management y Security management. ITIL: El mtodo IT Infrastructure Library (ITIL) define las mejores prcticas y recomendaciones para trabajar en equipo y lograr objetivos. TMN: Ms orientada al sector de las telecomunicaciones (ITU-T) es una variacin 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. Tambin 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 configuracin, mientras que las que s que hace falta una respuesta inmediata, como puede ser una cada de un router o switch principal deben tener una prioridad urgente: Los procedimientos ms comunes y que deberan formar parte de todas las redes son: Cambios en la configuracin: las redes de produccin estn 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 configuracin, en el software/hardware etc. Este proceso tambin es conocido como mover, aadir 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 tambin es una tarea imprescindible. Copias de Seguridad: Hacer copias de seguridad de archivos de configuracin e imgenes IOS, con el fin de que en caso de fallo del dispositivo, la recuperacin sea muchsimo ms rpida. 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 aaden caractersticas nuevas. Monitorizar el rendimiento de la red: Monitorizar tanto el trfico como los dispositivos (uso de memoria, cpu etc.) nos ayuda a reconocer cualquier posible problema y solucionarlo antes de que se produzca. Documentacin de la red: La documentacin influye directamente sobre los tiempos de resolucin y de localizacin de un problema. En una red bien documentada estos tiempos son muy inferiores comparados con los de una red que no lo est. La documentacin de la red normalmente se crea durante el diseo inicial y montaje de la red, sin embargo, es prioritario que se mantenga actualizada cada vez que se produzca algn cambio en la red, por pequeo que sea. Los elementos ms importantes en la documentacin de red son:

 Diagrama de topologa lgica: Un diagrama que incluya las interconexiones de los diferentes segmentos de red, protocolos usados. Diagrama de topologa fsico: Diagrama que incluya cmo las diferentes reas fsicas de la red se interconectan, indicando donde se encuentra situado fsicamente 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 ubicacin exacta dentro de la red. Asignaciones de IP: Documentar todas las IPs de gestin y las consideradas importantes. Por ejemplo, ips de gestin de switchs/routers, ips de interfaces de routers, ips de servidores, ips de puntos de acceso etc. Informacin de la configuracin: Tener documentada la configuracin de cada dispositivo y mantenerla actualizada ante cualquier cambio. Cuando se vaya a realizar un cambio en la configuracin es importante primero realizar una copia de seguridad de la configuracin actual para luego proceder al cambio, de esta forma si algo falla se puede volver al estado anterior de forma rpida. Mantener una copia de los documentos originales: Mantener una copia de la documentacin 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 bsicas para el mantenimiento de una red Una 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 resolucin 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. An as, sin recurrir a ningn software adicional podemos encontrar herramientas fundamentales de mantenimiento en la CLI de los dispositivos cisco. Las herramientas de la CLI ms bsicas son: Comandos show y debug: Los comandos show y debug ofrecen gran cantidad de informacin que nos ayuda a la resolucin de problemas, por ejemplo, con show podemos ver el estado de todo lo que tengamos configurado en el dispositivo, por ejemplo interfaces, archivos de configuracin, 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 estn enviando y recibiendo para cierta comunicacin (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 envan 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 recuperacin.

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 configuracin de forma manual o programada, adems, 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 ms usados para ste propsito es poco recomendable ya que no admite autenticacin y los datos viajan en texto plano. FTP y HTTP s admiten autenticacin, aunque los datos tambin viajan en texto plano, mientras que con HTTPS o SCP podemos configurar autenticacin y adems los datos viajarn cifrados.
La sintaxis de copy es la siguiente: copy [archivo a copiar] [protocolo://usuario:contrasea@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 autenticacin, en este caso el usuario es cisco1 y el password ciscopass1. Si el protocolo a usar es FTP y con autenticacin, cada vez que introduzcamos el comando copy deberemos poner el usuario y contrasea, si siempre usamos el mismo usuario y contrasea podemos configurarlo para guardarlo en la configuracin 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 configuracin 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 contrasea, que al tenerlo guardado en la configuracin, lo usar automticamente. Siguiendo el ejemplo anterior, el comando a usar sera copy startup-config ftp://192.168.1.30. Como vemos, el comando copy nos ayuda a hacer copias de archivos de configuracin o imgenes IOS de forma manual, pero y si queremos que se ejecuten las copias de forma automtica. Para ello la CLI de cisco nos ofrece el comando archive, que ejecutado desde el modo de configuracin global nos lleva a un sub-modo de configuracin donde debemos especificar los parmetros 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 autenticacin cisco1, ciscopass1. R1-config es el nombre con el que se guardarn los archivos, al ser copias peridicas, y para que no se sobreescriban, a este nombre se le va aadiendo una numeracin, 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 timeperiod, si en el dispositivo se ejecuta un copy run start, automticamente 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, todava faltaran 440 minutos para hacer la siguiente copia, pero si hacemos algn cambio de configuracin 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 aadiendo o eliminando los cambios necesarios. Esto es importante ya que con configure replace NO reemplazamos el archivo, slo 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 nmero 3, sera: 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 nmero, 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 almacenndolos en la memoria del dispositivo y otra guardndolos en un servidor syslog. Almacenarlos en el dispositivo implica un gasto de memoria y recursos innecesarios, adems, al ser la memoria limitada, cuando se llega al lmite 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 mximo de memoria a usar para logs, una vez llegado al mximo, los logs mas antiguos se sobreescribirn. Los logs son una fuente inmejorable de deteccin y resolucin de problemas, pero a veces tambin 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 muchsimos 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 slo tenemos que aadir al comando el nivel desde el cual queremos que se guarden. Indicar un nivel implica que los niveles de mas seguridad tambin sern guardados, por ejemplo si indicamos el nivel 4, los logs de los niveles 3,2,1 y 0 tambin sern guardados. Un ejemplo de guardar logs en la memoria del dispositivo sera: R1(config)#logging buffered 4096 warnings El ejemplo indica que se usaran 4 megas de RAM para guardar logs y que se guardarn a partir del nivel 4, es decir, los niveles 0, 1, 2,3 y 4 Otra forma ms usual y lgica 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 muchsimo mayor, a parte, tendremos todos los logs de todos los dispositivos de la red en el mismo servidor, lo que crea una administracin centralizada. El comando de configuracin de dispositivos cisco para el envo de logs a un servidor es bastante sencillo, logging [ip servidor], y para seleccionar el nivel desde el cual queremos que se enven los logs lo hacemos con el comando logging trap [nivel], desde el modo de configuracin 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 acte como NTP, y luego configurar los dispositivos de la red con el comando ntp server [ip servidor], desde el modo de configuracin global, por ejemplo. R1(config)# ntp server 192.168.1.40

CCNP TSHOOT: Introduccin a los procesos de resolucin de problemas de red

La resolucin de problemas o troubleshooting se puede definir como el proceso de respuesta a un problema reportado, diagnosticando dicho problema y dndole una solucin. Como es de imaginar es una tarea implcita en las responsabilidades de un administrador de red. Los

problemas normalmente son el resultado de un error humano (por ejemplo un error en configuracin), fallo de dispositivos, un error en el software (bug) o por patrones de trfico (por ejemplo ataque DDOS). Estos problemas pueden ser resueltos de diferentes maneras, es ms, cada administrador tendr sus formas de resolucin. Lo que si es recomendable es seguir siempre el mismo mtodo cuando surja un problema, ya que nos ayudar a resolverlo de manera ms eficiente y rpida. Lo primero que debemos hacer cuando se nos presenta un problema es aclarar lo que est pasando, obtener una definicin clara del error, luego obtener toda la informacin necesaria y que nos sea til. Con estos datos ya podemos formular hiptesis 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 solucin temporal hasta que el que el problema pueda ser reparado correctamente. Resumiendo, los pasos principales a seguir en la resolucin de problemas son: 1.- Reporte del problema. 2.-Diagnstico del problema, donde se incluye recolectar informacin, examinar la informacin recolectada, eliminar posibles causas y crear hiptesis sobre la posible causa del problema. 3.- Resolver el problema. Mtodos de resolucin de problemas ms usados Los mtodos ms 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 mtodo diferente. Los 6 mtodos ms comunes son: Mtodo Top-Down Mtodo Bottom-Up Mtodo Divide and Conquer Mtodo Following the traffic Path Mtodo Comparing Configurations Mtodo Component Swapping Mtodo Top-Down Con ste mtodo lo que hacemos es empezar a buscar el problema en la capa 7, aplicacin, e ir desplazndonos hacia abajo en las capas del modelo OSI hasta dar con la capa donde reside el problema. La teora de este modelo dice que desde que encuentres una capa que funcione completamente quiere decir que todas las capas inferiores tambin estn 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 tambin funcionan correctamente. Por lo contrario, si el ping falla nos desplazamos una capa ms abajo para seguir buscando el problema, en este caso en la capa 2.

Mtodo Bottom-Up Con Bottom-Up lo que hacemos es lo contrario que con Top-Down, es decir, comenzamos con la bsqueda del problema desde la capa 1 hacia arriba. Este mtodo es menos efectivo en redes grandes, ya que comenzar testeando la capa 1 en estas redes lleva demasiado tiempo.

Mtodo Divide and Conquer Divide and Conquer se basa en una mezcla entre Top-Down y Bottom-Up ya que se teora dice que debemos empezar a testear en una capa intermedia y luego dependiendo de los resultados movernos haca 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 estn 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.

Mtodo Following the Traffic Path

Como su nombre indica este mtodo consiste en seguir el enlace de un problema reportado hasta dar con el problema. Por ejemplo. Un usuario reporta un problema de conexin 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, comprobramos el enlace del router con el switch que conecta con el servidory as sucesivamente hasta dar con el problema.

Mtodo Comparing Configurations Es el mtodo que consiste en comparar configuraciones para ver dnde est el error. Por ejemplo, dos routers conectados por una VPN, en un extremo falla la VPN y no sabemos porqueUsando este mtodo compararemos la configuracin del router que est funcionando bien con la del router que est fallando en busca de diferencias. Dejando la configuracin igual en los dos extremos probablemente se solucione el problema. Este mtodo es usado a menudo por administradores de red con poca experiencia en resolucin de problemas. Mtodo Component Swapping El ltimo mtodo consiste en el cambio de componentes para localizar el problema. Cambiando componentes se puede llegar a la conclusin de que el error estaba en el componente reemplazado. Por ejemplo, un equipo est conectado a un switch y no tiene conectividad. Usando este mtodo lo primero que haramos sera cambiar el cable que conecta el ordenador con el switch, si el error continua, el siguiente paso sera conectar el cable a otro puerto del switch, por si acaso el error estuviera en el puerto. Si an as el error contina, habra que probar con otro ordenador, por si acaso el error estuviera en el ordenador y as sucesivamente hasta dar con el problema. Este mtodo slo es conveniente usarlo cuando estemos seguros que el error es debido a algn componente fsico y no de configuracin etc. Ejercicio prctico sobre el uso de mtodos de resolucin. 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 tenan acceso. Los otros 24 pcs conectan a Internet sin problema. Resolviendo el problema desde los diferentes mtodos. Top-Down: Como la capa de aplicacin funciona correctamente en algunos pcs situados en la misma localizacin (los 24 que si tienen acceso), este mtodo no sera muy efectivo usar en este caso. An as, es posible que la conexin 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: Basndonos en los sntomas, 24 pcs no funcionan, es muy probable que sean los 24 que conectan a un mismo switch por lo que empezar con ste mtodo (que comienza en la capa fsica) sera una buena opcin. Divide and Conquer: Puede ser una buena opcin comenzar con este mtodo, 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 llevara demasiado tiempo y sera poco efectivo. En este caso es mejor comenzar con otros mtodos e ir eliminando posibles causas del error. An as es posible que usando ste mtodo 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: Sera un buen mtodo a seguir en el caso de que los 24 pcs que fallan estn 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 mtodos resuelve el error es posible que tengamos que usar este. Como el fallo fue de un da 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 resolucin de problemas Al principio nombrbamos los pasos principales en la resolucin del problema, que recordndolos son: reporte del problema, diagnstico del problema y resolucin del problema. El reporte del problema es simplemente el aviso de algn usuario indicando una incidencia, ya sea va telefnica, va web, personalmente etc. En muchas ocasiones la informacin suministrada por el usuario ser insuficiente, como por ejemplo una incidencia reportada como La red esta cada. En estos casos deberemos llamar a dicho usuario y pedirle ms detalles sobre el error que tiene, una vez la incidencia est totalmente aclarada pasaremos al siguiente paso... El diagnstico del problema se divide en varias fases, que incluyen: Recolectar informacin: Obtener informacin sobre los dispositivos de la red donde pueda estar el problema. Esta informacin normalmente se obtiene con los comandos show y/o debug. Examinar la informacin recolectada: Hacer una evaluacin de los datos obtenidos con el show y debug en busca de posibles causas del error. Eliminar posibles causas: Basndose 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 hiptesis: Basndose en los resultados, formular hiptesis sobre cual o cuales pueden ser las causas del error. Verificar hiptesis: De las hiptesis formuladas, seleccionar la o las que ms se acerquen al problema para centrarnos en ellas.

 Teniendo ya las posibles causas aclaradas, debemos centrarnos en solucionar el problema. Si una hiptesis no soluciona el problema, se deshacen los cambios y se busca otra hiptesis, y as sucesivamente hasta dar con la solucin. Una vez solucionado, documentarlo y hacer una copia de seguridad de la antigua y la nueva configuracin. Tambin debemos informar a las personas implicadas que el problema ha sido resuelto (usuario, jefe, compaerosy en algunas ocasiones otros departamentos a los que tambin les afectaba el problema). Establecer una lnea base Un punto importante en la resolucin de problemas es la de establecer una lnea 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 lnea 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 resolucin de problemas

Despus de que un problema haya sido claramente definido, el siguiente paso en el diagnstico es el de recolectar la informacin necesaria. Esta tarea es de las que ms tiempo consume en el proceso de la resolucin del problema, por lo que la habilidad para recolectar la informacin apropiada nos ayudar a resolver el problema con mayor rapidez. El comando ms til en cisco para recolectar informacin es el show, sin embargo el resultado de muchas de las opciones que nos ofrece producen una gran cantidad de informacin la cual nos puede hacer demorar tiempo buscando la informacin que realmente necesitamos. Por ejemplo, con un show processes cpu obtenemos este resultado.

Como vemos se genera una lista de aproximadamente 180 lneas (puede ser mucho mayor dependiendo de los procesos que tengamos cargados en el dispositivo), sin embargo, slo nos interesa saber qu cantidad de cpu est usando el proceso llamado Check heaps Buscar ese proceso entre las 180 lneas nos llevar un tiempo, que podemos acortar considerablemente si pudiramos indicar slo el proceso que buscamos. Para esto podemos usar el comando include [texto] que indica que slo se muestre en pantalla las lneas 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 slo nos muestre las lneas donde aparezca la palabra Check heaps, que es el proceso que buscamos, ganando as bastante tiempo para la resolucin del problema. En otras ocasiones lo que nos interesar ser excluir algunas lneas del resultado generado por el show, para ello usaremos el comando exclude [texto], lo que har que no se muestren en pantalla las lneas 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 slo las interfaces con IP asignada, podemos usar el comando exclude para conseguirlo, indicando que no se muestren las lneas 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 configuracin base de cada dispositivo en la documentacin, ganaremos muchsimo mas tiempo exportando los resultados a un fichero que copiando y pegando en todos los dispositivos. Mirndolo por el lado de resolucin de problemas, enviar un debug a un fichero de texto nos ayudar bastante a analizarlo mejor ya que entre otras cosas podemos hacer bsquedas de algn texto especfico. Para usar esta caracterstica tenemos que aadir 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 adems 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 red Si con los comandos show o debug no conseguimos obtener toda la informacin necesaria para resolver un problema sera buena idea usar un capturador de paquetes para as poder

analizar con ms detalle lo que est pasando. Podemos usar como capturador de paquetes algn servidor dedicado a ello o algn PC con algn 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 comunicacin queremos capturar los paquetes ya que si el capturador de paquetes y el pc se encuentran en el mismo switch se configurar un mtodo llamado SPAN, pero si se encuentran en diferentes swichts se configurar otro mtodo llamado RSPAN. La idea principal es que se enve una copia de todos los paquetes tanto enviados como recibidos en un puerto hacia el puerto donde est conectado el capturador de paquetes. Usando SPAN SPAN es usado cuando queremos que se enve una copia de todos los paquetes que se envan y reciben de un puerto del switch haca otro puerto del mismo switch, donde tendremos conectado el capturador de paquetes. Por ejemplo, queremos capturar el todo el trfico 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 trfico que pase por el/ellos. Para hacerlo usamos el comando monitor session [id] source interface [interface] , desde el modo de configuracin global. ID indica un nmero de identificacin, 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 trfico de el/los puertos origen, con el comando monitor session [id] destination interface [interface] , desde el modo de configuracin global. Se debe configurar el mismo ID que en el paso 1. Volviendo al ejemplo de la imagen anterior, la configuracin sera la siguiente. SW1(config)# monitor session 1 source interface Gi 0/1 SW1(config)# monitor session 1 destination interface Gi 0/3 Usando RSPAN RSPAN tiene la misma finalidad que SPAN, con la diferencia de que el capturador de paquetes y el equipo del que queremos capturar estn conectados en switchs diferentes, por lo que la configuracin tambin cambia. En este caso tendremos que configurar una VLAN en

cada switch, y configurar los switchs para que en uno la copia del trfico se enve a travs de la VLAN, y en el otro, donde estar conectado el capturador de paquetes, se reciba el trfico en esa VLAN. Vemoslo 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 1 1.- Crear una VLAN que usaremos para enviar la copia de paquetes al switch 2, con el comando vlan [num], desde el modo de configuracin 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 configuracin de la VLAN. 3.- Indicar el puerto origen (donde conecta el servidor) del cual se copiar todo el trfico, con el comando monitor session [id] source interface [interface], desde el modo de configuracin global. 4.- Indicar el destino del trfico 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 configuracin 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 2 1.- 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 configuracin 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 configuracin 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 configuracin 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 configuracin global. Con todo esto, la configuracin de RSPAN en ambos switchs quedara 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: Resolucin de problemas bsicos en Switchs Cisco

Como ya sabemos los switchs son dispositivos de capa 2 encargados del reenvo de tramas a los dispositivos que conectan con l. En esta entrada veremos problemas bsicos 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 reenvan por todos sus puertos creando as un solo dominio de colisin y por lo tanto aumentando las posibilidades de colisin entre diferentes tramas. Cuando ocurre una colisin 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 reenvan slo por el puerto que conecta con esa MAC, creando as un dominio de colisin 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 reenva la trama por el puerto al que est asociado esa MAC, pero que pasa cuando un switch an 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 reenva la trama por todos los puertos excepto por el puerto que la recibi. Una vez reenviada, si existe algn dispositivo con esa MAC, obtendr la

respuesta de esa trama a travs de un determinado puerto. El Switch entonces asocia su MAC Adress Table esa MAC con ese puerto. La prxima trama que llegue con esa MAC ser reenviada directamente a ese puerto. Vemoslo con un ejemplo paso por paso. PC 1 quiere iniciar una sesin Telnet con Server, sin embargo el switchs no han rellenado an su Tabla de MACs. El proceso sera el siguiente Paso 1: Para iniciar una sesin Telnet, PC1 enva una solicitud de ARP a la IP del servidor, ya que PC1 no conoce la MAC del servidor y es necesaria para la comunicacin.

Paso 2: El switch recibe la trama de PC 1 a travs de la interfaz Gi 0/1. Como el switch an 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. Despus reenva 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 slo el server responder a la solicitud ya que la direccin 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 slo por la interfaz Gi0/1. Si el switch no tuviera asociada esa MAC a ningn puerto, lo reenviara 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 comunicacin entre ellos a partir de ahora ser directamente a travs de los puertos Gi0/1 y Gi0/5, sin tener que reenviar paquetes de esta comunicacin a los dems puertos.

Nota: Cuando el switch reciba algn paquete del PC2 y PC3 asociar sus MACs a los puertos donde estn conectados. Completando as su tabla de MACs. Una vez entendido el procedimiento de cmo se rellena la Tabla de MACs en un Switch cuando tengamos que resolver un problema relacionado con la capa 2 nos ser ms fcil identificar el problema, debiendo considerar alguna de las siguientes 3 causas: Problemas con el hardware: Algn cable daado o mal grimpado, algn puerto del switch daado. Configuracin de VLANs: Para que dos VLANs diferentes se puedan comunicar, el trfico debe ser enrutado. Si dos dispositivos que pertenecen a la misma VLAN no se pueden comunicar habra que comprobar la configuracin de los puertos a los que se

conectan, comprobar que el switch est aprendiendo bien las MACs de los dispositivos y si hay algn enlace trunk entre los dos dispositivos, comprobar que est configurado para transportar esa VLAN. Configuracin 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 ms probable es que el error se encuentre en el trunk. Comprobar que ambos extremos del trunk usan la misma encapsulacin (802.1q o ISL), que ambos extremos usan la misma VLAN nativa y que se est permitiendo el trfico de esa VLAN a travs del trunk. Comandos bsicos de resolucin de problemas en un Switch Algunos comandos bsicos que nos ayudarn a resolver o nos mostrarn informacin relevante sobre problemas de conectividad en un Switch son: Clear mac address-table dynamic: Borra todas las MAC aprendidas dinmicamente 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 algn dispositivo conectado a algn puerto no tenga comunicacin 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 dinmicamente, asocindolas 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 estn permitida en dichos trunks. Show interfaces switchport: Muestra un resumen con informacin de tos puertos del switch, incluyendo informacin 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 topologa 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 estarn 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 topologa 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 tambin 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, slo 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 ms bajo ser el elegido como root bridge. Si existe ms de un switch con el mismo valor BID, se elegir al que tenga la MAC ms baja en cualquiera de sus interfaces. Nonroot Brigde: Son todos los switchs restantes en la topologa STP. Los puertos que conectan cada enlace entre switchs tambin tendrn 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 ms cercano (basado en el coste de los enlaces) al root bridge. En otras palabras, es el puerto cuya velocidad de transmisin sea la ms rpida para llegar hasta el root bridge (la velocidad de transmisin 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 numeracin ms baja (ver ejemplo). Designated Port: Son los puertos de cada segmento de red con el coste ms bajo hasta el root bridge. Es decir, de cada enlace entre dos switchs slo un puerto actuar como designated port, y es el que tenga el coste ms 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 envan ni reciben trfico 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 algn cambio en la topologa y hay que activar un puerto no designado se activara 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 topologa), Listening (el puerto permanece en escucha durante 15 segundos, durante este tiempo enva 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 10 Mb (ethernet) 100Mb (Fast Ethernet) 1 Gbps (Gigabit ethernet) 10 Gbps (Ten gigabit ethernet) Coste STP

100 19
4 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 actuarn 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 numeracin sea ms 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 nmero 1 est enviando y recibiendo trfico con normalidad porque un puerto est actuando como root port y otro como puerto designado (por lo tanto ningn puerto est bloqueado). Si no se bloqueara ningn puerto en el segmento de red nmero 2 se crearan 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 actuarn 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 portsi recordamos el root port es el puerto cuyo coste hasta el root bridge sea el menor. El segmento de red nmero 1 tiene un coste de 100 porque es un enlace ethernet, mientras que el segmento nmero 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 razn 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 comunicacin. 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 ms fcil con un ejemplo. Vemoslo paso por paso con un ejemplo sencillo: Paso 1: El PC 1 enva un paquete a PC2 en una red con enlaces redundantes y sin STP configurado. El paquete llega a ambos switchs y stos aaden 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 travs de sus enlaces Gi0/2, al no tener STP configurado ninguno de estos puertos se bloquea por lo tanto cuando SW1 reenve el paquete a travs 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. Adems 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 enva 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 reenvan siempre por todos los puertos, los paquetes se irn 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. Vemoslo con un ejemplo.

Paso 1: El PC1 enva 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 reenvan por todos los puertos excepto por el que lo recibi. En este caso SW1 lo reenva por el puerto Gi0/2, lo que implica que el paquete le llegar a PC2 y SW2. Lo mismo hace SW2, reenva el paquete por su interfaz Gi0/2 y el paquete le llegar a PC2 y SW2. Adems 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 reenvan por todos sus puertos. En este caso SW1 lo reenva por Gi0/1 haciendo que el paquete llegue a SW2 y al PC1. Mientras, SW2 tambin reenva el paquete

por su interfaz Gi0/2, lo que hace que llegue a SW1 y PC1. Adems el paquete llegar duplicado a PC1. Loop creado: Llegados a este punto se repetiran 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 lgico a travs de varios enlaces fsicos. 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 lgico, fsicamente 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 ms rpido de lo que nos ofrecera un solo enlace. En el funcionamiento de STP los etherchannels funcionan como un solo puerto lgico, y aunque tambin ofrezcan redundancia, no es posible que se creen loops de enrutamiento entre los diferentes puertos fsicos que forman el etherchannel. Cuando nos encontremos con problemas con los etherchannels deberemos comprobar los siguientes aspectos: Configuraciones de puertos desiguales: La configuracin de los puertos que forman el etherchannel debe ser idntica en ambos switchs, por ejemplo, todos los puertos deben tener la misma velocidad, modo de duplex, configuracin de trunk y vlans nativas. Configuracin desigual del etherchannel: Los switchs que formen el etherchannel deben ser configurados con el mismo protocolo de negociacin de etherchannel, que debe ser LACP o PAgP. En el CCNP Tshoot se hace un breve repaso a los conceptos bsicos 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 informacin necesaria para reparar los errores que como ya hemos visto es a travs 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 mdulos (CCNPR o CCNPS).

CCNP TSHOOT: Ejercicio Troubleshooting STP

En los ejercicios de troubleshooting se nos presenta una topologa de red y se nos reporta una incidencia que debemos resolver. Para resolverla primero compararemos la configuracin base con la configuracin actual usando los comandos show y debug, los cuales nos darn la informacin necesaria para localizar el problema. Una vez localizado, solucionarlo con los comandos de configuracin aprendidos en CCNA, CCNPR o CCNPS.

Topologa

Incidencia: Los usuarios de la red 192.168.1.0 /24 estn experimentando mucha latencia cuando intentan acceder a la red 10.1.2.0 /24. Haciendo un seguimiento del trfico 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 prdidas de paquetes y altos niveles de condensacin de trfico, por lo que se decide investigar el problema en los enlaces entre los switchs. PASO 1: Comprobar la configuracin Base de la Red Toda red bien documentada tiene que tener una configuracin base. La configuracin base es la configuracin inicial de la red, antes de que se haya aplicado cualquier cambio y cuando todo funcionaba correctamente. Configuracin Base de SW2 (BaseLine):

Configuracin Base de SW1 (BaseLine):

Comprobando la configuracin 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 acta 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 etcque tienen el mismo valor en ambos switchs. sta es la configuracin de cuando la red funcionaba correctamente. Ahora entramos a buscar el problema actual. PASO 2: Analizar la configuracin actual de los switchs Habiendo analizado y entendido la configuracin base de los switchs procedemos a conectarnos al SW1 para comprobar la configuracin actual y nada ms conectarnos a la consola del SW1 nos aparece este mensaje.

Slo con este mensaje ya nos podemos hacer una idea de donde est el error ya que nos indica que varias MACS estn 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 configuracin 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 configuracin 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 configuracin 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 topologa 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 estn 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 configuracin base de ambos switchs y la configuracin actual y nos dimos cuenta del problema que haba en la red. Ahora slo hay que solucionarlo. Para ello debemos crear la instancia de STP para la VLAN 1 en ambos switchs.

PASO 4: Comprobar la nueva configuracin Una vez hayamos aplicado la nueva configuracin para resolver el problema debemos comprobar que esa configuracin se ha aplicado correctamente y con los resultados que nosotros buscbamos. 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 configuracin que hemos aplicado ha creado una instancia en STP para la VLAN1. Con esto logramos bloquear un puerto de los redundantes, ms 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: Resolucin de problemas avanzados en Switchs Cisco

Anteriormente analizbamos como resolver problemas bsicos 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 ms y analizaremos los problemas ms frecuentes de capa 3 que nos podemos encontrar en switchs, veremos el enrutado entre vlans, la redundancia en ruteo y la lgica de los switchs multicapa para poder enrutar paquetes Enrutado entre VLANs Para que dos VLANs diferentes se puedan comunicar tiene que haber algn dispositivo capaz de enrutar trfico, ya que las vlans no comparten el mismo rango de red. Como hemos visto en entradas anteriores enrutar trfico entre dos vlans se puede hacer de dos formas, o bien a travs de un router creando sub-interfaces (una por cada vlan) o bien a travs de un switch de capa 3 (o multicapa) creando interfaces virtuales. Hagamos un repaso rpido a los dos mtodos para luego ver los posibles problemas con los que nos podamos encontrar Enrutamiento de vlans a travs de un router Para enrutar vlans a travs de un router lo que tenemos que hacer es conectar el switch que tiene las vlans con una interfaz de un router a travs de un enlace trunk (recordamos que el trunk es capaz de transportar todas las vlans que queramos). Luego en la interfaz del router habra que configurar una sub-interfaz por cada vlan que queramos enrutar. Por ejemplo si queremos enrutar dos vlans, crearemos dos sub-interfaces. Vemoslo con un ejemplo.

Paso 1: PC1 pertenece a la VLAN 100 y enva un paquete a PC 2, que pertenece a la VLAN 200. PC1 enva 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 reenva a travs de su enlace trunk hacia el router. Paso 2: El router mira la direccin de destino del paquete, examina su tabla de rutas y comprueba que debe reenviarlo a travs de su interfaz Fa0/1.200. Este paquete ya sale etiquetado como vlan 200 (debido a la configuracin que hemos puesto en la interfaz). Paso 3: El paquete llega al switch etiquetado como VLAN 200 y el switch lo reenva 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 slo en Switchs de capa 3. Enrutamiento de vlans a travs de un Switch de capa 3: Los switchs de capa 3 o multicapa tienen la capacidad de enrutar trfico 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 trfico de dos formas, creando puertos de ruteo, que son puertos fsicos 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 lgico 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 enva un paquete a PC 2, que pertenece a la VLAN 200. PC1 enva 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 direccin de destino del paquete, examina su tabla de rutas y comprueba que debe reenviarlo a travs de su interfaz virtual SVI VLAN 200. Este paquete ya sale etiquetado como vlan 200. Paso 3: El paquete llega al PC2. Configuracin 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 estaran enrutadas a travs de un switch de capa 3. Como hemos nombrado antes, estos switchs tambin tienen la capacidad de trfico a travs de puertos fsicos habilitados para ello. Estos puertos desde que se configuran para operar en capa 3 pierden todas las caractersticas 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 configuracin 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 algn firewall. Por ejemplo.

En el ejemplo vemos una red con un router que es usado para la conexin a Internet, un firewall que examina todo el trfico 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 funcin es la de enrutar trfico, comunicar diferentes rangos de red, por lo tanto slo trabajaran en capa 3pero.porque hacerlo a travs de un switch de capa 3 y no de un router? No es lo mismo? S, las funciones son las mismas, funcionara perfectamente con un router, pero la velocidad no sera la misma. Los switchs de capa 3 enrutan a travs de hardware, ms concretamente gracias a unos circuitos integrados en cada puerto llamados ASIC, mientras que los routers lo hacen a travs de software. La diferencia entre uno y otro es que la velocidad de enrutamiento es muchsimo ms rpido a travs de hardware, por lo tanto el rendimiento y capacidad de la red aumentan usando un switch de capa 3. El inconveniente es que son muchsimo ms caros que un router. Por ltimo nombrar que los switchs catalyst de capa 3 toman sus decisiones de ruteo en base a una tecnologa 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. Bsicamente 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 informacin 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 matemtico bastante rpido para tomar decisiones de enrutamiento. La tabla cef se puede visualizar con el comando show ip cef La tabla de adyacencias con el comando show adjacency Mientras 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 slo tenemos que crear interfaces virtuales y asignarles una IP dentro del rango de la VLAN, mientras que para activar un puerto como routed port slo tenemos que aplicar el comando no switchport en la configuracin del puerto. An 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 podrn comunicar con los equipos de otra vlan. Una interfaz virtual se considera en estado down cuando ninguno de los puertos asociados a su vlan estn activos, es decir, cuando no existe ningn puerto con la misma vlan o estn cados por cualquier razn.

 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 direccin IP a la cual se enviarn los paquetes. El PC enva el paquete a esa direccin IP, que ser un dispositivo capaz de enrutar trfico, este dispositivo ya se encarga de enrutar el paquete hacia su destino. Las puertas de enlace son un punto crtico en una red, la mayora de las redes slo tienen un dispositivo que acta como puerta de enlace, por lo que si ese dispositivo cae sea cual sea la razn, ningn equipo que use esa puerta de enlace tendr conexin 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 llevndose a cabo, sin necesidad de hacer ningn cambio en la configuracin 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 slo 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 acte 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 ningn cambio de configuracin 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 slo 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 acta 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 ningn router se convertir en activo aquel que tenga la IP ms alta configurada en su interfaz. HSRP se configura dentro del modo de configuracin de la interfaz, dicha interfaz tendr una IP configurada para la interfaz fsica y otra IP virtual que ser la usada por HSRP. Para configurarlo se usa el comando standby [parmetros], una configuracin bsica incluye los siguientes parmetros: 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 nmero (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 ms alta que los dems routers, actuar como router activo. standby [grupo] preempt: el parmetro preempt se suele usar en el router que marquemos como activo e indica que si el router cae por la razn 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 fsico. Configuracin 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 configuracin actual Router 1 tomara 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. Adems si el router uno dejara de ser activo por lo que sea, cuando vuelva a estar operativo volvera 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 envan mensajes hello cada 3 segundos. Si el router en standby no recibe algn hello por parte del router activo

espera 10 segundos y si pasados esos 10 segundos an no ha recibido ningn hello el router standby da por cado 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 ms rpida. Si despus de la cada del router activo ste vuelve a estar operativo y adems tiene el preempt configurado el router enva 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 anteriorEl 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 enva 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 comunicacin en la red este router tambin tiene que tener una MAC, que como es lgico tambin ser virtual. La MAC no la configuramos manualmente, ya que se crea de forma automtica y est basada en el nmero de grupo que configuremos en HSRP. Todas las MACs de routers virtuales pertenecientes a HSRP siguen ste patrn. Los 6 primeros dgitos hexadecimales corresponden al cdigo de vendedor. Cada vendedor de router tendr un cdigo asignado para usar en HSRP, por ejemplo, Cisco: 0000.0c Los 4 siguientes dgitos corresponden a un cdigo establecido para HSRP, estos 4 dgitos siempre sern los mismos en todas las direcciones MAC de HSRPA sea cual sea el vendedor: 07.ac Los dos ltimos dgitos corresponden al nmero 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.ac0a 0000.0c: Cdigo vendedor. 07. ac: Cdigo HSRP. 0a: El grupo 10 en hexadecimal. Posibles problemas con HSRP: Cuando nos encontremos con problemas en HSRP tenemos que comprobar la configuracin y tener bien claro que router est actuando como router activo, qu router o routers tienen configurada la opcin 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 direccin y que la MAC es la correcta haciendo un arp a en cualquier equipo de la red. Teniendo estos datos delante usaremos comandos de verificacin para ver dnde est el error, los comandos ms tiles y de ayuda para la resolucin de problemas en HSRP son:

 show standby brief: Muestra en pantalla informacin sobre la configuracin 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 informacin de HSRP de una determinada interfaz. Estado, IP virtual, preempt, y tambin 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 estndar. En HSRP se pueden configurar 16 grupos como mximo, en VRRP 255. HSRP usa un switch como activo y otro como standby, VRRP usa un switch como master, y todos los dems como backups. Los tiempos de hello y holdtime son ms cortos en VRRP. VRRP soporta encriptacin en la autenticacin (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 clculo 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 clculo, 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 tambin 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 usarn 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 direccin IP de la puerta de enlace, cada equipo obtendr una direccin MAC diferente, por lo tanto enviarn los paquetes a la misma direccin IP pero diferente Router. Por ejemplo, tenemos 3 router (A, B y C) y 3 equipos. Los 3 routers estn 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 envan la solicitud de ARP a la ip virtual, slo se encarga de responder un router, el que tenga el rol de AVG (Active virtual gateway) (comparndolo 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 tendrn el rol de AVF (active virtual forwarder). Y qu pasa si el AVG se cae? Al igual que con HSRP otro router tomara su rol, es decir, un AVF pasara a ser AVG y la mac virtual que usaba el router cado? Tambin la usa el router que toma su rol. Usara 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 topologa de red y se nos reporta una incidencia que debemos resolver. Para resolverla primero compararemos la configuracin base con la configuracin actual usando los comandos show y debug, los cuales nos darn la informacin necesaria para localizar el problema. Una vez localizado, solucionarlo con los comandos de configuracin aprendidos en CCNA, CCNPR o CCNPS. Topologa

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 tena 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 configuracin Base de la Red

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

Configuracin Base de BB2 (BaseLine):

Examinando la configuracin 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 configuracin base funcionaba todo correctamente, sin embargo estudiando esta configuracin tambin nos podemos dar cuenta de donde est el posible error. El router BB1 no tiene configurada la opcin preempt, si recordamos preempt lo que hace es que si el router BB1 sufriera alguna cada al recuperarse volvera a tomar el rol de router activo. Con la configuracin actual si BB1 hubiera tenido alguna cada o micro cada BB2 tomara el rol de activo y cuando BB1 se recuperara NO volvera a tomar el rol de activo. PASO 2: Analizar la configuracin 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 cada o micro cada, lo que hizo que BB2 tomara el rol de router activo. Como BB2 no se ha cado y BB1 no tiene la opcin 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 tomara el rol de activo y cuando BB2 se recupere BB1 seguira siendo activo. La segunda opcin sera configurar la opcin preempt en el router BB1, lo que hara que automticamente tomara el rol de router activo ya que tiene una prioridad ms alta. Obviamente la segunda opcin es la ms lgica y recomendada as que procedemos a aplicarla y comprobar que efectivamente se han aplicado los cambios correctamente.

Como vemos, nada ms 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.An as hacemos un show standby brief para asegurarnos de que BB1 es ahora el router activo. Comprobamos que efectivamente lo es y adems de ahora en adelante si BB1 sufre una cada, cuando se recupere volver a tomar el rol de activo para el grupo 1 de HSRP.

CCNP TSHOOT: Introduccin a protocolos de enrutamiento - EIGRP

Todas las redes que estn compuestas por varias redes o subredes necesitan dispositivos capaces de enrutar trfico, esto es un router o un switch de capa 3 y para enrutar el trfico tienen que conocer las redes a las que pueden acceder. Para ello se pueden configurar todas las redes de forma esttica en cada dispositivo o configurarlo para que se transmitan las redes de forma dinmica mediante algn protocolo. En esta entrada repasaremos un poco el proceso de routing bsico junto con los comandos de ayuda para la resolucin de problemas, adems, repasaremos por encima el protocolo EIGRP junto con los comandos que ms nos ayudaran para la resolucin de problemas de este protocolo. Repasando el proceso de Routing Bsico Para que dos dispositivos pertenecientes a diferentes redes puedan comunicarse es necesario que dispositivos intermedios sean capaces de enrutar el trfico, estos dispositivos tienen que ser de capa 3 como un router o un switch de capa 3. Pero, Cmo se enruta el trfico? Pues fcil, cuando el paquete llega al router o switch multicapa ste comprueba la direccin 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. Vemoslo paso por paso ms detalladamente. PC1 enva un paquete a PC2, ubicado en otra red.

Paso 1: PC 1 enva un paquete a PC2. Para ello PC1 compara su propia IP 172.10.1.2 y mscara con la IP y mscara de destino. PC1 llega a la conclusin de que el destino se encuentra en una red diferente por los que enva 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 dinmicamente 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 nmero de saltos que puede hacer un paquete IP a lo largo de una redSi el campo estuviera con valor 0, el router descartara el paquete porque ya ese paquete IP no puede dar ms saltos. En este caso el router resta uno a el valor del campo TTL. Despus examina la direccin de destino y busca en su tabla de rutas el mejor camino para llegar a esa red, que en este caso es a travs de el enlace serial Se0/1. El router enva el paquete a travs 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 direccin 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 travs de su interfaz Fa0/0, as que enva el paquete a travs de esa interfaz. El paquete llega a PC2. Los dispositivos capaces de enrutar trfico usan varias tablas para poder llevar a cabo el enrutamiento, ests son: Ip routing table: Ya la hemos nombrado, es la tabla usada para determinar el camino ms corto haca 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 ms corto. Layer 3 to Layer 2 mapping: Toda comunicacin 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 tecnologa propia llamada CEF (Cisco express forwarding) que lo que hace es que el reenvo de paquete sea ms rpido y eficiente, para ello CEF crea y usa dos tablas propias que son: Forwarding Information Base (FIB): La tabal FIB contiene informacin de capa 3, es muy similar a la tabla de rutas pero aparte aade informacin como rutas multicast o host conectados directamente. Adjacency table: Contiene la informacin necesaria por el router para crear los paquetes que van a ser enviados por cada una de sus interfaces. Comandos de ayuda para resolucin de problemas de rounting bsico: Lo primero que tenemos que hacer cuando hay algn problema de routing es comprobar en que punto de la comunicacin est el problema, o lo que es lo mismo, averiguar que router no est reenviando el paquete como debera, 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 conexin en capa 1 (cablex etc..) y la configuracin de la interfaz donde est el problema (ip, mscara, que no est down) podemos usar estos comandos que nos servirn 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 configuracin 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 direccin IP especificada. Show ip route [red] [mscara]: 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 direccin IP, adems el siguiente salto, IP de la interfaz de salida Show ip cef [red] [mscara]: muestra informacin obtena 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 bsico a EIGRP: EIGRP (Enhanced Interior Gateway Protocol Routing Protocol), es un protocolo de enrutamiento dinmico el cual podemos usar en nuestra topologa 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 envan automticamente sus redes para que todos conozcan la topologa, y as poder elegir las mejores rutas hacia los destinos que necesiten enrutar. Las caractersticas ms significativas de EIGRP son: Es un protocolo de vector distancia, aunque usa algunas caractersticas 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 nmero mximo de saltos de 224 routers. La comunicacin entre routers se hace a travs de la direccin multicast 224.0.0.10, aunque en muchas ocasiones se usa comunicacin 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 topologa. La configuracin bsica de eigrp en un router se hace mediante los siguientes comandos: R1(config)#router eigrp [asn]

Donde asn (nmero de sistema autnomo) hace referencia al proceso de eigrp que se ejecuta, para que dos routers puedan formar una adyacencia, deben tener configurado el mismo nmero de asn R1(config-router)# network [red] [wildcard] Por cada red que queramos publicar, aplicamos el comando network aadiendo la red a publicar y su wildcard (la inversa de la mscara de red). Como se ha nombrado en las caractersticas, EIGRP soporta redes VLSM y por defecto se hace sumarizacin 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 sumarizacin automtica 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 nmero 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 resolucin de problemas tanto en EIGRP como en cualquier aspecto se basa en recolectar toda la informacin posible del problema y buscar donde est el error. Recolectar informacin se hace bsicamente con los comandos show y debug y para EIGRP estos son los ms tiles: Show ip eigrp interfaces: Muestra todas las interfaces que estn 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 especfico 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 Redistribucin de rutas

En esta entrada haremos un breve repaso a los conceptos bsicos de OSFP y la redistribucin de rutas para luego centrarnos en los comandos tiles para obtener toda la informacin necesaria para la resolucin 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 dinmico con el cual podemos hacer que los diferentes routers de la topologa intercambien y comuniquen sus redes de forma automtica. Las caractersticas bsicas de OSPF son: Usa el algoritmo de Diskjtra Para calcular las mtricas, se basa en el estado del link (link state LS). La mtrica 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 topologa con routers de varios fabricantes. La distancia administrativa es de 110. Mensajes multicast a la direccin 224.0.0.5 Admite dos tipos de autenticacin, en texto plano y usando md5. OSPF se configura mediante reas. Pueden existir varias reas de ospf dentro de una misma topologa, los routers que conectan varias areas 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 enva sus actualizaciones slo al router BR, y este se encarga de hacrselas llegar a los dems 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 dems 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 configuracin de OSPF. Si no se configura este parmetro. 2. La ip ms alta configurada en las interfaces loopback y que dichas interfaces estn operativas (up/up). Si no tenemos interfaces loopback configuradas o estn cadas. 3. La ip ms alta configurada en cualquiera de las interfaces no loopback y que dichas interfaces estn up/up. El router BR de un rea ser aquel que tenga el ID mayor (la ip ms alta). La configuracin bsica 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 aadiendo la red a publicar y su wildcard (la inversa de la mscara de red). Luego aadimos 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 estn listadas en esta tabla. OSPF Neighbor table: Todos los vecinos de OSPF de los que se han recibido paquetes hello estn 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 topologa para cada una de las reas de OSPF en las que participa el router, tambin guarda informacin sobre como enrutar trfico haca otra rea o otros sistemas autnomos. 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, tambin llamada RIB, guarda el resultado ms ptimo (el camino ms corto) hacia cada ruta mediante los clculos de OSPF (algoritmo Diskjtra). De todas estas tablas, la que nos ofrece una informacin ms comprensiva y de ayuda para la resolucin de problemas es la tabla de Link-State ya que contiene la informacin de toda la topologa del rea. Tipos de Routers en OSPF A 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) tambin se pueden definir qu tipo de router ser cada uno dependiendo de la ubicacin y reas que conecteestos son: Internal Router: Router interno a algn rea de OSPF, slo perteneciente a esa rea. Area Border Router (ABR): Un router que conecta con ms de un rea y por lo tanto mantiene ms de una tabla de estado de enlace. La principal funcin de este router es la de intercambiar informacin de topologas 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 autnomos e intercambia informacin de topologa entre ellos. Veamos un ejemplo de tipos de los diferentes tipos de routers:

Qu tipo de router ser cada uno en la topologa? R1 es un router Interno porque slo 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. Tambin es Backbone porque pertenece al rea 0. R3 es un router Interno y backbone. Interno porque slo 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 ningn tipo. El intercambio de informacin entre routers de OSPF se hace mediante mensajes LSA, existen 7 tipos de mensajes LSA y dependiendo de la funcin 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 travs de paquetes hello, estos paquetes hello contienen informacin que debe ser exactamente igual en ambos router para que se forme la adyacencia, esto es importantsimo a la hora de la resolucin de problemas, debemos comprobar que todos los parmetros de los paquetes hello de ambos routers sean iguales (si no estn configurados en alguno o en ambos routers se toman los valores por defecto). Los parmetros 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 nmero 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 autenticacin est configurada en un router, el router del otro extremo tiene que tener los mismos parmetros de autenticacin. Durante el proceso de formar una adyacencia con algn vecino los routers pasan por varios estados, a la hora de resolucin de problemas comprobar el estado en el que se encuentra el router tambin es un paso importante ya que nos ayuda a saber en que punto de la comunicacin est fallando el proceso. Los estados por los que se pasa para formar una adyacencia son:

Estado Down Attemp

Significado No se han recibido hellos durante un tiempo mayor que el intervalo dead. Por lo tanto el vecino esta cado. Estado del router normalente cuando se configura el comando neighbor, y ha enviado el mensaje hello pero an no ha recibido respuesta. 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). Se ha verificado el mensaje hello y pueden formar adyacencia. Los vecinos estan negociando la secuencia de intercambio de DD y quin sera el maestro y quin esclavo. Cuando ya empiezan a intercambiar paquetes DD. 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 tena anteriormente. Se ha completado la adyacencia y ambos vecinos tienen exactamente la misma base de datos LSDB.

Init

2Way ExStart Exchange Loading

Full

Por ltimo recordar que OSPF utiliza 4 tipos de redes, dependiendo de las caractersticas de cada red OSPF operar de una forma u otra. Los tipos de redes en OSPF y las caractersticas de cada una son:
Tipo de Red Broadcast Nonbroadcast Caractersticas Red OSPF por defecto en Los vecinos son Los routers tienen que Usa un router designado interfaces LAN descubiertos pertenecer a la misma (DR) automticamente. subred Red OSPF por defecto en Los vecinos se Routers tienen que estar Usa un router designado interfaces serial Frame configuran manualmente en la misma subred (DR) Relay Red OSPF por defectoSolo en los routers de ambos Cada enlace point-to- No usan un router interfaces serial nonextremos del link forman point pertenece a redes designado Frame Relay adyacencia diferentes

Point-to-Point

Point-to-Multipoint Puede ser configurado en Los vecinos se Router tienen que estar No usan un router cualquier interfaz determinana en la misma subred designado automticamente

Comandos para la resolucin de problemas en OSPF Hecho el repaso a los conceptos bsicos de OSPF veamos los comandos tiles para recolectar informacin 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 informacin 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 especfico de ospf. Show ip route OSPF: Muestra en pantalla las rutas aprendidas desde OSPF que se han aadido 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 informacin en tiempo real sobre adyacencias en OSPF. Debug ip ospf events: Muestra informacin en tiempo real sobre paquetes OSFP, incluyendo los paquetes hello y las LSAs. Show ip ospf virtual-links: Da informacin sobre el estado de los link virtuales en OSPF. Redistribucin de rutas La redistribucin 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 redistribucin 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 configuracin. Por ejemplo, dos empresas con EIGRP, una usa el asn 5 y otra el asn 30. En una misma compaa, 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 redistribucin de rutas se pueda llevar a cabo, se debe cumplir lo siguiente 1.- Que el router donde lo configuremos tenga al menos una conexin fsica con cada dominio de enrutamiento. 2.- Que el router donde lo configuremos tenga configurado ambos protocolos de enrutamiento. Por ejemplo

La mtrica que se asigna a una ruta que es inyectada dentro de otro dominio de enrutamiento recibe el nombre de seed metric. Esta mtrica 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 parmetro 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 sern accesibles. Posibles problemas con la redistribucin de rutas: Algunos pasos recomendables a seguir cuando nos encontremos con problemas en la redistribucin 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. Configuracin de la redistribucin: Si la ruta ha sido aprendida por el protocolo pero an as no se est redistribuyendo debemos fijarnos en la configuracin de la redistribucin. Esto implica comprobar la mtrica que se ha aplicado en la redistribucin, comprobar que el nmero de sistema autnomo o ID de proceso es

el correcto y si existe algn filtro (como por ejemplo alguna ACL, route-map etc) que est bloqueando la redistribucin. Protocolo de enrutamiento de destino: Si la ruta ha sido redistribuida pero an 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 aadiendo a la tabla de rutas etc Tambin hay que tener en cuenta que la ruta aprendida es marcada como ruta externa.

Comandos tiles para resolucin de problemas en la redistribucin: Para recolectar la informacin necesaria en caso de problemas con la redistribucin de rutas usamos los comandos propios de los protocolos que estemos redistribuyendo, por ejemplo los comandos show y debug de OSPF (listados un poco ms arriba) o los de EIGRP. A parte debemos tener muy claro que protocolos vamos a redistribuir y asegurarnos que el nmero de sistema autnomo o ID de proceso de OSPF que estamos indicando en la redistribucin son los correctos. Con un show run | begin router tendremos en pantalla la configuracin de los protocolos de enrutamiento y de la redistribucin. Es muy importante recordar configurar la mtrica y que cuando importemos rutas de eigrp a otro protocolo por ejemplo OSPF aadir el parmetro subnets al comando redistribute.