Semestre 2 CCNA, Módulo 10

Módulo 11: Listas de control de acceso (ACL)

Descripción general

Los administradores de red deben buscar maneras de impedir el acceso no autorizado a la red, permitiendo al mismo tiempo el acceso de los usuarios internos a los servicios requeridos. Aunque las herramientas de seguridad, como por ejemplo: las contraseñas, equipos de callback y dispositivos de seguridad física, son de ayuda, a menudo carecen de la flexibilidad del filtrado básico de tráfico y de los controles específicos que la mayoría de los administradores prefieren. Por ejemplo, un administrador de red puede permitir que los usuarios tengan acceso a Internet, pero impedir a los usuarios externos el acceso telnet a la LAN.

Los routers ofrecen funciones del filtrado básico de tráfico, como el bloqueo del tráfico de Internet, mediante el uso de las listas de control de acceso (ACLs). Una ACL es una lista secuencial de sentencias de permiso o rechazo que se aplican a direcciones o protocolos de capa superior Este módulo introduce las ACL estándar y extendidas como medio de control del tráfico de red y explica de qué manera se utilizan las ACL como parte de una solución de seguridad.

Además, este capítulo incluye consejos, consideraciones, recomendaciones y pautas generales acerca del uso de las ACL e incluye los comandos y configuraciones necesarias para crear las ACL. Finalmente, brinda ejemplos de ACL estándar y extendidas y su aplicación en las interfaces del router.

Las ACL pueden ser tan simples como una sola línea destinada a permitir paquetes desde un host específico o pueden ser un conjunto de reglas y condiciones extremadamente complejas que definan el tráfico de forma precisa y modelen el funcionamiento de los procesos de los routers. Aunque muchos de los usos avanzados de las ACL exceden el alcance de este curso, este módulo ofrece detalles sobre las ACL estándar y extendida, su ubicación adecuada y algunas de las aplicaciones especiales de las mismas.

Los estudiantes que completen este módulo deberán ser capaces de:

* Describir las diferencias entre las ACL estándar y extendida.
* Explicar las reglas para establecer las ACL.
* Crear y aplicar las ACL nombradas.
* Describir las funciones de los firewalls.
* Utilizar las ACL para restringir el acceso a la terminal virtual.

11.1 Aspectos fundamentales de las listas de control de acceso

11.1.1 ¿Qué son las ACL?

Las ACL son listas de condiciones que se aplican al tráfico que viaja a través de la interfaz del router. Estas listas le informan al router qué tipo de paquetes aceptar o rechazar. La aceptación y rechazo se pueden basar en ciertas condiciones específicas. Las ACL permiten la administración del tráfico y aseguran el acceso hacia y desde una red.

Es posible crear ACL en todos los protocolos de red enrutados, por ejemplo: el Protocolo de Internet (IP) y el Intercambio de paquetes de internetwork (IPX). Las ACL se pueden configurar en el router para controlar el acceso a una red o subred.

Las ACL filtran el tráfico de red, controlando si los paquetes enrutados se envían o se bloquean en las interfaces del router. El router examina cada paquete y lo enviará o lo descartará, según las condiciones especificadas en la ACL. Algunos de los puntos de decisión de ACL son direcciones origen y destino, protocolos y números de puerto de capa superior.

Las ACL se definen según el protocolo, la dirección o el puerto. Para controlar el flujo de tráfico en una interfaz, se debe definir una ACL para cada protocolo habilitado en la interfaz. Las ACL controlan el tráfico en una dirección por vez, en una interfaz. Se necesita crear una ACL por separado para cada dirección, una para el tráfico entrante y otra para el saliente. Finalmente, cada interfaz puede contar con varios protocolos y direcciones definidas. Si el router tiene dos interfaces configuradas para IP, AppleTalk e IPX, se necesitan 12 ACLs separadas. Una ACL por cada protocolo, multiplicada por dos por dirección entrante y saliente, multiplicada por dos por el número de puertos.

Estas son las razones principales para crear las ACL:

* Limitar el tráfico de red y mejorar el rendimiento de la red. Al restringir el tráfico de video, por ejemplo, las ACL pueden reducir ampliamente la carga de la red y en consecuencia mejorar el rendimiento de la misma.
* Brindar control de flujo de tráfico. Las ACL pueden restringir el envío de las actualizaciones de enrutamiento. Si no se necesitan actualizaciones debido a las condiciones de la red, se preserva el ancho de banda.
* Proporcionar un nivel básico de seguridad para el acceso a la red. Por ejemplo, las ACL pueden permitir que un host acceda a una parte de la red y evitar que otro acceda a la misma área. Por ejemplo, al Host A se le permite el acceso a la red de Recursos Humanos, y al Host B se le niega el acceso a dicha red.
* Se debe decidir qué tipos de tráfico se envían o bloquean en las interfaces del router. Permitir que se enrute el tráfico de correo electrónico, pero bloquear todo el tráfico de telnet.
* Permitir que un administrador controle a cuáles áreas de la red puede acceder un cliente.
* Analizar ciertos hosts para permitir o denegar acceso a partes de una red. Otorgar o denegar permiso a los usuarios para acceder a ciertos tipos de archivos, tales como FTP o HTTP.

Si las ACL no están configuradas en el router, todos los paquetes que pasen a través del router tendrán acceso a todas las partes de la red.

11.1.2 Funcionamiento de las ACL

Una lista ACL es un grupo de sentencias que definen si se aceptan o rechazan los paquetes en interfaces entrantes o salientes. Estas decisiones se toman haciendo coincidir una sentencia de condición en una lista de acceso y luego realizando la acción de aceptación o rechazo definida en la sentencia.

El orden en el que se ubican las sentencias de la ACL es importante. El software Cisco IOS verifica si los paquetes cumplen cada sentencia de condición, en orden, desde la parte superior de la lista hacia abajo. Una vez que se encuentra una coincidencia, se lleva a cabo la acción de aceptar o rechazar y no se verifican otras sentencias ACL. Si una sentencia de condición que permite todo el tráfico está ubicada en la parte superior de la lista, no se verifica ninguna sentencia que esté por debajo.

Si se requieren más cantidad de sentencias de condición en una lista de acceso, se debe borrar y volver a crear toda la ACL con las nuevas sentencias de condición. Para que el proceso de revisión de una ACL sea más simple, es una buena idea utilizar un editor de textos como el Bloc de notas y pegar la ACL a la configuración del router.

El principio del proceso de comunicaciones es el mismo, ya sea que las ACL se usen o no. A medida que una trama ingresa a una interfaz, el router verifica si la dirección de Capa 2 concuerda o si es una trama de broadcast. Si se acepta la dirección de la trama, la información de la trama se elimina y el router busca una ACL en la interfaz entrante. Si existe una ACL, entonces se verifica si el paquete cumple o no las condiciones de la lista. Si el paquete cumple las condiciones, se lleva a cabo la acción de aceptar o rechazar el paquete. Si se acepta el paquete en la interfaz, se lo compara con las entradas de la tabla de enrutamiento para determinar la interfaz destino y conmutarlo a aquella interfaz. A continuación, el router verifica si la interfaz destino tiene una ACL. Si existe una ACL, se compara el paquete con las sentencias de la lista y si el paquete concuerda con una sentencia, se lleva a cabo la aceptación o el rechazo del paquete. Si no hay ACL o se acepta el paquete, el paquete se encapsula en el nuevo protocolo de Capa 2 y se envía por la interfaz hacia el dispositivo siguiente.

A manera de revisión, las sentencias de la ACL operan en orden secuencial lógico. Si se cumple una condición, el paquete se permite o deniega, y el resto de las sentencias de la ACL no se verifican. Si todas las sentencias ACL no tienen coincidencias, se coloca una sentencia implícita que dice deny any (denegar cualquiera) en el extremo de la lista por defecto. Aunque la línea deny any no sea visible como última línea de una ACL, está ahí y no permitirá que ningún paquete que no coincida con las líneas anteriores de la ACL sea aceptada. Cuando esté aprendiendo por primera vez cómo crear una ACL, es una buena práctica agregar el deny any al final de las ACL para reforzar la presencia dinámica de la prohibición implícita deny.

11.1.3 Creación de las ACL

Las ACL se crean en el modo de configuración global. Existen varias clases diferentes de ACLs: estándar, extendidas, IPX, AppleTalk, entre otras. Cuando configure las ACL en el router, cada ACL debe identificarse de forma única, asignándole un número. Este número identifica el tipo de lista de acceso creado y debe ubicarse dentro de un rango específico de números que es válido para ese tipo de lista.

Después de ingresar al modo de comando apropiado y que se decide el número de tipo de lista, el usuario ingresa sentencias de lista de acceso utilizando el comando access-list, seguida de los parámetros necesarios. Estando en el modo de comandos adecuado y definido el tipo de número de lista, el usuario tipea las condiciones usando el comando access-list seguido de los parámetros apropiados. Este es el primero de un proceso de dos pasos. El segundo paso consiste en asignar la lista a la interfaz apropiada.

En TCP/IP, las ACL se asignan a una o más interfaces y pueden filtrar el tráfico entrante o saliente, usando el comando ip access-group en el modo de configuración de interfaz. Al asignar una ACL a una interfaz, se debe especificar la ubicación entrante o saliente. Es posible establecer la dirección del filtro para verificar los paquetes que viajan hacia dentro o fuera de una interfaz. Para determinar si la ACL controla el tráfico entrante o saliente, el administrador de red necesita mirar las interfaces como si se observara desde dentro del router. Este es un concepto muy importante. Una lista de acceso entrante filtra el tráfico que entra por una interfaz y la lista de acceso saliente filtra el tráfico que sale por una interfaz. Después de crear una ACL numerada, se la debe asignar a una interfaz. Una ACL que contiene sentencias ACL numeradas no puede ser alterada. Se debe borrar utilizando el comando no access-listlist-number y entonces proceder a recrearla.

Es necesario utilizar estas reglas básicas a la hora de crear y aplicar las listas de acceso.

* Una lista de acceso por protocolo y por dirección.
* Se deben aplicar las listas de acceso estándar que se encuentran lo más cerca posible del destino.
* Se deben aplicar las listas de acceso extendidas que se encuentran lo más cerca posible del origen.
* Utilice la referencia de la interfaz entrante y saliente como si estuviera mirando el puerto desde adentro del router.
* Las sentencias se procesan de forma secuencial desde el principio de la lista hasta el final hasta que se encuentre una concordancia, si no se encuentra ninguna, se rechaza el paquete.
* Hay un deny any (denegar cualquiera)implícito al final de todas las listas de acceso. Esto no aparece en la lista de configuración.
* Las entradas de la lista de acceso deben realizar un filtro desde lo particular a lo general. Primero se deben denegar hosts específico y por último los grupos o filtros generales.
* Primero se examina la condición de concordancia. El permiso o rechazo se examina SÓLO si la concordancia es cierta.
* Nunca trabaje con una lista de acceso que se utiliza de forma activa.
* Utilice el editor de texto para crear comentarios que describan la lógica, luego complete las sentencias que realizan esa lógica.
* Siempre, las líneas nuevas se agregan al final de la lista de acceso. El comando no access-listx elimina toda la lista. No es posible agregar y quitar líneas de manera selectiva en las ACL numeradas.
* Una lista de acceso IP envía un mensaje ICMP llamado de host fuera de alcance al emisor del paquete rechazado y descarta el paquete en la papelera de bits.
* Se debe tener cuidado cuando se descarta una lista de acceso. Si la lista de acceso se aplica a una interfaz de producción y se la elimina, según sea la versión de IOS, puede haber una deny any (denegar cualquiera) por defecto aplicada a la interfaz, y se detiene todo el tráfico.
* Los filtros salientes no afectan al tráfico que se origina en el router local.

11.1.4 Función de la máscara wildcard

Una máscara wildcard es una cantidad de 32-bits que se divide en cuatro octetos. Una máscara wildcard se compara con una dirección IP. Los números uno y cero en la máscara se usan para identificar cómo tratar los bits de la dirección IP correspondientes. El término máscara wildcard es la denominación aplicada al proceso de comparación de bits de máscara y proviene de una analogía con el "wildcard" (comodín) que equivale a cualquier otro naipe en un juego de póquer. Las máscaras wildcard no guardan relación funcional con las máscaras de subred. Se utilizan con distintos propósitos y siguen distintas reglas. Las máscaras de subred y las máscaras de wildcard representan dos cosas distintas al compararse con una dirección IP. Las máscaras de subred usan unos y ceros binarios para identificar las porciones de red, de subred y de host de una dirección IP. Las máscaras de wildcard usan unos y ceros binarios para filtrar direcciones IP individuales o en grupos, permitiendo o rechazando el acceso a recursos según el valor de las mismas. La única similitud entre la máscara wildcard y la de subred es que ambas tienen 32 bits de longitud y se componen de unos y ceros.

Para evitar la confusión, se substituirán las X por 1 en los gráficos de máscaras wildcard. La máscara en la Figura se escribe como 0.0.255.255. Un cero significa que se deje pasar el valor para verificarlo. Las X (1) significan impedir que se compare el valor.

Durante el proceso de máscara wildcard, la dirección IP en la sentencia de la lista de acceso tiene la máscara wildcard aplicada a ella. Esto crea el valor de concordancia, que se utiliza para comparar y verificar si esta sentencia ACL debe procesar un paquete o enviarlo a la próxima sentencia para que se lo verifique. La segunda parte del proceso de ACL consiste en que toda dirección IP que una sentencia ACL en particular verifica, tiene la máscara wildcard de esa sentencia aplicada a ella. El resultado de la dirección IP y de la máscara debe ser igual al valor de concordancia de la ACL ACL Este proceso se ilustra en la animación de la Figura .

