Ccna Nuevo v6

Ing. José Dennis Estela Zumaeta NUEVOS TEMAS AGREGADOS PARA EL EXAMEN DE CERTIFICACION CCNA 200-125

INTRODUCCION A LA REDES – CCNA 1 Descripción general de puente ITN Al finalizar finalizar este módulo, estará estará en condiciones condiciones de:  

  

Utilizar el resultado del comando tracert para establecer el rendimiento relativo de la red. Utilizar los comandos debug y terminal monitor para recopilar información sobre los dispositivos en una red. Describir las metodologías de solución de problemas de la red común. Solucionar problemas con el cable y los problemas de interfaz. Solucionar problemas de los dispositivos de la red.

Comando traceroute extendido Diseñado como variante del comando traceroute , el comando traceroute extendido permite permit e que el administrador ajuste los parámetros relacionados con el funcionamiento del comando. Esto es útil para solucionar problemas de bucles de routing, determinando el router de siguiente salto, o ayudar a determinar dónde los paquetes son descartados por un router o denegados por un firewall. firewa ll. Si bien el comando ping extendido se puede utilizar para determinar el tipo de problema de conectividad, el comando traceroute extendido es útil para localizar el problema. El mensaje de error de tiempo superado de ICMP indica que un router en la ruta ha visto y ha descartado el paquete. El mensaje de error de destino inalcanzable de ICMP indica que un router recibió el paquete, pero lo descartó porque no podía enviarse. Al igual que ping, traceroute utiliza solicitudes de eco ICMP y respuestas de eco. Si expira el temporizador ICMP antes de que se reciba una respuesta de eco ICMP, el resultado del comando traceroute muestra un asterisco (*). En IOS, el comando traceroute extendido finaliza cuando se producen cualquiera de los siguientes: 

El destino responde con una respuesta de eco ICMP.

Ing. José Dennis Estela Zumaeta 

El usuario interrump interrumpe e el seguimiento con la secuencia de escape.

Nota: En IOS, puede invocar esta secuencia de escape presionando Ctrl+Mayús+6. En Windows, la secuencia de escape se invoca presionando Ctrl+C. Para utilizar traceroute extendido, simplemente escriba traceroute, sin proporcionar ningún parámetro, y presione ENTER. IOS lo guiará en las opciones de comando presentando varios indicadores relacionados con la configuración de todos los parámetros diferentes. En la Tabla 1 se muestran mu estran las opciones de traceroute extendido de IOS y sus respectivas descripciones.

Tabla 1: Opciones de traceroute extendido de IOS

Aunque el comando tracert de Windows permite la entrada de varios parámetros, no es guiado y se debe ejecutar a través de opciones en la línea de comandos. El ejemplo 1 muestra las opciones disponibles para tracert de W indow indows. s.


El usuario interrump interrumpe e el seguimiento con la secuencia de escape.

Nota: En IOS, puede invocar esta secuencia de escape presionando Ctrl+Mayús+6. En Windows, la secuencia de escape se invoca presionando Ctrl+C. Para utilizar traceroute extendido, simplemente escriba traceroute, sin proporcionar ningún parámetro, y presione ENTER. IOS lo guiará en las opciones de comando presentando varios indicadores relacionados con la configuración de todos los parámetros diferentes. En la Tabla 1 se muestran mu estran las opciones de traceroute extendido de IOS y sus respectivas descripciones.

Tabla 1: Opciones de traceroute extendido de IOS

Aunque el comando tracert de Windows permite la entrada de varios parámetros, no es guiado y se debe ejecutar a través de opciones en la línea de comandos. El ejemplo 1 muestra las opciones disponibles para tracert de W indow indows. s.

Ing. José Dennis Estela Zumaeta Ejemplo 1: Opciones disponibles para tracert de Windows.

EL COMANDO DEBUG Los procesos, protocolos, mecanismos y eventos de IOS generan mensajes para comunicar su estado. Estos mensajes pueden proporcionar información valiosa cuando hay que solucionar problemas o verificar las operaciones del sistema. El comando debug de IOS permite que el administrador muestre estos mensajes en tiempo real para su análisis. Es una herramienta muy importante para supervisar eventos en un dispositivo Cisco IOS. Todos los comandos debug se introducen en el modo EXEC privilegiado. El IOS de Cisco permite limitar el resultado de debug para incluir solo la función o la subfunción relevante. Esto es importante porque se le asigna alta prioridad al resultado de depuración en el proceso de CPU y puede hacer que el sistema no se pueda utilizar. Por este motivo, motivo, use los comandos c omandos debug solo para solucionar problemas específicos. Para supervisar el estado de mensajes de ICMP en un router Cisco, utilice debug ip icmp. El Ejemplo 1 muestra el resultado de debug ip icmp.

Ejemplo 1: Resultado del comando debug ip icmp:

Ing. José Dennis Estela Zumaeta Para ver una lista con una breve descripción de todas las opciones del comando de depuración, utilice el comando debug? en modo EXEC privilegiado en la línea de comando. Para desactivar una característica de depuración específica, agregue la palabra no delante del comando debug: Router# no debug ip icmp Alternativamente, puede ingresar la forma undebug del comando en modo EXEC privilegiado: Router# undebug ip icmp Para desactivar todos los comandos debug activos de inmediato, utilice el comando undebug

all: Router# undebug all Algunos comandos de depuración como debug all y debug ip packet generan una importante cantidad de resultados y usan una gran porción de recursos del sistema. El router estaría tan ocupado mostrando mensajes de depuración que no tendría suficiente potencia de procesamiento para realizar las funciones de red, o incluso escuchar los comandos para desactivar la depuración. Por este motivo, no se recomienda y se debe evitar utilizar estas opciones de comando.

EL COMANDO TERMINAL MONITOR Las conexiones para otorgar acceso a la interfaz de línea de comandos de IOS se pueden establecer de forma local o remota. Las conexiones locales requieren acceso físico al router o switch, por lo tanto, se requiere una conexión de cable. Esta conexión se establece generalmente mediante la conexión de una PC al puerto de consola del router o del switch mediante un cable de sustitución. En este curso, nos referimos a una conexión local como conexión de consola. Las conexiones remotas se establecen en la red, y por lo tanto, requieren un protocolo de red como IP. No se requiere acceso físico directo para las sesiones remotas. SSH y Telnet son dos protocolos de conexión comunes utilizados para las sesiones remotas. En este curso, usamos el protocolo cuando hablamos de una conexión remota específica, como una conexión Telnet o una conexión SSH. Aunque los mensajes de registro de IOS se envían a la consola de manera predeterminada, estos mismos mensajes de registro no se envían a las líneas virtuales de manera predeterminada. Debido a que los mensajes de depuración son mensajes de registro, este comportamiento evita que los mensajes se muestren en las líneas VTY. Para mostrar los mensajes de registro en una terminal (consola virtual), utilice el comando modo EXEC privilegiado terminal monitor. Para detener los mensajes de registro en una terminal, utilice el comando modo EXEC privilegiado terminal no monitor.

Ing. José Dennis Estela Zumaeta

ENFOQUES PARA LA SOLUCIÓN DE PROBLEMAS BÁSICOS Los problemas de red pueden ser simples o complejos, y pueden ser el resultado de una combinación de problemas de hardware, software y conectividad. Los técnicos informáticos deben ser capaces de analizar el problema y determinar la causa del error para poder reparar el problema de red. Este proceso se denomina “solución de problemas”. Una metodología de solución de problemas común y eficaz se basa en el método científico y se puede dividir en los seis pasos importantes de la Tabla 1.

Tabla 1: Seis pasos de la metodología de solución de problemas

Ing. José Dennis Estela Zumaeta Para evaluar el problema, determine cuántos dispositivos de la red lo tienen. Si existe un problema con un dispositivo de la red, inicie el proceso de solución de problemas en ese dispositivo. Si existe un problema con todos los dispositivos de la red, inicie el proceso de solución de problemas en el dispositivo donde se conectan todos los otros dispositivos. Debe desarrollar un método lógico y coherente para diagnosticar problemas de red mediante la eliminación de un problema por vez. ¿SOLUCIONAR O ESCALAR? En algunas situaciones, quizás no sea posible solucionar el problema de inmediato. Un problema debería escalarse cuando requiere la decisión del gerente, cierta experiencia específica, o el nivel de acceso a la red no está disponible para el técnico que debe solucionar el problema. Por ejemplo, después de solucionar problemas, el técnico decide que un módulo de router debe reemplazarse. Este problema se debe escalar para obtener la aprobación del gerente. Es probable que el gerente tenga que escalar el problema nuevamente ya que podría necesitar la aprobación del departamento de finanzas antes de comprar un nuevo módulo. La política de la empresa debe indicar claramente cuándo y cómo un técnico debe escalar un problema.

VERIFICACION Y SUPERVISION DE LA SOLUCIÓN Cisco IOS incluye herramientas eficaces para la solución de problemas y la verificación. Cuando se ha solucionado el problema y se ha implementado la solución, es importante verificar el funcionamiento del sistema. Las herramientas de verificación incluyen los comandos ping, traceroute y show . El comando ping se utiliza para verificar si la conectividad de la red es satisfactoria. Todos los resultados de los comandos en los siguientes ejemplos se basan en la topología que se muestra en la Figura 1.

Nota: Un ping fallido no suele proporcionar suficiente información para llegar a una conclusión. Puede ser el resultado de una ACL o un firewall que bloqueaba los paquetes ICMP, o el dispositivo de destino puede estar configurado para no responder a los pings . Un ping fallido generalmente indica que se requiere investigación adicional. El comando traceroute , como se muestra en el Ejemplo 2, es útil para mostrar la ruta que los paquetes utilizan para llegar a un destino. Aunque el resultado del comando ping muestra si un paquete llegó al destino, el resultado del comando traceroute muestra qué ruta tomó para llegar allí, o dónde el paquete fue interrumpido a lo largo de la ruta.


Los comandos show de Cisco IOS son algunas de las herramientas más útiles para resolver problemas. Al aprovechar una gran variedad de opciones y de subopciones, el comando show puede utilizarse para reducir y mostrar información sobre prácticamente cualquier aspecto específico del IOS. El Ejemplo 3 muestra el resultado del comando show ip interface brief. Observe que las dos interfaces configuradas con las direcc iones IPv4 están en “up” y “up”. Estas interfaces pueden enviar y recibir tráfico. Las otras tres interfaces no tienen ningún direccionamiento IPv4 y están desactivadas.

PROCESOS DE SOLUCIÓN DE PROBLEMAS

Ing. José Dennis Estela Zumaeta OPERACIÓN EN DUPLEX Cuando se trata de comunicación de datos, dúplex se refiere a la dirección de la transmisión de datos entre dos dispositivos. Si las comunicaciones se limitan al intercambio de datos en una dirección por vez, esta conexión se denomina semidúplex. El dúplex completo permite el envío y la recepción de datos simultáneamente. Para un mejor rendimiento de la comunicación, dos interfaces de red Ethernet conectadas deben funcionar en el mismo modo dúplex para evitar la ineficiencia y la latencia en el enlace. La negociación automática de Ethernet se diseñó para facilitar la configuración, para minimizar problemas y maximizar el rendimiento del enlace. Los dispositivos conectados primero anuncian sus capacidades utilizadas y luego eligen el modo de mayor rendimiento soportado por ambos extremos. Por ejemplo, el switch y el router en la Figura 1 negociaron de manera automática y correcta el modo dúplex completo.

Surge una discordancia si uno de los dos dispositivos conectados funciona en modo dúplex completo y el otro funciona en modo semidúplex. Si bien la comunicación de datos se realizará a través de un enlace con una discordancia de dúplex, el rendimiento del enlace será muy deficiente. La discordancia de dúplex puede deberse a la configuración manual incorrecta, que configura manualmente los dos dispositivos conectados a diferentes modos dúplex. La discordancia de dúplex también puede producirse cuando se conecta un dispositivo que realiza la negociación automática con otro que está configurado manualmente en dúplex completo. Si bien no es común, la discordancia de dúplex también puede ocurrir debido a la falla de la negociación automática.

DISCORDANCIA DE DUPLEX Las discordancias de dúplex pueden ser difíciles de resolver mientras se produce la comunicación entre dispositivos. Es posible que no sean evidentes, incluso si se usan herramientas como ping. Los pequeños paquetes individuales no puedan revelar un problema de discordancia de dúplex. Una sesión de terminal que envía los datos lentamente (en ráfagas muy cortas) también podría comunicar con éxito a través de una discordancia de dúplex. Aun cuando cualquier extremo de la conexión intente enviar una cantidad significativa de datos y el rendimiento del enlace caiga considerablemente, la causa puede no ser fácilmente evidente debido a que la red está operativa de otra manera. El CDP, el protocolo de propiedad de Cisco, puede detectar fácilmente una discordancia de dúplex entre dos dispositivos Cisco. Vea la topología en la Figura 1 donde la interfaz G0/0 del R1 se ha configurado en forma errónea para funcionar en modo semidúplex.


El CDP muestra los mensajes de registro del enlace con la discordancia de dúplex. Los mensajes también contienen los nombres de los dispositivos y los puertos involucrados en la discordancia de dúplex, lo cual facilita mucho identificar y solucionar el problema. El ejemplo 1 muestra mensajes de registro de la discordancia de dúplex de CDP.

Nota: Debido a que estos son mensajes de registro, se muestran únicamente en una sesión de consola de manera predeterminada. Usted vería solamente estos mensajes en una conexión remota si se habilita el comando terminal monitor. El ejemplo 2 muestra la configuración dúplex que causó el problema.

Ing. José Dennis Estela Zumaeta PROBLEMAS DE ASIGNACIÓN DE DIRECCIONES IP EN DISPOSITIVOS IOS Los problemas relacionados con la dirección IP probablemente evitarán la comunicación de los dispositivos de redes remotas. Debido a que las direcciones IP son jerárquicas, cualquier dirección IP asignada a un dispositivo de red debe adaptarse al rango de direcciones de esa red. Las direcciones IP asignadas incorrectamente crean una variedad de problemas, incluso conflictos de direcciones IP y problemas de routing. Dos causas comunes de asignación incorrecta de IPv4 son los errores manuales de asignación o los problemas relacionados con DHCP. Los administradores de redes tienen que asignar a menudo las direcciones IP manualmente a los dispositivos como servidores y routers. Si se genera un error durante la asignación, es muy probable que ocurran problemas de comunicación con el dispositivo. En un dispositivo IOS, utilice los comandos show ip interface o show ip interface brief para verificar qué direcciones IPv4 se asignan a las interfaces de red. La topología se muestra en la Figura 1.

El Ejemplo 1 muestra el resultado de show ip interface ejecutado en un R1.

Observe que el comando show ip interface muestra la información de IPv4 (capa 3 del OSI), mientras que el comando anteriormente mencionado show interfaces muestra los detalles físicos y del enlace de datos de una interfaz.

PROBLEMAS DE ASIGNACIÓN DE DIRECCIONES IP EN TERMINALES En las máquinas con Windows, cuando el dispositivo no puede comunicarse con un servidor DHCP, Windows asigna automáticamente una dirección que pertenezca al rango 169.254.0.0/16. Este proceso se diseñó para facilitar la comunicación dentro de la red local. Piense que Windows dice: “Utilizaré esta dirección del rango 169.254.0.0/16 porque no pude obtener ninguna otra dirección”. A menudo, una computadora con rango 169.254.0.0/16 no podrá comunicarse con otros dispositivos en la red porque es probable que dichos dispositivos no pertenezcan a la red

Ing. José Dennis Estela Zumaeta 169.254.0.0/16. Esta situación indica un problema de asignación automática de direcciones IPv4 que debe solucionarse.

Nota: Otros sistemas operativos, como Linux y OS X, no asignarán una dirección IPv4 a la interfaz de red si falla la comunicación con un servidor DHCP. La mayoría de los terminales se configuran para confiar en un servidor DHCP para la asignación automática de direcciones IPv4. Si el dispositivo no puede comunicarse con el servidor DHCP, el servidor no puede asignar una dirección IPv4 para la red específica y el dispositivo no podrá comunicarse. Para verificar las direcciones IP asignadas a una computadora con Windows, utilice el comando ipconfig como se muestra en el Ejemplo 1.

PROBLEMAS CON EL GATEWAY PREDETERMINADO El gateway predeterminado para un terminal es el dispositivo de red más cercano que puede reenviar tráfico a otras redes. Si un dispositivo tiene una dirección de gateway predeterminado incorrecta o inexistente, no podrá comunicarse con los dispositivos de las redes remotas. Dado que el gateway predeterminado es la ruta a las redes remotas, su dirección debe pertenecer a la misma red que el terminal. La dirección del gateway predeterminado se puede configurar u obtener manualmente de un servidor DHCP. Como sucede con los problemas de asignación de direcciones IPv4, los problemas del gateway predeterminado pueden estar relacionados con la configuración incorrecta (en el caso de la asignación manual) o problemas de DHCP (si está en uso la asignación automática). Para resolver los problemas de un gateway predeterminado mal configurado, asegúrese de que el dispositivo tenga configurado el gateway predeterminado correcto. Si la dirección predeterminada fue configurada manualmente pero es incorrecta, simplemente reemplácela por la dirección apropiada. Si la dirección de gateway predeterminado fue configurada automáticamente, asegúrese de que el dispositivo pueda comunicarse correctamente con el servidor DHCP. También es importante verificar que se configuraron la dirección IPv4 y la máscara de subred correspondientes en la interfaz del router y que la interfaz esté activa. Para verificar el gateway predeterminado en las computadoras con Windows, utilice el comando ipconfig, como se muestra en el Ejemplo 1.


En un router, utilice el comando show ip route para mostrar la tabla de routing y verificar que se ha establecido el gateway predeterminado, conocido como ruta predeterminada. Se usa esta ruta cuando la dirección de destino del paquete no coincide con ninguna otra ruta en la tabla de routing. En la figura 1 se muestra que R2 es la ruta predeterminada para R1.

El Ejemplo 2 muestra que el gateway predeterminado se configuró con una ruta predeterminada de 10.1.0.2.

Ing. José Dennis Estela Zumaeta SOLUCIÓN DE PROBLEMAS DE DNS El Servicio de Nombres de Dominio (DNS) es un servicio automatizado que hace coincidir los nombres, como www.cisco.com, con la dirección IP. Aunque la resolución de DNS no es fundamental para la comunicación del dispositivo, es muy importante para el usuario final. Es común que los usuarios relacionen erróneamente el funcionamiento de un enlace de Internet con la disponibilidad del servicio DNS. Las quejas de los usuarios como “la red está inactiva” o “Internet está inactiva” se deben a menudo a un servidor DNS al que no se puede acceder. Aunque los servicios de routing de paquetes y cualquier otro tipo de servicios de red estén todavía operativos, los errores de DNS generalmente llevan al usuario a la conclusión incorrecta. Si un usuario escribe un nombre de dominio como www.cisco.com en un navegador web y no se puede acceder al servidor DNS, el nombre no será traducido a una dirección IP y la página web no se mostrará. Las direcciones del servidor DNS pueden asignarse de manera manual o automática. Los administradores de redes a menudo son responsables de asignar manualmente las direcciones del servidor DNS en servidores y otros dispositivos, mientras que el DHCP se usa para asignar automáticamente las direcciones del servidor DNS a los clientes. Si bien es común que las empresas y las organizaciones administren sus propios servidores DNS, cualquier servidor DNS accesible puede utilizarse para solucionar nombres. Los usuarios de oficinas pequeñas y oficinas en el hogar con frecuencia dependen del servidor DNS que mantiene su ISP para la resolución de nombres. Los servidores DNS mantenidos por un ISP son asignados a los clientes de SOHO mediante DHCP. Por ejemplo, Google mantiene un servidor DNS público que puede ser utilizado por cualquier persona y es muy útil para realizar pruebas. La dirección IPv4 del servidor DNS público de Google es 8.8.8.8 y 2001:4860:4860::8888 para su dirección IPv6 DNS. Utilice el comando ipconfig /all, como se muestra en el Ejemplo 1, para verificar qué servidor DNS es el que utiliza la computadora con Windows.

Ing. José Dennis Estela Zumaeta El comando nslookup es otra herramienta útil para la solución de problemas de DNS para PC. Con nslookup un usuario puede configurar manualmente las consultas de DNS y analizar la respuesta de DNS. El Ejemplo 2 muestra el resultado de nslookup al realizar una consulta para www.cisco.com.

Ing. José Dennis Estela Zumaeta PRINCIPIOS BASICOS DE ROUTING AND SWITCHING - CCNA 2 PUENTE RSE: Descripción general Al finalizar este módulo, estará en condiciones de:    

Configurar rutas estáticas IPv4 especificando una dirección del siguiente salto. Utilizar los protocolos de detección para asignar una topología de red. Configurar el servidor NTP entre un cliente NTP y un servidor NTP. Mantener la configuración del router y del switch y los archivos IOS.

1. RUTAS DE HOST LOCALES INSTALADAS AUTOMATICAMENTE Una ruta de host es una ruta donde la dirección IP de destino es un dispositivo específico con una máscara de subred de /32 para IPv4 o /128 para IPv6. Existen tres maneras de agregar una ruta de host a una tabla de routing   