Hay dos palabras clave especiales que se utilizan en las ACL, las opciones any y host. Para explicarlo de forma sencilla, la opción any reemplaza la dirección IP con 0.0.0.0 y la máscara wildcard por 255.255.255.255. Esta opción concuerda con cualquier dirección con la que se la compare. La máscara 0.0.0.0 reemplaza la opción host. Esta máscara necesita todos los bits de la dirección ACL y la concordancia de dirección del paquete. Esta opción sólo concuerda con una dirección.

11.1.5 Verificación de las ACL

Existen varios comandos show que verifican el contenido y ubicación de las ACL en el router.

El comando show ip interface muestra información de la interfaz IP e indica si se ha establecido alguna ACL. El comando show access-lists muestra el contenido de todas las ACL en el router. Para ver una lista específica, agregue el nombre o número ACL como opción a este comando. El comando show running-config también revela las listas de acceso en el router y la información de asignación de interfaz.

Estos comandos show verifican los contenidos y ubicación de las listas. También se recomienda verificar las listas de acceso usando tráfico de ejemplo para asegurarse que la lógica de la lista de acceso sea correcta.

11.2 Listas de control de acceso (ACL)

11.2.1 ACL estándar

Las ACL estándar verifican la dirección origen de los paquetes IP que se deben enrutar. Con la comparación se permite o rechaza el acceso a todo un conjunto de protocolos, según las direcciones de red, subred y host. Por ejemplo, se verifican los paquetes que vienen en Fa0/0 para establecer la dirección origen y el protocolo. Si se les otorga el permiso, los paquetes se enrutan a través del router hacia una interfaz de salida. Si se les niega el permiso, se los descarta en la interfaz entrante.

En la versión 12.0.1 del IOS de Cisco, se usaron por primera vez números adicionales (1300 al 1999) para las ACLs estándar pudiendo así proveer un máximo posible de 798 ACLs estándar adicionales, a las cuales se les conoce como ACLs IP expandidas. (también entre 1300 y 1999 en IOS recientes) En la primera sentencia ACL, cabe notar que no hay máscara wildcard. En este caso donde no se ve ninguna lista, se utiliza la máscara por defecto, que es la 0.0.0.0. Esto significa que toda la dirección debe concordar o que esta línea en la ACL no aplica y el router debe buscar una concordancia en la línea siguiente de la ACL.

La sintaxis completa del comando ACL estándar es:

Router(config)#access-listaccess-list-number {deny | permit | remark} source [source-wildcard ] [log]

El uso de remark facilita el entendimiento de la lista de acceso. Cada remark está limitado a 100 caracteres. Por ejemplo, no es suficientemente claro cual es el propósito del siguiente comando:

access-list 1 permit 171.69.2.88

Es mucho mas fácil leer un comentario acerca de un comando para entender sus efectos, así como sigue:

access-list 1 remark Permit only Jones workstation through

access-list 1 permit 171.69.2.88

La forma no de este comando se utiliza para eliminar una ACL estándar. Ésta es la sintaxis:

Router(config)#no access-listaccess-list-number

El comando ip access-group relaciona una ACL existente a una interface:

Router(config)#ip access-group {access-list-number | access-list-name} {in | out}

La tabla muestra descripciones de los parámetros utilizados en esta sintaxis.

11.2.2 ACL extendidas

Las ACL extendidas se utilizan con más frecuencia que las ACL estándar porque ofrecen un mayor control. Las ACL extendidas verifican las direcciones de paquetes de origen y destino, y también los protocolos y números de puerto. Esto ofrece mayor flexibilidad para establecer qué verifica la ACL. Se puede permitir o rechazar el acceso de los paquetes según el lugar donde se originó el paquete y su destino así como el tipo de protocolo y direcciones de puerto. Una ACL extendida puede permitir el tráfico de correo electrónico de Fa0/0 a destinos específicos S0/0, al mismo tiempo que deniega la transferencia de archivos y la navegación en la red. Una vez descartados los paquetes, algunos protocolos devuelven un paquete al emisor, indicando que el destino era inalcanzable.

Es posible configurar múltiples sentencias en una sola ACL. Cada una de estas sentencias debe tener el mismo número de lista de acceso, para poder relacionar las sentencias con la misma ACL. Puede haber tanta cantidad de sentencias de condición como sean necesarias, siendo la única limitación la memoria disponible en el router. Por cierto, cuantas más sentencias se establezcan, mayor será la dificultad para comprender y administrar la ACL.

La sintaxis de una sentencia ACL extendida puede ser muy extensa y a menudo, se vuelve engorrosa en la ventana terminal. Las wildcards también tienen la opción de utilizar las palabras clave host o any en el comando.

Al final de la sentencia de la ACL extendida, se obtiene más precisión con un campo que especifica el Protocolo para el control de la transmisión (TCP) o el número de puerto del Protocolo de datagrama del usuario (UDP). Los números de Puerto conocidos parar TCP/IP se muestran en la Figura . Las operaciones lógicas pueden especificarse como igual (eq), desigual (neq), mayor a (gt) y menor a (lt) aquéllas que efectuarán las ACL extendidas en protocolos específicos. Las ACL extendidas utilizan el número de lista de acceso entre 100 y 199 (también entre 2000 y 2699 en IOS recientes).

El comando ip access-group enlaza una ACL extendida existente a una interfaz. Recuerde que sólo se permite una ACL por interfaz por protocolo por dirección . El formato del comando es:

Router(config-if)#ip access-group access-list-number {in | out}

11.2.3 ACL nombradas

Las ACL nombradas IP se introdujeron en el software Cisco IOS Versión 11.2, permitiendo que las ACL extendidas y estándar tuvieran nombres en lugar de números. Las ventajas que ofrece una lista de acceso nombrada son las siguientes:

* Identifica intuitivamente las ACL usando un nombre alfanumérico.
* El IOS no limita el número de las ACL nombradas que se pueden configurar.
* Las ACL nombradas tienen la capacidad de modificar las ACL sin tener que eliminarlas y luego reconfigurarlas. Cabe notar que las listas de acceso nombradas permiten eliminar sentencias pero sólo permiten que las sentencias se agreguen al final de la lista. Aún con las ACL nombradas, se recomienda utilizar un editor de textos para crearlas.

Tenga en cuenta lo siguiente antes de implementar las ACL nombradas:

Las ACL nombradas no son compatibles con las versiones de Cisco IOS anteriores a la versión 11.2.

No se puede utilizar el mismo nombre para varias ACL. Por ejemplo, no se permite da el nombre de George a ACL estándar y extendida.

Es importante conocer las listas de acceso nombradas debido a las ventajas antes mencionadas. Las operaciones de la lista de acceso avanzadas como las ACL nombradas se verán en el currículum CCNP.

Una ACL nombrada se crea con el comando ip access-list. Esto coloca al usuario en el modo de configuración de ACL. En el modo de configuración de ACL, especifique una o más condiciones que se permitan o rechacen. Esto determina si el paquete se envía o se descarta cuando hay concordancia con las sentencias de la ACL.

La configuración vista crea una ACL estándar llamada filtro de Internet y una ACL extendida llamada “grupo de marketing”. Esta figura también muestra como las listas de acceso nombradas se aplican a una interfaz.

11.2.4 Ubicación de las ACL

Las ACL se utilizan para controlar el tráfico, filtrando paquetes y eliminando el tráfico no deseado de la red. Otra consideración importante a tener en cuenta al implementar la ACL es dónde se ubica la lista de acceso. Si las ACL se colocan en el lugar correcto, no sólo es posible filtrar el tráfico sino también toda la red se hace más eficiente. Si se tiene que filtrar el tráfico, la ACL se debe colocar en un lugar donde mejore la eficiencia de forma significativa.

En la figura el administrador quiere denegar el tráfico telnet o FTP del segmento LAN Ethernet del Router A al segmento LAN Ethernet conmutado Fa0/1 en el Router D, y al mismo tiempo permitir otros tipos de tráfico. Hay varias maneras de cumplir con esta política. La recomendación es utilizar ACL extendida, especificando las direcciones origen y destino. Se coloca esta ACL extendida en el Router A. Entonces los paquetes no atraviesan la Ethernet del Router A, no atraviesan las interfaces seriales de los Routers B y C, y no entran al Router D. El tráfico con direcciones de origen y destino diferentes todavía puede permitirse.

La regla es colocar las ACL extendidas lo más cerca posible del origen del tráfico denegado. Las ACL estándar no especifican las direcciones destino, de modo que se deben colocar lo más cerca posible del destino. Por ejemplo, una ACL estándar se debe colocar en Fa0/0 del Router D para evitar el tráfico desde el Router A.

Un administrador solo puede colocar una lista de acceso en el dispositivo que controla. De este modo, la ubicación de la lista de acceso se determina según hasta dónde se extienda el control del administrador de la red.

11.2.5 Firewalls

Un firewall es una estructura arquitectónica que existe entre el usuario y el mundo exterior para proteger la red interna de los intrusos. En la mayoría de los casos, los intrusos provienen de la Internet mundial y de las miles de redes remotas que interconecta. Normalmente, un firewall de red se compone de varias máquinas diferentes que funcionan al mismo tiempo para impedir el acceso no deseado e ilegal.

En esta arquitectura, el router conectado a Internet, es decir el router exterior, obliga todo el tráfico entrante a pasar por el gateway de la aplicación. El router conectado a la red interna, es decir el router interior, acepta los paquetes provenientes sólo del gateway de aplicación. En efecto, el gateway controla la entrega de servicios basados en red que entran y salen de la red interna. Por ejemplo, sólo ciertos usuarios pueden estar autorizados a comunicarse con Internet o sólo a ciertas aplicaciones se les puede permitir establecer conexiones entre un host interior y exterior. Si la única aplicación que se permite es el correo electrónico, entonces sólo se permiten paquetes de correo electrónico a través del router. Esto protege el gateway de aplicación y evita que se supere su capacidad con paquetes que de otra manera se descartarían.

Se deben utilizar ACL en los routers firewall, que a menudo se sitúan entre la red interna y una red externa, como Internet. Esto permite el control del tráfico entrante o saliente de alguna parte específica de la red interna. El router firewall proporciona un punto de aislamiento, de manera que el resto de la estructura interna de la red no se vea afectada.

Se necesita configurar las ACL en routers fronterizos, que son aquellos situados en las fronteras de la red, para brindar mayor seguridad. Esto proporciona protección básica contra la red externa u otra parte menos controlada de la red, en un área más privada de la red. En estos routers fronterizos, es posible crear ACLs para cada protocolo de red configurado en las interfaces del router.

11.2.6 Cómo restringir el acceso de terminal virtual

Las listas de acceso extendidas y estándar se aplican a paquetes que viajan a través de un router. No están diseñadas para bloquear paquetes que se originan dentro del router. Una lista de acceso extendida Telnet saliente, por defecto no impide las sesiones Telnet iniciadas por el router.

Del mismo modo que hay puertos físicos o interfaces, como Fa0/0 y S0/0 en el router, también hay puertos virtuales. Estos puertos virtuales se denominan líneas VTY. Existen cinco líneas vty, numeradas del 0 al 4, como se observa en la figura . Por razones de seguridad, es posible negar o permitir, a los usuarios, el acceso a la terminal virtual del router, pero se les puede negar el acceso a destinos desde dicho router.

El objetivo de restringir el acceso vty es aumentar la seguridad de la red. También se logra el acceso a vty utilizando el protocolo Telnet para realizar una conexión no física con el router. Como resultado, hay solo un tipo de lista de acceso vty. Es necesario imponer idénticas restricciones a todas las líneas vty, ya que no es posible controlar a qué línea se conectará el usuario.

El proceso de creación de una lista de acceso vty es igual al descrito para una interfaz. Sin embargo, para aplicar la ACL a una línea terminal se necesita el comando access-class en vez del access-group.

Cuando configure las listas de acceso en las líneas vty tenga en consideración lo siguiente:

* Cuando controle el acceso a una interfaz, es posible utilizar un número o un nombre.
* Sólo se pueden aplicar listas de acceso numeradas a las líneas virtuales.
* Imponga restricciones idénticas a todas las líneas de terminal virtual, porque el usuario puede querer conectarse a cualquiera de ellas.

by sdominguez.com

Semestre 2 CCNA, Módulo 10

Módulo 10: TCP/IP intermedio

Descripción general

Los routers utilizan información de la dirección del Protocolo de Internet (IP) en un encabezado IP del paquete para determinar cuál es la interfaz hacia la que se conmutará el paquete para que llegue lo más cerca posible de su destino. Como IP no brinda ningún servicio que ayude a asegurar que el paquete realmente llegue a destino, se describe como un protocolo no confiable, no orientado a conexión que hace uso de entregas de mejor esfuerzo. Si los paquetes se descartan en la ruta, llegan en el orden incorrecto o se transmiten a una velocidad mayor a la que el receptor puede aceptar, IP, por si mismo, no puede corregir el problema. Para resolver los problemas, IP confía en el Protocolo de control de transmisión (TCP). Este módulo describe el TCP y sus funciones e introduce el UDP, otro importante protocolo de Capa 4.

Cada capa del modelo de networking de OSI cumple varias funciones. Estas funciones son independientes de las otras capas. Cada capa espera recibir servicios de la capa inferior y cada una provee ciertos servicios a su capa superior. Las capas de aplicación, presentación y de sesión del modelo OSI son todas parte de la capa de aplicación del modelo TCP/IP, acceden a los servicios de la capa de transporte a través de entidades lógicas llamadas puertos. Este módulo presenta el concepto de puertos y explica su fundamental importancia y la de los números de puerto en el networking con datos.

Los estudiantes que completen este módulo deberán ser capaces de:

* Describir TCP y sus funciones.
* Describir sincronización y control de flujo de TCP.
* Describir operación y procesos de UDP.
* Identificar los números de puerto comunes.
* Describir las múltiples conversaciones entre los host.
* Identificar los puertos que se utilizan para servicios y clientes.
* Describir la numeración de los puertos y los puertos conocidos.
* Comprender las diferencias y la relación entre las direcciones MAC, direcciones IP y los números de los puertos.

10.1 Operación del TCP

10.1.1 Operación del TCP

Las direcciones IP permiten el enrutamiento de los paquetes entre las redes. Sin embargo, IP no garantiza la entrega. La capa de transporte es responsable del transporte confiable y de la regulación del flujo de datos desde el origen hacia el destino. Esto se logra utilizando ventanas deslizantes y números de secuencia junto con un proceso de sincronización que garantiza que cada host se encuentra listo y desea comunicarse.

Para comprender la confiabilidad y el control de flujo, piense en un estudiante que ha estudiado un idioma extranjero durante un año. Ahora imagine que este estudiante visita un país donde se habla ese idioma. Durante las conversaciones, deberá pedirle a la gente que repita lo que ha dicho (para confiabilidad) y que hable despacio, para que pueda entender las palabras (control de flujo). La capa de transporte, la Capa 4 del modelo OSI, provee estos servicios a la capa 5 por medio de TCP.

10.1.2 Sincronización del intercambio de señales de 3 vías

TCP es un protocolo orientado a conexión. Antes de transmitir datos, los dos clientes que desean comunicarse deben llevar a cabo unproceso de sincronización para establecer una conexión virtual para cada sesión entre ellos. Este proceso de sincronización asegura que ambas partesestán listas para la transmisión y permite que los dispositivos determinen los númeors de la secuencia inicial de dicha sesión. Este proceso se llama saludo de tres vías, es un proceso de tres pasospara establecer una conexión virtual entre dos dispositivos. Es muy importante sbaer que este proceso lo inicia un cliente. Para establecer la sesión TCP, el cliente usa un puerto conocido del servicio que desea contactar.

En el paso uno, el cliente inicia la sincronización enviando un paquete SYN para iniciar la conexión. Esto incdica que el paquete tiene un Número secuancial Válido. El bit de SYN se encuentra en el campo de códigodel encabezado del segmento.

En el paso dos, el otro host recive el paquete, graba el Número Secuancial x del cliente, y responde con un Acuse de Recibo (ACK). El bit de control del ACK indica que el campo de Acuse de Recibo contiene un número válido. el ACK es un bit en el campop de código del encabezado del segmento TCP, y el número ACK es un campo de 32 bits en el mismo encabezado. Una vez hecha la conexión, la bandera de ACK se fija para todos los segmentos durante la sesión. El campo de Número de ACK contiene el siguiente Número Secuencial que se espera recibir (x + 1). El número ACK x + 1 significa que el host ya recibió todos los bytes incluyendo x, y espera recibir el byte x + 1. El host también inicia un regreso de sesión, esto incluye un segmento TCP con su propio Número Secuencial y bandera de sincronización.

En el paso tres, el host que inició la conversación responde con un Númeor de ACK de y + 1, el cual es el Número Secuencial del valor del Host B + 1. Esto indica que recibió el ACK anterior y finaliza el proceso de conexión para esta sesión.

Es importante entender que los números secuenciales inciales se usan sólo para comenzar la comunicaión entre dos dispositivos. Actúan como referencia entre los dos dispositivos. Dichos números le dan a cada host la posibilidad de mandar acuses de recibo.

10.1.3 Ataques de denegación de servicio

Esta página enseñará a los estudientes acerca de los ataque de negación de Servicio (DoS). Estos ataques están diseñados para denegar serviciosa host legítimos que tratan de establecer conexiones. Los ataques DoS son muy comunes entre hackers para anular las respuestas delos sistemas. Un tipo de DoS es el inundamiento de SYN o SYN flooding. SYN flooding explota el saludo de tres vías y causa que los dispositivos manden un ACK a direcciones origen que no completarán el saludo.

El saludo de tres vías empieza al mandar un paquete SYN, el cual incluye las IP origen y destino. Ambas direcciones se utilizan para mandar ACK.

Enun ataque DoS, el hacker inicia una sincronización SYN pero falsifica (hace spoof) la dirección IP. Spoofing es un término que se usa para falsificar algo, como una direción IP, para esconder la identidad de uno. En este caso, como la dirección origen del paquete se cambió a una que no existe y por lo tanto es inalcanzable, la sesión TCP se pone en espera hasta que el tiempo de conexión expira. Este estado de espera requiere que el dispositivo que está siendo atacado utilice recursos del sistema, tales como la memoria, hasta que el contador de la conexión se acaba. Los Hackers inundan el host que están atacando con peticiones de sincronización (SYN) falsas para usar todos lso recursos de la conexión y evitar que respondan, logrando una conexión legítima con diche respuesta.

Para defenderse de estos ataques, los administradores del sistema pueden reducir el período de espera de desconexión y aumentar el tamaño de la cola de conexión. También existe software que puede detectar estos tipos de ataques e iniciar medidas de defensa.

10.1.4 Uso de ventanas y tamaño de las ventanas

A menudo, la cantidad de datos que se necesita transmitir es demasiado grande como para ser enviada en un solo segmento de datos. En este caso, los datos deben dividirse en porciones de menor tamaño para permitir su correcta transmisión. TCP tiene la responsabilidad de dividir los datos en segmentos. Esto se puede comparar con la forma en que son alimentados los niños pequeños. Su comida se corta en pedazos más pequeños que sus bocas pueden acomodar. Además, es posible que las máquinas receptoras no sean capaces de recibir datos con la rapidez que el origen los envía, tal vez, porque el dispositivo receptor está ocupado con otras tareas o porque el transmisor simplemente es un dispositivo más robusto.

Una vez segmentados los datos, deben transmitirse hacia el dispositivo destino. Uno de los servicios que provee TCP es el control de flujo que regula la cantidad de datos enviada durante un período de transmisión dado. Este proceso de control de flujo se conoce como uso de ventanas.

El tamaño del a ventana determina la cantidad de datos que se pueden transmitir simultáneamente antes que el destino responda con un Acuse de recibo (ACK). Después que un host transmita el tamañode ventana en bytes, el host debe recibir un ACK indicando que la información se recibió antes de poder enviar más información. Por ejemplo, si la ventana es de 1, se debe generar un ACK por cada byte antes de enviar el siguiente .

TCP usa las ventanas para determinar de forma dinámica el tamaño de la transmisión. Los dispositivos negociasn el tamaño de la ventana a un número específico de bytes para transmitir antes del ACK .

Este proceso de variación dinámica del tamaño de la ventana incrementa la confiabilidad. El tamaño de la ventana se puede basar en los ACKs.

10.1.5 Números de secuencia

TCP divide los datos en segmentos. Los segmentos de datos viajan entonces desde el transmisor hacia el receptor después del proceso de sincronización y la negociación del tamaño de ventana que dicta el número de bytes que es posible transmitir por vez. Los segmentos de datos que se transmiten deben reensamblarse una vez recibidos. No hay garantía alguna de que los datos llegarán en el orden en que se transmitieron. TCP aplica los números de secuencia a los segmentos de datos que transmite de modo que el receptor pueda reensamblar adecuadamente los bytes en su orden original. Si los segmentos TCP llegan desordenados, los segmentos se pueden reensamblar de forma incorrecta. Los números de secuencia le indican al dispositivo destino cómo ordenar correctamente los bytes a medida que arriban.

Estos números de secuencia también actúan como números de referencia de modo que el receptor sabe si ha recibido todos los datos. También identifican las porciones de datos perdidos y así el transmisor puede retransmitir los datos faltantes. Esto ofrece una mayor eficiencia ya que el transmisor sólo necesita retransmitir los segmentos faltantes en lugar de todo el grupo de datos.

Cada segmento TCP se numera antes de su transmisión. Tenga en cuenta que después del puerto destino en el formato del segmento se encuentra la porción del número de secuencia. En la estación receptora, TCP usa los números de secuencia para reensamblar los segmentos hasta formar un mensaje completo. Si falta algún número de secuencia en la serie, ese segmento se vuelve a transmitir.

10.1.6 ACK positivo

El acuse de recibo es un paso frecuente del proceso de sincronización que incluye ventanas deslizantes y secuenciación de datos. En un segmento TCP, el campo número de secuencia está seguido por el campo número de acuse de recibo, también conocido como el campo código.

Uno de los problemas con el protocolo IP no confiable es que no cuenta con un método de verificación para determinar que los segmentos de datos realmente llegan a destino. Por lo tanto, los segmentos de datos pueden enviarse de forma constante sin saber si realmente se recibieron o no. TCP utiliza acuse de recibo positivo y retransmisión para controlar el flujo de datos y confirmar la entrega de los datos.

El acuse de recibo positivo y retransmisión (PAR) es una técnica frecuente que muchos protocolos utilizan para proporcionar confiabilidad. Con PAR, el origen envía un paquete, inicia un temporizador y espera un acuse de recibo antes de enviar el siguiente paquete. Si el temporizador expira antes de que el origen reciba un acuse de recibo, el origen retransmite el paquete y reinicia el temporizador. TCP utiliza acuses de recibo de expectativa, lo que significa que el número de acuse de recibo se refiere al siguiente octeto esperado.

El uso de ventanas es un mecanismo de control de flujo que requiere que el dispositivo origen reciba un acuse de recibo desde el destino después de transmitir una cantidad determinada de datos. Con un tamaño de ventana de tres, el dispositivo origen puede enviar tres octetos al destino. Entonces debe esperar un acuse de recibo. Si el destino recibe los tres octetos, envía un acuse de recibo al dispositivo origen, que ahora puede transmitir otros tres octetos. Si, por algún motivo, el destino no recibe los tres octetos, posiblemente debido a búferes cuya capacidad se ha excedido, no envía un acuse de recibo. Debido a que el origen no recibe un acuse de recibo, sabe que los octetos se deben retransmitir, y que la velocidad de transmisión debe reducirse.

10.1.7 Operación de UDP

La pila del protocolo TCP/IP contiene muchos protocolos diferentes, cada uno diseñado para realizar una tarea determinada. IP provee transporte de Capa 3 no orientado a conexión a través de una internetwork. TCP permite la transmisión confiable, orientada a conexión de los paquetes en la Capa 4 del modelo OSI. UDP proporciona la transmisión de paquetes no orientado a conexión y no confiable de los paquetes en la Capa 4 del modelo OSI.

Tanto TCP como UDP utilizan IP como protocolo subyacente de Capa 3. Además, distintos protocolos de capa de aplicación utilizan TCP y UDP. TCP provee servicios para aplicaciones tales como FTP, HTTP, SMTP y DNS. UDP es el protocolo de capa de transporte utilizado por DNS, TFTP, SNMP y DHCP.

TCP debe utilizarse cuando las aplicaciones requieren la garantía de que un paquete llegue intacto, en secuencia y sin duplicar. El encabezado que se asocia con garantizar la entrega del paquete, a veces, se convierte en un problema al utilizar TCP. No todas las aplicaciones necesitan garantizar la entrega del paquete de datos, por lo tanto, utilizan un mecanismo de entrega no orientado a conexión, más rápido, que aporta el UDP. El estándar del protocolo UDP, que se describe en RFC 768, es un protocolo simple que intercambia segmentos sin acuses de recibo ni entrega garantizada.

UDP no hace uso de ventanas ni acuses de recibo de modo que los protocolos de capa de aplicación deben brindar la detección de errores. El campo Puerto de origen es un campo optativo que sólo se utiliza si la información debe regresar al host transmisor. Cuando un router destino recibe una actualización de enrutamiento, el router origen no solicita nada, de modo que nada debe regresar a la fuente. El campo "Puerto Destino" especifica la aplicación para la cual UDP necesita pasar los datos. Una petición DNS proveniente de un host hacia un servidor DNS suele tener un campo Puerto destino de 53, el número de puerto de UDP para DNS. El campo Longitud identifica el número de octetos de un segmento UDP. El checksum de UDP es optativo pero debería utilizarse para garantizar que no se han dañado los datos durante la transmisión. Para el transporte a través de la red, UDP se encapsula en el paquete IP.

Una vez que el segmento UDP llega a la dirección IP destino, debe haber un mecanismo que permita que el host receptor determine la exacta aplicación en destino. Para este fin se utilizan los puertos destino. Si un host provee servicios de TFTP y DNS, debe ser capaz de determinar cuál es el servicio que necesitan los segmentos UDP que llegan. El campo del Puerto destino del encabezado UDP determina la aplicación hacia la que se enviará el segmento UDP.

10.2 Descripción general de los puertos de la capa de transporte

10.2.1 Múltiples conversaciones entre hosts

En un momento dado, miles de paquetes que proveen cientos de servicios distintos atraviesan una red moderna. En muchos casos, los servidores proveen una gran cantidad de servicios lo que causa problemas singulares para el direccionamiento de los paquetes. Si un servidor ofrece servicios SMTP y HTTP, utiliza el campo puerto destino para determinar cuál es el servicio que solicita el origen. El origen no puede construir un paquete destinado sólo a la dirección IP del servidor porque el destino no sabría cuál es el servicio que se solicita. Un número de puerto debe asociarse a la conversación entre hosts para garantizar que el paquete alcance el servicio adecuado en el servidor. Sin una forma de distinguir entre las distintas conversaciones, el cliente sería incapaz de enviar un mensaje electrónico y navegar una página web utilizando un servidor al mismo tiempo. Debe utilizarse un método para separar las conversaciones de la capa de transporte.