Instalarla automáticamente cuando se configura una dirección IP en el Router. Configurarla como una ruta de host estático. Obtener la ruta de host automáticamente a través de otros métodos (se analiza en cursos posteriores.

El IOS de Cisco instala automáticamente una ruta de host, también conocida como ruta de host local, cuando se configura una dirección de interfaz en el router. Una ruta host permite un proceso más eficiente para los paquetes que se dirigen al router mismo, en lugar del envío de paquetes. Esto se suma a la ruta conectada, designada con una C en la tabla de routing para la dirección de red de la interfaz. El análisis de las rutas de host utiliza la topología que se muestra en la Figura. 1.

Cuando una interfaz activa en un router se configura con una dirección IP, se agrega automáticamente una ruta de host local a la tabla de routing. Las rutas locales se marcan con “L” en el resultado de la tabla de routing. Las direcciones IP asignadas a la interfaz Branch Serial0/0/0 son 198.51.100.1/30 para IPv4 y 2001:DB8:ACAD:1::1/64 para IPv6. Las rutas locales para la interfaz son instaladas por el IOS en la tabla de routing como se muestra en el resultado del Ejemplo 1 para IPv4 y el Ejemplo 2 para IPv6. Nota: Para IPv4, las rutas locales marcadas con una “L” se introdujeron con la versión 15 de IOS.


2. RUTAS DE HOST CONFIGURADAS MANUALMENTE Una ruta de host puede ser una ruta estática configurada manualmente para dirigir el tráfico a un dispositivo de destino específico, como un servidor de autenticación. La ruta estática utiliza una dirección IP de destino y una máscara 255.255.255.255 (/32) para las rutas de host IPv4 y una longitud de prefijo /128 para las rutas de host IPv6. Las rutas estáticas se marcan con una “S” en el resultado de la tabla de routing. En la topología de la Figura 1, se configuran un IPv4 y una ruta de host IPv6 en el router BRANCH para acceder al servidor.


Desde el router BRANCH, se configuran las rutas de host IPv4 e IPv6 d para enrutar paquetes hasta servidor, como se muestra en el Ejemplo. 1.

Ing. José Dennis Estela Zumaeta Para rutas estáticas IPv6, la dirección del siguiente salto puede ser la dirección link-local del router adyacente. Sin embargo, debe especificar un tipo de interfaz y un número de interfaz cuando usa una dirección link-local como siguiente salto, como se muestra en el Ejemplo 2.

3. DESCRIPCION GENERAL DEL CDP Cisco Discovery Protocol (CDP) es un protocolo de Capa 2 patentado de Cisco que se utiliza para recopilar información sobre los dispositivos Cisco que comparten el mismo enlace de datos. El CDP es independiente de los medios y del protocolo y se ejecuta en todos los dispositivos Cisco, como routers, switches y servidores de acceso. El dispositivo envía mensajes periódicos del CDP a los dispositivos conectados. Estos mensajes comparten información sobre el tipo de dispositivo que se descubre, el nombre de los dispositivos, y la cantidad y el tipo de interfaces. Debido a que la mayoría de los dispositivos de red se conectan a otros dispositivos, el CDP puede ayudar a tomar decisiones de diseño, solucionar problemas, y realizar cambios en el equipo. El CDP se puede utilizar como herramienta de análisis de redes para conocer información sobre los dispositivos vecinos. Esta información recopilada del CDP puede ayudar a crear una topología lógica de una red cuando falta documentación o detalles.

Ing. José Dennis Estela Zumaeta 3.1. CONFIGURA CONFIGURACIÓN CIÓN Y VERIFICACIÓN DEL CDP Para los dispositivos Cisco, el CDP está habilitado de manera predeterminada. Por motivos de seguridad, puede ser conveniente deshabilitar el CDP en un dispositivo de red de manera global, o por interfaz. Con el CDP, un atacante puede recolectar información valiosa sobre el diseño de la red, como direcciones IP, versiones de IOS, y tipos de dispositivo dispositivos. s. Para verificar el estado del CDP y mostrar información sobre el mismo, introduzca el comando show cdp, como se muestra en el Ejemplo 1.

Para habilitar el CDP globalmente para todas las interfaces admitidas en el dispositivo, ingrese cdp run en el modo de configuración global. El CDP se puede deshabilitar en todas las interfaces del dispositivo con el comando no cdp run en el modo de configuración configura ción global. Para deshabilitar el CDP en una interfaz específica, como la interfaz orientada a un ISP, ingrese no cdp enable en el modo de configuración de interfaz. int erfaz. El CDP aún se encuentra habilitado en el dispositivo; sin embargo, no se enviarán más mensajes a la interfaz. Para habilitar el CDP en una interfaz específica nuevamente, ingrese cdp enable, como se muestra en el Ejemplo 2.

El ejemplo 3 muestra el CDP inhabilitado globalmente mediante el comando no cdp run y habilitado nuevamente mediante el comando cdp run.

Para verificar el estado del CDP y mostrar una lista de vecinos, utilice el comando show cdp neighbors en modo EXEC privilegiado. El comando show cdp neighbors muestra información importante acerca de los vecinos del CDP. Actualmente, este dispositivo no tiene vecinos porque no está físicamente conectado a ningún dispositivo, como lo indican los resultados del comando show cdp neighbors que se muestran en el Ejemplo 4.


Utilice el comando show cdp interface para mostrar las interfaces que están habilitadas en CDP en el dispositivo. También se muestra el estado de cada interfaz. El Ejemplo 5 muestra que cinco interfaces están habilitadas en el CDP en el router solamente con una conexión activa a otro dispositivo.


3.2. DETECCIÓN DE DISPOSI DISPOSITIVOS TIVOS CON CDP Con el CDP habilitado en la red, el comando show cdp neighbors se puede utilizar para determinar el diseño de la red. Por ejemplo, considere la falta de documentación en la topología de la Figura 1. No hay información disponible relacionada con el resto de la red.

El comando show cdp neighbors brinda información sobre cada dispositivo vecino en el CDP:  





Identificadores de dispositivos - El nombre de host del dispositivo vecino ( S1) Identificador de puerto - El nombre del puerto local y remoto ( Gig 0/1 y Fas 0/5, respectivamente). Lista de funcionalidades - Si el dispositivo es un router o un switch ( S para el switch; I para IGMP está más allá del ámbito de este curso). Plataforma - La plataforma de hardware del dispositivo ( WS-C2960 para el switch Cisco 2960)

Si se necesita más información, el comando show cdp neighbors también puede ofrecer información, como la versión y la dirección IP del IOS de los vecinos, como se muestra en el Ejemplo 2.


Al tener acceso al S1 de manera remota a través de SSH o físicamente a través del puerto de consola, un administrador de redes puede determinar los otros dispositivos conectados a S1, como se muestra en el resultado de show cdp neighbors en el Ejemplo 3.

Otro switch, S2, se revela en el resultado. El administrador de redes después tiene acceso al S2 y muestra los vecinos del CDP, como se muestra en el Ejemplo 4.


El único dispositivo conectado al S2 es el S1. Por lo tanto, no hay más dispositivos a descubrir en la topología. El administrador de redes ahora puede actualizar la documentación para reflejar los dispositivos detectados, como se muestra en la Figura 2.

Ing. José Dennis Estela Zumaeta CONFIGURAR Y VERIFICAR CDP

Ing. José Dennis Estela Zumaeta 3.3. 4. DESCRIPCION GENERAL DE LLDP Los dispositivos Cisco también admiten protocolo de detección de capa de enlace (LLDP), que es un protocolo neutro de detección de vecinos de un proveedor similar al CDP. El LLDP funciona con los dispositivos de red, como routers, switches, y puntos de acceso inalámbrico LAN. Este protocolo informa su identidad y capacidades a otros dispositivos y recibe información de un dispositivo físicamente conectado de capa 2.

4.1. CONFIGURACION Y VERIFICACION DE LLDP En algunos dispositivos, el LLDP podría estar activado de manera predeterminada. Para habilitar el LLDP de manera global en un dispositivo de red Cisco, introduzca el comando lldp run en el modo de configuración global, como se muestra en el Ejemplo 1. Para deshabilitar el LLDP, ingrese el comando no lldp run en el modo de configuración global.

Al igual que el CDP, el LLDP se puede configurar en interfaces específicas. Sin embargo, el LLDP se debe configurar de manera independiente para transmitir y recibir paquetes LLDP, como se muestra en el Ejemplo 2.

Para verificar que el LLDP esté activado en el dispositivo, ingrese el comando show lldp en modo EXEC privilegiado, como se muestra en el Ejemplo 3.

Ing. José Dennis Estela Zumaeta 4.2. DETECCION DE DISPOSITIVOS CON LLDP Cuando LLDP está activado, se pueden detectar los vecinos del dispositivo mediante el comando show LLDP neighbors. Por ejemplo, considere la falta de documentación en la topología de la Figura 1. El administrador de redes solo sabe que el S1 está conectado a dos dispositivos.

Mediante el comando show lldp neighbors, como se muestra en el Ejemplo 1, el administrador de redes detecta que el S1 tiene un router y un switch como vecinos.

La letra B en capacidad de S2 representa un puente (Bridge). Para este resultado, la palabra puente también puede significar el switch. A partir de los resultados de show lldp neighbors, se puede construir una topología del switch S1 como se ilustra en la Figura 2.

Ing. José Dennis Estela Zumaeta Cuando se necesitan más detalles acerca de los vecinos, el comando show llldp neighbors puede proporcionar información, como versión de IOS, dirección IP, y capacidad del dispositivo IOS de los vecinos, como se muestra en el Ejemplo 2.

CONFIGURAR Y COMPROBAR LLDP



5. CONFIGURACION DEL RELOJ DEL SISTEMA – NTP El reloj de software de un router o un switch se inicia cuando arranca el sistema y es de donde el sistema extrae la hora. Es importante sincronizar la hora en todos los dispositivos de la red porque todos los aspectos de administración, seguridad, solución de problemas, y planificación de redes requieren una marca de hora precisa. Cuando no se sincroniza la hora entre los dispositivos, será imposible determinar el orden de los eventos y la causa de un evento. Generalmente, las configuraciones de fecha y hora en un router o un switch se pueden configurar de una de las siguientes maneras: Configurar el día y la hora de manera manual. Configurar protocolo de tiempo de red (NTP).  

El Ejemplo 1 muestra cómo configurar manualmente el reloj en un dispositivo Cisco.

A medida que una red crece, se hace difícil garantizar que todos los dispositivos de infraestructura operen con una hora sincronizada. Incluso en un entorno de red más pequeño, el método manual no es lo ideal. ¿Cómo obtener una fecha y una marca de hora precisas si se reinicia un router? Una mejor solución consiste en configurar el NTP en la red. Este protocolo permite que los Routers de la red sincronicen la configuración de la hora con un servidor NTP. Si un grupo de clientes de NTP obtiene información de fecha y hora de un único origen, tiene una configuración de tiempo más coherente. Cuando el NTP se implementa en la red, se puede configurar para sincronizarse con un reloj maestro privado o se puede sincronizar con un servidor NTP disponible al público en Internet. El NTP utiliza el puerto UDP 123 y se registra en RFC 1305.

Ing. José Dennis Estela Zumaeta 5.1. FUNCIONAMIENTO DEL NTP Las redes NTP utilizan un sistema jerárquico de fuentes horarias. Cada nivel en este sistema jerárquico se denomina estrato. El nivel de estrato se define como la cantidad de saltos desde fuente autorizada. La hora sincronización se distribuye en la red mediante el protocolo NTP. La Figura 1 muestra una red NTP.

Estrato 0 Una red NTP obtiene la hora de fuentes horarias autorizadas. Estas fuentes autorizadas, conocidas como dispositivos de estrato 0, son dispositivos de cronometraje de alta precisión que son presuntamente precisos y con poco o ningún retraso asociado con los mismos. Los dispositivos del estrato 0 están representados por el reloj en la Figura 1.

Estrato 1 Los dispositivos del estrato 1 están conectados directamente a las fuentes horarias válidas. Actúan como el estándar horario de la red principal.

Estrato 2 y más bajos Los servidores del estrato 2 están conectados a dispositivos del estrato 1 a través de conexiones de red. Los dispositivos del estrato 2, como clientes de NTP, sincronizan su horario con los paquetes NTP desde servidores del estrato 1. Podrían también actuar como servidores para dispositivos del estrato 3. Los números más bajos de estratos indican que el servidor está más cerca de la fuente horaria autorizada que los números de estrato más altos. Cuanto mayor sea el número de estrato, menor es el nivel del estrato. El recuento de saltos máximo es 15. El estrato 16, el nivel de estrato inferior, indica que un dispositivo no está sincronizado. Los servidores horarios en el mismo nivel de estrato pueden configurarse para actuar como

Ing. José Dennis Estela Zumaeta un par con otros servidores horarios en el mismo nivel de estratos para la verificación o la copia de respaldo del horario.

5.2. CONFIGURACION Y VERIFICACION DEL NTP Se utiliza un servidor NTP externo como fuente horaria autorizada para la red que se describe en la Figura 1. El R1 está configurado para sincronizar su reloj con el servidor NTP externo, y el reloj en el S1 está configurado para sincronizarse con el R1 mediante NTP. Los otros dispositivos en la red están configurados para sincronizar sus relojes con el R1 o el S1 como fuente horaria.

Antes de que se configure el NTP en la red, el comando show clock muestra la hora actual en el reloj del software. Con la opción detail, también se muestra la fuente horaria. Como se muestra en el Ejemplo 1, el reloj del software se configuró manualmente.

Como se muestra en el Ejemplo 2, utilice el comando ntp server ip-address en el modo de configuración global para configurar en 209.165.200.225 como el servidor NTP para el R1.

Para verificar que la fuente horaria está configurada con el NTP, utilice el comando show clock detail , como en el Ejemplo 3.


Utilice los comandos show ip ntp associations y show ntp status para verificar que R1 esté sincronizado con el servidor NTP en 209.165.200.225, como se muestra en el Ejemplo 4. Observe que el R1 está sincronizado con un servidor NTP de estrato 1 en 209.165.200.225, que se sincroniza con un reloj GPS. El comando show ntp statusmuestra que el R1 ahora es un dispositivo de estrato 2 sincronizado con el servidor NTP en 209.165.220.225.

El reloj en el S1 está configurado para sincronizarse con el R1. El reloj en el S1 está configurado en la misma zona horaria y con las configuraciones horarias de verano que el router R1, como se muestra en el Ejemplo 5.

El ejemplo 6 muestra que el reloj en el S1 ahora está sincronizado con el R1 en 192.168.1.1 mediante NTP. El R1 es un dispositivo de estrato 2 y un servidor NTP para el S1. Ahora el S1 es un dispositivo de estrato 3 que puede proporcionar el servicio NTP a otros dispositivos en la red, por ejemplo terminales.


5.3. CONFIGURAR Y COMPROBAR NTP


6. RECUPÉRACION DE CONTRASEÑAS Las contraseñas de los dispositivos se utilizan para evitar el acceso no autorizado. Las contraseñas encriptadas, como las contraseñas "enable secret", se deben reemplazar después de su recuperación. De acuerdo con el dispositivo, el procedimiento detallado para la recuperación de contraseñas varía; sin embargo, todos los procedimientos de recuperación de contraseñas siguen el mismo principio:

Paso 1. Ingresar en el modo ROMMON. Paso 2. Cambiar el registro de configuración a 0x2142 para ignorar el archivo de configuración de inicio. Paso 3. Realizar los cambios necesarios en el archivo original de configuración de inicio. Paso 4. Guardar la configuración nueva. Para la recuperación de contraseñas, se requiere el acceso a la consola del dispositivo a través de un terminal o el software emulador de terminal en una PC. Las configuraciones de terminal para acceder al dispositivo son: 

9600 velocidades en baudios.



Sin paridad.

  

8 bits de datos. 1 bit de parada. Sin control de flujo.

Con el acceso a la consola, el usuario puede acceder al modo ROMMON mediante una secuencia de interrupción durante el proceso de arranque o eliminando la memoria flash externa cuando el dispositivo está apagado.

Nota: La secuencia de interrupción para PuTTY es Ctrl+Break. Puede encontrar una lista de secuencias estándar de la tecla de pausa interna (Break) para otros emuladores de terminal y sistemas operativos en http://www.cisco.com/c/en/us/support/docs/routers/10000-series-routers/1281861.html (Enlaces a un sitio externo.) El software ROMMON admite algunos comandos básicos, como confreg. El comando confreg 0x2142 permite que el usuario configure el registro de configuración a 0x2142. Con el registro de configuración en 0x2142, el dispositivo ignorará el archivo de

Ing. José Dennis Estela Zumaeta configuración de inicio durante el arranque. El archivo de configuración de inicio es donde se almacenan las contraseñas olvidadas. Después de configurar el registro de configuración en 0x2142, escriba reset en la petición de entrada para reiniciar el dispositivo. Introduzca la secuencia de interrupción mientras el dispositivo está reiniciando y descomprimiendo el IOS. El Ejemplo 1 muestra el resultado para el terminal de un router 1941 en modo ROMMON después de usar una secuencia de interrupción durante el proceso de arranque.

Después de que el dispositivo haya finalizado la recarga, copie la configuración de inicio (startup-config) a la configuración en ejecución (running-config), como se muestra en el Ejemplo 2.

PRECAUCIÓN: No introduzca copy running-config startup-config. Este comando borra la configuración de inicio original. Dado que está en el modo EXEC privilegiado, ahora puede configurar todas las contraseñas necesarias. Una vez que se configuran las nuevas contraseñas, cambie el registro de configuración a 0x2102 mediante el comando config-register 0x2102 en el modo de configuración global. Guarde la configuración en ejecución (running-config) en la configuración de inicio (starup-config) y vuelva a cargar el dispositivo, como se muestra en el Ejemplo 3.


Nota: La contraseña cisco no es una contraseña segura y se utiliza aquí solo como ejemplo. El dispositivo ahora utiliza las contraseñas para autenticación recién configuradas. Asegúrese de utilizar los comandos show para verificar que todas las configuraciones están en su lugar. Por ejemplo, verifique que las interfaces adecuadas no estén apagadas después de recuperar la contraseña. El siguiente enlace proporciona instrucciones detalladas para el procedimiento de recuperación de contraseñas para un dispositivo específico: http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-software-releases-121mainline/6130-index.html (Enlaces a un sitio externo.)

6.1.RECUPERACIÓN DE LA CONTRASEÑA DE UN ROUTER


Ing. José Dennis Estela Zumaeta ESCALAMIENTO DE REDES – CCNA 3 PUENTE SCAN: DESCRIPCION GENERAL Al finalizar este módulo, estará en condiciones de:       

 

Comparar las versiones de VTP 1 y 2. Configurar las versiones de VTP 1 y 2. Configurar las VLAN extendidas. Configurar el protocolo de enlace troncal dinámico (DTP). Solucionar problemas comunes de configuración entre VLAN. Solucionar problemas de VTP y DTP comunes en una red de router inter-VLAN. Explicar el valor de apilamiento de switch y de agregación del chasis en una LAN pequeña conmutada. Implementar HSRP. Resolver problemas de entradas de rutas faltantes en las tablas de routing OSPFv2 y OSPFv3 multiárea.

1. DESCRIPCION GENERAL DE VTP A medida que aumenta el número de Switches en una red de empresas pequeñas o medianas, la administración general requerida para administrar las VLAN y los enlaces troncales en una red se convierte en un desafío. Considere la red de la Figura 1.

Suponga que las VLAN 10, 20, y 99 ya se implementaron y debe agregar ahora VLAN 30 a todos los switches. Agregar la VLAN manualmente en esta red incluiría la configuración de switches 12. En redes más grandes, la administración de VLAN puede volverse desalentadora. El protocolo de troncal VLAN (VTP) permite que un administrador de redes maneje las VLAN en un switch configurado como servidor VTP. El servidor VTP distribuye y sincroniza la información de la VLAN en los enlaces troncales a los switches habilitados por el VTP en toda la red conmutada. Esto minimiza los problemas causados por las configuraciones incorrectas y las inconsistencias de configuración.

Nota: El VTP solo aprende sobre las VLAN de rango normal (ID de VLAN 1 a 1005). Las VLAN de rango extendido (ID mayor a 1005) no son admitidas por la versión 1 o versión 2 de VTP. La versión 3 del VTP admite VLAN extendidas, pero no entra dentro del ámbito de este curso.

Ing. José Dennis Estela Zumaeta Nota: El VTP guarda configuraciones VLAN en una base de datos llamada vlan.dat. La Tabla 1 ofrece una breve descripción de los componentes principales del VTP.

Nota: Las publicaciones del VTP no se intercambiarán si el enlace troncal entre los Switches está inactivo.

1.1. VTP MODOS Un switch se puede configurar en uno de los tres modos VTP, como se describe en la Tabla 1.

La Tabla 2 resume los tres modos de VTP.


Nota: Un switch que está en modo servidor o modo cliente con un número de revisión de configuración más alto que el servidor VTP existente actualiza toda la información de la VLAN en el dominio VTP. Los números de revisión de configuración se analizan más adelante en este capítulo.

1.2. PUBLICACIONES DE VTP El VTP emite tres tipos de publicaciones: 





Publicaciones de resumen: informan a los switches adyacentes el nombre de dominio del VTP y el número de revisión de configuración. Solicitud de publicación: responde a un mensaje de publicación de resumen cuando la publicación de resumen contiene un número de revisión de configuración más alto que el valor actual. Publicaciones de subgrupos: contienen información de VLAN incluido cualquier cambio.

De forma predeterminada, los switches Cisco ejecutan publicaciones de resumen cada cinco minutos. Las publicaciones de resumen informan a los switches del VTP adyacentes el nombre de dominio de VTP actual y el número de revisión de la configuración. El número de revisión de la configuración es un número de 32 bits que indica el nivel de revisión para un paquete VTP. Cada dispositivo de VTP rastrea el número de revisión de configuración del VTP que se le asigna. Esta información se utiliza para determinar si la información recibida es más reciente que la versión actual. Cada vez que modifica una VLAN en un dispositivo VTP, la revisión de la configuración se incrementa en uno. Nota : Para reiniciar una revisión de configuración en un switch, cambie el nombre de dominio VTP, y luego vuelva a cambiarlo al nombre original. Cuando un switch recibe un paquete de publicación de resumen, compara el nombre de dominio de VTP con su propio nombre de dominio de VTP. Si el nombre es diferente, el switch simplemente ignora el paquete. Si el nombre es el mismo, el switch compara la

Ing. José Dennis Estela Zumaeta revisión de configuración con su propia revisión. Si el número de revisión de la configuración es mayor o igual al número de revisión de configuración del paquete, se ignora el paquete. Si el número de revisión de la configuración es más bajo, se envía una solicitud de publicación que solicita para el mensaje de publicación del subgrupo. El mensaje de publicación de subgrupo contiene información de la VLAN con cualquier cambio. Al agregar, eliminar o cambiar una VLAN en el servidor VTP, el servidor del VTP aumenta la revisión de configuración y emite una publicación de resumen. Una o varias publicaciones de subgrupos siguen la publicación de resumen que incluye la información de VLAN que incluye cualquier cambio. El proceso se muestra en la Figura 1.

1.3. VERSIONES DE VTP La versión 1 y la versión 2 de VTP se describen en la Tabla 1. Los switches en el mismo dominio VTP deben utilizar la misma versión de VTP.

Nota: El VTPv2 no es muy diferente del VTPv1 y generalmente solo se configura si se requiere soporte para Token Ring antiguo. La última versión de VTP es la versión 3. Sin embargo, la versión 3 de VTP no entra dentro del ámbito de este curso.

Ing. José Dennis Estela Zumaeta 1.4. CONFIGURACION PREDETERMINADA DEL VTP El comando EXEC privilegiado show vtp status muestra el estado del VTP. La ejecución del comando en un switch Cisco 2960 Plus genera el resultado que se muestra en el Ejemplo 1.

La Tabla 1 describe brevemente los parámetros show VTP status.


1.5. ADVERTENCIAS SOBRE VTP Algunos administradores de redes evitan el VTP porque podría presentar información errónea de la VLAN en el dominio VTP existente. Se utiliza el número de revisión de configuración para determinar si un switch debe mantener su base de datos de VLAN existente, o sobrescribirla con la actualización del VTP enviada por otro switch en el mismo dominio con la misma contraseña. Agregar un switch con VTP habilitado a un dominio de VTP existente borrará las configuraciones de la VLAN existente en el dominio si el nuevo switch se configura con distintas VLAN y tiene un número de revisión de configuración más alto que el servidor VTP existente. El nuevo switch puede ser servidor VTP o switch de cliente. Esta propagación puede ser difícil de corregir. Por lo tanto, cuando un switch se agrega a una red, asegúrese de que tenga la configuración predeterminada del VTP

Ing. José Dennis Estela Zumaeta Un ejemplo es la red que ejecuta el VTP en la Figura 1

El switch S1 es el servidor VTP mientras que los switches S2 y S3 son clientes VTP. Todos los switches están en el dominio cisco1 y la versión actual del VTP es 17. Además de la VLAN 1 predeterminada, el servidor VTP (S1) tiene las VLAN 10 y 20 configuradas. Estas VLAN fueron propagadas por el VTP a los otros dos switches. Un técnico de redes agrega el S4 a la red debido a la necesidad de contar con capacidad adicional. Sin embargo, el técnico no borró la configuración de inicio o eliminó el archivo VLAN.DAT en el S4. El S4 tiene el mismo nombre de dominio VTP configurado que los otros dos switches pero su número de revisión es 35, que es un número más alto que el número de revisión en los otros dos switches. El S4 tiene VLAN 1 y se configura con la VLAN 30 y 40. Pero no tiene las VLAN 10 y 20 en la base de datos. Desafortunadamente, debido a que el S4 tiene un número de revisión más alto, el resto de los switches en el dominio se sincronizarán con la revisión del S4. Como consecuencia las VLAN 10 y 20 no existirán más en los switches, lo que deja sin conectividad a los clientes que están conectados a los puertos que pertenecen a VLAN no existentes. El número de revisión de configuración del VTP se almacena en la NVRAM (o Flash en algunas plataformas) y no se restablece si borra la configuración del switch y lo vuelve a cargar. Para restablecer el número de revisión de configuración del VTP en cero tiene dos opciones: 



Cambie el dominio VTP del switch a un dominio VTP inexistente y luego vuelva a cambiar el dominio al nombre original. Cambie al modo VTP del switch al modo transparente y luego vuelva al modo anterior del VTP.

Nota: Los comandos para restablecer el número de revisión de configuración del VTP se analizan en el próximo tema.

Ing. José Dennis Estela Zumaeta 1.6. CONCEPTOPS Y OPERACIONES DE VTP

1.7. DESCRIPCION GENERAL DE LA CONFIGURACION DEL VTP Complete los siguientes pasos para configurar el VTP:

Paso 1: Configure el servidor VTP En la Figura 1, se muestra la topología de referencia para configurar y verificar una implementación de VTP. El switch S1 será el servidor VTP mientras que el S2 y el S3 serán los clientes.

Confirme que todos los switches están configurados con las configuraciones predeterminadas para evitar cualquier problema con los números de revisión de

Ing. José Dennis Estela Zumaeta configuración. Configure el S1 como servidor VTP con comandos de configuración global vtp mode server , como se muestra en el Ejemplo 1.

Escriba el comando show vtp status para confirmar que el S1 es el servidor VTP, como se muestra en el Ejemplo 2.

Observe que el número de revisión de configuración todavía está configurado en 0 y la cantidad de VLAN existentes es 5. Esto sucede porque no se configuró ninguna VLAN todavía y el switch no pertenece a un dominio VTP. Las 5 VLAN son la VLAN 1 predeterminada y las VLAN 1002-1005

Ing. José Dennis Estela Zumaeta Paso 2: Configure el nombre de dominio y la contraseña del VTP. En la Figura 1, se muestra la topología de referencia para configurar y verificar una implementación de VTP. El switch S1 será el servidor VTP mientras que el S2 y el S3 serán los clientes.

El nombre de dominio está configurado con el comando de configuración global vtp domain domain-name . En el ejemplo 1, el nombre de dominio se configura como CCNAen el S1. El switch S1 luego envía una publicación del VTP al S2 y el S3. Si el S2 y el S3 tienen la configuración predeterminada con el nombre de dominio NULL, entonces ambos switches aceptarán CCNA como el nuevo nombre de dominio del VTP. El cliente VTP debe tener el mismo nombre de dominio que el servidor del VTP antes de que acepte las publicaciones del VTP.

Por razones de seguridad, se debe configurar una contraseña usando el comando vtp password. En el Ejemplo 2, la contraseña de dominio del VTP se configura en cisco12345 . Todos los switches en el dominio del VTP deben utilizar la misma contraseña de dominio del VTP.


Paso 3: Configure los clientes VTP En la Figura 1, se muestra la topología de referencia para configurar y verificar una implementación de VTP. El switch S1 será el servidor VTP mientras que el S2 y el S3 serán los clientes.

Configure S2 y S3 como clientes VTP en el dominio CCNA utilizando la contraseña de VTP cisco12345 . La configuración para el S2 se muestra en el Ejemplo 1. El S3 tiene una configuración idéntica.

Ing. José Dennis Estela Zumaeta Paso 4: Configure la VLAN en el servidor VTP. En la Figura 1, se muestra la topología de referencia para configurar y verificar una implementación de VTP. El switch S1 será el servidor VTP mientras que el S2 y el S3 serán los clientes.

Actualmente no hay ninguna VLAN configurada en el S1 con excepción de las VLAN predeterminadas. Configure 3 VLAN, como se muestra en el Ejemplo 1.


Observe que las 3 VLAN ahora están en la base de datos de VLAN. Verifique el estado del VTP, como se muestra en el Ejemplo 3.

Ing. José Dennis Estela Zumaeta Observe que el número de revisión de configuración se incrementó seis veces a partir del valor predeterminado de 0 a 6. Esto es porque se agregaron tres nuevas VLAN con nombre. Cada vez que el administrador realiza un cambio en la base de datos de VLAN del servidor VTP, este número se incrementará en uno. La cantidad aumentó en uno cuando se agregó la VLAN y en uno cuando se configuró el nombre para la VLAN.

Paso 5: Verifique que los clientes VTP hayan recibido la nueva información de la VLAN En la Figura 1, se muestra la topología de referencia para configurar y verificar una implementación de VTP. El switch S1 será el servidor VTP mientras que el S2 y el S3 serán los clientes.

En el S2, verifique que las VLAN configuradas en el S1 se hayan recibido y se hayan ingresado en la base de datos de VLAN en el S2, como se muestra en el Ejemplo 1.

Ing. José Dennis Estela Zumaeta Tal como se previó, las VLAN configuradas en el servidor VTP se han propagado al S2. Verifique el estado del VTP en el S2, como se muestra en el Ejemplo 2.

Observe que el número de revisión de configuración en el S2 es el mismo que el número del servidor VTP. Debido a que el S2 opera en modo cliente VTP, no se permiten los intentos para configurar las VLAN, como se muestra en el Ejemplo 3.

1.8. CONFIGURAR Y COMPROBAR VTP


Ing. José Dennis Estela Zumaeta 2. VLAN NORMALES Y EXTENDIDAS Las VLAN se dividen en VLAN de rango normal o de rango extendido como se describe en la Tabla 1.

Nota: Un switch Cisco Catalyst 2960 puede admitir hasta 255 VLAN de rango normal y rango extendido. Sin embargo, la cantidad de VLAN configurada afectará el rendimiento del hardware del switch. El Ejemplo 1 muestra que, de manera predeterminada, un switch Catalyst 2960 Plus no admite VLAN extendidas.

Si se requiere una VLAN extendida, el switch debe configurarse como un dispositivo con VTP transparente. El Ejemplo 2 muestra cómo crear una VLAN de rango extendido.

Ing. José Dennis Estela Zumaeta Utilice el comando show vlan brief para verificar que se creó la VLAN, como se muestra en el Ejemplo 3

El resultado confirma que se configuró la VLAN extendida 2000 y está activa.

2.1. CONFIGURAR Y COMPROBAR UNA VLAN EXTENDIDA

Ing. José Dennis Estela Zumaeta 3. MODOS DE ENLACE TRONCAL DEL DTP El protocolo de enlace troncal dinámico (DTP) ayuda a los switches a negociar y establecer los enlaces troncales 802.1Q. El DTP es un protocolo patentado por Cisco. Un puerto de switch en un switch de Cisco admite varios modos de enlaces troncales. El modo de enlace troncal define la manera en la que el puerto negocia mediante la utilización del DTP para configurar un enlace troncal con su puerto par. El DTP se configura mediante el comando de configuración de interfaz switchport mode{access | dynamic {auto | desirable} | trunk} . Las opciones del comando se describen en la Tabla 1.

El Ejemplo 1 muestra varios comandos de puerto del DTP.

La Tabla 2 muestra las combinaciones resultantes del modo troncal del DTP.


Nota: El DTP también puede deshabilitarse en una interfaz con el comando de configuración de interfaz switchport nonnegotiate. 3.1.ELIMINACION DE LA VLAN A veces, es necesario eliminar una VLAN de la base de datos de VLAN. Al eliminar una VLAN de un switch que está en el modo servidor VTP, la VLAN se elimina de la base de datos de VLAN para todos los switches del dominio VTP. Cuando elimina una VLAN de un switch que está en modo VTP transparente, la VLAN se elimina solo en ese switch o pila de switch específica.

Nota: No puede eliminar VLAN predeterminadas (es decir, VLAN 1, 1002 a 1005). La siguiente situación ilustra cómo eliminar una VLAN. Suponga que el S1 tiene configuradas las VLAN 10, 20, y 99, como se muestra en el Ejemplo 1.


Observe que la VLAN 99 está asignada a los puertos Fa0/18 a Fa0/24 Para eliminar una VLAN, utilice el comando de modo de configuración global no vlanvlan-id . El Ejemplo 2 muestra cómo eliminar la VLAN 99 en el S1 y verificar que se haya eliminado la VLAN 99.

Ing. José Dennis Estela Zumaeta Cuando elimina una VLAN, cualquier puerto asignado a esa VLAN queda inactivo. Este sigue asociado con la VLAN (y por eso está inactivo) hasta que lo asigna a una nueva VLAN. Observe que las interfaces Fa0/18 a 0/24 ya no se enumeran en las asignaciones de VLAN. Todo puerto que no se ha movido a una VLAN activa no puede comunicarse con otras estaciones luego de eliminar la VLAN. Por lo tanto, antes de borrar una VLAN, reasigne todos los puertos de miembros a una VLAN distinta

3.2.SOLUCION DE PROBLEMAS DEL DTP Los problemas de los enlaces troncales están relacionados con las configuraciones incorrectas. Según la Tabla 1, hay tres problemas comunes asociados con los enlaces troncales.

3.3.SOLUCION DE PROBLEMAS DEL VTP Los problemas comunes con el VTP se enumeran en la Tabla 1:


Ing. José Dennis Estela Zumaeta 4. CONCEPTOS PARA EL APILAMIENTO APILAMIENTO DE SWITCHES Una pila de switch puede contener hasta nueve switches Catalyst 3750 conectados a través de sus puertos StackWise. Uno de los switches controla la operación de la pila y se denomina switch maestro de la pila. El switch maestro de la pila y otros switches de la pila son miembros de la pila. Los protocolos de capa 2 y capa 3 presentan la pila de switch completa como una sola entidad para la red. La Figura 1 muestra la placa de circuito de cuatro switches Catalyst 3750 y cómo están conectados en una pila.

Cada miembro se identifica mediante su propio número de miembro de la pila. Todos los miembros se pueden elegir como maestros. Si el maestro deja de estar disponible, existe un proceso automático para escoger un nuevo switch maestro entre los miembros de la pila restantes. Uno de los factores es el valor de prioridad de miembro de la pila. El switch con el valor de prioridad más alto de miembro de la pila se convierte en maestro. Uno de los beneficios principales de una pila de switch es que usted administra la pila mediante una única dirección dirección IP. La L a dirección IP es una configuración a nivel del sistema y no es específica para el maestro u otro miembro. Puede administrar la pila a través de la misma dirección IP incluso si se quita el maestro o cualquier otro miembro de la pila. El maestro contiene archivos guardados y de configuración de ejecución para la pila. Por lo tanto, hay solo un archivo de configuración a administrar y mantener. Los archivos de configuración incluyen las configuraciones del nivel de sistema para la pila y las configuraciones de nivel de interfaz para cada miembro. Cada miembro tiene una copia actual de estos archivos como respaldo. El switch se administra como switch único incluidas las contraseñas, VLAN e interfaces. El Ejemplo 1 muestra las interfaces en una pila de switches con cuatro switches de 52 puertos. Observe que el primer número luego del tipo de interfaz es el número de miembro de la pila.


4.1. ARBOL DE EXPANSIÓN Y PILAS DE SWITCH Otro beneficio del apilado de switch es la capacidad de agregar más switches a una única instancia del STP sin aumentar el diámetro del STP. El diámetro es la cantidad máxima de switches que debe atravesar para conectar dos switches. El IEEE recomienda un diámetro máximo de siete switches para los temporizadores de STP predeterminados. Por ejemplo, en la Figura 1 el diámetro de S1-4 a S3-4 es de nueve switches. Este diseño infringe la recomendación de IEEE.


El diámetro recomendado se basa en los valores de los temporizadores de STP predeterminados, que son los siguientes:   

Temporizador de saludo (2 segundos): el intervalo entre las actualizaciones de BPDU. Temporizador de edad máxima (20 segundos): la cantidad máxima de tiempo que un switch guarda información de BPDU. Temporizador de retraso en el envío (15 segundos): el tiempo que transcurre en los estados de escuchar y aprender.

Nota: Las fórmulas usadas para calcular el diámetro exceden el ámbito de este curso. Consulte el siguiente documento de Cisco para obtener más información::http://ww información http://www.cisco.co w.cisco.com/c/en/us/suppor m/c/en/us/support/docs/lan-switchin t/docs/lan-switching/spanning-tre g/spanning-treeeprotocol/19120-122.html Las pilas de switch ayudan a mantener o reducir el impacto del diámetro en la reconvergencia del STP. En una pila de switch, todos los switches utilizan el mismo ID de puente para una instancia de árbol de expansión determinada. Esto significa que, si los switches de la Figura 1 están apilados, como se muestra en la Figura 2, el diámetro máximo es de 3 en lugar de 9.


Recursos: Administración de pilas de switch. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/releas e/15-0_2_se/configuration/guide/scg3750/swstack.html (Enlaces a un sitio externo.) Configuración del STP. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3750/software/release/ 15-0_2_se/configuration/guide/scg3750/swstp.html (Enlaces a un sitio externo.) Instalación del switch. http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/hardware/instal lation/guide/b_c3850_hig/b_c3850_hig_chapter_010.html (Enlaces a un sitio externo.)

4.2. IDENTIFICAR LOS CONCEPTOS DE APILAMIENTO DEL SWITCH

Ing. José Dennis Estela Zumaeta 5. DESCRIPCION GENERAL DE HSRP El Protocolo de router de reserva activa (HSRP) fue diseñado por Cisco para permitir la redundancia de gateway sin una configuración adicional de los terminales. Los routers configurados con HSRP funcionan en conjunto para funcionar como un único gateway predeterminado virtual (router) para los terminales, como se muestra en la Figura 1. El HSRP selecciona uno de los routers para que sea el router activo. El router activo actuará como gateway predeterminado para los terminales. El otro router será el router de reserva. Si falla el router activo, el router de reserva asumirá automáticamente el rol de router activo. Asumirá la función del gateway predeterminado para los terminales. No se requieren cambios de configuración en los terminales.

El router activo del HSRP y el router de reserva presentan a una única dirección de gateway predeterminado a los terminales. La dirección de gateway predeterminado es una dirección IP virtual junto con una dirección MAC virtual compartida entre ambos routers HSRP. Los terminales utilizan esta dirección IP virtual como su dirección de gateway predeterminado. El administrador de redes configura la dirección IP virtual del HSRP. La dirección MAC virtual se crea automáticamente. Sin importar que router físico se utilice, la IP virtual y las direcciones MAC proporcionan la asignación de direcciones al gateway predeterminado para los terminales. Solo el router activo recibirá y reenviará el tráfico enviado al gateway predeterminado. Si falla el router activo, o falla la comunicación al router activo, el router de reserva asume el rol de router activo.

Ing. José Dennis Estela Zumaeta 5.1. VERSIONES DEL HSRP La versión predeterminada para Cisco IOS 15 es la 1. La versión 2 del HSRP proporciona las siguientes mejoras:











HSRPv2 aumenta la cantidad de grupos admitidos. La versión 1 de HSRP admite los números de grupo de 0 a 255. La versión 2 de HSRP admite los números de grupo de 0 a 4095. HSRPv1 usa la dirección de multidifusión 224.0.0.2. El HSRP versión 2 utiliza la dirección de multidifusión IPv4 224.0.0.102 o a la dirección IPv6 de multidifusión FF02:: 66 para enviar paquetes de saludo. HSRPv1 usa el rango de direcciones MAC virtual 0000.0C07.AC00 a 0000.0C07.ACFF, donde los últimos dos dígitos hexadecimales indican el número de grupo del HSRP. HSRP v2 usa el rango de direcciones MAC de 0000.0C9F.F000 a 0000.0C9F.FFFF para IPv4 y de 0005.73A0.0000 a 0005.73A0.0FFF para direcciones IPv6. Para IPv4 e IPv6, los últimos tres dígitos hexadecimales de la dirección MAC indican el número de grupo del HSRP. HSRPv2 incorpora la compatibilidad para autenticación MD5, tema que no se encuentra dentro del ámbito de este curso.

Nota: Los números de grupo se utilizan para configuraciones HSRP más avanzadas que están fuera del ámbito de este curso. Para nuestros fines, utilizaremos el número de grupo 1

5.2. PRIORIDAD E INTENTO DE PRIORIDAD DEL HSRP El rol de los routers activos y de reserva se determina durante el proceso de elección del HSRP. De manera predeterminada, el router con la dirección IP numéricamente más alta se elige como router activo. Sin embargo, siempre es mejor conocer cómo funcionará su red en condiciones normales en lugar de dejarlo librado al azar.

PRIORIDAD DE HSRP La prioridad HSRP se puede utilizar para determinar el router activo. El router con la prioridad HSRP más alta será el router activo. De manera predeterminada, la prioridad HSRP es 100. Si las prioridades son iguales, el router con la dirección IP numéricamente más alta es elegido como router activo. Para configurar un router para que sea el router activo, utilice el comando de interfaz standby priority. El rango de prioridad HSRP es de 0 a 255.

INTENTO DE PRIORIDAD DE HSRP De forma predeterminada, después de que un router se convierte en el router activo, seguirá siendo el router activo incluso si otro router está disponible en línea con una prioridad HSRP más alta. Para forzar un nuevo proceso de elección del HSRP, el intento de prioridad se debe activar mediante el comando de interfaz standby preempt. El intento de prioridad es la capacidad de un router HSRP de activar el proceso de la nueva elección. Con este intento de prioridad activado, un router disponible en línea con una prioridad HSRP más alta asume el rol de router activo. El intento de prioridad solo permite que un router se convierta en router activo si tiene una prioridad más alta. Un router habilitado para intento de propiedad, con una

Ing. José Dennis Estela Zumaeta prioridad equivalente pero una dirección IP más alta no realizará desplazará la prioridad de un router activo. Consulte la topología en la Figura 1.

El R1 se configuró con la prioridad de HSRP de 150 mientras que el R2 tiene la prioridad de HSRP predeterminada de 100. El intento de prioridad está habilitado en el R1. Con una prioridad más alta, el R1 es el router activo y el R2 es el router de reserva. Debido a un corte de energía que solo afecta al R1, el router activo ya no está disponible y el router de reserva R2 asume el rol de router activo. Después de que se restaura la energía, el R1 vuelve a estar en línea. Dado que R1 tiene una prioridad más alta y el intento de prioridad se encuentra habilitado, forzará un nuevo proceso de elección. R1 reanudará su rol de router activo y el R2 volverá al rol de router de reserva. Nota: Si el intento de prioridad está desactivado, el router que arranque primero será el router activo si no hay otros routers en línea durante el proceso de elección.

5.3. ESTADOS DE HSRP Un router puede ser el router HSRP activo responsable del reenvío del tráfico para el segmento, o puede ser un router HSRP pasivo de reserva, listo para asumir un rol activo si falla el router activo. Cuando se configura una interfaz con HSRP o se habilita primero con una configuración HSRP existente, el router envía y recibe paquetes de saludo del HSRP para comenzar el proceso de determinar qué estado asumirá en el grupo HSRP. La Tabla 1 resume los estados de HSRP:


5.4. TEMPORIZADORES DE HSRP De manera predeterminada, los routers activos y de reserva de HSRP envían paquetes de saludo a la dirección de multidifusión del grupo HSRP cada 3 segundos. El router de reserva se convertirá en activo si no recibe un mensaje de saludo del router activo después de 10 segundos. Puede bajar estas configuraciones del temporizador para agilizar las fallas o el intento de prioridad. Sin embargo, para evitar el aumento del uso de la CPU y cambios de estado de reserva innecesarios, no configure el temporizador de saludo a menos de 1 segundo o el temporizador de espera a menos de 4 segundos.

5.5. IDENTIFICACION LA TERMINOLOGIA Y EL ESTADO DEL HSRP


5.6. COMANDOS DE CONFIGURACION DE HSRP Siga estos pasos para configurar el HSRP:

Paso 1. Configure la versión 2 del HSRP. Paso 2. Configure la dirección IP virtual para el grupo. Paso 3. Configure la prioridad para el router activo deseado de modo que sea superior a 100.

Paso 4. Configure el router activo para sustituir al router de reserva en caso de que el router activo vuelva a estar en línea después del router de reserva. La Tabla 1 muestra la sintaxis de comandos utilizada para completar los pasos de configuración.

Ing. José Dennis Estela Zumaeta 5.7. EJEMPLO DE CONFIGURACION DE HSRP El Ejemplo 1 muestra las configuraciones del R1 y el R2 en la Figura 1.

5.8. VERIFICACIÓN DEL HSRP Utilice los comandos show para verificar la configuración del R1 y el R2 en la Figura. 1.


Para verificar que el HSRP esté configurado correctamente, utilice el comando show standby como se muestra en el Ejemplo 1 para el R1 y el R2.

Ejemplo 1: Verificación de HSRP en el R1 y el R2


Nota: Puede cambiar el nombre de grupo predeterminado con el comando de configuración de interfaz standby [ group-number ] name group-name. También puede utilizar el comando show standby brief, como se muestra en el Ejemplo 2 para R1 y R2.

Ing. José Dennis Estela Zumaeta 5.9. FALLA DE HSRP Para solucionar problemas de HSRP, debe comprender el funcionamiento básico. La mayoría de los problemas se presentará durante una de las siguientes funciones de HSRP:    

No poder elegir correctamente el router activo que controla la IP virtual para el grupo. El router de reserva no puede realizar el correctamente el seguimiento del router activo. No poder determinar cuándo el control de IP virtual para el grupo se debe brindar a otro router. Las terminales no pueden configurar correctamente la dirección IP virtual como gateway predeterminado.

5.10. COMANDOS DE DEPURACION DE HSRP Los comandos de depuración del HSRP le permiten ver el funcionamiento del HSRP cuando un router falla o está administrativamente apagado. Los comandos de depuración de HSRP disponibles pueden verse ingresando el comando debug standby?, como se muestra en el Ejemplo 1.

Use debug standby packets para ver la recepción y el envío de paquetes de saludo cada 3 segundos, como se muestra en el Ejemplo 2 para el R2 en la Figura 1. Los routers HSRP supervisan estos paquetes de saludo e iniciarán un cambio de estado después de 10 segundos si no reciben saludos de un vecino de HSRP.


El HSRP se comporta de manera diferente, dependiendo de si el router activo falla o si es apagado manualmente por el administrador. Utilice debug standby terse, como se muestra en el Ejemplo 3, para ver los eventos del HSRP mientras el R1 se apaga y el R2 asume la función del router HSRP activo para la red 172.16.10.0/24

El ejemplo 4 muestra qué sucede en el R2 cuando el R1 se vuelve a encender. Debido a que el R1 se configura con el comando standby 1 preempt, inicia un pulso y asume el rol de router activo, como se destaca a continuación. El resto del resultado muestra que el R2 escucha activamente los mensajes de saludo durante el estado Speak hasta que confirma que el R1 es el nuevo router activo y el R2 es el nuevo router de reserva


Si la interfaz G0/1 del R1 está administrativamente apagada, el R1 envía un mensaje Init que indica a todos los routers HSRP en el enlace que está renunciando a su rol de router activo. Como se muestra en el ejemplo 5, 10 segundos después el R2 asume el rol de router activo de HSRP.


Observe que el R2 inicia un temporizador de espera pasivo para el R1. Después de 3 minutos, este temporizador de espera pasivo expira y el R1 (172.16.10.2) se destruye, lo que significa que se elimina de la base de datos del HSRP.

5.11. PROBLEMAS COMUNES DE CONFIGURACION HSRP Los comandos debug en la página anterior ilustran el funcionamiento esperado del HSRP. También puede utilizar los comandos debug para detectar problemas comunes de configuración:

Ing. José Dennis Estela Zumaeta 



  

Los routers en HSRP no están conectados al mismo segmento de red. Si bien esto podría ser un problema de la capa física, también podría ser un problema de configuración de la subinterfaz de VLAN. Los routers en HSRP no están configurados con las direcciones IP de la misma subred. Los paquetes de saludo del HSRP son locales. No se enrutan más allá del segmento de red. Por lo tanto, un router de reserva no sabría cuándo falla el router activo. Los routers en HSRP no están configurados con la misma dirección IP virtual. La dirección IP virtual es el gateway predeterminado para terminales. Los routers en HSRP no están configurados con el mismo número de grupo HSRP. Esto hará que cada router asuma un rol activo. Los terminales no se configuran con la dirección de gateway predeterminada correcta. Aunque no está relacionado directamente con el HSRP, configurar el servidor DHCP con una de las direcciones IP reales del router en HSRP significaría que los terminales tendrían solo conectividad a redes remotas cuando dicho router HSRP esté activo.

5.12. SOLUCIÓN DE PROBLEMAS DEL HSRP

Ing. José Dennis Estela Zumaeta 6. HABILIDADES PARA LA SOLUCIÓN DE PROBLEMAS DE OSPF MULTIAREA Antes de comenzar a diagnosticar y solucionar los problemas relacionados con una implementación de OSPF multiárea, debe poder hacer lo siguiente:   

Comprender los procesos que OSPF utiliza para distribuir, guardar y seleccionar la información de routing. Comprender cómo fluye la información de OSPF dentro de las áreas y entre las mismas. Utilizar los comandos de Cisco IOS para recopilar e interpretar la información necesaria para solucionar problemas de funcionamiento de OSPF.

6.1.ESTRUCTURA DE DATOS OSPF MULTIAREA OSPF almacena la información de routing en cuatro estructuras de datos principales: 







Tabla de la interfaz: esta tabla incluye una lista de todas las interfaces activas que se hayan habilitado para OSPF. Los LSA de tipo 1 incluyen las subredes asociadas a cada interfaz activa. Tabla de vecinos: esta tabla se utiliza para administrar las adyacencias de vecinos a través de los temporizadores de saludo y de los temporizadores muertos. Se agregan y se actualizan las entradas vecinas cuando se recibe un saludo. Los vecinos se eliminan cuando expira el temporizador muerto. Base de datos de estado de enlace: Es la estructura de datos principales que utiliza OSPF para almacenar información de la topología de la red. Incluye información topológica completa sobre cada área a la que el router OSPF está conectado, así como cualquier ruta que esté disponible alcanzar otras redes o sistemas autónomos. Tabla de routing: después de que se calcula el algoritmo SPF, se ofrecen a la tabla de enrutamiento las mejores rutas para cada red.

6.2.SITUACIÓN DE PROBLEMAS DE OSPF MULTIAREA Con respecto a la topología de la Figura 1, la información detallada en la Tabla 1 debería aparecer en las cuatro estructuras de datos principales.


Usted utilizaría este conocimiento acerca de qué información debe estar visible en estructuras de datos OSPF para comparar con lo que se ve realmente al utilizar los comandos show de Cisco IOS.

Ing. José Dennis Estela Zumaeta CONEXION A LAS REDES – CCNA 4 PUENTE CN: DESCRIPCION GENERAL       

   

 

Explicar el propósito de una WAN. Describir las VPN de sitio a sitio y de acceso remoto. Implementar un router Cisco con PPPoE. Configurar el protocolo EBGP en una red de acceso remoto único dirigida. Resolver problemas comunes de ACL con los comandos de CLI. Explicar cómo mitigar los ataques comunes de seguridad LAN. Configurar SNMP para supervisar las operaciones en una red de una empresa pequeña a mediana. Resolver un problema de red utilizando SPAN. Explicar el propósito y las características de QoS. Explicar la forma en la que los dispositivos de red implementan QoS. Explicar por qué la computación en la nube y la virtualización son necesarias para redes en evolución. Explicar por qué la programabilidad de la red es necesaria para las redes en evolución. Utilizar un IP SLA basado en eco ICMP para resolver problemas de conectividad de red.

1. TOPOLOGIAS DE WAN La interconexión de varios sitios a través de WAN puede incluir una variedad de tecnologías del proveedor de servicios y de topologías de WAN. Las topologías de WAN más comunes son:

PUNTO A PUNTO Una topología punto a punto, como se muestra en la Figura 1, utiliza un circuito punto a punto entre dos terminales. Generalmente se trata de conexiones de líneas alquiladas dedicadas como las líneas T1/E1. Una conexión punto a punto implica un servicio de transporte de capa 2 a través de la red del proveedor de servicios. Los paquetes enviados desde un sitio se entregan a otro sitio y viceversa. Una conexión punto a punto es transparente para la red del cliente, como si hubiera un enlace físico directo entre dos terminales.

Ing. José Dennis Estela Zumaeta DE ESTRELLA Si se requiere una conexión de red privada entre varios sitios, entonces una topología punto a punto con múltiples circuitos punto a punto es una opción. Cada circuito punto a punto requiere su propia interfaz de hardware dedicada que requiere múltiples routers con tarjetas de interfaz WAN. Suele ser una opción costosa. Una opción menos costosa es una topología de punto a multipunto (Figura 2), también conocida como topología de estrella (hub and spoke). Con una topología de estrella (hub-and-spoke) una sola interfaz a hub puede ser compartida por todos los circuitos de radio. Por ejemplo, los sitios radiales se pueden interconectar a través del sitio de hubs mediante circuitos virtuales y subinterfaces enrutadas del hub. Una topología de estrella (hub and spoke) también es un ejemplo de una topología de conexión única.

MALLA COMPLETA Una de las desventajas de las topologías de estrella es que la comunicación debe pasar a través del hub. Con una topología de malla completa (Figura 3) mediante circuitos virtuales, cualquier sitio puede comunicarse directamente con cualquier otro sitio. La desventaja aquí es la gran cantidad de circuitos virtuales que se deben configurar y mantener.

Ing. José Dennis Estela Zumaeta TOPOLOGIA DE DOBLE CONEXIÓN Una topología de doble conexión ofrece redundancia, como se muestra en la Figura 4. La desventaja de las topologías de doble conexión es que son más costosas de implementar que las topologías de seguridad única. Esto es porque requieren hardware de red, como routers y switches adicionales. Las topologías de doble conexión son más difíciles de implementar porque requieren configuraciones adicionales y complejas. Sin embargo, la ventaja de las topologías de doble conexión es que ofrecen redundancia de red, equilibrio de carga, computación o proceso distribuido mejorados, y la capacidad de implementar las conexiones del proveedor de servicio de respaldo.

2. DMVPN La VPN dinámica multipunto (DMVPN) es una solución de Cisco para crear VPN múltiples de forma fácil, dinámica y escalable. El objetivo es simplificar la configuración y conectar los sitios de la oficina central con facilidad y flexibilidad con las sucursales. Esto se denomina "concentrador a radio", como se muestra en la Figura 1

Ing. José Dennis Estela Zumaeta Con los DMVPN, las sucursales también pueden comunicarse directamente con otras sucursales, como se muestra en la Figura 2.

El DMVPN se crea utilizando las siguientes tecnologías:   

Next Hop Resolution Protocol (NHRP). Túneles de encapsulación de routing genérico multipunto (mGRE). Cifrado de protocolo de seguridad IP (IPsec).

NHRP es un protocolo de resolución y de almacenamiento en caché de capa 2 similar al protocolo de resolución de direcciones (ARP). NHRP crea una base de datos de asignación distribuida de direcciones IP públicas para todos los radios del túnel. NHRP es un protocolo cliente-servidor que consta del hub de NHRP conocido como el servidor del siguiente salto (NHS) y los radios de NHRP conocidos como los clientes del siguientes salto (NHC). Encapsulación de routing genérico (GRE) es un protocolo de túnel desarrollado por Cisco que puede encapsular una amplia variedad de tipos de paquetes de protocolo dentro de túneles IP. Una interfaz de túnel mGRE permite que una única interfaz de GRE admita túneles IPSec múltiples. Con la interfaz mGRE, se crean túneles asignados de manera dinámica a través de un origen de túnel permanente en el hub y de los destinos de túnel asignados de manera dinámica que se crean en los radios según sea necesario. Esto reduce el tamaño y simplifica la complejidad de la configuración. Al igual que otros tipos de VPN, la DMVPN depende de IPsec para proporcionar el transporte seguro de información privada en redes públicas, como Internet.

3. COMANDOS DE VERIFICACION DE PPPoE Como se muestra en la Figura 1, el router del cliente se conecta al router ISP utilizando DSL. Ambos routers fueron configurados para PPPoE.


Como se muestra en el Ejemplo 1, el comando show ip interface brief se ejecuta en R1 para verificar la dirección IPv4 asignada automáticamente a la interfaz del marcador por el router ISP.

Como se muestra en el Ejemplo 2, el comando show interface dialer en R1 verifica el encapsulamiento de MTU y PPP configurado en la interfaz del marcador.

En Ejemplo 3 muestra la tabla de routing en R1.


Tenga en cuenta que se instalaron dos rutas de host /32 para 10.0.0.0 en la tabla de routing R1. La primera ruta de host para la dirección asignada a la interfaz del marcador. La segunda ruta de host es la dirección IPv4 del ISP. La instalación de esas dos rutas de host es el comportamiento predeterminado para PPPoE. Como se muestra en el Ejemplo 4, el comando show pppoe session se utiliza para mostrar información acerca de las sesiones PPPoE actualmente activas. El resultado muestra las direcciones de Ethernet MAC locales y remotas de ambos routers. Las direcciones Ethernet MAC se pueden verificar utilizando el comando show interfaces en cada router.

3.1.DESCRIPCION GENERAL DE LA SOLUCIÓN DE PROBLEMAS DE PPPoE Después de asegurarse de que el router cliente y el módem DSL estén conectados a los cables correctos, uno o más de los siguientes motivos generalmente son la causa de una conexión de PPPoE que no funciona correctamente:   

Falla en el proceso de negociación de PPP. Falla en el proceso de autenticación de PPP. Falla en el ajuste del tamaño máximo del segmento de TCP.

Ing. José Dennis Estela Zumaeta 3.2.NEGOCIACIÓN PPPoE Verifique la negociación PPP utilizando el comando debug ppp negotiation. El ejemplo 1 muestra una parte del resultado de la depuración una vez que se ha habilitado la interfaz G0/1 del R1.

Hay cuatro puntos principales de fallas en una negociación PPP:    

No hay respuesta del dispositivo remoto (el ISP). Protocolo de control de enlaces (LCP) no abierto. Falla de autenticación. Falla del protocolo de control de IP (IPCP).

3.3.AUTENTICACION PPPoE Después de confirmar con el proveedor de servicios de Internet (ISP) que utiliza CHAP, verifique que el nombre de usuario y la contraseña de CHAP sean correctos. El ejemplo 1 muestra la configuración de CHAP en la interfaz dialer2.

Ing. José Dennis Estela Zumaeta El reexamen del resultado del comando debug ppp negotiation, en el ejemplo 2, verifica que el nombre de usuario de CHAP es correcto.

Si el nombre de usuario y la contraseña de CHAP fueran incorrectos, el resultado del comando debug ppp negotiation mostrará un mensaje de error de autenticación, como se muestra en el Ejemplo 3.

3.4.TAMAÑO DE PPPoE MTU El acceso a algunas páginas web puede ser un problema con PPPoE. Cuando un cliente solicita una página web, se produce un protocolo TCP de enlace de tres vías entre el cliente y el servidor web. Durante la negociación, el cliente especifica el valor del tamaño máximo del segmento (MSS) de TCP. El MSS del TCP es el tamaño máximo de la porción de datos del segmento TCP. Un host determina el valor de su campo de MSS restando los encabezados IP y TCP de unidad máxima de transmisión (MTU) de Ethernet. En una interfaz de Ethernet, el MTU predeterminado es de 1500 bytes. Si se sustrae el encabezado de IPv4 de 20 bytes y el encabezado TCP de 20 bytes, el tamaño del valor predeterminado MSS será de 1460 bytes, como se muestra en la Figura 1


El tamaño predeterminado de MSS es de 1460 bytes, cuando el MTU predeterminado es de 1500 bytes. Sin embargo, PPPoE admite un MTU de sólo 1492 bytes que para adaptarse al encabezado PPPoE adicional de 8 bytes que se muestra en la Figura 2.

Puede verificar el tamaño de MTU de PPPoE en la configuración en ejecución, como se muestra en el Ejemplo 1.

Esta disparidad entre el host y el tamaño de MTU de PPPoE puede hacer que el router descarte paquetes de 1500 bytes y termine las sesiones de TCP en la red de PPPoE. El comando ip tcp adjust-mss max-segment-size del comando ayuda a evitar que se descarte las sesiones de TCP ajustando el valor de MSS durante el protocolo TCP de enlace de tres vías. En la mayoría de los casos, el valor óptimo para el argumento maxsegment-size es de 1452 bytes. En el Ejemplo 2, se muestra esta configuración en la interfaz LAN de R1.


El valor de MSS del TCP de 1452, más el encabezado de IPv4 de 20 bytes, el encabezado de TCP de 20 bytes y el encabezado de PPPoE de 8 bytes da como resultado un MTU de 1500 bytes, como se muestra en la Figura 2.

4. ROUTING PROTOCOLS IGP Y EGP IP, EIGRP y OSPF son protocolos de gateway interior (IGP). Los ISP y sus clientes, como corporaciones y otras empresas, generalmente utilizan un IGP para enrutar el tráfico dentro de sus redes. Los IGP se utilizan para intercambiar información de routing dentro de una red de una empresa o de un sistema autónomo (AS). El protocolo de puerta de enlace fronteriza (BGP) es un protocolo de gateway exterior (EGP) utilizado para el intercambio de información de routing entre sistemas autónomos, como ISP, empresas, y proveedores de contenido (por ejemplo, YouTube, Netflix, etc.). En el BGP, se asigna a cada AS un número AS de 16 o 32 bits único que lo identifica de manera única en Internet. En la Figura 1, se muestra un ejemplo de cómo se utilizan los IGP.

Nota: También hay números AS privados. Sin embargo, los números AS privados están más allá del alcance de este curso.

Los protocolos de routing internos utilizan una métrica específica, como el costo de OSPF, para determinar las mejores rutas hacia las redes de destino. BGP no utiliza una sola métrica, a diferencia de los IGP. Los routers BGP intercambian varios atributos de ruta que incluyen una lista de números de AS (salto por salto) necesarios para lograr una red de destino. Por ejemplo, en la Figura 1 AS 65002 pueden utilizar la ruta AS de 65003 y 65005

Ing. José Dennis Estela Zumaeta para llegar a una red dentro del proveedor de contenido AS 65005. El BGP se conoce como un protocolo de routing de vector de ruta.

Nota: la ruta AS es uno de varios atributos que pueden ser utilizados por el BGP para determinar el mejor camino. Sin embargo, los atributos de ruta y la determinación del mejor camino de BGP exceden el alcance de este curso. Las actualizaciones de BGP se encapsulan sobre el TCP en el puerto 179. Por lo tanto, BGP conserva las propiedades orientadas a la conexión TCP, lo que asegura que las actualizaciones de BGP se transmitan de manera confiable. Los protocolos de routing de IGP se utilizan para enrutar el tráfico dentro de la misma organización, y son administrados por una sola organización. En cambio, el BGP se utiliza para el enrutamiento entre redes administradas por dos organizaciones diferentes. El BGP es utilizado por un AS para publicar sus redes y, en algunos casos, las redes aprendidas de otros sistemas autónomos, en el resto de Internet.

4.1.eBGP e iBGP Se denomina "pares BGP" a dos routers que intercambian información de routing de BGP. Como se muestra en la Figura 1, existen dos tipos de BGP: 



BGP externo (eBGP): El BGP externo es el protocolo de routing utilizado entre los routers de sistemas autónomos diferentes. BGP interno (iBGP): El BGP interno es el protocolo de routing utilizado entre los routers del mismo AS.

Este curso se centra en el protocolo EBGP únicamente.

Nota: Existen algunas diferencias en la manera en la que funciona el BGP; esto depende de si los dos routers son pares de eBGP o pares iBGP. Sin embargo, estas diferencias están más allá del alcance de este curso.

Ing. José Dennis Estela Zumaeta 4.2.CUANDO UTILIZAE EL BGP El uso de BGP resulta muy apropiado cuando un AS tiene conexiones a sistemas autónomos múltiples. Esto se conoce como “alojamiento múltiple”. Cada AS en la Figura 1 es un entorno de host múltiples porque cada AS tiene conexiones con al menos otros dos sistemas autónomos o pares BGP. Antes de ejecutar BGP, es importante que el administrador de red conozca y entienda bien el BGP. Una configuración incorrecta de un router BGP puede tener consecuencias negativas en toda la Internet.

4.3.CUANDO NO SE DEBE UTILIZAR BGP El BGP no debe utilizarse cuando existe al menos una de las siguientes condiciones: 



Hay una sola conexión a Internet u otro AS. Esto se conoce como “alojamiento simple”. En este caso, la empresa A puede ejecutar un IGP con el ISP o tanto la empresa A y como el ISP utilizarán rutas estáticas, como se muestra en la Figura 1. Aunque esto se recomienda solo en situaciones inusuales, en este curso, configurará un BGP de alojamiento simple. Cuando hay una comprensión limitada del BGP. Una configuración incorrecta de un router BGP puede producir errores de gran alcance más allá del AS local, y esto puede tener un impacto negativo en los routers en Internet

Nota: Existen algunas situaciones de alojamiento simple donde el BGP puede ser apropiado, como la necesidad de una política de routing específica. Sin embargo, las políticas de routing están más allá del alcance de este curso.

Ing. José Dennis Estela Zumaeta 4.4.OPCIONES DE BGP El BGP es utilizado por los sistemas autónomos para publicar las redes que se originaron dentro del AS o, en el caso de los ISP, las redes que se originaron en otros sistemas autónomos. Por ejemplo, una empresa que se conecta al ISP utilizando BGP publicaría sus direcciones de red en su ISP. El ISP luego publicaría dichas redes en otros ISP (pares BGP). Finalmente, el resto de los sistemas autónomos en Internet aprenden sobre las redes originadas inicialmente por la empresa. Existen tres maneras comunes mediante las cuales una organización puede elegir implementar el BGP en un entorno de alojamientos múltiples:

RUTA PREDETERMINADA SOLAMENTE El ISP publica una ruta predeterminada en la empresa A, como se muestra en la Figura 1. Las flechas indican que el valor predeterminado está configurado en los ISP, no en la empresa A. Este es el método más simple para implementar el BGP. Sin embargo, debido a que la empresa recibe una sola ruta predeterminada de ambos ISP, se puede producir el routing por debajo del nivel óptimo. Por ejemplo, la empresa A puede elegir usar la ruta predeterminada desde ISP-1 cuando envía paquetes a una red de destino en los ISP-2 AS.

RUTA PREDETERMINADA Y RUTAS DE ISP Los ISP publican su ruta predeterminada y su red en la empresa A, como se muestra en la Figura 2. Esta opción permite que la empresa A reenvíe el tráfico al ISP correspondiente para las redes anunciadas por ese ISP. Por ejemplo, la empresa A elegiría el ISP-1 para redes publicadas por el ISP-1. Para todas las demás redes, se puede usar una de las dos rutas predeterminadas, lo que significa que el routing por debajo del nivel óptimo aún puede tener lugar para el resto de las rutas de Internet.


TODAS LAS RUTAS DE INTERNET Los ISP publican todas las rutas de Internet a la empresa A, como se muestra en la Figura 3. Debido a que la empresa A recibe todas las rutas de Internet de ambos ISP, la empresa A puede determinar qué ISP utilizará como la mejor ruta para reenviar tráfico hacia cualquier red. Si bien esto resuelve el problema del routing por debajo del nivel óptimo, el router BGP de la empresa A debe contener todas las rutas de Internet, que son actualmente las rutas a más de 550 000 redes.

Ing. José Dennis Estela Zumaeta 4.5.IDENTIFICAR LA TERMINOLOGIA DE BGP

4.6.IDENTIFICAR EL DISEÑO DE BGP

Ing. José Dennis Estela Zumaeta 4.7.PASOS PARA CONFIGURAR eBGP Para implementar eBGP para este curso, deberá completar las siguientes tareas:

Paso 1: Habilitar el routing BGP. Paso 2: Configurar el vecino BGP (peering). Paso 3: Publicar las redes que se originan de este AS. La Tabla 1 muestra la sintaxis de comandos y una descripción para la configuración básica del protocolo eBGP.

4.8.EJEMPLO DE CONFIGURACION DE BGP La Figura 1 muestra una topología de BGP de alojamiento simple. Utilizando el protocolo eBGP, la empresa A en AS 65000 publicará su red 198.133.219.0/24 en ISP1 a AS 65001. El ISP-1 anunciará una ruta predeterminada en las actualizaciones de eBGP a la empresa A.

Nota: El protocolo BGP normalmente no es necesario en AS de alojamiento simple. Se utiliza aquí para proporcionar un ejemplo de configuración sencilla.

El ejemplo 1 muestra la configuración de BGP para la empresa A. Los clientes utilizarán generalmente el espacio privado para la dirección postal IPv4 para los dispositivos internos dentro de su propia red. Luego, el router de la empresa A utiliza NAT para traducir estas direcciones privadas IPv4 privadas a una de sus direcciones IPv4 públicas, publicadas por el protocolo BGP en el ISP.

Ing. José Dennis Estela Zumaeta El comando router bgp habilita el BGP e identifica el número de AS para la empresa A. Un router sólo puede pertenecer a una sola AS, de modo que solo puede ejecutase un único proceso de BGP en un router. El comando neighbor identifica el par de BGP y su número de AS. Observe que el AS del ISP es diferente que el número de AS de la empresa A. Esto le informa al proceso de BGP que el vecino está en un AS diferente y que, por lo tanto, se trata de un vecino de BGP externo. La opción mask debe utilizarse cuando la red que se publica es diferente a su equivalente con clase. En este ejemplo, 198.133.219.0/24 es equivalente a una red Clase C. Las redes Clase C tienen una máscara de subred /24, así que, en este caso, la opción mask no se requiere. Si el cliente A estuviera anunciando la red 198.133.0.0/16, sería necesaria la opción mask. De lo contrario, el protocolo BGP publicaría de red con una máscara /24 con clase. El comando network introduce la dirección-red en la tabla local de BGP. La tabla de BGP contiene todas las rutas aprendidas a través del BGP o publicadas mediante el BGP. El eBGP luego publicará la dirección-red a sus vecinos de eBGP. Nota: A diferencia de un protocolo IGP, la dirección-red utilizada en el comando network no tiene que ser una red conectada directamente. El router sólo necesita tener una ruta hacia esta red en su tabla de routing. El ejemplo 2 muestra la configuración de BGP para el ISP-1.

Los comandos de eBGP en el router ISP-1 son similares a la configuración en la empresa A. Observe cómo el comando network 0.0.0.0 de la red para anunciar una red predeterminada a la empresa A.

Nota: Si bien el comando network 0.0.0.0 es una opción de configuración válida de BGP, hay mejores maneras para anunciar una ruta predeterminada en el EBGP. Sin embargo, estos métodos están más allá del alcance de este curso.

4.9.VERIFICACION DEL PROTOCOLO eBGP Se pueden usar tres comandos pueden usarse para verificar el protocolo eBGP, como se muestra en la Tabla 1.

En la figura 1, se muestra la topología de configuración de eBGP.


Observe cómo el código de origen B identifica que la ruta fue aprendida mediante el BGP. Específicamente, en este ejemplo, la Empresa A recibió una ruta predeterminada publicada por BGP desde ISP-1. El Ejemplo 2 muestra el resultado de la tabla de BGP de la Empresa A.

La primera entrada 0.0.0.0 con un salto siguiente 209.165.201.1 es la ruta predeterminada publicada por ISP-1. La ruta del AS muestra el AS simple de 65001 porque la red 0.0.0.0/0 publicada por el ISP-1, surgió del mismo AS. La mayoría de las entradas de la tabla de BGP muestran los números del sistema autónomo múltiple en

Ing. José Dennis Estela Zumaeta la ruta y detallan la secuencia de números de AS necesarios para llegar a la red de destino. La segunda entrada 198.133.219.0/24 es la red publicada por el router de la empresa A al ISP-1. La dirección del siguiente salto de 0.0.0.0 indica que la red 198.133.219.0/24 se originó en este router. El ejemplo 3 muestra el estado de conexión de BGP en la Empresa A.

La primera línea muestra la dirección IPv4 local utilizada para establecer una interconexión con otro vecino de BGP y el número local de AS de este router. Aparecerá la dirección y el número de AS del vecino BGP remoto en la parte inferior del resultado.

4.10.

CONFIGURAR Y COMPROBAR BGP


Ing. José Dennis Estela Zumaeta 5. DESCRIPCION GENERAL DE LA SOLUCIÓN DE PROBLEMAS DE ACL DE IPV6 Si después de probar una ACL comprueba que no funciona como se espera, es momento de resolver problemas de errores comunes. El uso de los comandos show como show ipv6 access-list o show running-config puede revelar los errores típicos de la ACL. Si bien la mayoría de los errores más comunes incluyen la introducción de las ACE en el orden equivocado y la ausencia de especificación de las reglas adecuadas de ACL, otros errores comunes implican la aplicación de ACL con el nombre incorrecto, la interfaz incorrecta, o la dirección incorrecta.

5.1.SOLUCIÓN DE PROBLEMAS DE ACL DE IPV6: ESCENARIO 1 Este escenario de solución de problemas de las ACL de IPv6 utiliza la topología que se muestra en la Figura 1.

R1 está configurada con una ACL de IPv6 para denegar el acceso FTP desde la red :10 a la red :11. Sin embargo, después de configurar la ACL, la PC1 todavía puede conectarse al servidor FTP que se ejecuta en la PC2. Al consultar el resultado del comando access-list show ipv6 en el Ejemplo 1, se muestran las coincidencias para la declaración de permiso, pero no se muestran las declaraciones de negación

Solución: Los ACE en las ACL no muestran ningún problema en el orden o en los criterios de las reglas. El siguiente paso es ver cómo se aplica la ACL en la interfaz utilizando ipv6 traffic-filter . ¿La ACL se aplicó utilizando el nombre correcto, la interfaz correcta y la dirección correcta? Para revisar errores de configuración de interfaz, visualice la configuración en ejecución, como se muestra en el Ejemplo. 2.


La ACL se aplicó con el nombre correcto, pero con una dirección incorrecta. La dirección in o out se toma desde la perspectiva del router, lo cual significa que la ACL actualmente se aplica al tráfico antes de que se reenvíe desde la interfaz G0/0 e ingrese en la red :10. Para corregir el problema, elimine ipv6 traffic-filter NO-FTP-TO11 outy reemplácelo con ipv6 traffic-filter NO-FTP-TO-11 in , como se muestra en el Ejemplo 3.

Ahora los intentos de PC1 para acceder al servidor FTP se rechazan, como se muestra en el Ejemplo 4.

5.2.SOLUCIÓN DE PROBLEMAS DE ACL DE IPV6: ESCENARIO 2 Este escenario de solución de problemas de ACL de IPv6 utiliza la topología que se muestra en la Figura 1.


R3 está configurada con una ACL de IPv6 llamada RESTRICTED-ACCESS que debe aplicar la siguiente política para la LAN del R3:   

Permitir acceso a la red :10. Denegar acceso a la red :11. Permitir acceso de SSH a la PC en 2001:DB8:CAFE:11::11.

Sin embargo, después de configurar la ACL, la PC3 no puede llegar a la red 10 o la red 11, y no puede utilizar SSH en el host en 2001:DB8:CAFE:11::11

Solución: En esta situación, el problema no se debe a cómo se aplicó la ACL. En la interfaz, la ACL no se escribe mal y la dirección y la ubicación son correctas, como se muestra en el Ejemplo 1.

Una mirada más detallada a la ACL de IPv6 que se muestra en el ejemplo 2 revela que el problema está en el pedido y los criterios de las reglas de ACE.


La primera declaración de permiso debería permitir el acceso a la red :10. Sin embargo, el administrador configuró una instrucción de host y no especificó un prefijo. En este caso, se otorga acceso únicamente a 2001:DB8:CAFE:10:: se permite el host. Para corregir este problema, elimine el argumento de host y cambie el prefijo /64 a. Puede hacer esto sin eliminar la ACL reemplazando el ACE mediante el número de secuencia 10, como se muestra en el Ejemplo. 3.

El segundo error en la ACL es el orden de las dos siguientes afirmaciones. La política especifica que los hosts en la LAN del R3 deben poder utilizar SSH en el host 2001:DB8:CAFE:11::11. Sin embargo, la declaración deny para la red :11 se encuentra antes de la declaración permit. Por lo tanto, todos los intentos para acceder al: se deniega la red 11 antes de que la instrucción que permite el acceso de SSH puede evaluarse. Una vez que se establece una coincidencia, no se analizan otras sentencias. Para corregir este problema, necesitará eliminar las sentencias primero y, luego, ingresarlas en el orden correcto, como se muestra en el Ejemplo. 4.

Ing. José Dennis Estela Zumaeta 5.3.SOLUCIÓN DE PROBLEMAS DE ACL DE IPV6: ESCENARIO 3 Este escenario de solución de problemas de ACL de IPv6 utiliza la topología que se muestra en la Figura 1.

R1 está configurada con una ACL de IPv6 llamada DENY-ACCESS que debe aplicar la siguiente política para la LAN del R3:  

Permitir acceso a la red :11 desde la red :30 Denegar acceso a la red :10

El Ejemplo 1 muestra la configuración y la aplicación de ACL de IPv6.

Ing. José Dennis Estela Zumaeta La ACL DENY-ACCESS debe permitir el acceso a la red:11 desde la red :30 y denegar el acceso a la red :10. Sin embargo, después de aplicar la ACL a la interfaz: la red 10 aún es accesible desde la red :30.

Solución: En esta situación, el problema no tiene que ver con la manera en la que se escribieron las declaraciones de las ACL, sino con la ubicación de la ACL. Dado que las ACL de IPv6 deben configurarse con un origen y un destino, debe aplicarse lo más cerca posible del origen del tráfico. La ACL DENY-ACCESS se aplicó en la dirección saliente en la interfaz R1 G0/1 que está más cerca del destino. Como resultado, el tráfico a la red: 10 no se ve no se ve afectado porque alcanza la red: 10 a través de la otra interfaz de la red LAN, G0/0. Puede aplicar la ACL entrante en la interfaz S0/0/0 del R1. Sin embargo, porque tenemos control sobre el R3, la mejor ubicación sería configurar y aplicar la ACL lo más cerca posible del origen del tráfico. El ejemplo 2 muestra la eliminación de la ACL en el R1 y la configuración y la aplicación correctas de la ACL en el R3.

6. DETECCION DHCP Un ataque de suplantación de DHCP se produce cuando un servidor DHCP dudoso se conecta a la red y brinda parámetros de configuración IP falsos a los clientes legítimos. La suplantación de DHCP es peligrosa porque los clientes pueden recibir información de concesión de IP, como servidores DNS maliciosos, puertas de enlace predeterminadas maliciosas y asignaciones IP maliciosas. Las mejores prácticas de seguridad recomiendan el uso de la detección DHCP para mitigar los ataques de suplantación de DHCP. La detección DHCP crea y mantiene una base de datos denominada base de datos de enlaces de detección DHCP (también conocida como tabla de enlaces de detección DHCP). Esta base de datos incluye la dirección MAC del cliente, la dirección IP, el tiempo de la concesión de DHCP, el tipo de enlace, el número de VLAN, y la información de interfaz en cada puerto de switch o interfaz no confiables. El administrador de redes debe definir qué puertos son confiables. Al combinar la información en la base de datos de enlace de detección DHCP con los puertos confiables, el switch puede filtrar los mensajes DHCP de fuentes no confiables. Cuando la detección DHCP se habilita en una interfaz o una VLAN, y un switch recibe un paquete DHCP en un puerto no confiable, el switch compara la información del paquete de

Ing. José Dennis Estela Zumaeta origen con la información que se mantiene en la base de datos de enlaces de detección DHCP. El switch negará los paquetes que contengan la siguiente información: 





Mensajes no autorizados del servidor DHCP que provengan de un puerto no confiable. Mensajes del cliente DHCP que no cumplan con la base de datos de enlaces de detección DHCP o con los límites de velocidad. Paquetes de agente de retransmisión DHCP que incluyan información de la opción 82 proveniente de un puerto no confiable.

Nota: La opción 82 proporciona seguridad y se utiliza para enviar información sobre los clientes DHCP a servidor DHCP. Sin embargo, un puerto no confiable no debe recibir paquetes de opción 82. En una red grande, la creación de la base de datos de enlaces de detección DHCP puede llevar tiempo una vez que se habilita. Por ejemplo, la detección DHCP puede tardar 2 días para completar la base de datos, si el tiempo de la concesión de DHCP es de 4 días. La detección DHCP reconoce dos tipos de puertos: 



Puertos de confianza de DHCP: Solo se puede confiar en los puertos conectados a servidores DHCP corriente arriba. Estos puertos deben generar tráfico a los servidores DHCP que respondan con mensajes de DHCP Offer y DHCP Ack. Los puertos confiables se deben identificar explícitamente en la configuración. Puertos no confiables: estos puertos se conectan a los hosts que no deben proporcionar mensajes de servidor DHCP. De manera predeterminada, todos los puertos de switch no son confiables.

En la Figura 1, se presenta un ejemplo visual que muestra cómo los puertos de detección DHCP se deben asignar en una red.

Ing. José Dennis Estela Zumaeta Observe cómo los puertos confiables siempre conducen al servidor de DHCP legítimo, mientras que el resto de los puertos (es decir, los puertos de acceso que se conectan a los terminales) no son confiables de manera predeterminada.

Nota: la configuración de detección DHCP va más allá del alcance de este curso. 7. AAA con RADIUS y TACACS+ Para evitar que usuarios malintencionados obtengan acceso a equipos de red y servicios sensibles, los administradores deben habilitar el control de acceso. El control de acceso limita a las personas o los dispositivos que pueden utilizar recursos específicos. También limita los servicios o las opciones que están disponibles después de que se concede el acceso. El control de acceso básico en los dispositivos de red se activa mediante la autenticación. Existen diferentes métodos para implementar la autenticación en un dispositivo Cisco, y cada método ofrece varios niveles de seguridad. A continuación, se describen dos métodos comunes: 



Autenticación de contraseña simple : Esto implica el uso de los comandos de configuración password y login para proteger la consola, las líneas vty, y los puertos auxiliares. Lamentablemente, este método es también el método más débil y menos seguro porque no proporciona ninguna responsabilidad. Por ejemplo, cualquier persona que tenga la contraseña puede obtener acceso al dispositivo y modificar la configuración. Autenticación local de bases de datos : Esto implica la creación de las cuentas de usuario local con el comando de configuración global username name secret password y luego configurar el comando de configuración de línea login local en la consola, el VTY y los puertos auxiliares. Esto proporciona seguridad adicional, ya que un atacante necesita saber un nombre de usuario y una contraseña. También proporciona más responsabilidad porque el nombre de usuario queda registrado cuando un usuario inicia sesión.

Sin embargo, el método de la base de datos local no escala mucho más allá de algunos dispositivos de red porque las cuentas de usuario deben configurarse localmente en cada dispositivo. Esto no es adecuado en un entorno empresarial grande con varios routers y switches para administrar. Además, la configuración de la base de datos local no proporciona ningún método de autenticación de reserva. Por ejemplo, ¿qué sucede si el administrador olvida el nombre de usuario y la contraseña para ese dispositivo? Sin el método de respaldo disponible para la autenticación, la recuperación de la contraseña se convierte en la única opción. Una solución mejor y más escalable es lograr que todos los dispositivos remitan a una base de datos de nombres de usuario y contraseñas alojados en un servidor central. Para admitir esto, los dispositivos Cisco admiten el marco de trabajo de autenticación, autorización y auditoría (AAA) que ayuda a asegurar el acceso de los dispositivos. En los dispositivos Cisco, se utilizan dos protocolos de autenticación AAA: 



Terminal Access Controller Access-Control System Plus (TACACS+, sistema de control de acceso mediante control del acceso desde terminales [se pronuncia como “tack-axe plus”]). Remote Authentication Dial-In User Service (RADIUS, servicio de usuario de acceso telefónico de autenticación remota).

Un dispositivo compatible con AAA se puede configurar para remitir a una base de datos de usuarios externa para la autenticación de usuarios, licencias y contabilización. El dispositivo

Ing. José Dennis Estela Zumaeta se comunica con el servidor AAA mediante el protocolo TACACS+ o RADIUS. Cada protocolo admite capacidades y funcionalidades diferentes. La selección de TACACS+ o RADIUS depende de las necesidades de la organización. Por ejemplo, un ISP grande puede seleccionar RADIUS porque admite la contabilización detallada necesaria para la facturación de los usuarios. Una organización con varios grupos de usuarios puede seleccionar TACACS+ porque requiere políticas de autorización que se aplican por usuario o por grupo. Es importante comprender las diferencias entre los protocolos TACACS+ y RADIUS. Estos son tres factores cruciales para TACACS+:   

Separa la autenticación y la autorización. Cifra todas las comunicaciones. Utiliza el puerto TCP 49.

A continuación, se enumeran cuatro factores cruciales para RADIUS:    

Combina la autenticación de RADIUS y autorización como un solo proceso. Cifra solamente la contraseña. Utiliza UDP. Admite tecnologías de acceso remoto, 802.1x y el protocolo SIP (Session Initiation Protocol).

Mientras ambos protocolos pueden usarse para la comunicación entre un router y los servidores AAA, TACACS+ se considera el protocolo más seguro. Esto se debe a que se cifran todos los intercambios de protocolos TACACS+, mientras que RADIUS solo cifra la contraseña del usuario. RADIUS no cifra nombres de usuario, información de la cuenta, o cualquier otra información que contenga el mensaje de RADIUS.

Nota: la configuración de AAA va más allá del alcance de este curso. 8. 802.1X El estándar IEEE 802.1X define un control de acceso y un protocolo de autenticación basado en puertos que evita que las estaciones de trabajo no autorizadas se conecten a una LAN a través de los puertos de switch acceso público. El servidor de autenticación autentica cada estación de trabajo que está conectada a un puerto del switch antes habilitar cualquier servicio ofrecido por el switch o la LAN. Con la autenticación 802.1x basada en puertos, los dispositivos de la red tienen funciones específicas, como se muestra en la Figura 1.






El cliente (suplicante): Es generalmente el puerto habilitado 802.1x en el dispositivo que solicita el acceso a los servicios de la LAN y del switch y luego responde a las solicitudes desde el switch. En la Figura 1, el dispositivo es una PC que ejecuta software de cliente que cumple con el estándar 802.1X. Switch (autenticador): Controla el acceso físico a la red según el estado de autenticación del cliente. El switch funciona como actúa intermediario (proxy) entre el cliente y el servidor de autenticación. Solicita la identificación de la información del cliente, verifica dicha información al servidor de autenticación y transmite una respuesta al cliente. El switch utiliza un agente de software de RADIUS que es responsable de encapsular y desencapsular las tramas del protocolo de autenticación extensible (EAP) y de interactuar con el servidor de autenticación. Servidor de autenticación: realiza la autenticación real del cliente. El servidor de autenticación acepta la identidad del cliente y notifica al switch si el cliente está autorizado para acceder a los servicios de la LAN y del switch. Debido a que el switch actúa como el proxy, el servicio de autenticación es transparente para el cliente. El sistema de seguridad RADIUS con extensiones de EAP es el único servidor de autenticación admitido.

9. IDENTIFICAR LA MEJOR PRACTICA DE SEGURIDAD

10. DESCRIPCIÓN GENERAL DE SNMPv3 El protocolo simple de administración de redes versión 3 (SNMPv3) autentica y cifra los paquetes de toda la red para proporcionar un acceso seguro a los dispositivos. El agregado de la autenticación y el cifrado a SNMPv3 brinda una solución a las vulnerabilidades de las versiones anteriores de SNMP.

10.1. PASOS DE CONFIGURACIÓN DE SNMPv3 SNMPv3 se puede asegurar con solo unos pocos comandos, como se muestra en los siguientes pasos:

Paso 1. Configurar una ACL que permita el acceso a los administradores de SNMP autorizados. Router(config)# ip access-list standard acl-name Router(config-std-nacl)# permit source_net

Ing. José Dennis Estela Zumaeta Paso 2. Configurar una vista de SNMP con el comando snmp-server view para identificar qué identificadores de objetos MIB (OID) podrá leer el administrador de SNMP. Se requiere la configuración de una visualización para limitar los mensajes SNMP a acceso de sólo lectura. Router(config)# snmp-server view view-name oid} tree {included | excluded

Paso 3. Configurar características de grupo SNMP con el comandosnmp-server group: 1. 2. 3. 4.

Configure un nombre para el grupo. Establezca la versión de SNMP en 3 con la palabra clave v3. Requerir autenticación y el cifrado con la palabra clave priv. Asocie una visualización al grupo y otórguele acceso de solo lectura con el comando read. 5. Especifique la ACL configurada en el paso 1. Router(config)# snmp-server group group-name v3 priv read viewname access [acl-number | acl-name]

Paso 4. Configure las características de usuario del grupo SNMP con el comando snmp-server user: 1. Configure un nombre de usuario y asigne el usuario al nombre del grupo que se configuró en el paso 3.

2. Establezca la versión de SNMP en 3 con la palabra clave v3. 3. Establezca el tipo de autenticación en md5 o sha y configurar una contraseña de autenticación. Se prefiere el SHA y debe ser admitido por el software de administración de SNMP. 4. Requiera cifrado con la palabra clave priv y configure una contraseña de cifrado. Router(config)# snmp-server user username group-name v3 auth { md5 | sha} auth password priv {des | 3des | aes {128 | 192 | 256}} privpassword

En el Ejemplo 1, una ACL estándar con nombre PERMIT-ADMIN está configurada para admitir sólo la red 192.168.1.0/24. Todos los hosts conectados a esta red tendrán permiso para acceder al agente SNMP que se ejecuta en R1. Una vista de SNMP se denomina SNMP-RO y está configurada para incluir el árbol completo de la iso de la MIB. En una red de producción, el administrador de red probablemente configuraría esta vista para incluir sólo los OID de MIB que fueran necesarios para supervisar y administrar la red. Se configura un grupo SNMP con el nombre ADMIN. El SNMP se establece en versión 3 con autenticación y cifrado requeridos. El grupo tiene acceso de solo lectura a la vista (SNMP-RO). El acceso para el grupo está limitado por PERMIT-ADMIN ACL. Un usuario SNMP, BOB, se configura como miembro del grupo ADMIN. El SNMP se establece en la versión 3. La autenticación se establece para usar SHA, y se configura una contraseña de autenticación. Aunque el R1 admite hasta el cifrado AES 256, software de administración SNMP solo admite AES 128. Por lo tanto, el cifrado se establece en AES 128 y se configura una contraseña de cifrado.

Ing. José Dennis Estela Zumaeta Un análisis completo de las opciones de configuración para SNMPv3 excede el alcance de este curso.

10.2. VERIFICACIÓN SNMPv3 Utilice el comando ping para verificar la conectividad entre los agentes y los clientes. Utilice el comando show snmp group para mostrar información sobre cada grupo SNMP en la red, como se muestra en el Ejemplo 1.

Utilice el comando show snmp user para mostrar información sobre las características configuradas de un usuario SNMP, como se muestra en el Ejemplo. 2.

Ing. José Dennis Estela Zumaeta 10.3. CONFIGURAR Y VERIFICAR SNMPv3

Ing. José Dennis Estela Zumaeta 11.PUERTOS REFLEJADOS Un analizador de paquetes (también conocido como analizador de protocolos, detector de paquetes o analizador de tráfico) es una herramienta valiosa para ayudar a supervisar y a resolver los problemas de una red. Un analizador de paquetes es el software que captura los paquetes que ingresan y que salen de una tarjeta de interfaz de red (NIC). Por ejemplo, Wireshark es un analizador de paquetes que se usa comúnmente para capturar y analizar los paquetes en una computadora local. ¿Qué sucedería si un administrador de red deseara capturar los paquetes de muchos otros dispositivos fundamentales y no solos la NIC local? Una solución consiste en configurar los dispositivos de red para copiar y enviar el tráfico que va a los puertos de interés a un puerto conectado a un analizador de paquetes. El administrador luego podría analizar el tráfico de red de diversas fuentes en la red Sin embargo, la operación básica de una red conmutada moderna inhabilita la capacidad del analizador de paquetes para capturar el tráfico de otras fuentes. Por ejemplo, un usuario que ejecuta Wireshark puede capturar sólo el tráfico que entra a su NIC. No puede capturar el tráfico entre otro host y un servidor. El motivo es porque un switch de capa 2 completa la tabla de direcciones MAC en base a la dirección MAC de origen y el puerto de ingreso de la trama de Ethernet. Una vez que se crea la tabla, el switch solamente reenvía el tráfico destinado a una dirección MAC directamente al puerto correspondiente. Esto evita que un analizador de paquetes conectado a otro puerto del switch "escuche" otro tráfico del switch. La solución a este dilema es habilitar los puertos reflejados. La función de puertos reflejados permite que un switch copie y envíe tramas de Ethernet desde puertos específicos al puerto de destino conectado a un analizador de paquetes. La trama original aún se reenvía de la manera habitual. En la Figura 1, se muestra un ejemplo de puertos reflejados.

En la figura, el tráfico entre la PC1 y la PC2 también se envía a la computadora portátil que tiene un analizador de paquetes instalado.

12.SPAN LOCAL La función Analizador de puertos con switches (SPAN) de los switches Cisco es un tipo de puertos reflejados que envía copias de la trama que ingresa a un puerto, desde otro puerto del mismo switch. Es común encontrar un dispositivo ejecutando un analizador de paquetes, un sistema de detección de intrusiones (IDS), o un sistema de prevención de intrusiones (IPS) conectado a ese puerto.

Ing. José Dennis Estela Zumaeta En la Tabla 1, se describen los términos de uso general con el SPAN.

Una sesión SPAN es la asociación entre los puertos de origen (o VLAN) y un puerto de destino. El tráfico que entra o que sale del puerto de origen (o VLAN) es replicado por el switch en el puerto de destino. Aunque SPAN puede admitir múltiples puertos de varias fuentes en una misma sesión o toda una VLAN como el origen del tráfico, una sesión SPAN no admite a ambos. Los puertos de capa 2 y de capa 3 se pueden configurar como puertos de origen. Existen tres cosas más importantes para tener en cuenta cuando configuramos SPAN: 





El puerto de destino no puede ser un puerto de origen, y el puerto de origen no puede ser un puerto de destino. El número de puerto de destino depende de la plataforma. Algunas plataformas permiten más de un puerto de destino. El puerto de destino ya no es un puerto de switch normal. A través de ese puerto solo pasa tráfico supervisado.

Ing. José Dennis Estela Zumaeta Se dice que la función SPAN es local cuando todos los puertos supervisados se encuentran en el mismo switch que el puerto de destino. Esta función contrasta con del SPAN remoto (RSPAN).

12.1. SPAN REMOTO El RSPAN permite que los puertos de origen y destino estén en switches diferentes. El RSPAN es útil en redes de campus, donde es muy probable que no haya un analizador de paquetes conectado al mismo switch en el que necesita capturar el tráfico. En la Tabla 1, se describen los términos de uso general con el RSPAN.

SPAN remoto utiliza dos sesiones, una sesión como origen y una sesión para copiar o recibir el tráfico de una VLAN. La Figura 1 muestra un ejemplo de RSPAN. Observe el enlace troncal utilizado para transportar la VLAN de SPAN remoto a través de la red.

Ing. José Dennis Estela Zumaeta 12.2. IDENTIFICAR LA TERMINOLOGIA SPAN

12.3. CONFIGURACION DE SPAN LOCAL Utilice los siguientes comandos para definir el puerto de origen y el puerto de destino para una sesión SPAN: S1(config)# monitor session number source {interface | vlans} S1(config)# monitor session number destination {interface | vlans}

Nota: El ID de sesión utilizado para definir los puertos de origen y destino debe ser igual para asignar los puertos a la misma sesión SPAN. En la Figura 1, el administrador debe captar todo el tráfico que se envía a la PC1 o que es recibido por esta. Un analizador de paquetes está conectado a G0/2. Como PC1 conectado al puerto del switch G0/1, se crea una sesión utilizando SPAN G0/1 como origen y G0/2 como destino. Dado que todos los puertos involucrados pertenecen al mismo switch, esto se considera SPAN local.

El ejemplo 1 ilustra una configuración básica de SPAN para la Figura 1.


Para verificar la configuración de la sesión SPAN, utilice el comando show monitor , como se muestra en el Ejemplo. 2. Este comando devuelve el tipo de sesiones, los puertos de origen para cada dirección del tráfico y el puerto de destino.

12.4. SOLUCIÓN DE PROBLEMAS CON LA DESCRIPCIÓN GENERAL DE SPAN La función Analizador de puertos con switches (SPAN) permite que los administradores distribuyan el tráfico a los dispositivos especializados, como los analizadores de paquete y los sistemas de protección contra intrusiones (IPS). Esto permite que los administradores analicen el tráfico y resuelvan problemas antes de enviar el tráfico hacia el destino. Los IPS buscan patrones específicos en el tráfico. A medida que el tráfico atraviesa los IPS, puede analizar el tráfico en tiempo real y tomar medidas al detectar un patrón de tráfico predefinido. Los IPS se utilizan principalmente para detectar ataques a la red mientras estos se producen y enviar alertas o incluso bloquean los paquetes maliciosos mientras se produce el ataque. Para ser eficaces, los IPS deben tener la capacidad para examinar todo el flujo de tráfico en una red. Debido a que las redes modernas son entornos conmutados, el SPAN es fundamental para la operación eficaz de los IPS. Algunos patrones de ataques son más complejos que otros. Por ejemplo, un ataque LAND (ataque de red de área local) envía un paquete TCP SYN suplantado (inicio de conexión) con la misma dirección IP de origen y de destino del host de destino y el mismo puerto de origen y destino que un puerto abierto del objetivo. Un ataque LAND hace que la máquina responda a sí misma continuamente. Debido a que se requiere un solo paquete se requiere para identificar este tipo de ataque, el IPS puede evitar fácilmente que estos paquetes ingresen a la red en su totalidad. Además de los IPS, otro dispositivo común utilizado para recibir el tráfico de SPAN el analizador de paquetes. Mientras que los IPS se centran más en el aspecto de seguridad del tráfico, los analizadores de paquete se suelen utilizar para la solución de problemas. Por ejemplo, si una aplicación de red particular demora demasiado en ejecutar las tareas, un administrador de red puede utilizar SPAN para duplicar y redirigir el tráfico hacia un analizador de paquetes para capturarlo. El administrador luego puede analizar el tráfico de todos los dispositivos para solucionar problemas de funcionamiento por debajo del nivel óptimo de la aplicación de red.

Ing. José Dennis Estela Zumaeta 13.PRIORIZACIÓN DEL TRAFICO (CALIDAD DE SERVICIO –QoS) La calidad de servicio (QoS) es un requisito cada vez más importante para las redes hoy en día. Las nuevas aplicaciones disponibles para los usuarios, como las transmisiones de voz y de video en vivo generan expectativas más altas sobre la calidad de los servicios que se proporcionan. La congestión se produce cuando la demanda de ancho de banda excede la cantidad disponible. Cuando se producen intentos de comunicaciones simultáneas a través de la red, la demanda de ancho de banda puede exceder su disponibilidad, lo que provoca congestión en la red. Cuando el volumen del tráfico es mayor que lo que se puede transportar través de la red, los dispositivos colocan los paquetes en cola, o en espera, en la memoria hasta que haya recursos disponibles para transmitirlos, como se muestra en la Figura 1. Los paquetes en cola causan retrasos, dado que los nuevos paquetes no se pueden transmitir hasta que no se hayan procesado los anteriores. Si el número de paquetes en cola continúa aumentando, las colas de la memoria se llenan y los paquetes se descartan.

13.1. ANCHO DE BANDA, CONGESTION, DEMORA Y FLUCTUACIONES El ancho de banda de la red es la medida de la cantidad de bits que se pueden transmitir en un segundo, es decir, bits por segundo (bps). Los administradores de redes generalmente hacen referencia al rendimiento de los dispositivos de red describiendo el ancho de banda de las interfaces expresadas. Por ejemplo, para describir un dispositivo de red, se puede especificar que tiene un rendimiento de 10 gigabits por segundo (Gbps). La congestión de la red produce demoras. Las variaciones en la demora producen fluctuaciones. Una interfaz experimenta congestión cuando tiene más tráfico del que puede gestionar. Los puntos de congestión de la red son candidatos fuertes para los mecanismos de QoS. La Figura 1 muestra tres ejemplos típicos de puntos de congestión.


Nota: Un dispositivo implementa únicamente QoS cuando experimenta algún tipo de congestión. La demora o la latencia se refiere al tiempo que demora un paquete en viajar de origen a destino. Hay demoras fijas y demoras variables. Las causas de las demoras se resumen en la Tabla 1.

La fluctuación de fase es la variación en la demora de paquetes. En el extremo emisor, los paquetes se envían de manera permanente con los paquetes de espacio uniforme por separado. Debido a la congestión en la red, la espera incorrecta o los errores de configuración, la demora entre cada paquete puede variar en lugar de mantenerse constante. Es necesario controlar y minimizar tanto la demora como las fluctuaciones para admitir el tráfico en tiempo real e interactivo.

13.2. PÉRDIDA DE PAQUETES Sin mecanismos de QoS en el lugar, los paquetes se procesan en el orden en el que se reciben. Cuando se produce una congestión, los routers y los switches comienzan a descartar los paquetes. Esto significa que los paquetes sensibles al tiempo, como el video y la voz en tiempo real y voz, se descartarán con la misma frecuencia que los datos que no sean urgentes, como el correo electrónico y la exploración web. Por ejemplo, cuando un router recibe un flujo de audio digital del protocolo de transmisión en tiempo real (RTP) del protocolo de tiempo real para voz sobre IP (VoIP), debe compensar las fluctuaciones que se encuentren. El mecanismo que administra esta función es el búfer de demora de reproducción. El búfer de demora de reproducción debe almacenar en búfer estos paquetes y luego reproducirlos en un flujo

Ing. José Dennis Estela Zumaeta constante que se convertirá en un flujo de audio analógico, como se muestra en la Figura 1.

Si las fluctuaciones son tan grandes que hacen que los paquetes se reciban fuera del alcance de este búfer, se descartan los paquetes que están fuera del rango, y se escuchan interrupciones en el audio, como se muestra en la Figura 2.

Para las pérdidas tan pequeñas como un paquete, el procesamiento digital de señales (DSP) interpola lo que considera que debe ser el audio y no hay ningún problema audible. Sin embargo, cuando las fluctuaciones exceden lo que puede hacer el DSP para compensar los paquetes faltantes, se escuchan los problemas de audio. La pérdida de paquetes es una causa común de los problemas de calidad de voz en una red IP. En una red diseñada correctamente, la pérdida de paquetes debe estar cerca de cero. Los códecs de voz utilizados por DSP pueden tolerar cierto grado de pérdida de paquetes sin un efecto radical en la calidad de voz. Los ingenieros de redes utilizan mecanismos de QoS para clasificar paquetes de voz para que la pérdida de paquetes sea igual a cero. Se garantiza el ancho de banda para las llamadas de voz dando prioridad al tráfico de voz sobre el tráfico que no es sensible al tiempo.

Ing. José Dennis Estela Zumaeta 13.3. IDENTIFICAR LA TERMINOLOGIA DE LA CALIDAD DE LA TRANSMISION DE LA RED

13.4. TENDENCIAS DEL TRÁFICO DE LA RED A principios de la década del 2000, los tipos de tráfico IP predominantes eran voz y datos. El tráfico de voz tiene una necesidad de ancho de banda predecible y tiempos de llegada de paquete conocidos. El tráfico de datos no es en tiempo real, y tiene una necesidad impredecible de ancho de banda. El tráfico de datos puede tener estallidos temporalmente, como cuando se descarga un archivo grande. Este estallido puede consumir todo el ancho de banda de un enlace. Más recientemente, el tráfico de video se ha vuelto cada vez más importante para las comunicaciones y las operaciones empresariales. Según Cisco Virtual Networking Index (VNI) (Enlaces a un sitio externo.), en 2014, el tráfico de video representó el 67% de todo el tráfico. Para 2019, representará el 80% de todo el tráfico. Además, el tráfico de video móvil aumentará más del 600%, de 113 672 TB a 768 334 TB. Los tipos de demandas de voz, video y tráfico de datos en la red son muy diferentes.

13.5. VOZ El tráfico de voz es predecible y uniforme, como se muestra en la Figura 1. El tráfico de voz es benigno, lo que significa que no consume muchos recursos de red. Sin embargo, la voz es muy sensible a las demoras y los paquetes descartados, y no se puede volver a transmitir si se pierde. Por lo tanto, debe recibir una prioridad más alta. Por ejemplo, los productos de Cisco utilizan el rango de puerto de 16384 a 32767 de RTP para priorizar el tráfico de voz. La voz puede tolerar cierta cantidad de latencia, fluctuación y la pérdida sin ningún efecto notable. La latencia no debe superar los 150 milisegundos (ms). Las fluctuaciones no deben superar los 30 ms y la pérdida de paquetes de voz no debe ser superior al 1%. El tráfico de voz requiere por lo menos 30 KB/s de ancho de banda.


13.6. VIDEO Sin QoS y una cantidad significativa de capacidad de ancho de banda adicional, la calidad de video normalmente disminuye. La imagen se muestra borrosa, dentada o en la cámara lenta. El audio de la fuente puede perder la sincronización con el video. El tráfico de video tiende a ser imprevisible, inconsistente y a transmitirse por ráfagas, en comparación con el tráfico de voz. En comparación con la transmisión de voz, el video es menos resistente a pérdidas y tiene un mayor volumen de los datos por paquete, como se muestra en la Figura 1. Observe cómo los paquetes de voz llegan cada 20 ms y son de 200 bytes predecibles cada uno. En cambio, la cantidad y el tamaño de los paquetes de video varían cada 33 ms según el contenido del video. Por ejemplo, si la transmisión de video se compone de contenido que no cambia mucho de un cuadro a otro, los paquetes de video serán pequeños, y se necesitarán menos para mantener una experiencia de usuario aceptable. Sin embargo, si la transmisión de video está compuesta por contenido que cambia rápidamente (por ejemplo, una secuencia de acción en una película), los paquetes de video serán más grandes y se requerirán más por cada módulo de tiempo de 33 ms para mantener una experiencia de usuario aceptable.

Ing. José Dennis Estela Zumaeta En la Tabla 2, se resumen las características del tráfico de video. Los puertos UDP, como 554 utilizados para el protocolo de transmisión en tiempo real (RSTP), deben tener prioridad sobre otro tráfico de red menos sensible al tiempo. Al igual que la voz, el video puede tolerar cierta cantidad de latencia, fluctuación, y pérdida sin ningún efecto notable. La latencia no debe ser superior a 400 milisegundos (ms). Las fluctuaciones no deben ser de más de 50 ms, y la pérdida de paquetes de video no debe ser superior al 1%. El tráfico de video requiere por lo menos 384 kb/s de ancho de banda.

13.7. DATOS La mayoría de las aplicaciones utilizan TCP o UDP. A diferencia de UDP, TCP realiza la recuperación de errores. Aplicaciones de datos que no tienen tolerancia a la pérdida de datos, como el correo electrónico y las páginas web, el uso de TCP para asegurarse de que, si los paquetes se pierden en tránsito, se envíen nuevamente. El tráfico de datos puede ser fluido o puede tener estallidos. El tráfico de control de red generalmente es elegante y predecible. Cuando hay un cambio de topología, el tráfico de control de red puede tener estallidos durante unos segundos. Pero la capacidad de las redes actuales permite administrar fácilmente el aumento del tráfico de control de red mientras la red converge. Sin embargo, algunas aplicaciones TCP pueden ser muy expansivas y consumir una gran porción de la capacidad de la red. El FTP ocupará tanto ancho de banda como pueda obtener cuando usted descargue un archivo grande, como una película o un juego. En la Tabla 1, se resumen las características del tráfico de datos.

Ing. José Dennis Estela Zumaeta Aunque el tráfico de datos es relativamente insensible a las caídas y demoras en comparación con la voz y el video, un administrador de red igualmente debe tener en cuenta la calidad de la experiencia del usuario, a veces denominada "calidad de la experiencia" o QoE. Los dos factores principales acerca del flujo del tráfico de datos por los que un administrador de red debe preguntar son los siguientes:

13.8. DESCRIPCION GENERAL DE LA PUESTA EN COLA La política de QoS implementada por el administrador de la red se activa cuando se produce una congestión en el enlace. La puesta en cola es una herramienta administrativa para la congestión que puede almacenar en búfer, priorizar, y, si corresponde, reordenar los paquetes antes de que estos se transmitan al destino. Se encuentran disponibles varios algoritmos de puesta en cola. A los fines de este curso, nos concentraremos en lo siguiente:   



Primero en entrar, primero en salir (FIFO) Mecanismo de cola equitativo ponderado (WFQ) CBWFQ (mecanismo de cola de espera equitativo y ponderado basado en clases) Mecanismo de cola de baja latencia (LLQ)

EL PRIMERO EN ENTRAR ES EL PRIMERO EN SALIR (FIFO, first in, first out) En su forma más sencilla, la cola FIFO (también conocida como "primero en entrar, primero en salir" o FCFS) implica almacenar en búfer y reenviar paquetes en el orden de llegada. FIFO no tiene ningún concepto de prioridad o clase de tráfico y, por lo tanto, no toma ninguna decisión sobre la prioridad del paquete. Hay una sola cola, y todos los paquetes se tratan por igual. Se envía una interfaz a los paquetes en el orden en el que llegan, como se muestra en la Figura 1. Aunque el tráfico sea más importante o sensible al tiempo según la clasificación de prioridad, observe que el tráfico se envía en el orden en que se recibe.


Cuando se utiliza FIFO, el tráfico importante o sensible al tiempo se puede descartar cuando se produce una congestión en el router o en la interfaz del switch. Cuando no hay otras estrategias de cola configuradas, todas las interfaces, excepto las interfaces seriales en E1 (2048 mbps) y debajo utilizan FIFO de manera predeterminada. (Las interfaces seriales en E1 y debajo utilizan WFQ por defecto). FIFO, que es el método más rápido de espera, es eficaz para enlaces grandes que tienen poco retraso y congestión mínima. Si su enlace tiene una congestión muy pequeña, la cola FIFO puede ser la única cola que necesite usar.

MECANISMO DE COLA EQUITATIVO PONDERADO (WFQ) La WFQ es un método de programación automatizada que proporciona la asignación del ancho de banda justo a todo el tráfico de red. La WFQ aplica la prioridad o las ponderaciones al tráfico identificado y lo clasifica en conversaciones o flujos, como se muestra en la Figura 1.

Ing. José Dennis Estela Zumaeta El WFQ luego determina la cantidad de ancho de banda que se le permite a cada flujo en relación con otros flujos. El algoritmo basado en el flujo utilizado por la WFQ planifica simultáneamente el tráfico interactivo al frente de una cola para reducir el tiempo de respuesta. Luego, comparte equitativamente el ancho de banda restante entre flujos de ancho de banda altos. El WFQ le permite dar prioridad al tráfico de bajo volumen e interactivo, como las sesiones Telnet y de voz, sobre el tráfico de gran volumen, como las sesiones de FTP. Cuando se producen simultáneamente los flujos de las transferencias de archivo múltiples, se asigna un ancho de banda similar a las transferencias. La WFQ clasifica el tráfico en distintos flujos basados en el encabezado de manejo de paquetes, lo que incluye características como las direcciones IP de origen y de destino, las direcciones MAC, los números de puerto, el protocolo y el valor del tipo de servicio (ToS). El valor ToS en el encabezado IP puede utilizarse para clasificar el tráfico. El ToS se describirá más adelante en el capítulo. Los flujos de tráfico de bajo ancho de banda, que conforman el mayor parte del tráfico, reciben servicio preferencial, lo que permite que todas sus cargas ofrecidas se envíen oportunamente. Los flujos de tráfico de gran volumen comparten la capacidad restante proporcionalmente entre sí. Limitaciones La WFQ no se utiliza con los túneles y el cifrado porque estas funciones modifican la información de contenido de paquete requerida por la WFQ para la clasificación. Si bien la WFQ se adapta automáticamente a las condiciones de tráfico de red cambiantes, no ofrece el grado de control de precisión sobre la asignación de ancho de banda que ofrece el CBWFQ.

CBWFQ (MECANISMO DE COLA DE ESPERA EQUITATIVO Y PONDERADO BASADO EN CLASES) El CBWFQ extiende la funcionalidad estándar de la cola equitativa ponderada (WFQ) para admitir las clases de tráfico definidas por el usuario. Para el CBWFQ, se definen las clases de tráfico en base a los criterios de concordancia, incluidos los protocolos, las listas de control de acceso (ACL) y las interfaces de entrada. Los paquetes que cumplen los criterios de coincidencia para una clase constituyen el tráfico para esa clase. Se reserva una cola FIFO para cada clase, y el tráfico que pertenece a una clase se dirige a la cola para esa clase, como se muestra en la Figura 1.

Ing. José Dennis Estela Zumaeta Cuando se ha definido una clase según sus criterios de coincidencia, puede asignarle características. Para cuantificar una clase, le asigna el ancho de banda, el peso, y el límite de paquete máximo. El ancho de banda asignado a una clase es el ancho de banda garantizado que se entrega a la clase durante la congestión. Para caracterizar una clase, también especifica el límite de cola para esa clase, que es la cantidad máxima de paquetes que se pueden acumular en la cola de esa clase. Los paquetes que pertenecen a una clase están sujetos al ancho de banda y a los límites de cola que caracterizan a la clase. Una vez que una cola haya alcanzado su límite de cola configurado, el agregado de más paquetes a la clase hace que surtan efecto el descarte de cola o el descarte de paquetes, según cómo esté configurada la política de clase. El descarte de cola significa que un router descarta simplemente cualquier paquete que llega al extremo de una cola que ha utilizado por completo sus recursos de retención de paquetes. Esta es la respuesta de espera predeterminada para la congestión. El descarte de cola trata todo el tráfico por igual y no distingue entre las clases de servicio.

MECANISMO DE COLA DE BAJA LATENCIA (LLQ) La función de LLQ proporciona la cola de prioridad estricta (PQ) a CBWFQ. La asignación de cola de prioridad estricta permite que los datos susceptibles a la demora, como la voz, se envíen antes que los paquetes de otras colas. La LLQ proporciona la cola de prioridad estricta para CBWFQ, lo que reduce las fluctuaciones en las conversaciones de voz, como se muestra en la Figura 1.

Sin la LLQ, CBWFQ proporciona el WFQ según las clases definidas sin una cola de prioridad estricta disponible para el tráfico en tiempo real. El peso para un paquete que pertenece a una clase específica se deriva del ancho de banda que le asignó a la clase al configurarla. Por lo tanto, el ancho de banda asignado a los paquetes de una clase determina el orden en que se envían los paquetes. Se realiza el servicio de todos los paquetes en base suficiente al peso; ninguna clase de paquetes puede otorgar la prioridad estricta. Este esquema presenta problemas para el tráfico de voz, que en gran medida no admite retrasos, especialmente variaciones en el retraso. Para el tráfico de voz, las variaciones en la demora introducen irregularidades en la transmisión que se manifiestan como fluctuaciones en la conversación escuchada. Con la LLQ, los datos susceptibles a la demora se envían primero, antes de que se procesen los paquetes de otras colas. La LLQ permite que los datos susceptibles a la

Ing. José Dennis Estela Zumaeta demora, como la voz, se envíen primero (antes que los paquetes de otras colas), con lo que se otorga un tratamiento preferencial a los datos susceptibles a la demora con respecto a otros tipos de tráfico. Si bien se pueden poner varios tipos de tráfico en tiempo real en la cola de prioridad estricta, Cisco recomienda enviar solamente el tráfico de voz.

COMPARAR LOS ALGORITMOS DE COLA



La cantidad de bits que se pueden transmitir a través de una red en un solo segundo: ANCHO DE BANDA.

13.9. SELECCIÓN DE UN MODELO ADECUADO DE POLITICA DE CALIDAD DE SERVICIO (QoS) ¿Cómo se puede implementar QoS en una red? Existen tres modelos para implementar QoS. La Tabla 1 resume estos tres modelos:

Ing. José Dennis Estela Zumaeta QoS se implementa realmente en una red que utiliza IntServ o DiffServ. Aunque IntServ proporciona la garantía más alta de QoS, utiliza muchos recursos y por lo tanto su escalabilidad es limitada. En cambio, DiffServ consume menos recursos y es más escalable. En algunas ocasiones, los dos se emplean juntos para la implementación de QoS en redes.

MODELO DE MEJOR ESFUERZO El diseño básico de Internet ofrece la entrega de paquetes mediante el modelo de mejor esfuerzo y no brinda ninguna garantía. Este enfoque aún predomina en Internet actualmente y sigue siendo adecuado en la mayoría de los casos. El modelo de mejor esfuerzo trata a todos los paquetes de red de la misma manera, por eso un mensaje de voz de emergencia se trata de la misma manera que una foto digital adjuntada a un correo electrónico. Sin QoS, la red no puede conocer la diferencia entre paquetes y, como resultado, no puede tratar a los paquetes de manera preferencial. El modelo de mejor esfuerzo es un concepto similar al de enviar una carta por correo postal estándar. Su carta se trata exactamente de la misma manera que las otras cartas. Con el modelo de mejor esfuerzo, la carta podría no llegar y, a menos que haya llegado a un acuerdo de notificación con el destinatario de la carta, tal vez nunca se entere de que la carta no llegó. La Tabla 1 muestra los beneficios y las desventajas del modelo de mejor esfuerzo.

SERVICIOS INTEGRADOS Las necesidades de aplicaciones en tiempo real, como video remoto, conferencias multimedia, visualización y realidad virtual, motivaron el desarrollo del modelo de arquitectura IntServ en 1994 (RFC 1633, 2211 y 2212). IntServ es un modelo de servicio múltiple que puede acomodar múltiples requisitos de Calidad de Servicio (QoS). IntServ proporciona una manera de entregar la QoS completa que las aplicaciones en tiempo real requieren al administrar explícitamente los recursos de red para proporcionar QoS a las transmisiones de paquetes específicas de usuario, a veces denominados microflujos. Utiliza reserva de recursos y mecanismos de control de admisión como módulos de construcción para establecer y mantener QoS. Esta práctica es similar a un concepto conoci do como “hard QoS”. Hard QoS garantiza las características de tráfico, como el ancho de banda, la demora y las velocidades de pérdida de paquetes, de extremo a extremo. Hard QoS asegura niveles de servicios predecibles y garantizados para las aplicaciones críticas. La Figura 1 es una simple ilustración del modelo de IntServ.


IntServ utiliza un enfoque orientado a la conexión heredado del diseño de una red de telefonía. Cada comunicación individual debe especificar explícitamente su descriptor de tráfico y los recursos solicitados a la red. El router perimetral realiza el control de admisión para garantizar que los recursos disponibles son suficientes en la red. El estándar de IntServ asume que los routers a lo largo de una ruta configuran y mantienen el estado de cada comunicación individual. En el modelo de IntServ, la aplicación solicita a un tipo específico de servicio a la red antes de enviar datos. La aplicación informa a la red su perfil de tráfico y solicita a un tipo particular de servicio que puede abarcar requisitos de ancho de banda y retraso. IntServ utiliza el Protocolo de reserva de recursos (RSVP) para señalar las necesidades de QoS del tráfico de una aplicación junto con los dispositivos en la ruta de extremo a extremo a través de la red. Si los dispositivos de red a lo largo de la ruta pueden reservar el ancho de banda necesario, la aplicación de origen puede comenzar a transmitir. Si reserva solicitada falla a lo largo de la ruta, la aplicación de origen no envía ningún dato. La red realiza el control de admisión en base a la información de aplicaciones y los recursos de red disponibles. La red cumple con los requisitos de QoS de la aplicación siempre que el tráfico esté dentro de las especificaciones del perfil. La red cumple su compromiso al mantener el estado por flujo y llevar a cabo luego la clasificación de paquetes, de políticas, y espera inteligente basada en ese estado.

Ing. José Dennis Estela Zumaeta SERVICIOS DIFERENCIADOS El modelo de Calidad de Servicio (QoS) de servicios diferenciados (DiffServ) especifica un mecanismo simple y escalable para clasificar y administrar el tráfico de red y proporcionar las garantías de QoS en redes IP modernas. Por ejemplo, DiffServ puede proporcionar servicio garantizado de baja latencia al tráfico de red crítico, como voz o video, al mismo tiempo que proporciona garantías del mejor tráfico a servicios no críticos como tráfico web o transferencias de archivos. El diseño de DiffServ supera las limitaciones de los modelos de mejor esfuerzo e IntServ. El modelo DiffServ se describe en RFC 2474, 2597, 2598, 3246, 4594. DiffServ puede proporcionar una Calidad de Servicio “casi garantizada” sin perder rentabilidad ni escalabilidad. El modelo DiffServ es un concepto similar al de enviar un paquete mediante un servicio de entrega. Usted solicita (y paga) un nivel de servicio cuando envía un paquete. En la red de paquetes, se reconoce el nivel de servicio por el que usted pagó y se le brinda a su paquete servicio normal o preferencial, según lo que usted solicitó. DiffServ no es una estrategia de QoS de extremo a extremo porque no puede otorgar garantías de extremo a extremo. Sin embargo, el modelo DiffServ es un enfoque más escalable para implementar QoS. A diferencia de IntServ y "hard QoS" (QoS fuerte) en los que los hosts terminales señalan sus necesidades de QoS a la red, DiffServ no utiliza la señalización. En su lugar, DiffServ usa un enfoque de “soft QoS” (QoS suave). Funciona en el modelo que proporciona QoS, donde los elementos de red se configuran para mantener varias clases de tráfico cada uno con requisitos de QoS diferentes.

Mientras el host envía tráfico a un router, el router clasifica los flujos en agregados (clases) y proporciona la política QoS apropiada para las clases. DiffServ impone y aplica los mecanismos de QoS en base a saltos, aplicando uniformemente el

Ing. José Dennis Estela Zumaeta significado global a cada clase de tráfico para proporcionar flexibilidad y escalabilidad. Por ejemplo, DiffServ agrupa todos los flujos TCP como una única clase, y asigna un ancho de banda para esa clase, en lugar de los flujos individuales como haría IntServ. Además de clasificar el tráfico, DiffServ minimiza los requisitos de mantenimiento de señalización y estado en cada nodo de la red. Específicamente, DiffServ divide el tráfico de red en clases según los requisitos de la empresa. Se puede asignar a un nivel diferente de servicio a cada una de las clases. A medida que los paquetes atraviesan una red, cada uno de los dispositivos de red identifica la clase de paquete y brinda servicios al paquete según esa clase. Con DiffServ, es posible elegir muchos niveles de servicio. Por ejemplo, al tráfico de voz desde teléfonos IP se le otorga generalmente un trato preferencial sobre el resto del tráfico de aplicaciones, al correo electrónico se le da generalmente el servicio de mejor esfuerzo, y al tráfico no empresarial se le puede asignar muy poco servicio o bloquearlo por completo.

Nota: La red moderna usa principalmente el modelo DiffServ. Sin embargo, debido a los volúmenes crecientes de tráfico sensible a demoras y fluctuaciones, en ocasiones IntServ y RSVP se implementan juntos.

13.10. EVITAR LA PERDIDA DE PAQUETES La pérdida de paquetes es generalmente el resultado de la congestión en una interfaz. La mayoría de las aplicaciones que utilizan el TCP experimentan una disminución de velocidad debido a que el TCP se ajusta automáticamente a la congestión en la red. Los segmentos caídos del TCP hacen que las sesiones del TCP reduzcan su tamaño de ventana. Algunas aplicaciones no utilizan TCP y no pueden manejar las caídas (flujos frágiles).

Ing. José Dennis Estela Zumaeta Los siguientes enfoques pueden evitar las caídas de aplicaciones sensibles:  



Aumentar la capacidad de enlace para facilitar o evitar la congestión. Garantizar el suficiente ancho de banda y aumentar el espacio en búfer para acomodar las ráfagas de tráfico de flujos frágil. Existen varios mecanismos disponibles en el software de calidad de servicio (QoS) de Cisco IOS que pueden garantizar el ancho de banda y proporcionar el reenvío prioritario a las aplicaciones sensibles a las caídas. Algunos ejemplos son WFQ, CBWFQ y LLQ. Evitar la congestión el descartar paquetes de prioridad más baja antes de que se produzca la congestión. QoS de Cisco IOS proporciona mecanismos de espera que comienzan a descartar paquetes de prioridad más baja antes de que se produzca la congestión. Un ejemplo es la Detección Temprana Aleatoria Ponderada (WRED).

13.11. HERRAMIENTAS DE CALIDAD DE SERVICIO (QoS) Hay tres categorías de herramientas de QoS como se describe en la Tabla 1.

Consulte la Figura 1 para comprender la secuencia de cómo se utilizan estas herramientas cuando se aplica QoS a los flujos de paquetes.

Ing. José Dennis Estela Zumaeta Como se muestra en la ilustración, se clasifican los paquetes de ingreso (cuadros grises) y se marca su encabezado IP respectivo (cuadros de color). Para evitar la congestión, luego se asignan recursos a los paquetes en base a las políticas definidas. Los paquetes son luego puestos en la cola y reenviados a la interfaz de egreso según la política definida de modelado y regulación de tráfico de QoS.

Nota: La clasificación y la marcación se pueden aplicar en el ingreso o en el egreso, mientras que las otras acciones de QoS, como la organización de la cola y el modelado, generalmente se realizan al egreso.

13.12. CLASIFICACION Y MARCACION Antes de que a un paquete se le pueda aplicar una política de QoS, el mismo tiene que ser clasificado. La clasificación y la marcación nos permiten identificar o “marcar” los tipos de paquetes. La clasificación determina la clase de tráfico al cual los paquetes o tramas pertenecen. Solamente se pueden aplicar políticas al tráfico después de que este se haya identificado. Cómo se clasifica un paquete depende de la implementación de QoS. Los métodos de clasificación de flujos de tráfico en la capa 2 y 3 incluyen el uso de interfaces, ACL y mapas de clase. El tráfico también se puede clasificar en las capas 4 a 7 mediante el uso del Reconocimiento de aplicaciones basado en la red (NBAR).

Nota: NBAR es una función de clasificación y detección del protocolo del software Cisco IOS que funciona con funciones de QoS. NBAR excede el ámbito de este curso. La marcación significa que estamos agregando un valor al encabezado de paquetes. Los dispositivos que reciben el paquete se basan en este campo para ver si coincide con una política definida. La marcación debe realizarse tan cerca de la fuente como sea posible. Esto determina el límite de confianza.

13.13. MARCACIÓN DE TRÁFICO La forma en la que se marca el tráfico generalmente depende de la tecnología. La Tabla 1 describe algunos de los campos de marcación utilizados en las diferentes tecnologías. La decisión de marcar el tráfico en las capas 2 o 3 o en ambas no es trivial y se debe hacer una vez que se hayan considerado los siguientes puntos:

802.1Q es el estándar IEEE que admite VLAN en una red Ethernet. El estándar también incluye el esquema de priorización de calidad de servicio, denominado IEEE 802.1p.

Ing. José Dennis Estela Zumaeta 13.14. MARCACIÓN EN CAPA 2 El estándar 802.1Q es una especificación IEEE para implementar VLAN en redes conmutadas de capa 2. Como se muestra en la Figura 1, hay dos campos insertados en la trama de Ethernet después del campo de dirección de origen.

El identificador de protocolo de etiqueta (TPID) está establecido actualmente, y se le ha asignado el valor 0x8100. La información de control de etiqueta (TCI) contiene el campo de PRI de 3 bits (prioridad) que identifica las marcaciones de clase de servicio (CoS). La marcación de CoS permite que una trama de Ethernet de Capa 2 esté marcada con ocho niveles de prioridad (valores de 0 a 7), como se muestra en la Figura 2.

Ing. José Dennis Estela Zumaeta 13.15. MARCACION EN CAPA 3 IPv4 e IPv6 especifican un campo de 8 bits en sus encabezados de paquetes para marcar los paquetes. Como se muestra en la Figura 1, el IPv4 tiene el campo “Tipo de servicio” y el IPv6 tiene el campo “clase de tráfico” de 8 bits.

Estos campos se utilizan para transportar la marcación de paquete asignada por las herramientas de la clasificación de QoS. Luego, los dispositivos receptores remiten al campo para reenviar los paquetes según la política QoS asignada correspondiente. La Figura 2 muestra el contenido (es decir, de 7 a 0) del campo de 8 bits.

Nota: Los bits notificación de congestión extendida (ECN) se utilizan para identificar una marcación de capa 2 QoS. Algunos ejemplos son los bits de clase de servicio (CoS) de Ethernet 802.1p, los bits de prioridad de usuario de puente 802.1D de MAC o los valores experimentales de switching por etiquetas multiprotocolo (EXP MPLS). Los primeros 3 bits de orden superior significativos izquierdos se conocen como el campo de prioridad IP. Los 8 bits proporcionan un total de ocho clases de servicio posibles, como se muestra en la Figura 3.


Cuando se utiliza el modelo de servicios diferenciados (DiffServ), el paquete se marca utilizando 6 bits denominados bits del punto de código de servicios diferenciados (DSCP). Seis bits ofrecen un máximo de 64 clases de servicio posibles. Los routers de reconocimiento de DiffServ implementan los comportamientos por salto (PHB), que definen las propiedades de reenvío de paquetes asociadas a una clase de tráfico. Específicamente, existen cuatro categorías de PBH, como se describe en la Figura 1.

Ing. José Dennis Estela Zumaeta 13.16. LIMITES DE CONFIANZA ¿Dónde deberían producirse las marcaciones? El tráfico se debe clasificar y marcar lo más cerca su origen como sea técnicamente y administrativamente posible. Esto define el límite de confianza, como se muestra en la Figura 1.







Los terminales confiables tienen las capacidades y la inteligencia para marcar el tráfico de aplicaciones con las CoS de capa 2 apropiadas y/o los valores de DSCP de la Capa 3. Algunos ejemplos de terminales de confianza incluyen teléfonos IP, puntos de acceso inalámbrico, gateways y sistemas de videoconferencia, estaciones de conferencia IP y más. Los terminales seguros pueden hacer que el tráfico se marque en el switch de la capa 2. El tráfico también puede marcarse en los switches/routers de la capa 3.

Generalmente, es necesario volver a marcar el tráfico. Por ejemplo, la remarcación de los valores de CoS a valores de prioridad IP o DSCP.

13.17. PREVENCIÓN DE CONGESTIÓN La administración de congestión incluye los métodos de espera y de programación, donde el tráfico excesivo se almacena en búfer o se pone en cola (y a veces se descarta) mientras espera ser enviado en una interfaz de egreso. Las herramientas para evitar la congestión son más simples. Las cargas de tráfico de la red, en un esfuerzo por anticipar y evitar la congestión en los cuellos de botella de la red común y de internetwork antes de que la congestión se convierta en un problema. Estas técnicas proporcionan un trato preferencial para el tráfico superior (prioridad) cuando hay una congestión, mientras que en paralelo maximiza el uso del rendimiento de la red y de la capacidad, y minimiza pérdida de paquetes y el retardo. Por ejemplo, Cisco IOS QoS incluye la detección temprana aleatoria y ponderada (WRED) como una solución posible para evitar la congestión. El algoritmo WRED permite evitar la congestión en las interfaces de red al brindar administración del búfer y permitir que el tráfico TCP disminuya antes de que se agoten los buffers. El uso de WRED ayuda a evitar las eliminaciones de cola y maximiza el uso de la red y el rendimiento de las aplicaciones basadas en TCP. No se evita la congestión para el tráfico basado en el protocolo de datagrama de usuario (UDP), como el tráfico de voz. En el caso del tráfico basado en UDP, los métodos como la

Ing. José Dennis Estela Zumaeta puesta en cola y las técnicas de compresión ayudan a reducir, e incluso a prevenir, la pérdida de paquetes UDP.

13.18. MODELADO Y VIGILANCIA Las políticas de modelado y de vigilancia del son dos mecanismos proporcionados por el software Cisco IOS QoS para evitar la congestión. El modelado del tráfico conserva los paquetes en exceso en una cola y luego programa el exceso para la transmisión posterior en incrementos de tiempo. El resultado del modelado del tráfico es una velocidad de salida de paquetes alisada, como se muestra en la Figura 1.

El modelado implica la existencia de una cola y de memoria suficiente para almacenar en búfer los paquetes retardados, mientras que la vigilancia no hace esto. En cambio, la vigilancia del tráfico propaga los estallidos. Cuando la velocidad del tráfico alcanza el la velocidad máxima, se descarta el tráfico excesivo (o comentado). El resultado es una velocidad de salida que tiene una apariencia similar a la de los dientes de una sierra, con crestas y canales, como se muestra en la Figura 2.

La espera es un concepto de salida; los paquetes que salen de una interfaz pueden ponerse en cola y pueden ser formados. Solo se puede aplicar vigilancia al tráfico entrante en una interfaz. Asegúrese de tener memoria suficiente cuando active el modelado. Además, la formación requiere una función de programación para la transmisión posterior de cualquier paquete con retardo. Esta función de programación le permite organizar la cola de modelado en distintas colas. Entre las funciones de programación son CBWFQ y LLQ.


14.DESCRIPCION GENERAL DE LA NUBE La computación en la nube implica una gran cantidad de computadoras conectadas a través de una red que puede estar ubicada físicamente cualquier lugar. Los proveedores dependen en mayor medida de la virtualización para brindar sus servicios de computación en la nube. La computación en la nube puede reducir costos operativos al utilizar los recursos con mayor eficacia. La computación en la nube admite una variedad de problemas de administración de datos:  







Permite el acceso a los datos de organización en cualquier momento y lugar. Optimiza las operaciones de TI de la organización suscribiéndose únicamente a los servicios necesarios. Elimina o reduce la necesidad de equipos, mantenimiento y administración de TI en las instalaciones. Reduce el costo de equipos y energía, los requisitos físicos de la planta y las necesidades de capacitación del personal. Permite respuestas rápidas a los crecientes requisitos de volumen de datos.

La computación en la nube, con su modelo de “pago según el consumo”, permite que las organizaciones consideren los gastos de computación y almacenamiento más como un servicio que como una inversión en infraestructura. Los gastos de capital se transforman en gastos operativos.

14.1. SERVICIOS EN LA NUBE Los servicios en la nube están disponibles en una variedad de opciones diseñadas para cumplir con los requisitos del cliente. Los tres servicios principales de computación en la nube definidos por el Instituto Nacional de Normas y Tecnología (NIST) de los Estados Unidos en su publicación especial 800-145 son los siguientes:






Software como servicio (SaaS): El proveedor de la nube es responsable del acceso a los servicios, como correo electrónico, comunicación y Office 365 que se ofrecen a través de Internet. El usuario sólo necesita proporcionar sus datos. Plataforma como servicio (PaaS): El proveedor de la nube es responsable del acceso a las herramientas y los servicios de desarrollo utilizados para distribuir las aplicaciones. Infraestructura como servicio (IaaS): El proveedor de la nube es responsable del acceso al equipo de red, los servicios de red virtualizados y la infraestructura de red que utiliza.

Los proveedores de servicios en la nube han extendido este modelo para proporcionar también soporte de TI para cada uno de los servicios de computación en la nube (ITaaS). Para las empresas, los ITaaS pueden extender las funcionalidades de TI sin necesidad de invertir en infraestructura nueva, capacitación de personal nuevo o licencias de software nuevo. Estos servicios están disponibles a petición y se proporcionan de forma económica a cualquier dispositivo en cualquier lugar del mundo, sin comprometer la seguridad ni el funcionamiento.

14.2. MODELOS DE NUBE Existen cuatro tipos principales de nubes, como se muestra en la Figura 1.



Nubes públicas: Las aplicaciones basadas en la nube y los servicios que se ofrecen en una nube pública están a disposición de la población en general. Los servicios pueden ser gratuitos u ofrecerse en el formato de pago según el








uso, como el pago de almacenamiento en línea. La nube pública utiliza Internet para proporcionar servicios. Nubes privadas: Las aplicaciones y los servicios basados en una nube privada que se ofrecen en una nube privada están destinados a una organización o una entidad específica, como el gobierno. Se puede configurar una nube privada utilizando la red privada de la organización, si bien el armado y el mantenimiento pueden ser costosos. Una organización externa que cuente con una seguridad de acceso estricta también puede administrar una nube privada. Nubes híbridas: Una nube híbrida consta de dos o más nubes (por ejemplo, una parte personalizada y otra parte pública); donde cada una de las partes sigue siendo un objeto separado, pero ambas están conectadas a través de una única arquitectura. En una nube híbrida, las personas podrían tener grados de acceso a diversos servicios según los derechos de acceso de los usuarios. Nubes personalizadas: Estas son nubes desarrolladas para satisfacer las necesidades de una industria específica, como los servicios de salud o los medios de comunicación. Las nubes personalizadas pueden ser privadas o públicas.

14.3. COMPARACIÓN ENTRE LA COMPUTACIÓN EN LA NUBE Y EL CENTRO DE DATOS Los términos "centro de datos" y "computación en la nube" a menudo se usan de manera incorrecta. Estas son las definiciones correctas de centro de datos y computación en la nube: 



Centro de datos: Generalmente, consiste en una instalación de almacenamiento y procesamiento de datos gestionados por un departamento de TI interno o arrendado fuera de las instalaciones. Computación en la nube: Generalmente, consiste en un servicio fuera de las instalaciones que ofrece acceso a pedido a un grupo compartido de recursos informáticos configurables. Estos recursos se pueden aprovisionar y lanzar rápidamente con un esfuerzo de administración mínimo.

La computación en la nube es posible gracias a los centros de datos. Un centro de datos es una instalación utilizada para alojar sistemas de computación y componentes relacionados. Un centro de datos puede ocupar una habitación en un edificio, un piso o más, o un edificio entero. Por lo general, la creación y el mantenimiento de centros de datos son muy costosos. Por esta razón, solo las grandes organizaciones utilizan centros de datos privados creados para alojar sus datos y proporcionar servicios a los usuarios. Las organizaciones más pequeñas, que no pueden costear el mantenimiento de su propio centro de datos privado, pueden reducir el costo total de propiedad mediante el alquiler de servicios de servidor y almacenamiento a una organización en la nube con un centro de datos más grande. A menudo, la computación en la nube es a menudo un servicio proporcionado por los centros de datos, como se muestra en la Figura 1.


Los proveedores de servicios en la nube utilizan los centros de datos para sus servicios en la nube y sus recursos basados en la nube. Para garantizar la disponibilidad de los servicios de datos y los recursos, a menudo los proveedores mantienen espacios en varios centros de datos remotos.

14.4. TERMINOLOGIA DE COMPUTACION EN LA NUBE

Ing. José Dennis Estela Zumaeta 14.5. COMPUTACION EN LA NUBE Y VIRTUALIZACION Los términos “computación en la nube” y “virtualización” suelen usarse indistintamente; Sin embargo, significan diferentes cosas. La virtualización es la base de la computación en la nube. Sin ella, la computación en la nube más ampliamente utilizada no sería posible.

La computación en la nube separa la aplicación del hardware. La virtualización separa el SO hardware. Los diferentes proveedores ofrecen servicios en la nube virtuales que pueden proveer dinámicamente los servidores según sea necesario. Por ejemplo, el servicio web Amazon Elastic Compute Cloud (Amazon EC2) proporciona una manera simple para que los clientes proporcionen dinámicamente los recursos informáticos que necesitan. Estas instancias virtualizadas de los servidores se crean a pedido en el EC2 de Amazon.

14.6. SERVIDORES DEDICADOS Para poder apreciar completamente la virtualización, primero es necesario entender un poco parte la historia de la tecnología de los servidores. Históricamente, los servidores empresariales consistían en un sistema operativo (SO) del servidor, como Windows Server o Linux Server, instalado en el hardware específico, como se muestra en la Figura 1. Toda la RAM, la potencia de procesamiento y todo el espacio del disco duro de un servidor se dedicaban al servicio proporcionado (por ejemplo, red, servicios de correo electrónico, etc.).

El principal problema con esta configuración es que cuando falla un componente, el servicio proporcionado por este servidor no se encuentra disponible. Esto se conoce como punto único de falla. Otro problema era que los servidores dedicados eran infrautilizados. A menudo, los servidores dedicados estaban inactivos durante largos períodos de tiempo, esperando hasta que hubiera una necesidad de ofrecer un servicio específico que estos proporcionaban. Estos servidores malgastaban energía y ocupaban más espacio del que estaba garantizado por la cantidad de servicio. Esto se conoce como proliferación de servidores.

Ing. José Dennis Estela Zumaeta 14.7. VIRTUALIZACIÓN DE SERVIDORES La virtualización de servidores saca provecho de los recursos inactivos y consolida el número de servidores requeridos. Esto también permite que múltiples sistemas operativos existan en una sola plataforma de hardware. Por ejemplo, en la Figura 1, los ocho servidores dedicados anteriores se consolidaron en dos servidores utilizando hipervisores para admitir instancias virtuales múltiples de los sistemas operativos.

El hipervisor es un programa, un firmware o un hardware que suma una capa de abstracción a la parte superior del hardware físico real. La capa de abstracción se utiliza para crear máquinas virtuales que tienen acceso a todo el hardware de la máquina física, como CPU, memoria, controladores de disco y NIC. Cada una de esas máquinas virtuales ejecuta un sistema operativo completo y separado. Con la virtualización, las empresas ahora pueden consolidar el número de servidores. Por ejemplo, no es raro que 100 servidores físicos se consoliden como máquinas virtuales sobre los 10 servidores físicos que utilicen hipervisores. El uso de la virtualización normalmente incluye redundancia para brindar protección desde un punto sencillo de falla. La redundancia se puede implementar de diferentes maneras. Si falla el hipervisor, se puede reiniciar la VM en otro hipervisor. Además, la misma VM se puede ejecutar en dos hipervisores simultáneamente copiando las instrucciones de RAM y de CPU entre estos. Si falla un hipervisor, la VM continúa ejecutándose en el otro supervisor. Los servicios que se ejecutan en las VM también son virtuales y se pueden instalar o deshabilitar dinámicamente, según sea necesario.

Ing. José Dennis Estela Zumaeta 14.8. VENTAJAS DE LA VIRTUALIZACIÓN Una de las ventajas más importantes de la virtualización es un menor costo total: 





Se necesitan menos equipos: La virtualización permite la consolidación de los servidores, que requiere menos servidores físicos, menos dispositivos de red y menos infraestructura de soporte. También significa menores costos de mantenimiento. Se consume menos energía: La consolidación de los servidores reduce los costos de energía y de refrigeración mensuales. El consumo reducido ayuda a las empresas a alcanzar una huella de carbono más pequeña. Se requiere menos espacio La consolidación de servidores con la virtualización reduce la huella general del centro de datos. Menos servidores, dispositivos de red y racks reducen la cantidad de espacio de piso requerido

Estos son los beneficios adicionales de la virtualización: 









Creación de prototipos más sencilla : se pueden crear rápidamente laboratorios autónomos que funcionen en redes aisladas para probar y crear prototipos de implementación de redes. Si se comete un error, un administrador puede volver simplemente a una versión anterior. Los entornos de prueba pueden estar en línea, pero deben estar aislados de los usuarios finales. Una vez completada la prueba, se pueden implementar los servidores y los sistemas. Aprovisionamiento más rápido de servidores : crear un servidor virtual es mucho más rápido que el aprovisionamiento de un servidor físico. Mayor tiempo de actividad del servidor: La mayoría de las plataformas de virtualización de servidores ahora ofrecen funciones avanzadas redundantes con tolerancia a fallas, como la migración en vivo, la migración de almacenamiento, la alta disponibilidad y la programación distribuida de recursos. También admiten la capacidad de mover una máquina virtual de un servidor a otro. Recuperación tras un desastre mejorada: La virtualización ofrece soluciones avanzadas de continuidad de los negocios. Brinda la capacidad de abstracción de hardware de modo que el sitio de recuperación ya no necesite tener hardware que sea idéntico al hardware del entorno de producción. La mayoría de las plataformas de virtualización de servidores de la empresa también tienen software que puede ayudar a probar y automatizar las fallas antes de que suceda un desastre. Soporte heredado: La virtualización puede extender la vida útil de los OSS y de las aplicaciones, y esto brinda más tiempo a las organizaciones para migrar a nuevas soluciones.

Ing. José Dennis Estela Zumaeta 14.9. CAPAS DE ABSTRACCIÓN Para ayudar a explicar cómo funciona la virtualización, es conveniente utilizar capas de abstracción en arquitecturas de PC. Un sistema de computación consta de las capas de abstracción siguientes, como se muestra en la Figura 1:

En cada una de estas capas de abstracción, se utiliza algún tipo de código de programación como interfaz entre la capa inferior y la capa superior. Por ejemplo, el lenguaje de programación C se suele utilizar para programar el firmware que accede al hardware. En la Figura 2, se muestra un ejemplo de virtualización. Un hipervisor se instala entre el firmware y el OS. El hipervisor puede admitir varias instancias de SO.


14.10. HIPERVISORES DE TIPO 2 Un hipervisor es un software que crea y ejecuta instancias de VM. La computadora, en la que un hipervisor está ejecutando una o más VM, es un equipo host. Los hipervisores de tipo 2 también se denominan hipervisores alojados. Esto se debe a que el hipervisor está instalado en el SO existente, como Mac OS X, Windows o Linux. Luego, una o varias instancias adicionales del SO se instalan en el hipervisor, como se muestra en la Figura 1:

Una gran ventaja de los hipervisores de tipo 2 es que el software de la consola de administración no es necesario.

Ing. José Dennis Estela Zumaeta Los hipervisores de tipo 2 son muy populares entre los consumidores y en las organizaciones que experimentan con la virtualización. Los hipervisores comunes de tipo 2 incluyen:     

Virtual PC. VMware Workstation. Oracle VM VirtualBox. VMware Fusion. Mac OS X Parallels.

Muchos de estos hipervisores de tipo 2 son gratuitos. Algunos ofrecen funciones más avanzadas mediante el pago de una cuota.

Nota: Es importante asegurarse de que el equipo host sea lo suficientemente resistente para instalar y ejecutar las VM, para que no se quede sin recursos.

14.11. IDENTIFICAR LA TERMINOLOGIA DE LA VIRTUALIZACION

14.12. HIPERVISORES DE TIPO 1 Los hipervisores de tipo 1 también se denominan el enfoque de “infraestructura física” porque el hipervisor está instalado directamente en el hardware. Los hipervisores de tipo 1 se usan generalmente en los servidores empresariales y los dispositivos de redes para centros de datos.

Con los hipervisores de tipo 1, el hipervisor se instala directamente en el servidor o en el hardware de red. Luego, las instancias de un OS se instalan en el hipervisor, como se muestra en la Figura 1. Los hipervisores de tipo 1 tienen acceso directo a los recursos de hardware; por lo tanto, son más eficaces que las arquitecturas alojadas. Los hipervisores de tipo 1 mejoran la escalabilidad, el rendimiento y la solidez.


14.13. INSTALACION DE UNA VM EN UN HIPERVISOR Cuando se instala un hipervisor de tipo 1 y se reinicia el servidor, sólo se muestra la información básica, como la versión de SO, la cantidad de RAM y la dirección IP. Una instancia de OS no se puede crear a partir de esta pantalla. Los hipervisores de tipo 1 requieren una “consola de administración” para administrar el hipervisor. El software de administración se utiliza para administrar varios servidores con el mismo hipervisor. La consola de administración puede consolidar los servidores automáticamente y encender o apagar los servidores, según sea necesario. Por ejemplo, suponga que el Servidor1 de la Figura 1 se queda con menos recursos. Para hacer que haya más recursos disponibles, la consola de administración mueve la instancia de Windows al hipervisor en el Servidor2.

La consola de administración proporciona la recuperación ante las fallas de hardware. Si falla un componente del servidor, la consola de administración mueve la VM a otro servidor automáticamente y sin inconvenientes. Algunas consolas de administración también permiten la sobreasignación. La sobreasignación se produce cuando se instalan varias instancias de SO, pero su asignación de memoria excede la cantidad total de memoria que tiene un servidor. Por

Ing. José Dennis Estela Zumaeta ejemplo, un servidor tiene 16 GB de RAM, pero el administrador crea cuatro instancias de SO con 10 GB de RAM asignadas a cada una. Este tipo de asignación excesiva es habitual porque las cuatro instancias de SO requieren raramente los 10 GB completo de RAM en todo momento.

14.14. VIRTUALIZACION DE LA RED La virtualización del servidor oculta los recursos del servidor (por ejemplo, la cantidad y la identidad de los servidores físicos, de los procesadores y del SO) de los usuarios del servidor. Esta práctica puede crear problemas si el centro de datos está utilizando las arquitecturas de red tradicionales. Por ejemplo, las LAN virtuales (VLAN) utilizadas por las VM se deben asignar al mismo puerto de switch que el servidor físico que ejecuta el hipervisor. Sin embargo, las VM son trasladables, y el administrador de la red debe poder agregar, descartar y cambiar los recursos y los de la red. Este proceso es difícil de hacer con los switches de red tradicionales. Otro problema es que los flujos de tráfico difieren considerablemente del modelo cliente-servidor tradicional. Generalmente, un centro de datos tiene una cantidad considerable de tráfico que se intercambia entre los servidores virtuales (denominado "tráfico entre nodos"). Estos flujos cambian en la ubicación y la intensidad en el tiempo, lo que requiere un enfoque flexible a la administración de recursos de red. Las infraestructuras de red existentes pueden responder a los requisitos cambiantes relacionados con la administración de los flujos de tráfico utilizando las configuraciones de calidad de servicio (QoS) y de ajustes de nivel de seguridad para los flujos individuales. Sin embargo, en empresas grandes que utilizan equipos de varios proveedores, cada vez que se activa una nueva VM, la reconfiguración necesaria puede llevar mucho tiempo. ¿Podría la infraestructura de red también beneficiarse de la virtualización? Si esto es así, ¿de qué manera podría hacerlo? La respuesta se encuentra en la manera en la que un dispositivo de red funciona mediante un plano de datos y un plano de control.

14.15. PLANOS DE CONTROL Y PLANOS DE DATOS Un dispositivo de red contiene los siguientes planos: 



Plano de control: Generalmente, esto se considera como el cerebro de un dispositivo. Se utiliza para tomar decisiones de reenvío. El plano de control contiene los mecanismos de reenvío de ruta de capa 2 y capa 3, como las tablas de vecinos de protocolo de routing y las tablas de topología, las tablas de routing IPv4 e IPv6, STP, y la tabla ARP. La información que se envía al plano de control es procesada por la CPU. Plano de datos: Este plano, también denominado "plano de reenvío", generalmente es la estructura de switch que conecta los diversos puertos de red en un dispositivo.El plano de datos de cada dispositivo se utiliza para reenviar los flujos de tráfico. Los routers y los switches utilizan la información del plano de control para reenviar el tráfico entrante desde la interfaz de egreso correspondiente. Por lo general, la información del plano de datos es procesada por un procesador especial del plano de datos, como un procesador de señal digital (DSP) sin que se involucre a la CPU.

Ing. José Dennis Estela Zumaeta El ejemplo de la Figura 1 muestra cómo Cisco Express Forwarding (CEF) utiliza el plano de control y el plano de datos para procesar los paquetes:

CEF es una tecnología de switching de IP de capa 3 que permite que el reenvío de los paquetes ocurra en el plano de datos sin que se consulte el plano de control. En CEF, la tabla de routing del plano de control rellena previamente la tabla de base de información de reenvío (FIB) de CEF en el plano de datos. La tabla ARP del plano de control rellena previamente la tabla de adyacencia. Luego, los paquetes son reenviados directamente por el plano de datos basado en la información incluida en la FIB y en la tabla de adyacencia, sin necesidad de consultar la información en el plano de control. Para virtualizar la red, un controlador centralizado realiza y elimina la función del plano de control de cada dispositivo, como se muestra en la Figura 2. El controlador centralizado comunica las funciones del plano de control a cada dispositivo. Cada dispositivo ahora puede enfocarse en el envío de datos mientras el controlador centralizado administra el flujo de datos, mejora la seguridad y proporciona otros servicios.

Ing. José Dennis Estela Zumaeta 14.16. VIRTUALIZACION DE LA RED Hace más de una década, VMware desarrolló una tecnología de virtualización que permitía a un SO host admitir uno o más SO clientes. La mayoría de las tecnologías de virtualización ahora se basan en esta tecnología. La transformación de los servidores exclusivos para los servidores virtualizados se ha adoptado y se implementa rápidamente en el centro de datos y las redes empresariales. Se han desarrollado dos arquitecturas de red principales para admitir la virtualización de la red: 

Redes definidas por software (SDN): una arquitectura de red definida por software que virtualiza la red.



Infraestructura centrada en aplicaciones (ACI) de Cisco: Una solución de hardware diseñada específicamente para la integración de computación en la nube y administración de centros de datos.

Estas son otras tecnologías de virtualización de redes, incluyen algunas de las cuales se incluyen como componentes en SDN y ACI: 





OpenFlow: Este enfoque se desarrolló de Universidad Stanford para administrar el tráfico entre los routers, los switches, los puntos de acceso inalámbrico y un controlador. El protocolo OpenFlow es un elemento básico en el desarrollo de soluciones de SDN. OpenStack : Este enfoque es una plataforma de virtualización y organización disponible para desarrollar entornos de nube escalables y proporcionar una infraestructura como una solución (IaaS) de servicio. OpenStack se usa frecuentemente en conjunto con Cisco ACI. La organización en la red es el proceso para automatizar el aprovisionamiento de los componentes de red como servidores, almacenamiento, switches, routers y aplicaciones. Otros componentes: otros componentes incluyen la interfaz a Routing System (I2RS), la interconexión transparente de varios enlaces (TRILL), Cisco FabricPath (FP) e IEEE 802.1aq Shortest Path Bridging (SPB).

14.17. ARQUIECTURA SDN En un router o una arquitectura de switches tradicionales, el plano de control y las funciones del plano de datos se producen en el mismo dispositivo. Las decisiones de routing y el envío de paquetes son responsabilidad del sistema operativo del dispositivo. Las redes definidas por software (SDN) son una arquitectura de red que se desarrolló para virtualizar la red. Por ejemplo, las SDN pueden virtualizar el plano de control. También conocidas como SDN basadas en controladores, las SDN mueven el plano de control desde cada dispositivo de red a una inteligencia de la red central y una entidad de las políticas fabricación denominada controlador de SDN. Las dos arquitecturas se muestran en la Figura 1.


El controlador de SDN es una entidad lógica que permite que los administradores de red administren y determinen cómo el plano de datos de switches físicos y virtuales de los routers debe administrar el tráfico de red. Coordina, media y facilita la comunicación entre las aplicaciones y los elementos de red. El marco de SDN se ilustra en la Figura 2. Observe el uso de interfaces de programación de aplicaciones (API) dentro del marco de SDN. Una API es un conjunto de solicitudes estandarizadas que definen la forma adecuada para que una aplicación solicite servicios de otra aplicación. El controlador de SDN usa los API ascendentes para comunicarse con las aplicaciones ascendentes. Estos administradores de red de ayuda de API forman el tráfico e implementan los servicios. El controlador de SDN también utiliza interfaces API descendentes para definir el comportamiento de los switches y routers virtuales descendentes. OpenFlow es la API original descendente ampliamente implementada. Open Networking Foundation es responsable de mantener el estándar de OpenFlow.

Nota: El tráfico en un centro de datos moderno se describe como (en sentido) vertical (que se produce entre los usuarios del centro de datos externos y los servidores del centro de datos) y (en sentido) transversal (que se produce entre los servidores del centro de datos).


Para obtener más información sobre SDN, OpenFlow y Open Networking Foundation, visite: https://www.opennetworking.org/sdn-resources/sdn-definition (Enlaces a un sitio externo.)

14.18. CONTROLADOR SDN Y OPERACIONES El controlador de SDN define los flujos de datos que ocurren en el flujo de datos de las SDN. Un flujo es una secuencia de paquetes que atraviesan una red que comparten un conjunto de valores de campo del encabezado. Por ejemplo, un flujo puede consistir en todos los paquetes con las mismas direcciones IP de origen y de destino, o todos los paquetes con el mismo identificador de VLAN. Cada flujo que atraviesa la red debe obtener primero un permiso del controlador de SDN, que verifica que la comunicación sea permisible según la política de red. Si el controlador permite un flujo, calcula una ruta para que tome el flujo y agrega una entrada para ese flujo en cada uno de los switches que están a lo largo de la ruta. El controlador realiza todas las funciones complejas. El controlador completa las tablas de flujo, y los switches administran las tablas de flujo. En la Figura 1, un controlador de SDN se comunica con los switches compatibles con OpenFlow utilizando el protocolo OpenFlow. Este protocolo utiliza Transport Layer Security (TLS) para enviar de manera segura las comunicaciones del plano de control a través de la red. Cada switch de OpenFlow se conecta con otros switches de OpenFlow. También pueden conectarse a los dispositivos de usuarios finales que forman parte de un flujo de paquetes.


Dentro de cada switch, se utiliza una serie de tablas implementadas en el hardware o el firmware para administrar flujos de paquetes a través del switch. Para el switch, un flujo es una secuencia de paquetes que coincide con una entrada específica en una tabla de flujo. Las tablas sirven para lo siguiente: 



Tabla de flujo: Esta tabla asigna los paquetes entrantes a un flujo determinado y especifica las funciones que deben realizarse en los paquetes. Puede haber tablas de flujo múltiples que funcionan a modo de canalización. Tabla de medidor: Esta tabla activa una variedad de acciones relacionadas con el funcionamiento en un flujo.

Una tabla de flujo puede dirigir un flujo a una tabla de grupos, que puede alimentar una variedad de acciones que afecten a uno o más flujos.

14.19. INFRAESTRUCTURA CENTRADA EN APLICACIONES CISCO Muy pocas organizaciones tienen realmente el deseo o las habilidades para programar la red utilizando las herramientas de SDN. Sin embargo, la mayoría de las organizaciones desea automatizar la red, acelerar la implementación de aplicaciones y alinear sus infraestructuras de TI para cumplir mejor con los requisitos empresariales. Cisco desarrolló la Infraestructura centrada en aplicaciones (ACI) para alcanzar los siguientes objetivos de maneras más avanzadas y más innovadoras que antes los enfoques de SDN. ACI es una arquitectura de red de centro de datos desarrollada por Insieme y adquirida por Cisco en 2013. Cisco ACI es una solución de hardware diseñada específicamente para la integración de la computación en la nube y de la administración de centros de

Ing. José Dennis Estela Zumaeta datos. En un nivel alto, el elemento de políticas de la red se elimina del plano de datos. Esto simplifica el modo en que se crean redes del centro de datos. Para obtener más información sobre las diferencias entre SDN y ACI, visite: http://blogs.cisco.com/datacenter/is-aci-really-sdn-one-point-of-view-to-clarify-theconversation (Enlaces a un sitio externo.) Para obtener más información sobre los aspectos básicos de ACI, vea el siguiente video de Cisco TechWise:http://video.cisco.com/detail/videos/techwisetv/video/3368644296001/fundam entals-of-aci (Enlaces a un sitio externo.)

14.20. COMPONENTES PRINCIPALES DE ACI Estos son los tres componentes principales de la arquitectura de ACI: 





Perfil de red de aplicaciones (ANP): Un ANP es un conjunto de grupos de terminales (EPG), sus conexiones y las políticas que definen esas conexiones. Los EPG que se muestran en la Figura 1, como VLAN, servicios web y las aplicaciones, son simplemente ejemplos. Un ANP es con frecuencia mucho más complejo. Controlador de infraestructura de políticas de aplicaciones (APIC): El APIC se considera como el cerebro de la arquitectura de ACI. El APIC es un controlador centralizado de software que administra y opera una estructura agrupada ACI escalable. Está diseñado para la programabilidad y la administración centralizada. Traduce las políticas de las aplicaciones a la programación de la red. Switches Cisco Nexus 9000 : estos switches proporcionan una estructura de switching con reconocimiento de aplicaciones y funcionan con una APIC para administrar la infraestructura virtual y de red física.

Como se muestra en la ilustración, el APIC se ubica entre el APN y la infraestructura de red habilitada con ACI. El APIC traduce los requisitos de aplicaciones a una configuración de red para cumplir con esas necesidades.

Ing. José Dennis Estela Zumaeta 14.21. TOPOLOGIA DE NODO PRINCIPAL Y NODO SECUNDARIO La estructura Cisco ACI está compuesta por el APIC y los switches Cisco Nexus de la serie 9000 mediante una topología de dos niveles de nodo principal y secundario, como se muestra en la Figura 1. Los switches de nodo secundario siempre se adjuntan a los nodos principales, pero nunca se adjuntan entre sí. De manera similar, los switches principales solo se adjuntan a la hoja y a los switches de núcleo (no se muestran). En esta topología de dos niveles, todo está a un salto de todo lo demás.

Los APIC de Cisco y todos los demás dispositivos de la red se adjuntan físicamente a los switches de nodo secundario. En comparación con una SDN, el controlador de APIC no manipula la ruta de datos directamente. En cambio, el APIC centraliza la definición de políticas y programas a los que cambia el nodo secundario para reenviar tráfico según las políticas definidas. Para la virtualización, la ACI es compatible con entornos de varios proveedores de hipervisor que se conectarían a los switches secundarios, incluidos los siguientes:   

Microsoft (Hyper-V/SCVMM/Azure Pack). Red Hat Enterprise Linux OS (KVM OVS/OpenStack). VMware (ESX/vCenter/vShield).

14.22. TIPOS DE SDN El controlador de infraestructura de política de aplicación (módulo para empresas [APIC-EM]) de Cisco extiende la ACI destinada a la aplicación en empresas y campus. Para comprender mejor el APIC-EM, es útil dar una mirada más amplia a los tres tipos de SDN.

Ing. José Dennis Estela Zumaeta SDN BASADO EN DISPOSITIVOS En este tipo de SDN, los dispositivos son programables por las aplicaciones que se ejecutan en el mismo dispositivo o en un servidor en la red, como se muestra en la Figura 1. Cisco OnePK es un ejemplo de un SDN basado en dispositivos. Permite que los programadores creen aplicaciones utilizando C y a Java con Python para integrar e interactuar con los dispositivos Cisco.

SDN BASADO EN CONTROLADORES Este tipo de SDN utiliza un controlador centralizado que tiene conocimiento de todos los dispositivos de la red, como se muestra en la Figura 2. Las aplicaciones pueden interactuar con el controlador responsable de administrar los dispositivos y de manipular los flujos de tráfico en la red. El controlador SDN Cisco Open es una distribución comercial de Open Daylight.

SDN BASADO EN POLITICAS Este tipo de SDN es similar a un SDN basado en controladores donde un controlador centralizado tiene una vista de todos los dispositivos de la red, como se muestra en la Figura 3. El SDN basado en políticas incluye una capa de políticas adicional que funciona a un nivel de abstracción mayor. Utiliza las aplicaciones integradas que automatizan tareas de configuración avanzada mediante un flujo de trabajo guiado y

Ing. José Dennis Estela Zumaeta una GUI fácil de usar que no requiere habilidades de programación. Cisco APIC-EM es un ejemplo de este tipo de SDN.

14.23. FUNCIONES APIC-EM Cada tipo de SDN tiene sus propias funciones y ventajas. Las SDN basadas en políticas son las más resistentes, lo que proporciona un mecanismo simple para controlar y administrar políticas en toda la red. Cisco APIC-EM proporciona las siguientes funciones: 







 

Descubrimiento : Admite una funcionalidad de detección que se utiliza para completar la base de datos de inventario de dispositivos y de host de controlador. Inventario de dispositivos: de dispositivos que recopila información detallada de los dispositivos dentro de la red incluidos el nombre del dispositivo, el estado del dispositivo, la dirección MAC, las direcciones IPv4/IPv6, el IOS/firmware, la plataforma, el tiempo de actividad y la configuración. Inventario de host: Recopila información detallada de los hosts con la red, que incluye el nombre del host, la identificación del usuario, la dirección MAC, las direcciones IPv4/IPv6 y el punto de conexión de red. Topología: Admite una visión gráfica de la red (vista de topología). Cisco APIC-EM detecta automáticamente y asigna dispositivos a una topología física con datos detallados de nivel del dispositivo. Además, la visualización automática de las topologías de capa 2 y 3 sobre la topología física proporciona una vista detallada para la planificación de diseño y la solución de problemas simplificada. La Figura 1 muestra un ejemplo de una vista de topología generada por Cisco APIC-EM. Política: Capacidad de ver y políticas de control en toda la red, incluido el QoS. Análisis de política: Inspección y análisis de las políticas de control de acceso a la red. Capacidad de rastrear las rutas específicas de la aplicación entre los terminales para identificar rápidamente las ACL en uso y las áreas problemáticas. Habilita la administración de cambios de permisos mediante ACL con una identificación más sencilla de la redundancia, los conflictos y el ordenamiento incorrecto de las entradas de control de acceso. Las entradas de ACL incorrectas se conocen como sombras.


14.24. ANALISIS DE ACL DE APIC-EM Una de las funciones más importantes del controlador APIC-EM es la capacidad de administrar políticas en toda la red. Las políticas operan en un nivel de abstracción más alto. La configuración de dispositivos tradicional se aplica de a un dispositivo por la vez, mientras que las políticas de SDN se aplican a toda la red. El análisis y el seguimiento de ruta de APIC-EM ACL proporcionan herramientas para permitir que el administrador analice y comprenda las políticas y las configuraciones de las ACL. Crear nuevas ACL o editar las ACL existentes a través de la red para implementar una nueva política de seguridad puede ser desafiante. Los administradores son reticentes a cambiar las ACL por miedo a romperlos y a causar nuevos problemas. El análisis y el seguimiento de ruta de las ACL permiten que el administrador visualice fácilmente flujos de tráfico y descubra las entradas de ACL conflictivas, conflictivas, duplicadas o sombreadas. sombreadas. APIC-EM proporciona las siguientes herramientas para solucionar problemas en las entradas de las ACL:

ANALISIS DE ACL Esta herramienta examina las ACL en los dispositivos y busca entradas redundantes, en conflicto o entradas sombreadas. El análisis de las ACL permite el examen y la interrogación de las ACL en toda la red y expone los inconvenientes y los conflictos. En la Figura 1, se muestra una pantalla de ejemplo de esta herramienta.


SEGUIMIENTO DE RUTA ACL Esta herramienta examina las ACL específicas en la ruta entre dos nodos finales y muestra todos los problemas potenciales. En la Figura 2, se muestra una pantalla de ejemplo de esta herramienta.

14.25. IDENTIFICAR TIPO DE SDN


15.IP SLA Los acuerdos de nivel de servicio (SLA) de IP son una función de IOS de Cisco que permite el análisis de los niveles de servicio de IP. Los IP SLA generaron el tráfico para medir el rendimiento de la red entre dos dispositivos de red, ubicaciones de red múltiples, o en varias rutas de red. Los ingenieros de redes utilizan IP SLA para simular los datos de red y los servicios IP para recopilar información de rendimiento de la red en tiempo real. La supervisión del rendimiento puede realizarse en cualquier momento, en cualquier lugar, sin implementar una sonda física.

Nota: Ping y traceroute son herramientas de sondeo. Una sonda física es diferente. Es un dispositivo que puede insertarse en algún lugar en la red para recopilar y monitorear el tráfico. El uso de sondas físicas excede excede el alcance de este curso. Las mediciones proporcionadas por varias operaciones de IP SLA se pueden utilizar para resolver problemas de funcionamiento de red con las mediciones uniformes, confiables que identifican problemas inmediatamente y ahorran tiempo de solución de problemas. Los beneficios adicionales para utilizar los IP SLA se indican a continuación:  





Supervisión, medición y verificación del acuerdo de nivel de servicio. Monitoreo de rendimiento de la red:  Mide las fluctuaciones, la latencia, o la pérdida de paquetes en la red.  Proporciona las mediciones continuas, confiables y predecibles. Evaluación del estado de la red de servicio IP para verificar que la QoS existente es suficiente para nuevos servicios IP. Supervisión de contorno contra contorno de disponibilidad de red para la verificación de la conectividad dinámica de los recursos de red.

Las operaciones de IP SLA múltiples se pueden ejecutar en la red o en un dispositivo en cualquier momento. Los IP SLA se pueden lograr mediante la interfaz de línea de comandos (CLI) o a través del protocolo simple de administración de redes (SNMP).

Nota: Las notificaciones de SNMP según datos reunidos por una operación de IP SLA están más allá del alcance de este curso.

Ing. José Dennis Estela Zumaeta 15.1. CONFIGURACION DE IP SLA UTILIZACIÓN DE IP SLA PARA SOLUCIÓN DE PROBLEMAS En lugar de utilizar el ping manualmente, un ingeniero de redes puede utilizar la operación de eco ICMP de IP SLA para probar la disponibilidad de los dispositivos de red. Un dispositivo de red puede ser cualquier dispositivo con las funcionalidades de IP (router, switch, PC, servidor, etc.). La operación de eco ICMP de IP SLA proporciona las siguientes mediciones:   

Supervisión de disponibilidad (estadísticas de pérdida de paquetes). Supervisión de rendimiento (latencia y tiempo de respuesta). Operación de red (conectividad completa).

COMPROBACIÓN DE LA DISPONIBILIDAD DE LA OPERACIÓN DE ECO ICMP DE IP SLA Utilice el comando show ip sla application en el modo EXEC con privilegios para comprobar que la operación deseada de IP SLA esté disponible en el dispositivo de origen. La opción de eco ICMP de IP SLA aparece como disponible en el Ejemplo 1.

PASOS Y COMANDOS UTILIZADOS PARA CONFIGURAR LA OPERACIÓN ECO ICMP DE IP SLA En la Tabla 1 se enumeran los pasos, la sintaxis de comandos y las descripciones de los comandos necesarios para configurar la operación de eco ICMP de IP SLA en un dispositivo Cisco.


Para deshabilitar la operación de IP SLA, introduzca el comando no ip sla o p e r a t i o n - n u m b e r en el modo de configuración global.

CONFIGURACIÓN DE LA MUESTRA DE ECO ICMP DE IP SLA En la Figura 1 se muestra la topología de muestra que se utilizará en nuestro ejemplo de configuración.


El ejemplo 1 muestra la configuración de eco ICMP de IP SLA en R1.

El comando ip sla crea una operación IP SLA con un número de operación igual a 1. Se pueden configurar varias operaciones IP SLA en un dispositivo y se puede consultar cada operación mediante el número de operación correspondiente. El comando icmp-echo identifica la dirección de destino que se supervisará. En el ejemplo, se establece para supervisar la interfaz S1 del R3. El comando frequency marca la velocidad de IP SLA a intervalos de 30 segundos. El comando ip sla schedule está planificando que el número de operación 1 de IP SLA comience inmediatamente (now) y continúe hasta que se cancele manualmente (forever).

Nota: Utilice el comando no ip sla schedule (operation-number) para cancelar la operación de SLA. La configuración de la operación de SLA se preserva y se puede reprogramar cuando sea necesario.

VERIFICACIÓN DE LA CONFIGURACIÓN DE IP SLA Utilice el comando show ip sla configuration [operation-number] para mostrar los valores de configuración, incluidos todos los valores predeterminados para las operaciones IP SLA o para una operación específica. El ejemplo 3 consiste en utilizar el comando show ip sla configuration para mostrar la configuración de eco ICMP de IP de SLA realizada en el ejemplo anterior.


Revise el resultado del comando show ip sla configuration para verificar los ajustes de configuración

VISUALIZACION DE ESTADISTICAS DE LA OPERACIÓN DE IP SLA Utilice el comando show ip sla statistics [operation-number] para visualizar las estadísticas de supervisión de la operación de IP SLA, como se muestra en el ejemplo. 4.

Ccna Nuevo v6

Recommend Documents