Los hosts que corren TCP/IP asocian los puertos de la capa de transporte con determinadas aplicaciones. Los números de puerto se usan para realizar el seguimiento de las distintas conversaciones que atraviesan la red al mismo tiempo. Los números de puerto son necesarios cuando un host se comunica con un servidor que provee múltiples servicios. Tanto TCP como UDP utilizan números de puerto o socket para enviar información a las capas superiores.

Los fabricantes de software de aplicación han acordado utilizar los números de puerto bien conocidos que se definen en la RFC1700. Toda conversación dirigida a la aplicación FTP utiliza el número de puerto estándar 21. Las conversaciones que no involucran aplicaciones con números de puerto bien conocidos reciben números de puerto elegidos de forma aleatoria de un rango específico. Estos números de puerto se usan como direcciones origen y destino en el segmento TCP.

Los números de puerto tienen los siguientes intervalos asignados:

* Los puertos bien conocidos son aquellos desde 0 a 1.023.
* Los puertos registrados son aquellos desde 1.024 a 49.151.
* Los puertos dinámicos y/o privados son aquellos desde el 49.152 al 65.535.

Los sistemas que inician solicitudes de comunicación usan números de puerto para seleccionar las aplicaciones adecuadas. El host que origina la transferencia asigna dinámicamente los números del puerto de origen para estas solicitudes y, en general, son números mayores a 1023. Los números de puerto en el rango de 0 a 1023 se consideran números de puerto públicos y son controlados por la Autoridad de Asignación de Números de Internet (IANA, por sus siglas en inglés).Los números de las casillas de correo postal son una buena analogía de los números de puerto. Es posible enviar una carga postal a un código postal, ciudad y casilla de correo. El código postal y la ciudad dirigen la correspondencia hacia las instalaciones postales correctas mientras que la casilla de correo garantiza la entrega a la persona a quien va dirigida la carta. De igual forma, la dirección IP lleva al paquete hacia el servidor correcto, pero el número de puerto TCP o UDP garantiza que el paquete pase a la aplicación correspondiente.

10.2.2 Puertos para servicios

Los servicios que funcionan en los host deben contar con un número de puerto asignado para que la comunicación se produzca. Un host remoto que intenta conectarse con un servicio espera que el servicio utilice puertos y protocolos de capa de transporte específicos. Algunos puertos, definidos en la RFC 1700, se conocen como puertos bien conocidos y reservados tanto en TCP como UDP.

Estos puertos bien conocidos definen las aplicaciones que se ejecutan sobre los protocolos de la capa de transporte. Por ejemplo, un servidor que provee servicio FTP enviará las conexiones TCP que utilizan los puertos 20 y 21 provenientes de los clientes hacia su aplicación FTP. De esta forma, el servidor puede determinar con exactitud cuál es el servicio que solicita el cliente. TCP y UDP utilizan los números de puerto para determinar el servicio adecuado a las peticiones enviadas.

10.2.3 Puertos para los clientes

Cada vez que un cliente se conecta a un servicio de un servidor, es necesario especificar el puerto de origen y destino. Los segmentos de TCP y UDP contienen campos para los puertos de origen y destino. Los puertos destino o los puertos para servicios, generalmente, se definen utilizando los puertos conocidos. Los puertos de origen configurados por el cliente se determinan de forma dinámica.

En general, un cliente determina el puerto de origen asignando un número mayor a 1023 de forma aleatoria. Por ejemplo, un cliente que intenta comunicarse con un servidor web utiliza TCP y asigna el puerto destino con el número 80 y el puerto origen con 1045. Cuando el paquete llega al servidor, pasa hacia la capa de transporte superior y eventualmente al servicio HTTP que opera en el puerto 80. El servidor HTTP responde a las peticiones del cliente con un segmento que utiliza el puerto 80 como origen y 1045 como destino. De esta manera, los clientes y servidores utilizan los puertos para diferenciar el proceso al que se asocia el segmento.

10.2.4 Numeración de los puertos y números de puerto conocidos

Los números de puerto se representan con 2 bytes en el encabezado del segmento TCP o UDP. Este valor de 16 bits puede hacer que los números de puerto varíen de 0 a 65535. Estos números de puerto se dividen en tres categorías diferentes: puertos bien conocidos, puertos registrados y puertos dinámicos o privados. Los primeros 1023 puertos son puertos bien conocidos. Como su nombre indica, estos puertos se utilizan para los servicios de red bien conocidos, por ejemplo; FTP, Telnet, o DNS. Los puertos registrados varían de 1024 a 49151. Los puertos entre 49152 y 65535 se conocen como puertos dinámicos o privados.

10.2.5 Ejemplo de múltiples sesiones entre hosts

Se usan números de puerto para rastrear múltiples sesiones que pueden ocurrir entre hosts. Los números de puerto de origen y destino se combinan con la dirección de red para formar un socket. Un par de sockets, uno en cada host, forman una única conexión. Por ejemplo, un host puede tener una conexión telnet, puerto 23 mientras que, al mismo tiempo, puede navegar la red, puerto 80. Las direcciones IP y MAC son las mismas porque los paquetes provienen del mismo host. Por lo tanto, cada conversación en el extremo origen necesita su propio número de puerto y cada servicio solicitado necesita de su propio número de puerto.

10.2.6 Comparación de direcciones MAC, direcciones IP y números de puerto

Estos tres métodos de direccionamiento resultan a menudo confusos, pero es posible evitar la confusión si se explican las direcciones haciendo referencia al modelo OSI. Los números de puerto se encuentran en la capa de transporte y la capa de red les brinda servicio. La capa de red asigna una dirección lógica (dirección IP) y recibe servicios de la capa de enlace de datos quien le asigna una dirección física (dirección MAC).

Una clara analogía podría ser la de una carta normal. La dirección de la carta consta de nombre, calle, ciudad y estado. Estos pueden compararse con el puerto, la dirección MAC y la dirección IP que se utilizan para los datos de red. El nombre en el sobre equivale al número de puerto, la calle es la dirección MAC, y la ciudad y estado son la dirección IP. Es posible enviar varias cartas a la misma calle, ciudad y estado pero incluye distintos nombres. Por ejemplo, se podrían enviar dos cartas a la misma casa, una dirigida a John Doe y la otra a Jane Doe. Esto es análogo a múltiples sesiones con diferentes números de puerto.

by sdominguez.com

Semestre 2 CCNA, Módulo 9

Módulo 9: Diagnóstico básico de fallas del router

Descripción general

Un router usa un protocolo de enrutamiento dinámico para aprender acerca de rutas a las redes destino. La mayoría de los routers usa una combinación de enrutamiento dinámico y rutas estáticas configuradas manualmente. Cualquiera sea el método utilizado, cuando un router determina que una ruta es el mejor camino hacia un destino, la instala en su tabla de enrutamiento. Este módulo describe los métodos para examinar e interpretar los contenidos de una tabla de enrutamiento.

La prueba y el diagnóstico de las fallas de una red son, tal vez, los componentes que demandan más tiempo entre las tareas que ejecuta un administrador de redes. Una prueba y diagnóstico de fallas eficientes deben llevarse a cabo de forma lógica, ordenada y bien documentada. De lo contrario, volverán a producirse los mismos problemas y el administrador de la red nunca podrá entender la red a ciencia cierta. Este módulo describe un enfoque estructurado respecto del diagnóstico de fallas y provee algunas herramientas que se utilizan en este proceso.

Para los administradores de redes, los problemas de enrutamiento son los más comunes y difíciles de diagnosticar. Identificar y resolver los problemas de enrutamiento puede no resultar tan sencillo, pero muchas son las herramientas que pueden hacer más fácil la tarea. Este módulo presenta varias de las herramientas más importantes y proporciona la práctica de su utilización.

Los estudiantes que completen este módulo deberán ser capaces de:

* Utilizar el comando show ip route para recopilar información detallada sobre las rutas instaladas en el router.
* Configurar un router o una red por defecto.
* Comprender la forma en que un router utiliza el direccionamiento de Capa 2 y de Capa 3 para transferir los datos a través de la red.
* Utilizar el comando ping para realizar las pruebas básicas de conectividad de la red.
* Utilizar el comando telnet para verificar el software de capa de aplicación entre las estaciones origen y destino.
* Diagnosticar las fallas por medio de pruebas secuenciales

9.1 Examen de la tabla de enrutamiento

9.1.1 El comando show ip route

Una de las funciones principales de un router es determinar la mejor ruta a un destino determinado. Un router averigua las rutas desde la configuración de un administrador o desde otros routers mediante los protocolos de enrutamiento. Los routers almacenan esta información en tablas de enrutamiento que se mantienen en la memoria de acceso aleatorio (RAM) del router. Una tabla de enrutamiento contiene una lista de las mejores rutas disponibles. El router usa la tabla de enrutamiento para tomar decisiones de envío de paquetes.

El comando showip route muestra el contenido de una tabla de enrutamiento IP. Esta tabla contiene entradas para todas las redes y subredes conocidas, así como un código que indica de qué forma se obtuvo la información. Los siguientes son algunos comandos adicionales que se pueden utilizar con el comando show ip route:

* show ip route connected
* show ip route address
* show ip route rip
* show ip route igrp
* show ip route static

La tabla de enrutamiento mapea los prefijos de la red hacia la interfaz saliente. Cuando RTA recibe un paquete con destino a 192.168.4.46, busca el prefijo 192.168.4.0/24 en su tabla. RTA luego envía el paquete hacia una interfaz (Ethernet0) basándose en la entrada de la tabla de enrutamiento. Si RTA recibe un paquete con destino a 10.3.21.5, envía dicho paquete hacia Serial 0.

El ejemplo de tabla de enrutamiento muestra cuatro rutas para las redes directamente conectadas. Estas rutas, identificadas como C, se encuentran disponibles para las redes directamente conectadas. RTA descarta cualquier paquete destinado a una red que no se encuentre en la lista de la tabla de enrutamiento. A fin de efectuar el envío hacia otros destinos, la tabla de enrutamiento para RTA debe incluir más rutas. Estas nuevas rutas pueden agregarse utilizando uno de los dos siguientes métodos:

* Enrutamiento estático: el administrador define, de forma manual, las rutas hacia una o más redes destino.
* Enrutamiento dinámico: los router siguen reglas definidas por el protocolo de enrutamiento para intercambiar información de enrutamiento y seleccionar la mejor ruta de forma independiente.

Se dice que las rutas definidas administrativamente son estáticas porque no cambian hasta que un administrador de red programe los cambios de forma manual. Las rutas obtenidas de otros routers son dinámicas porque pueden cambiar de forma automática a medida que los routers vecinos se actualizan entre sí con la nueva información. Cada método tiene ventajas y desventajas fundamentales.

9.1.2 Determinación del gateway de último recurso

No es factible, ni siquiera deseable, que un router mantenga rutas hacia cada posible destino. En su lugar, los routers guardan una ruta por defecto o un gateway de último recurso. Las rutas por defecto se utilizan cuando un router no es capaz de hacer coincidir una red destino con ninguna entrada de la tabla de enrutamiento. El router utiliza esta ruta por defecto para llegar al gateway de último recurso en un esfuerzo por enviar el paquete.

Una característica de escalabilidad clave es que las rutas por defecto mantienen las tablas de enrutamiento tan simples como es posible. Posibilitan que los routers envíen los paquetes destinados a cualquier host de Internet sin tener que mantener una entrada en la tabla para cada red de la Internet. El administrador puede ingresar estáticamente las rutas por defecto o es posible obtener información de las mismas de forma dinámica mediante un protocolo de enrutamiento.

El enrutamiento por defecto comienza en el administrador: Antes de que los routers puedan intercambiar la información de forma dinámica, el administrador debe configurar al menos un router con una ruta por defecto. Según los resultados deseados, el administrador puede utilizar alguno de los siguientes comandos para configurar una ruta por defecto de forma estática:

ip default-network

o

ip route 0.0.0.0 0.0.0.0

El comando ip default-network se usa para establecer una ruta predeterminada en redes que usan protocolos de enrutamiento dinámico. Este comando es con distinción de clase o classful, lo que quiere decir que una subred señalada por este comando instala la red mayor en la tabla de ruteo. El comando ip default-network se debe usar en la red mayor, para marcar la subred candidata a ser la ruta predeterminada.

El comando ip default-network establece una ruta por defecto en las redes que utilizan protocolos de enrutamiento dinámico. El comando global ip default-network 192.168.17.0 define la red Clase C 192.168.17.0 como la ruta destino para paquetes que no poseen entradas en la tabla de enrutamiento. Para cada red configurada con el comando ip default-network, si un router cuenta con una ruta hacia la red, dicha ruta queda señalada como candidata a ser la ruta por defecto.

Crear un ip route hacia 0.0.0.0/0 es otra forma de configurar una ruta por defecto.

Router(config)#ip route 0.0.0.0 0.0.0.0 [address | interface]

Después de configurar una ruta o una red por defecto, el comando show ip route mostrará lo siguiente:

Gateway of last resort is 172.16.1.2 to network 0.0.0.0

9.1.3 Determinación del origen y destino de una ruta

En el tráfico que fluye a través de la nube de la red, la determinación de la ruta se produce en la capa de red. La función de determinación de ruta permite al router evaluar las rutas disponibles hacia un destino y establecer el mejor manejo de un paquete. Los servicios de enrutamiento utilizan la información de topología de red al evaluar las rutas de red. Esta información la puede configurar el administrador de red o se puede recopilar a través de procesos dinámicos ejecutados en la red.

La capa de red proporciona entrega de paquetes de mejor esfuerzo y de extremo a extremo a través de redes interconectadas. La capa de red utiliza la tabla de enrutamiento IP para enviar paquetes desde la red origen a la red destino. Una vez que el router determina cuál es la ruta a utilizar, toma el paquete proveniente de una interfaz y lo envía hacia otra interfaz o puerto que refleje la mejor ruta hacia su destino.

9.1.4 Determinación de las direcciones L2 y L3

Mientras las direcciones de capa de red se utilizan para que los paquetes viajen desde el origen hacia el destino, es importante comprender que se utiliza un tipo de dirección diferente para que los paquetes se transmitan desde un router hacia el siguiente. Para que un paquete se transmita desde un origen hacia su destino, se utiliza tanto las direcciones de Capa 2 como de Capa 3. Como se muestra en la Figura , en cada interfaz, a medida que el paquete se desplaza por la red, se examina la tabla de enrutamiento y el router determina el salto siguiente. El paquete se envía entonces utilizando la dirección MAC del salto siguiente. Los encabezados origen y destino IP no cambian en ningún momento.

La dirección de Capa 3 se utiliza para enrutar el paquete desde la red origen hacia la red destino. Las direcciones IP de origen y destino no cambian. La dirección MAC cambia en cada salto o router. La dirección de capa de enlace de datos resulta necesaria porque la entrega dentro de la red está determinada por la dirección del encabezado de la trama de Capa 2 y no por el encabezado del paquete de Capa 3.

9.1.5 Determinación de la distancia administrativa de la ruta.

Un router puede descubrir rutas utilizando protocolos de enrutamiento dinámico o rutas que el administrador configura de forma manual en el router. Una vez descubiertas o configuradas, el router debe elegir cuáles son las mejores rutas hacia una red dada.

La distancia administrativa de la ruta es la información clave que el router utiliza para decidir cuál es el mejor camino hacia un destino en particular. La distancia administrativa es un número que mide la confiabilidad del origen de la información de la ruta. Cuanto menor es la distancia administrativa, mayor la confiabilidad del origen.

Diferentes protocolos de enrutamiento presentan diferentes distancias administrativas por defecto. Si un camino tiene la menor distancia administrativa, se incluye en la tabla de enrutamiento. La tabla de enrutamiento no incluye una ruta si la distancia administrativa desde otro origen es menor.

9.1.6 Determinación de la métrica de la ruta

Los protocolos de enrutamiento utilizan la métrica para determinar la mejor ruta hacia un destino. La métrica es un valor que mide la conveniencia de una ruta. Algunos protocolos de enrutamiento sólo utilizan un factor para calcular una métrica. Por ejemplo, RIP versión 1 (RIP v1) utiliza el recuento de saltos como único factor para determinar la métrica de una ruta. Otros protocolos basan su métrica en el recuento de saltos, ancho de banda, retardo, carga, confiabilidad, y costo.

Cada algoritmo de enrutamiento interpreta lo que es mejor a su manera. El algoritmo genera un número, denominado métrica, para cada ruta a través de la red. Normalmente, cuanto menor es el valor de la métrica, mejor es la ruta.

Factores tales como ancho de banda y retardo son estáticos porque permanecen inalterables para cada interfaz hasta que se cambie la configuración del router o se rediseñe la red. Factores tales como carga y confiabilidad son dinámicos porque el router los calcula para cada interfaz en tiempo real.

Cuantos más factores compongan una métrica, mayor la flexibilidad para adaptar las operaciones de la red a las necesidades específicas. Por defecto, IGRP utiliza los factores estáticos ancho de banda y retardo para calcular el valor de la métrica. Estos dos factores pueden configurarse de forma manual, permitiendo un control preciso sobre cuál es la ruta que elige el router. IGRP también puede configurarse para incluir loa factores dinámicos: carga y confiabilidad, en el cálculo de la métrica. Utilizando los factores dinámicos, los routers IGRP pueden tomar decisiones basándose en las condiciones del momento. Si un enlace está muy cargado o es no confiable, IGRP aumentará la métrica de las rutas que utilizan dicho enlace. En estas circunstancias, las rutas alternativas pueden presentar una métrica menor que las rutas cuya métrica aumentó y se utilizarán como reemplazo.

IGRP calcula la métrica agregando los valores ponderados de las diferentes características del enlace con la red en cuestión. En el siguiente ejemplo, los valores: ancho de banda, ancho de banda dividido por la carga y el retardo se ponderan con las constantes K1, K2, y K3.

Métrica = [K1 * Ancho de banda + (K2 * Ancho de banda)/(256-Carga) + K3*Retardo] * [K5/(Confiabilidad + K4)]

Los valores por defecto de las constantes son K1 = K3 = 1 y K2 = K4 = K5 = 0.

Si K5=0, el término [K5/(Confiabilidad + K4)] no se utiliza. Dados los valores por defecto para las constantes K1 a K5, el cálculo de la métrica compuesta usado por IGRP se reduce a Métrica = Ancho de banda + Retardo.

9.1.7 Determinación del salto siguiente en la ruta

Los algoritmos de enrutamiento pueblan las tablas de enrutamiento con una amplia variedad de información. Las asociaciones entre el destino/salto siguiente le dicen al router que la mejor forma de alcanzar un destino en particular es enviar el paquete hacia un router en particular. Este router representa el siguiente salto en el camino hacia el destino final.

Cuando un router recibe un paquete entrante, lee la dirección destino e intenta asociar esta dirección con el salto siguiente.

9.1.8 Determinación de la última actualización de enrutamiento

Utilice los siguientes comandos para encontrar la última actualización de enrutamiento:

* show ip route
* show ip route address
* show ip protocols
* show ip rip database

9.1.9 Observación de las múltiples rutas hacia un destino

Algunos protocolos de enrutamiento soportan múltiples rutas hacia un mismo destino. A diferencia de los algoritmos de ruta única, estos algoritmos de rutas múltiples permiten el tráfico a través de múltiples líneas, proporcionan un mejor rendimiento y son más confiables.

IGRP soporta balanceo de carga asimétrico, el cual se conoce como variance. El comando variance instruye al router a incluir rutas con métricas menores a n veces la métrica mínima para esa ruta, donde n es el número especificado por el comando variance. La variable n puede tomar valores entre 1 y 128, con el valor por defecto igual a 1, lo cual significa balanceo de carga simétrico.

Rt1 tiene dos rutas a la red 192.168.30.0. El comando Variance se fija en Rt1 para asegurar que ambas rutas se utilizen.

La Figura muestra el resultado del comando show ip route ejecutado en Rt1 antes de configurada la variancia. La interfaz Fastethernet 0/0 es la única ruta a la red 192.168.30.0. Esta ruta tiene una distancia administrativa de 100 y un amétrica de 8986.

La Figura muestra el resultado de show ip route ejecutado en Rt1 después de configurada la variancia.

La mejor ruta es la interfaz FastEthernet 0/0, pero también se utiliza la interfaz Serial 0/0. Para verificar el balanceo de la carga, ejecute el comando ping 192.168.30.1.

Una vez ejecutado ping, la mejor ruta es utilizando la interfaz Serial 0/0. IGRP utilizará balanceo de carga entre los dos enlaces.

9.2 Pruebas de red

9.2.1 Introducción a las pruebas de red

Las pruebas básicas de una red deben desarrollarse en secuencia comenzando desde una capa del modelo de referencia OSI a la siguiente. Se recomienda comenzar con la Capa 1 y continuar hasta llegar a la Capa 7, si fuera necesario. Comenzando con la Capa 1, busque problemas simples tales como cables de suministro conectados a la pared. Los problemas más frecuentes que se producen en las redes IP son causados por errores en el esquema de direccionamiento. Es importante verificar la configuración de direcciones antes de continuar con los siguientes pasos de configuración.

Cada prueba presentada en esta sección se ocupa de las operaciones de red en una capa específica del modelo de referencia OSI. Los comandos telnet y ping son dos comandos fundamentales que se utilizan para probar la red.

9.2.2 Uso de un enfoque estructurado en el diagnóstico de fallas

El diagnóstico de fallas es un proceso que permite que el usuario encuentre los problemas en una red. Debe existir un proceso ordenado para diagnosticar fallas basado en los estándares de networking establecidos por un administrador de red. La documentación es una parte muy importante del proceso de diagnóstico de fallas.

Los pasos de este modelo son:

Paso 1: Obtener toda la información disponible y analizar los síntomas de la falla

Paso 2: Circunscribir el problema a un segmento de la red, a un módulo o unidad completos o a un usuario.

Paso 3: Aislar la falla a un hardware o software específico dentro de la unidad, el módulo o la cuenta de red del usuario.

Paso 4: Localizar y corregir el problema específico.

Paso 5: Verificar si el problema se ha resuelto.

Paso 6: Documente el problema y la solución.

La Figura muestra otro enfoque para el diagnóstico de fallas. Ninguno de estos conceptos es el único método de diagnóstico. Sin embargo, un proceso ordenado es de fundamental importancia a fin de mantener la red en funcionamiento uniforme y eficiente.

Utilizando un enfoque estructurado para diagnosticar fallas, cada miembro de un equipo de asistencia técnica de redes puede saber cuáles son los pasos que cada miembro del grupo ha llevado a cabo para resolver el problema. Si se intenta llevar a cabo una variedad de ideas para el diagnóstico de fallas sin organización o documentación, la forma de solucionar los problemas no es efectiva. Aun si se resuelve el problema en un entorno no estructurado, probablemente resulte imposible repetir la solución en problemas similares en el futuro.

9.2.3 Prueba capa por capa OS

La prueba debe comenzar con la Capa 1 del modelo OSI y continuar hasta la Capa 7 si fuera necesario.

Los errores de Capa 1 incluyen:

* Cables defectuosos.
* Cables desconectados.
* Cables conectados a los puertos incorrectos.
* Conexión de cable intermitente.
* Cables inadecuados para la tarea (se deben usar los cables rollover, de conexión cruzada y de conexión directa (straight-through) correctamente).
* Problemas en el transceptor.
* Problemas en el cable del DCE.
* Problemas en el cable del DTE.
* Dispositivos apagados.

Los errores de Capa 2 incluyen:

* Interfaces seriales incorrectamente configuradas.
* Interfaces Ethernet incorrectamente configuradas.
* Encapsulamiento incorrecto (HDLC es el encapsulamiento por defecto para las interfaces seriales).
* Configuraciones de temporización incorrectas en las interfaces seriales
* Problemas en la tarjeta de interfaz de red (NIC).

Los errores de Capa 3 incluyen:

* Protocolo de enrutamiento no habilitado.
* Protocolo de enrutamiento incorrecto habilitado.
* Direcciones IP incorrectas.
* Máscaras de subredes incorrectas.

Si se producen errores en la red, debe iniciarse el proceso de prueba a través de las capas de OSI. El comando ping se utiliza en la Capa 3 para probar la conectividad. En la Capa 7, es posible utilizar el comando telnet para verificar el software de capa de aplicación entre las estaciones origen y destino. Ambos comandos se tratarán en mayor detalle en una sección posterior.

9.2.4 Diagnóstico de fallas en la Capa 1 utilizando indicadores

Las luces indicadoras constituyen una herramienta útil para el diagnóstico de fallas. La mayoría de las interfaces o NICs cuentan con luces indicadoras que muestran si la conexión es válida. A menudo, esta luz recibe el nombre "link". La interfaz también puede contar con luces que indican si se transmite (TX) o recibe (RX) tráfico. Si la interfaz cuenta con luces indicadoras que no muestran una conexión válida, apague el dispositivo y vuelva a colocar la tarjeta de la interfaz. Un cable no apropiado o defectuoso también puede hacer que la luz de enlace indique una mala conexión o la ausencia de enlace.

Verifique que todos los cables se conecten a los puertos correctos. Asegúrese de que todas las conexiones cruzadas realicen una adecuada conexión con la ubicación correcta utilizando el cable y método apropiados. Verifique que todos los puertos del hub o del switch se encuentren en la VLAN o en el dominio de colisión correctos y que se hayan configurado las opciones correctas para el spanning tres y demás consideraciones.

Verifique que se use el cable correcto. Puede resultar necesario el uso de un cable de interconexión cruzada para realizar conexiones directas entre dos switches o hubs o entre dos host, por ejemplo: PCs o routers. Verifique la correcta conexión del cable proveniente de la interfaz origen y su buen estado. Si hubiera alguna duda de que la conexión es buena, vuelva a colocar el cable y controle que la conexión sea segura. Pruebe reemplazar el cable con otro que usted sepa que funciona. Si este cable se conecta a un toma de pared, utilice el analizador de cables para garantizar que la conexión esté bien cableada.

Además, controle todos los transceptores para garantizar que sean del tipo correcto y que estén bien conectados y configurados. Si reemplazar el cable no resuelve el problema, pruebe reemplazar el transceptor, si hubiera uno en uso.

Asegúrese siempre de que el dispositivo se encuentre encendido. Controle siempre los principios básicos antes de efectuar el diagnóstico o de intentar un diagnóstico de fallas complejo.

9.2.5 Diagnóstico de fallas en la Capa 3 utilizando el comando ping

Ping se utiliza para verificar la conectividad de la red. Como ayuda para diagnosticar la conectividad básica de red, muchos protocolos de red admiten un protocolo de eco. Los protocolos de eco se utilizan para verificar el enrutamiento de los paquetes de protocolo. El comando ping envía un paquete al host destino y luego espera un paquete de respuesta de ese host. Los resultados de este protocolo de eco pueden ayudar a evaluar la confiabilidad de ruta hacia el host, las demoras en la ruta y si se puede acceder al host o si este funciona. El resultado del comando ping muestra los tiempos mínimo, promedio y máximo que tarda un paquete ping en encontrar un sistema especificado y regresar. El comando ping utiliza el Protocolo de mensajes de control en Internet (ICMP) para verificar la conexión de hardware y la dirección lógica de la capa de red. La Figura es una tabla que muestra los distintos tipos de mensajes de ICMP. Este es un mecanismo de prueba sumamente básico para la conectividad de la red.

En la figura , el destino de ping 172.16.1.5 respondió con éxito a los cinco datagramas enviados. Los signos de exclamación (!) indican cada eco exitoso. Si se visualizan uno o más puntos (.) en lugar de signos de exclamación, significa que se venció el tiempo de espera de la aplicación en el router mientras se esperaba un eco de paquete proveniente del objetivo de ping.

El siguiente comando activa una herramienta de diagnóstico que se usa para probar la conectividad.

Router#ping [protocol] {host | address}

El comando ping prueba las conexiones de red enviando peticiones de eco ICMP hacia un host objetivo y controla el tiempo de respuesta. El comando ping registra el número de paquetes enviados, el número de respuestas recibidas y el porcentaje de paquetes perdidos. También registra la cantidad de tiempo que tardan los paquetes en llegar al destino y las respuestas en ser recibidas. Esta información permite verificar la comunicación entre una estación de trabajo y otros host, y si se perdió información.

Es posible invocar el comando ping desde el modo EXEC del usuario y desde el modo EXEC privilegiado. El comando ping se puede utilizar para confirmar la conectividad básica de una red en AppleTalk, Servicio de red no orientado a la conexión ISO (CLNS), IP, Novell, Apollo, VINES, DECnet, o redes XNS.

El uso de un comando ping extendido hace que el router ejecute una variedad más extensa de opciones de prueba. Para utilizar ping extendido, escriba ping en la línea de comando, luego presione la tecla Intro sin ingresar una dirección IP. Aparecerán indicadores cada vez que se presiona la tecla Intro. Estos indicadores proporcionan muchas más opciones que el comando ping estándar.

Es una buena idea utilizar el comando ping cuando la red funciona correctamente para ver cómo funciona el comando en condiciones normales y de modo que sea posible compararlo cuando se ejecuta el diagnóstico de fallas.

9.2.6 Diagnóstico de fallas en la Capa 7 utilizando Telnet

Telnet es un protocolo de terminal virtual que forma parte del conjunto de protocolos TCP/IP. Permite la verificación del software de capa de aplicación entre las estaciones origen y destino. Es el mecanismo de prueba más completo disponible. La aplicación de telnet se utiliza generalmente para conectar dispositivos remotos, recopilar información y ejecutar programas.

La aplicación Telnet proporciona una terminal virtual para conectarse a routers que ejecutan TCP/IP. A los fines del diagnóstico de fallas, resulta de utilidad verificar que se pueda realizar la conexión utilizando Telnet. Esto prueba que, al menos, una aplicación TCP/IP es capaz de conectarse de extremo a extremo. Una conexión exitosa de Telnet indica que la aplicación de capa superior y los servicios de las capas inferiores funcionan correctamente.

Si un administrador puede conectarse por Telnet con un router pero no con otro, verifique la conectividad de la capa inferior. Si se ha verificado la conectividad, probablemente la falla de Telnet se deba a problemas de permiso de acceso, denominación o direccionamiento específicos. Estos problemas pueden producirse en el router del administrador o en el router que falló como objetivo de Telnet.

Si la conexión Telnet con un servidor particular falla desde un host, pruebe conectarse desde un router y desde otros dispositivos diferentes. Cuando trate de conectarse por Telnet, si no aparece el indicador de conexión, verifique lo siguiente:

* ¿Se puede realizar una verificación DNS inversa de la dirección del cliente? Muchos servidores Telnet no permiten conexiones desde direcciones IP que no tienen entrada DNS. Este es un problema frecuente de las direcciones asignadas por DHCP en que el administrador no ha agregado entradas DNS adicionales para los grupos DHCP.
* Es posible que la aplicación Telnet no pueda negociar las opciones adecuadas y, por lo tanto, no se produce la conexión. En un router Cisco, este proceso de negociación se puede visualizar utilizando el comando debugtelnet.
* Es posible que el servicio Telnet esté desactivado o que se haya trasladado a un puerto diferente al 23 en el servidor destino.

9.3 Descripción general del diagnóstico de fallas del router

9.3.1 Diagnóstico de fallas de la Capa 1 utilizando el comando show interfaces

Cisco IOS contiene un conjunto de comandos completo para el diagnóstico de fallas. Entre los más usados se encuentran los comandos show. Cada aspecto del router puede visualizarse con uno o más comandos show.

El comando show utilizado para verificar el estado y las estadísticas de las interfaces es el comando show interfaces. El comando show interfaces sin argumentos entrega el estado y las estadísticas de todas las interfaces del router. El comando show interfaces entrega el estado y las estadísticas del puerto indicado. Para ver el estado de la interfaz serial 0/0, use el comando show interfaces serial 0/0.

El estado de dos porciones importantes de las interfaces se muestra con el comando show interfaces. Son la porción física (hardware) y la porción lógica (software). Pueden estar relacionadas con las funciones de Capa 1 y Capa 2.

El hardware incluye a los cables, conectores e interfaces que muestran el estado de la conexión física entre los dispositivos. El estado del software muestra el estado de los mensajes, por ejemplo: mensajes de actividad, información de control e información del usuario que se transmiten entre los dispositivos adyacentes. Esto se relaciona con el estado del protocolo de Capa 2 que se transfiere entre dos interfaces de router conectadas.

Estos elementos fundamentales del resultado del comando show interfaces serial se muestran como estado del protocolo de enlace de datos y de la línea.

El primer parámetro se refiere a la capa de hardware y básicamente refleja si la interfaz recibe la señal de detección de portadora (CD) proveniente del otro extremo de la conexión. Si la línea está desactivada, hay un problema con el cableado, el equipo puede estar apagado en alguna parte del circuito o puede estar funcionando mal, o puede haber sido administrativamente desactivada. Si la interfaz está en el estado administrativamente desactivada, ha sido manualmente desactivada en la configuración.

El comando show interfaces serial también proporciona información de ayuda para el diagnóstico de otros problemas de la Capa 1 que no resultan fáciles de determinar. Un número creciente de recuentos de transiciones de portadora en un enlace serial puede indicar uno o más de los siguientes problemas:

* Interrupciones en la línea debido a problemas en la red del proveedor de servicios de red.
* Switch, DSU o hardware del router defectuosos.

Si aparece un número creciente de errores de entrada en el resultado del comando show interfaces serial, varios son las causas posibles de estos errores. Algunos son problemas relacionados con la Capa 1, a saber.

* Equipo de la compañía de telefonía defectuoso.
* Línea serial con ruidos.
* Cable o longitud de cable incorrectos.
* Cable o conexión dañados.
* CSU o DSU defectuosas.
* Hardware del router defectuoso.

Otra área a examinar es el número de reinicios de las interfaces. Son el resultado de la pérdida de demasiados mensajes de actividad. Los siguientes problemas de Capa 1 pueden ser causa de los reinicios de las interfaces:

* Línea inadecuada que produce transiciones de la portadora.
* Posible problema de hardware en la CSU, DSU, o en el switch

Si las transiciones de portadora y los reinicios de las interfaces aumentan o si los errores de entrada son muchos a medida que aumentan los reinicios de la interfaz, el problema probablemente sea un enlace inadecuado o CSU o DSU defectuosas.

El número de errores debe interpretarse en relación a la cantidad de tráfico que ha procesado el router y la cantidad de tiempo durante el cual las estadísticas han sido capturadas. El router registra estadísticas que suministran información acerca de la interfaz. Las estadísticas reflejan el funcionamiento de un router desde que se puso en marcha o desde la última vez que se reiniciaron los contadores.

Si el resultado del comando show interfaces muestra que nunca se reiniciaron los contadores, utilice el comando show version para saber cuánto hace que el router se encuentra en funcionamiento.

Utilice el comando clear counters para poner los contadores en cero. Siempre es necesario reiniciar los contadores después de la corrección de un problema en la interfaz. Comenzar desde cero brinda un mejor cuadro sobre el estado actual de la red y ayuda a verificar que la corrección del problema sea real.

9.3.2 Diagnóstico de fallas de la Capa 2 utilizando el comando show interfaces

El comando show interfaces es tal vez la única herramienta de importancia para descubrir problemas de Capa 1 y de Capa 2 con el router. El primer parámetro (línea) se refiere a la capa física. El segundo parámetro (protocolo) indica si los procesos del IOS que controlan el protocolo de la línea consideran utilizable la interfaz o no. Esto está determinado por la recepción exitosa de los mensajes de actividad. Se entiende por mensajes de actividad a los mensajes enviados por un dispositivo de red para informar a otro que el circuito virtual entre ambos sigue estando activo. Si la interfaz pierde tres mensajes de actividad consecutivos, el protocolo de línea se marca como desactivado.

Siempre que la línea esté desactivada, el protocolo también lo está porque no existe un medio utilizable para el protocolo de Capa 2. Esto se aplica cuando la interfaz se encuentra desactivada debido a un problema de hardware y cuando esté desactivada por el administrador.

Si la interfaz está activada y el protocolo de línea no, existe un problema en la Capa 2. Las posibles causas son:

* Falta de mensajes de actividad.
* Falta de velocidad de reloj.
* Falta de concordancia en el tiempo de encapsulamiento.

El comando show interfaces serial debe utilizarse después de configurar una interfaz serial a fin de verificar los cambios y que la interfaz se encuentre operando.

9.3.3 Diagnóstico de fallas utilizando el comando show cdp

Cisco Discovery Protocol (CDP) divulga la información sobre el dispositivo a sus vecinos directos incluyendo direcciones IP y MAC e interfaces salientes.

El resultado del comando show cdp neighbors muestra información sobre los dispositivos Cisco vecinos que se conectan de forma directa. Esta información es de utilidad para la depuración de los temas relacionados con la conectividad. Si se sospecha que el problema es de cableado, habilite las interfaces con el comando no shutdown y luego ejecute el comando show cdp neighbors detail antes de cualquier configuración. Este comando muestra el detalle del dispositivo específico, por ejemplo: interfaces, ID del puerto y el dispositivo. También muestra la versión del Cisco IOS que se ejecuta en los dispositivos remotos.

Si la capa física funciona correctamente, entonces también se muestran todos los restantes dispositivos Cisco directamente conectados. Si no aparece un dispositivo conocido, probablemente el problema sea de Capa 1.

Un área problemática para CDP es la seguridad. La cantidad de información que CDP proporciona es tan inmensa que puede ser un potencial agujero en la seguridad. Por razones de seguridad, CDP debe configurarse sólo en enlaces entre dispositivos Cisco y inhabilitarse en puertos o enlaces de usuario no administrados a nivel local.

9.3.4 Diagnóstico de fallas utilizando el comando traceroute

El comando traceroute se utiliza para descubrir las rutas que toman los paquetes cuando viajan hacia su destino. Traceroute también puede utilizarse para ayudar a verificar la capa de red (Capa 3) teniendo en cuenta salto por salto y para proporcionar puntos de referencia para el desempeño.

El comando traceroute a menudo se refiere como comando trace en los materiales de referencia. Sin embargo, la sintáxis correcta del comando es traceroute.

El resultado del comando traceroute genera una lista de saltos alcanzados de forma exitosa. Si los datos finalmente llegan a su destino, entonces el resultado indica cada router por el que pasa el datagrama. Es posible capturar y utilizar este resultado para futuros diagnósticos de fallas en internetwork.

El resultado de traceroute también indica el salto específico donde se produce la falla. Para cada router de la ruta se genera una línea de resultado en la terminal que indica la dirección IP de la interfaz que ingresó los datos. Si aparece un asterisco (*), el paquete falló. Si se obtiene el último salto exitoso del resultado de traceroute y se lo compara con el diagrama de internetwork, es posible aislar el área del problema.

Traceroute también brinda información que indica el desempeño relativo de los enlaces. El tiempo de viaje redondo (Round Trip Time; RTT) es el tiempo que se requiere para enviar un paquete y recibir una respuesta. Esto es útil para tener una idea aproximada del retardo del enlace. Estos valores no son suficientemente precisos como para ser utilizados para una evaluación exacta del desempeño. Sin embargo, es posible capturar y utilizar este resultado para futuros diagnósticos de fallas en el desempeño de la internetwork.

Tenga en cuenta que el dispositivo que recibe el traceroute también tiene que saber cómo enviar la respuesta nuevamente hacia el origen del traceroute. Para que los datos del comando traceroute o ping completen el recorrido con éxito entre los routers, debe haber rutas conocidas en ambas direcciones. Una falla en la respuesta no siempre indica un problema ya que los mensajes ICMP pueden estar limitados por la velocidad o filtrados en el sitio del host. Esto se aplica en especial a Internet.

Traceroute envía una secuencia de datagramas de Protocolo de datagramas de usuario (UDP) desde el router hacia una dirección de puerto inválida en el host remoto. Para la primera secuencia de tres datagramas enviada, el valor de campo de Tiempo de existencia (TTL) se establece en uno. El valor de TTL de 1 hace que el datagrama expire el tiempo de espera en el primer router de la ruta. Este router entonces responde con un Mensaje ICMP de tiempo excedido (TEM) que indica que ha caducado el datagrama.

Luego, se envían tres mensajes UDP adicionales, esta vez con un valor de TTL de 2. Esto hace que el segundo router devuelva los TEM ICMP. Este proceso continúa hasta que los paquetes alcanzan su destino o se ha alcanzado el valor TTL máximo. El valor TTL máximo por defecto para el comando traceroute es 30.

Como estos datagramas tratan de acceder a un puerto inválido en el host destino, los mensajes que vuelven son ICMP de puerto inalcanzable y no ICMP de tiempo excedido. Esto indica un puerto inalcanzable y señala que el programa traceroute da por terminado el proceso.

9.3.5 Diagnóstico de los problemas relacionados con el enrutamiento

Los comandos show ip protocols y show ip route muestran información sobre los protocolos de enrutamiento y la tabla de enrutamiento. El resultado de estos comandos puede utilizarse para verificar la configuración del protocolo de enrutamiento.

El comando show ip route es tal vez el único comando fundamental para el diagnóstico de problemas relacionados con el enrutamiento. Este comando muestra el contenido de la tabla de enrutamiento IP. El resultado del comando show ip route muestra las entradas para todas las redes y subredes conocidas y de qué forma se obtuvo la información.

Si el problema se produce al llegar al host de una red en particular, entonces es posible utilizar el resultado del comando show ip route para verificar que el router tenga una ruta hacia dicha red.

Si el resultado del comando show ip route no muestra que se tomaron las rutas aprendidas esperadas o que no hay rutas aprendidas, entonces el problema posiblemente sea la falta de intercambio en la información de enrutamiento. En este caso, utilice el comando show ip protocols en el router para verificar el error de configuración del protocolo de enrutamiento.

El comando show ip protocols muestra los valores sobre la información del protocolo IP de enrutamiento de todo el router. Este comando se puede utilizar para confirmar cuáles son los protocolos configurados, cuáles son las redes divulgadas, cuáles son las interfaces que envían actualizaciones y las actualizaciones de los orígenes del enrutamiento. El resultado del comando show ip protocols también muestra los temporizadores, los filtros, el resumen de las rutas, la redistribución de las rutas y otros parámetros que son específicos para cada protocolo de enrutamiento que se habilita en el router. Cuando se configuran múltiples protocolos de enrutamiento, la información sobre cada protocolo se enumera en una lista por separado.

El resultado del comando show ip protocols se puede utilizar para diagnosticar una gran variedad de problemas de enrutamiento, incluyendo la identificación de un router del que se sospecha envía información incorrecta sobre un router. Puede utilizarse para confirmar la presencia de los protocolos esperados, las redes divulgadas y los vecinos de enrutamiento. Como sucede con cualquier proceso de diagnóstico de fallas, identificar el problema es difícil pero no imposible si no se dispone de documentación que indique lo esperado.

9.3.6 Diagnóstico de fallas utilizando el comando show controllers

Muy a menudo, la configuración y el diagnóstico de fallas de los routers se realiza de forma remota, cuando no es posible inspeccionar físicamente las conexiones del router. El comando show controllers es de utilidad para determinar el tipo de cable conectado sin inspeccionar los cables.

Examinando el resultado del comando show controllers, es posible determinar el tipo de cable que el controlador detecta. Resulta útil para encontrar una interfaz serial sin cable, el tipo de cable inadecuado o un cable defectuoso.

El comando show controllers serial 0/0 interroga al circuito integrado (chip) que controla las interfaces seriales y muestra información acerca de la interfaz física serial 0/0.Incluso dentro de un tipo de router, pueden utilizarse chips de controlador distintos.

Sin tener en cuenta el tipo de controlador, el comando show controllers serial genera un resultado impresionante. Excepto por el tipo de cable, la mayor parte de este resultado es detalle técnico interno relacionado con el estado del chip del controlador. Sin conocimiento específico del circuito integrado, esta información carece de utilidad.

9.3.7 Introducción al comando debug

El comando debug ayuda a aislar los problemas de configuración y de protocolo. El comando debug se utiliza para mostrar los sucesos y datos dinámicos. Como los comandos show sólo muestran información estática, brindan un cuadro histórico del la operación del router. Con el comando debug, el resultado brinda una visión interna de los sucesos que se producen en el router. Estos sucesos pueden ser tráfico en una interfaz, mensajes de error generados por los nodos de una red, paquetes de diagnóstico específicos del protocolo y otros datos útiles para el diagnóstico de fallas. El resultado dinámico del comando debug se genera a costa del desempeño, produciendo un mayor encabezado en el procesador que puede interrumpir el funcionamiento normal del router. Por este motivo, debug sólo debe utilizarse de forma moderada. Utilice los comandos debug para examinar los tipos de tráfico o problemas específicos una vez que los problemas potenciales se circunscriban a unas pocas causas.

by sdominguez.com

Semestre 2 CCNA, Módulo 8

Módulo 8: Mensajes de control y de error de los protocolos TCP/IP

Descripción general

El protocolo IP es limitado porque es un sistema de entrega de mejor esfuerzo. No dispone de un mecanismo para garantizar la entrega de los paquetes de datos, a pesar de los problemas con los que se puedan encontrar en la red. Los paquetes pueden no llegar a su destino por diversas razones, tales como fallas de hardware, configuración inadecuada o información de enrutamiento incorrecta. Para ayudar a identificar estas fallas, el IP usa el Protocolo de mensajes de control en Internets (ICMP), para notificar al emisor de los paquetes que se produjo un error durante el proceso de envío. Este módulo describe los diversos tipos de mensajes de error del ICMP y algunas de las formas en las que se utilizan.

Dado que el protocolo IP no cuenta con un mecanismo incorporado para enviar mensajes de error y control, usa ICMP para enviar y recibir mensajes de error y control a los hosts de la red. Este módulo se refiere principalmente a los mensajes de control, que son los mensajes que suministran información o parámetros de configuración a los hosts. El conocimiento de los mensajes de control del ICMP es una parte esencial del diagnóstico de fallas de la red y es un elemento clave para lograr una comprensión absoluta de las redes IP.

Los estudiantes que completen este módulo deberán ser capaces de:

* Describir el protocolo ICMP
* Describir el formato de mensajes del ICMP
* Identificar los tipos de mensajes de error del ICMP
* Identificar las causas potenciales de mensajes de error específicos
* Describir los mensajes de control del ICMP
* Identificar diversos mensajes de control del ICMP que se usan actualmente en las redes
* Determinar las causas de los mensajes de control del ICMP

8.1 Descripción general de los mensajes de error del TCP/IP

8.1.1 Protocolo de mensajes de control de Internets (ICMP)

El IP es un método poco confiable para la entrega de paquetes de red. Se le conoce como un mecanismo de entrega de mejor esfuerzo. No cuenta con ningún proceso incorporado para garantizar la entrega de paquetes en caso de que se produzca un problema de comunicación en la red. Si un dispositivo que actúa como intermediario falla como por ejemplo un router, o si un dispositivo de destino sale fuera de la red, los paquetes no se pueden entregar. Además, nada en su diseño básico hace que el IP notifique al emisor de que la transmisión ha fallado. El Protocolo de control de mensajes de Internet (ICMP) es el componente del conjunto de protocolos TCP/IP que corrige esta limitación básica del IP. El ICMP no resuelve los problemas de falta de confiabilidad en el protocolo IP. En caso de ser necesario, la confiabilidad debe ser prevista por los protocolos de capa superior.

8.1.2 Informes de error y corrección de errores

El ICMP es un protocolo de notificación de errores para el protocolo IP. Cuando se produce un error en la entrega de datagramas, se usa el ICMP para notificar de dichos errores a la fuente de los datagramas. Por ejemplo, si la estación de trabajo 1 de la Figura envía un datagrama a la estación de trabajo 6, pero la interfaz Fa0/0 del router C deja de funcionar, el router C utiliza ICMP para enviar un mensaje de vuelta a la estación de trabajo 1, el cual notifica que el datagrama no se pudo entregar. El ICMP no corrige el problema en la red; sólo informa del problema.

Cuando el router C recibe el datagrama de la estación de trabajo 1, sólo conoce las direcciones de IP de origen y destino del datagrama. No sabe cuál es la ruta exacta que tomó el datagrama en su camino hacia él. Por lo tanto, el router C sólo puede notificar a la estación de trabajo 1 acerca de la falla, y no se envía ningún mensaje de error ICMP al router A y al router B. El ICMP sólo informa al dispositivo de origen acerca del estado del paquete. No envía ninguna información sobre cambios en la red a los routers.

8.1.3 Entrega de mensajes ICMP

Los mensajes del ICMP se encapsulan en datagramas, del mismo modo en que se entrega cualquier otro dato mediante el protocolo IP. La Figura muestra el encapsulamiento de datos ICMP dentro de un datagrama IP.

Dado que los mensajes del ICMP se transmiten del mismo modo que cualquier otro paquete, están sujetos a las mismas fallas en la entrega. Esto crea una situación en la que los informes de error pueden generar más informes de error, lo que provoca una congestión creciente en una red que ya tiene fallas. Por esta razón, las fallas relativas a los mensajes del ICMP no generan sus propios mensajes de ICMP. De este modo, es posible que haya un error de entrega cuyo informe no llegue nunca de vuelta al emisor de los datos.

8.1.4 Redes fuera de alcance

Las comunicaciones en una red dependen de que se cumpla determinadas condiciones básicas. En primer lugar, los dispositivos emisor y receptor deben disponer de la pila del protocolo TCP/IP debidamente configurada. Esto incluye la instalación del protocolo TCP/IP y de la configuración adecuada de la dirección de IP y la máscara de subred. También se debe configurar una puerta de enlace predeterminada (también conocido como gateway por defecto), si va a haber envío de datagramas fuera de la red local. En segundo lugar, se debe proveer de dispositivos que actúen como intermediarios, para el enrutamiento de los datagramas desde el dispositivo y la red de origen hacia la red de destino. Los routers cumplen esta función. El router también debe disponer del protocolo TCP/IP debidamente configurado en sus interfaces y debe usar un protocolo de enrutamiento adecuado.

Si no se cumplen estas condiciones, no se puede realizar la comunicación entre redes. Por ejemplo, el dispositivo emisor puede dirigir el datagrama a una dirección de IP inexistente o a un dispositivo de destino que está fuera de la red. Los routers también pueden ser puntos de falla si la interfaz de conexión está desactivada o si el router no cuenta con la información necesaria para detectar la red de destino. Si la red de destino no está accesible, se dice que es una red que está fuera de alcance.

Las Figuras y muestran un router que recibe un paquete, el cual no puede enviar a su destino final. No se puede entregar el paquete porque no existe ninguna ruta conocida hacia el destino. Por ello, el router envía al origen un mensaje ICMP llamado de host fuera de alcance.

8.1.5 Uso de ping para verificar el estado del destino

El protocolo ICMP se puede usar para verificar el estado de un destino en particular. La Figura muestra el uso del ICMP para emitir un mensaje de solicitud de eco a un dispositivo de destino. Si el dispositivo de destino recibe la petición de eco, crea un mensaje de respuesta el cual es enviado de vuelta al origen de la petición. Si el emisor recibe la respuesta, confirma que el dispositivo destino se puede alcanzar mediante el uso del protocolo IP.

Generalmente, el mensaje de petición de eco se inicia al ejecutar el comando ping, como se muestra en la Figura . En este ejemplo, el comando se usa con la dirección de IP del dispositivo de destino. El comando se puede usar también como se muestra en la Figura usando la dirección IP del dispositivo destino. En estos ejemplos, el comando ping emite cuatro peticiones de eco y recibe cuatro respuestas, lo que confirma la conectividad IP entre los dos dispositivos.

Como se muestra en la figura , la respuesta de eco incluye un valor TTL (tiempo de vida) el cual es un campo del ancabezado de un paquete IP que limita el número de reenvíos de un paquete. al procesar un paquete, cada router decrementa el valor de TTL en uno. Cuando un router recibe un paquete con un valor de 1, éste no puede ser reenviado. Un mensaje ICMP se genera y se manda al origen, y el paquete original se elimina.

8.1.6 Detección de rutas excesivamente largas

Se puede producir situaciones en las comunicaciones de red en las que un datagrama viaje en círculos, sin llegar nunca a su destino. Esto puede ocurrir si dos routers enrutan continuamente un datagrama de ida y vuelta entre ellos, pensando que el otro debe ser el siguiente salto hacia el destino. Éste es un ejemplo de información de enrutamiento defectuosa.

Las limitantes del protocolo de enrutamiento pueden dar como resultado destinos inalcanzables. El número máximo de saltos en RIP es de 15, lo cual significa que las redes mayores a los 15 saltos no se pueden manejar con RIP.

En cualquiera de los casos, existe una ruta excesivamente larga. Ya sea que la ruta actual incluya un círculo, o bien que el paquete exceda el número máximo de saltos.

8.1.7 Mensajes de eco

Al igual que cualquier tipo de paquete, los mensajes ICMP tienen formatos especiales. Cada tipo de mensaje ICMP que se muestra en la Figura tiene sus propias características, pero todos los formatos de mensaje ICMP comienzan con estos mismos tres campos:

* Tipo
* Código
* Suma de comprobación (checksum)

El campo de tipo indica el tipo de mensaje ICMP que se envía. El campo de código incluye información adicional relativa al tipo de mensaje en particular. El campo checksum (suma de comprobación), al igual que en los otros tipos de paquetes, se usa para verificar la integridad de los datos.

La Figura muestra el formato de los mensajes ICMP "echo request" (petición de eco) y "echo reply" (respuesta de eco). Se muestra el tipo y los números de código pertinentes para cada tipo de mensaje. El campo identificador y el de número de secuencia son exclusivos de los mensajes de petición de eco y respuesta de eco. Estos campos se usan para comparar las respuestas de eco con la petición de eco correspondiente. El campo de datos contiene información adicional que puede formar parte de un mensaje de petición de eco o de respuesta de eco).

8.1.8 Mensaje "destination unreachable" (destino fuera de alcance)

No siempre es posible enviar los datagramas a sus destinos. Las fallas de hardware, configuraciones inadecuadas del protocolo, interfaces inactivas y errores en la información de enrutamiento son algunas de las razones que pueden impedir que la entrega se complete con éxito. En estos casos, el ICMP envía de vuelta al emisor un mensaje llamado "destination unreachable" (destino fuera de alcance), el cual le indica al emisor que el datagrama no se pudo entregar adecuadamente.

La Figura muestra el encabezado de un mensaje de destino fuera de alcance del ICMP. El valor 3 en el campo de tipo señala que es un mensaje de destino fuera de alcance. El valor del código indica el motivo por el cual el paquete no se pudo entregar. La Figura muestra un valor de código de 0, lo que indica que la red está fuera de alcance. La Figura muestra el significado de cada uno de los valores de código posibles en un mensaje de destino fuera de alcance.

También se puede enviar un mensaje de destino fuera de alcance cuando se requiere la fragmentación de los paquetes para hacer posible su envío. La fragmentación generalmente es necesaria cuando se envía un datagrama desde una red Token-Ring a una red Ethernet. Si el datagrama no permite la fragmentación, el paquete no puede enviarse, por lo que se envía un mensaje de destino fuera de alcance. Los mensajes de destino fuera de alcance también se pueden generar si los servicios IP relacionados, como por ejemplo el FTP o los servicios WWW, no están disponibles. Para diagnosticar las fallas de una red IP de forma eficaz, es necesario comprender las diversas causas de los mensajes ICMP de destino fuera de alcance.

8.1.9 Otros informes de error

Es posible que los dispositivos que procesan datagramas no puedan enviar un datagrama debido a un error en el encabezado. Este error no se relaciona con el estado del host de destino o de su red, pero impide que el datagrama se procese y se envíe, y debido a esto, el datgrama se descarta. En este caso, se envía un mensaje ICMP "parameter problem" (problema de parámetros) de tipo 12 a la fuente del datagrama. La Figura muestra el encabezado del mensaje de problema de parámetros.

El mensaje de problema de parámetros incluye el campo del marcador o apuntador del encabezado. Si el valor del código es 0, el campo de marcador indica el octeto del datagram que generó el error.

8.2 Mensajes de control del conjunto de protocolos TCP/IP

8.2.1 Introducción a los mensajes de control

El Protocolo de mensajes de control en Internet (ICMP) es una parte integral del conjunto de protocolos TCP/IP. De hecho, todas las implementaciones del IP deben incluir soporte al ICMP. La razón es muy sencilla. En primer lugar, dado que el IP no garantiza la entrega, no cuenta con ningún método incorporado para informar a los hosts que se ha producido un error. Además, el IP no cuenta con ningún método incorporado para suministrar mensajes de información o control a los hosts. El ICMP ejecuta estas funciones para el IP.

A diferencia de los mensajes de error, los mensajes de control no se presentan como el resultado deperdida de paquetes o condiciones de error que puedan ocurrir durante la transmisión de los paquetes, sino que se utilizan para mantener a los hosts informadosde eventos como congestionamiento o la existencia de un mejor gatewaya una red remota. ICMP usa el header IP básico para viajar a través de varias redes.

El ICMP usa múltiples tipos de mensajes de control. Algunos de los más comunes se muestran en la Figura . Muchos de ellos se tratan en esta sección.

8.2.2 Peticiones ICMP de redireccionamiento/cambio

Un mensaje común de control del protocolo ICMP es la petición de redireccionamiento/cambio. Este tipo de mensaje sólo puede originarse de un gateway, que es un término que se usa comúnmente para describir un router. Todos los hosts que se comunican con múltiples redes IP deben tener configurado un gateway por defecto. Este gateway por defecto es la dirección del puerto del router conectado a la misma red que el host. La Figura muestra un host conectado a un router que tiene acceso a la Internet. Una vez configurado con la dirección IP de la interfaz Fa 0/0 como su gateway por defecto, el host B usa esa dirección de IP para llegar a cualquier red a la cual no esté conectado directamente. Normalmente, el host B está conectado sólo a un gateway. Sin embargo, en algunos casos, el host está conectado a un segmento de red el cual tiene dos o más routers conectados directamente. En este caso, es posible que el gateway por defecto del host deba utilizar una petición de redireccionamiento/cambio para informar al host cuál es la mejor ruta hacia una red determinada.

La Figura muestra una red donde podría ocurrir el redireccionamiento ICMP. El host B envía un paquete al host C en la red 10.0.0.0/8. Dado que el host B no está directamente conectado a la misma red, envía el paquete a su gateway por defecto, el router A. El router A encuentra la ruta correcta hacia la red 10.0.0.0/8 en su tabla de enrutamiento, y determina que la ruta hacia la red es a través de la misma interfaz de la que provino la petición para enviar el paquete. Envía el paquete y hace una petición ICMP de redireccionamiento/cambio al host B, en la cual le indica que debe usar el router B como gateway para enviar todas las peticiones futuras para la red 10.0.0.0/8.

Los gateway por defecto envían mensajes ICMP de peticiones de redireccionamiento/cambio sólo si se cumplen las siguientes condiciones:

* La interfaz a través de la cual el paquete ingresa al router es la misma a través de la cual sale el paquete enrutado.
* La subred/red de la dirección de IP de origen es la misma red/subred de la dirección de IP del salto siguiente del paquete enrutado.
* El datagrama no está enrutado desde el origen.
* La ruta para el redireccionamiento no es otro redireccionamiento ICMP ni otra ruta por defecto.
* El router está configurado para enviar redireccionamientos. (Por defecto, los routers Cisco envían redireccionamientos ICMP. El subcomando de interfaces no ip redirects inhabilita todos los redireccionamientos ICMP).

La petición ICMP de redireccionamiento/cambio utiliza el formato que se muestra en la Figura . Tiene un código ICMP de tipo 5. Además, puede tener valores de código de 0, 1, 2 ó 3.

El campo Router Internet Address (Dirección Internet del router) del redireccionamiento ICMP es la dirección de IP a ser usada como gateway por defecto para una red en particular. En el ejemplo que aparece en la Figura , el redireccionamiento ICMP que se envía desde el router A al host B tiene un valor de campo del Router Internet Address de 172.16.1.200, el cual es la dirección IP de la interfaz E0 en el router B.

8.2.3 Sincronización de relojes y estimación del tiempo de tránsito

El conjunto de protocolos TCP/IP permite que los sistemas se conecten entre sí a través de amplias distancias por múltiples redes. Cada una de estas redes individuales hace su sincronización de reloj de una manera particular. Como resultado de ello, puede haber problemas en el caso de hosts en redes distintas que tratan de comunicarse mediante software que requiere de sincronización de reloj. El mensaje ICMP de tipo "timestamp" (de marca horaria) está diseñado para ayudar a resolver este problema.

El mensaje ICMP de petición de marca horaria permite que un host solicite la hora actual que observa el host remoto. El host remoto usa un mensaje ICMP de respuesta de marca horaria para responder a la petición.

El campo de tipo de un mensaje ICMP de marca horaria puede ser 13 (timestamp request/petición de marca horaria) o 14 (timestamp reply/respuesta de marca horaria). El valor del campo de código se fija siempre en 0 dado que no hay ningún parámetro adicional disponible. La petición de marca horaria ICMP contiene una marca horaria de origen, que es la hora en el host solicitante al momento de enviar la petición de marca horaria. La marca horaria de recepción es la hora en que el host destino recibe la petición de marca horaria. La marca horaria de transmisión se completa justo antes de que se devuelva la respuesta de marca horaria. Las marcas horarias de origen, recepción y transmisión se calculan según la cantidad de milisegundos que transcurrieron desde la medianoche de la Hora Universal (UT).

Todos los mensajes ICMP de respuesta de marca horaria contienen las marcas horarias de origen, recepción y transmisión. Usando estos tres marca de tiempo, el cliente puede determinar el tiempo de tránsito a través de la red mediante la resta del tiempo de llegada y el tiempo de salida. O también en la dirección contraria restando el tiempo de transmisión del tiempo actual. El host que originó la petición de marca horaria también puede estimar la hora local en la computadora remota.

Aunque los mensajes ICMP de marca horaria suministran una forma sencilla para estimar la hora en un host remoto y el tiempo de tránsito total de una red, no es la mejor manera de obtener esta información. En lugar de ello, existen protocolos más sólidos como por ejemplo el Protocolo de hora de red (NTP), perteneciente a las capas superiores de la pila del protocolo TCP/IP, el cual realiza la sincronización de relojes de un modo más confiable.

8.2.4 Formatos de los mensajes de petición de información y de respuesta

Los mensajes ICMP de petición de información y de respuesta fueron concebidos originalmente para permitir que el host determine su número de red. La Figura muestra el formato de un mensaje ICMP de petición de información y de respuesta.

Hay dos códigos de tipo disponibles para estos mensajes. El tipo 15 indica un mensaje de petición de información y el tipo 16 señala un mensaje de respuesta de información. Este tipo de mensaje ICMP en particular se considera obsoleto. En la actualidad se usan otros protocolos como, por ejemplo el BOOTP, Reverse Address Resolution Protocol (RARP), y el Protocolo de configuración dinámica del host (DHCP), para que los hosts obtengan sus números de red.

8.2.5 Solicitud de la máscara de dirección

Cuando un administrador de red emplea el proceso de división en subredes para dividir un grupo amplio de direcciones IP en múltiples subredes, se crea una nueva máscara de subred. Esta nueva máscara de subred es vital para identificar los bits correspondientes a la red, la subred y el host de una dirección de IP. Si un host no conoce su máscara de subred, puede enviar una petición de máscara al router local. Si se conoce la dirección del router, esta petición se puede enviar directamente al router. De otro modo, la petición será hecha como broadcast. Cuando el router recibe la petición, envía de vuelta una respuesta de máscara de dirección o "address mask reply". Esta respuesta de máscara de dirección indica la máscara de subred correcta. Por ejemplo, consideremos que el host se encuentra en una red Clase B y tiene una dirección de IP de 172.16.5.2. Este host desconoce su máscara de subred, por lo tanto hace una petición de la máscara de dirección como broadcast.

Dirección de origen: 172.16.5.2

Dirección de destino: 255.255.255.255

Protocolo: ICMP = 1

Tipo: Petición de máscara de dirección = AM1

Código: 0

Máscara: 255.255.255.0

Este broadcast se recibe en 172.16.5.1, el router local. El router responde enviando una respuesta de máscara de dirección o "address mask reply":

Dirección de origen: 172.16.5.1

Dirección de destino: 172.16.5.2

Protocolo: ICMP = 1

Tipo: Respuesta de máscara de dirección = AM2

Código: 0

Máscara: 255.255.255.0

Los formatos de la petición y respuesta de máscara de dirección se indican en la Figura . La Figura muestra las descripciones de cada uno de los campos del mensaje de petición de máscara de dirección. Observe que se usa el mismo formato tanto para la petición como para la respuesta de máscara de dirección. Sin embargo, el número de tipo 17 se asigna a la petición y, el 18, a la respuesta.

8.2.6 Mensaje de descubrimiento de routers

Cuando arranca un host de la red, y su gateway por defecto no se ha configurado manualmente, puede aprender cuáles son los routers disponibles a través del proceso de descubrimiento de routers. Este proceso comienza cuando el host envía un mensaje de solicitud de routers a todos los routers. Para ello utiliza la dirección multicast 224.0.0.2 como la dirección destino. La Figura muestra el mensaje ICMP de descubrimiento de routers o "router discovery". El mensaje de descubrimiento de router se puede enviar también como broadcast, para que incluya los routers que no se pueden configurar para multicast. Si se envía un mensaje de descubrimiento de router a un router que no maneja el proceso de descubrimiento, no se recibirá ninguna respuesta a dicho mensaje.

Si un router que permite el proceso de descubrimiento recibe un mensaje de descubrimiento de router, envía de vuelta una publicación o anuncio de router. El formato de la publicación de router se muestra en la Figura y la Figura da una explicación de cada uno de los campos.

8.2.7 Mensaje de solicitud de router

Un host genera un mensaje ICMP de solicitud de router en respuesta a la ausencia de un gateway por defecto. Este mensaje se envía mediante multicast y es el primer paso del proceso de descubrimiento de routers. El router local responde con una publicación de router, en la que se identifica el gateway por defecto para el host local. La Figura identifica el formato de la publicación de router y la Figura da una explicación de cada uno de los campos.

8.2.8 Mensajes de congestión y control de flujo

Si varias computadoras tratan de tener acceso al mismo destino a la vez, la computadora de destino puede ser incapaz de manejar el alto tráfico. También se puede producir congestión cuando el tráfico de una LAN de alta velocidad llega a una conexión WAN más lenta. Cuando hay demasiada congestión en una red, los paquetes se pierden. Los mensajes ICMP source-quench (supresión en el origen) se usan para reducir la cantidad de datos perdidos. Los mensajes de supresión en el origen solicitan a los emisores reducir la velocidad a la que transmiten los paquetes. En la mayoría de los casos, la congestión se reduce luego de un corto período de tiempo, y el origen lentamente aumenta la velocidad de transmisión siempre y cuando no se reciba ningún otro mensaje de supresión en el origen. La mayoría de los routers Cisco por defecto no envían mensajes de supresión en el origen, dado que dichos mensajes pueden contribuir a la congestión de la red.

El caso de las oficinas pequeñas o oficinas en el hogar (SOHO) es uno en el que los mensajes ICMP de supresión en el origen se pueden usar de forma efectiva. Una red SOHO puede estar compuesta por cuatro computadoras conectadas en red mediante cable CAT-5 y que tienen una conexión Internet compartida a través de un módem de 56K. Es muy fácil determinar que el ancho de banda de 10 ó 100 Mbps de la red local puede copar rápidamente el ancho de banda de 56Kbps del enlace WAN, lo que da como resultado la pérdida de datos y las retransmisiones. El host que actúa como gateway puede usar un mensaje ICMP "source quench" para solicitar que los otros hosts reduzcan sus velocidades de transmisión para prevenir la pérdida continua de datos. En la Figura se muestra una red en la que la congestión del enlace WAN puede provocar problemas en la comunicación.

by sdominguez.com