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

Descripcin general de puente ITN
Al finalizar este mdulo, estar en 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 informacin sobre los
dispositivos en una red.
Describir las metodologas de solucin de problemas de la red comn.
Solucionar problemas con el cable y los problemas de interfaz.
Solucionar problemas de los dispositivos de la red.
Comando traceroute extendido

Diseado como variante del comando traceroute, el comando traceroute extendido permite que
el administrador ajuste los parmetros 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 dnde los paquetes son descartados por un router o denegados por un
firewall. 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 poda 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 interrumpe el seguimiento con la secuencia de escape.
Nota: En IOS, puede invocar esta secuencia de escape presionando Ctrl+Mays+6. En

Windows, la secuencia de escape se invoca presionando Ctrl+C.
Para utilizar traceroute extendido, simplemente escriba traceroute, sin proporcionar ningn
parmetro, y presione ENTER. IOS lo guiar en las opciones de comando presentando varios
indicadores relacionados con la configuracin de todos los parmetros diferentes. En la Tabla
1 se muestran 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 parmetros, no es guiado

y se debe ejecutar a travs de opciones en la lnea de comandos. El ejemplo 1 muestra las
opciones disponibles para tracert de Windows.

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 informacin 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 anlisis. 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 funcin o la subfuncin relevante. Esto
es importante porque se le asigna alta prioridad al resultado de depuracin en el proceso de CPU
y puede hacer que el sistema no se pueda utilizar. Por este motivo, use los comandos debug solo
para solucionar problemas especficos. 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:

Para ver una lista con una breve descripcin de todas las opciones del comando de depuracin,
utilice el comando debug? en modo EXEC privilegiado en la lnea de comando.
Para desactivar una caracterstica de depuracin especfica, 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 depuracin como debug all y debug ip packet generan una importante
cantidad de resultados y usan una gran porcin de recursos del sistema. El router estara tan
ocupado mostrando mensajes de depuracin que no tendra suficiente potencia de
procesamiento para realizar las funciones de red, o incluso escuchar los comandos para
desactivar la depuracin. 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 lnea de comandos de IOS se pueden
establecer de forma local o remota.
Las conexiones locales requieren acceso fsico al router o switch, por lo tanto, se requiere una
conexin de cable. Esta conexin se establece generalmente mediante la conexin de una PC
al puerto de consola del router o del switch mediante un cable de sustitucin. En este curso, nos
referimos a una conexin local como conexin 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 fsico directo para las sesiones remotas. SSH y Telnet son dos
protocolos de conexin comunes utilizados para las sesiones remotas. En este curso, usamos el
protocolo cuando hablamos de una conexin remota especfica, como una conexin Telnet o una
conexin SSH.
Aunque los mensajes de registro de IOS se envan a la consola de manera predeterminada,
estos mismos mensajes de registro no se envan a las lneas virtuales de manera
predeterminada. Debido a que los mensajes de depuracin son mensajes de registro, este
comportamiento evita que los mensajes se muestren en las lneas 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.
ENFOQUES PARA LA SOLUCIN DE PROBLEMAS BSICOS

Los problemas de red pueden ser simples o complejos, y pueden ser el resultado de una
combinacin de problemas de hardware, software y conectividad. Los tcnicos informticos
deben ser capaces de analizar el problema y determinar la causa del error para poder reparar el
problema de red. Este proceso se denomina solucin de problemas.
Una metodologa de solucin de problemas comn y eficaz se basa en el mtodo cientfico y se
puede dividir en los seis pasos importantes de la Tabla 1.
Tabla 1: Seis pasos de la metodologa de solucin de problemas

Para evaluar el problema, determine cuntos dispositivos de la red lo tienen. Si existe un
problema con un dispositivo de la red, inicie el proceso de solucin de problemas en ese
dispositivo. Si existe un problema con todos los dispositivos de la red, inicie el proceso de
solucin de problemas en el dispositivo donde se conectan todos los otros dispositivos. Debe
desarrollar un mtodo lgico y coherente para diagnosticar problemas de red mediante la
eliminacin de un problema por vez.
SOLUCIONAR O ESCALAR?
En algunas situaciones, quizs no sea posible solucionar el problema de inmediato. Un problema
debera escalarse cuando requiere la decisin del gerente, cierta experiencia especfica, o el
nivel de acceso a la red no est disponible para el tcnico que debe solucionar el problema.
Por ejemplo, despus de solucionar problemas, el tcnico decide que un mdulo de router debe
reemplazarse. Este problema se debe escalar para obtener la aprobacin del gerente. Es
probable que el gerente tenga que escalar el problema nuevamente ya que podra necesitar la
aprobacin del departamento de finanzas antes de comprar un nuevo mdulo.
La poltica de la empresa debe indicar claramente cundo y cmo un tcnico debe escalar un
problema.
VERIFICACION Y SUPERVISION DE LA SOLUCIN
Cisco IOS incluye herramientas eficaces para la solucin de problemas y la verificacin. Cuando
se ha solucionado el problema y se ha implementado la solucin, es importante verificar el
funcionamiento del
sistema.
Las herramientas de
verificacin
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 topologa que
se muestra en la Figura 1.
Nota: Un ping fallido no suele proporcionar suficiente informacin para llegar a una conclusin.
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 investigacin 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 dnde el paquete fue interrumpido a lo largo de la ruta.
Los comandos show de Cisco IOS son algunas de las herramientas ms tiles para resolver
problemas. Al aprovechar una gran variedad de opciones y de subopciones, el
comando show puede utilizarse para reducir y mostrar informacin sobre prcticamente
cualquier aspecto especfico del IOS.
El Ejemplo 3 muestra el resultado del comando show ip interface brief. Observe que las dos
interfaces configuradas con las direcciones IPv4 estn en up y up. Estas interfaces pueden
enviar y recibir trfico. Las otras tres interfaces no tienen ningn direccionamiento IPv4 y estn
desactivadas.
PROCESOS DE SOLUCIN DE PROBLEMAS

OPERACIN EN DUPLEX
Cuando se trata de comunicacin de datos, dplex se refiere a la direccin de la transmisin de
datos entre dos dispositivos. Si las comunicaciones se limitan al intercambio de datos en una
direccin por vez, esta conexin se denomina semidplex. El dplex completo permite el envo
y la recepcin de datos simultneamente.
Para un mejor rendimiento de la comunicacin, dos interfaces de red Ethernet conectadas deben
funcionar en el mismo modo dplex para evitar la ineficiencia y la latencia en el enlace.
La negociacin automtica de Ethernet se dise para facilitar la configuracin, 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 automtica y
correcta el modo dplex completo.
Surge una discordancia si uno de los dos dispositivos conectados funciona en modo dplex
completo y el otro funciona en modo semidplex. Si bien la comunicacin de datos se realizar
a travs de un enlace con una discordancia de dplex, el rendimiento del enlace ser muy
deficiente. La discordancia de dplex puede deberse a la configuracin manual incorrecta, que
configura manualmente los dos dispositivos conectados a diferentes modos dplex. La
discordancia de dplex tambin puede producirse cuando se conecta un dispositivo que realiza
la negociacin automtica con otro que est configurado manualmente en dplex completo. Si
bien no es comn, la discordancia de dplex tambin puede ocurrir debido a la falla de la
negociacin automtica.
DISCORDANCIA DE DUPLEX
Las discordancias de dplex pueden ser difciles de resolver mientras se produce la
comunicacin entre dispositivos. Es posible que no sean evidentes, incluso si se usan
herramientas como ping. Los pequeos paquetes individuales no puedan revelar un problema
de discordancia de dplex. Una sesin de terminal que enva los datos lentamente (en rfagas
muy cortas) tambin podra comunicar con xito a travs de una discordancia de dplex. Aun
cuando cualquier extremo de la conexin intente enviar una cantidad significativa de datos y el
rendimiento del enlace caiga considerablemente, la causa puede no ser fcilmente evidente
debido a que la red est operativa de otra manera.
El CDP, el protocolo de propiedad de Cisco, puede detectar fcilmente una discordancia de
dplex entre dos dispositivos Cisco. Vea la topologa en la Figura 1 donde la interfaz G0/0 del
R1 se ha configurado en forma errnea para funcionar en modo semidplex.
El CDP muestra los mensajes de registro del enlace con la discordancia de dplex. Los mensajes
tambin contienen los nombres de los dispositivos y los puertos involucrados en la discordancia
de dplex, lo cual facilita mucho identificar y solucionar el problema. El ejemplo 1 muestra
mensajes de registro de la discordancia de dplex de CDP.
Nota: Debido a que estos son mensajes de registro, se muestran nicamente en una sesin de
consola de manera predeterminada. Usted vera solamente estos mensajes en una conexin
remota si se habilita el comando terminal monitor.
El ejemplo 2 muestra la configuracin dplex que caus el problema.

PROBLEMAS DE ASIGNACIN DE DIRECCIONES IP EN DISPOSITIVOS IOS
Los problemas relacionados con la direccin IP probablemente evitarn la comunicacin de los
dispositivos de redes remotas. Debido a que las direcciones IP son jerrquicas, cualquier
direccin 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 asignacin incorrecta de IPv4 son los errores manuales de asignacin
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 asignacin, es muy
probable que ocurran problemas de comunicacin 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 topologa 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 informacin de IPv4 (capa 3 del OSI),
mientras que el comando anteriormente mencionado show interfaces muestra los detalles
fsicos y del enlace de datos de una interfaz.
PROBLEMAS DE ASIGNACIN DE DIRECCIONES IP EN TERMINALES
En las mquinas con Windows, cuando el dispositivo no puede comunicarse con un servidor
DHCP, Windows asigna automticamente una direccin que pertenezca al rango 169.254.0.0/16.
Este proceso se dise para facilitar la comunicacin dentro de la red local. Piense que Windows
dice: Utilizar esta direccin del rango 169.254.0.0/16 porque no pude obtener ninguna otra
direccin. 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

169.254.0.0/16. Esta situacin indica un problema de asignacin automtica de direcciones IPv4
que debe solucionarse.
Nota: Otros sistemas operativos, como Linux y OS X, no asignarn una direccin IPv4 a la
interfaz de red si falla la comunicacin con un servidor DHCP.
La mayora de los terminales se configuran para confiar en un servidor DHCP para la asignacin
automtica de direcciones IPv4. Si el dispositivo no puede comunicarse con el servidor DHCP,
el servidor no puede asignar una direccin IPv4 para la red especfica 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 ms cercano que puede
reenviar trfico a otras redes. Si un dispositivo tiene una direccin 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 direccin debe pertenecer a la
misma red que el terminal.
La direccin del gateway predeterminado se puede configurar u obtener manualmente de un
servidor DHCP. Como sucede con los problemas de asignacin de direcciones IPv4, los
problemas del gateway predeterminado pueden estar relacionados con la configuracin
incorrecta (en el caso de la asignacin manual) o problemas de DHCP (si est en uso la
asignacin automtica).
Para resolver los problemas de un gateway predeterminado mal configurado, asegrese de que
el dispositivo tenga configurado el gateway predeterminado correcto. Si la direccin
predeterminada fue configurada manualmente pero es incorrecta, simplemente reemplcela por
la direccin apropiada. Si la direccin de gateway predeterminado fue configurada
automticamente, asegrese de que el dispositivo pueda comunicarse correctamente con el
servidor DHCP. Tambin es importante verificar que se configuraron la direccin IPv4 y la
mscara 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 direccin 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.

SOLUCIN 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 direccin IP. Aunque la resolucin de DNS no es
fundamental para la comunicacin del dispositivo, es muy importante para el usuario final.
Es comn que los usuarios relacionen errneamente 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 estn
todava operativos, los errores de DNS generalmente llevan al usuario a la conclusin 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 direccin IP y la pgina web
no se mostrar.
Las direcciones del servidor DNS pueden asignarse de manera manual o automtica. 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
automticamente las direcciones del servidor DNS a los clientes.
Si bien es comn que las empresas y las organizaciones administren sus propios servidores
DNS, cualquier servidor DNS accesible puede utilizarse para solucionar nombres. Los usuarios
de oficinas pequeas y oficinas en el hogar con frecuencia dependen del servidor DNS que
mantiene su ISP para la resolucin 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 pblico que puede ser utilizado por cualquier persona y es muy til para realizar pruebas.
La direccin IPv4 del servidor DNS pblico de Google es 8.8.8.8 y 2001:4860:4860::8888 para
su direccin 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.

El comando nslookup es otra herramienta til para la solucin 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.

PRINCIPIOS BASICOS DE ROUTING AND SWITCHING - CCNA 2
PUENTE RSE: Descripcin general
Configurar rutas estticas IPv4 especificando una direccin del siguiente salto.
Utilizar los protocolos de deteccin para asignar una topologa de red.
Configurar el servidor NTP entre un cliente NTP y un servidor NTP.
Mantener la configuracin 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 direccin IP de destino es un dispositivo especfico con
una mscara 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 automticamente cuando se configura una direccin IP en el Router.

Configurarla como una ruta de host esttico.
Obtener la ruta de host automticamente a travs de otros mtodos (se analiza en
cursos posteriores.
El IOS de Cisco instala automticamente una ruta de host, tambin conocida como ruta de
host local, cuando se configura una direccin de interfaz en el router. Una ruta host permite
un proceso ms eficiente para los paquetes que se dirigen al router mismo, en lugar del envo
de paquetes. Esto se suma a la ruta conectada, designada con una C en la tabla de routing
para la direccin de red de la interfaz.
El anlisis de las rutas de host utiliza la topologa que se muestra en la Figura. 1.
Cuando una interfaz activa en un router se configura con una direccin IP, se agrega
automticamente 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 versin 15 de
IOS.
2. RUTAS DE HOST CONFIGURADAS MANUALMENTE

Una ruta de host puede ser una ruta esttica configurada manualmente para dirigir el trfico
a un dispositivo de destino especfico, como un servidor de autenticacin. La ruta esttica
utiliza una direccin IP de destino y una mscara 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 estticas se
marcan con una S en el resultado de la tabla de routing. En la topologa 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.

Para rutas estticas IPv6, la direccin del siguiente salto puede ser la direccin link-local del
router adyacente. Sin embargo, debe especificar un tipo de interfaz y un nmero de interfaz
cuando usa una direccin 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 informacin 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 enva mensajes peridicos del CDP a los dispositivos conectados. Estos
mensajes comparten informacin 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 mayora de los dispositivos de red se conectan a otros dispositivos, el CDP
puede ayudar a tomar decisiones de diseo, solucionar problemas, y realizar cambios en el
equipo. El CDP se puede utilizar como herramienta de anlisis de redes para conocer
informacin sobre los dispositivos vecinos. Esta informacin recopilada del CDP puede
ayudar a crear una topologa lgica de una red cuando falta documentacin o detalles.

3.1. CONFIGURACIN Y VERIFICACIN 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
informacin valiosa sobre el diseo de la red, como direcciones IP, versiones de IOS, y
tipos de dispositivos.
Para verificar el estado del CDP y mostrar informacin 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 configuracin global. El CDP se puede deshabilitar en
todas las interfaces del dispositivo con el comando no cdp run en el modo de
configuracin global.
Para deshabilitar el CDP en una interfaz especfica, como la interfaz orientada a un ISP,
ingrese no cdp enable en el modo de configuracin de interfaz. El CDP an se encuentra
habilitado en el dispositivo; sin embargo, no se enviarn ms mensajes a la interfaz. Para
habilitar el CDP en una interfaz especfica 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
informacin importante acerca de los vecinos del CDP. Actualmente, este dispositivo no
tiene vecinos porque no est fsicamente conectado a ningn 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 estn habilitadas
en CDP en el dispositivo. Tambin se muestra el estado de cada interfaz. El Ejemplo 5
muestra que cinco interfaces estn habilitadas en el CDP en el router solamente con una
conexin activa a otro dispositivo.
3.2. DETECCIN DE DISPOSITIVOS CON CDP

Con el CDP habilitado en la red, el comando show cdp neighbors se puede utilizar para
determinar el diseo de la red.
Por ejemplo, considere la falta de documentacin en la topologa de la Figura 1. No hay
informacin disponible relacionada con el resto de la red.
El comando show cdp neighbors brinda informacin 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 ms all del mbito de este curso).
Plataforma - La plataforma de hardware del dispositivo (WS-C2960 para el
switch Cisco 2960)
Si se necesita ms informacin, el comando show cdp neighbors tambin puede

ofrecer informacin, como la versin y la direccin IP del IOS de los vecinos, como se
Al tener acceso al S1 de manera remota a travs de SSH o fsicamente a travs 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 despus 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 ms dispositivos a

descubrir en la topologa. El administrador de redes ahora puede actualizar la
documentacin para reflejar los dispositivos detectados, como se muestra en la Figura
2.

CONFIGURAR Y VERIFICAR CDP

3.3.
4. DESCRIPCION GENERAL DE LLDP

Los dispositivos Cisco tambin admiten protocolo de deteccin de capa de enlace (LLDP),
que es un protocolo neutro de deteccin de vecinos de un proveedor similar al CDP. El
LLDP funciona con los dispositivos de red, como routers, switches, y puntos de acceso
inalmbrico LAN. Este protocolo informa su identidad y capacidades a otros dispositivos y
recibe informacin de un dispositivo fsicamente conectado de capa 2.
4.1. CONFIGURACION Y VERIFICACION DE LLDP
En algunos dispositivos, el LLDP podra 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 configuracin global, como se muestra en el Ejemplo
1. Para deshabilitar el LLDP, ingrese el comando no lldp run en el modo de
configuracin global.
Al igual que el CDP, el LLDP se puede configurar en interfaces especficas. 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.

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 documentacin
en la topologa 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 tambin puede significar el switch. A partir de los resultados de show
lldp neighbors, se puede construir una topologa del switch S1 como se ilustra en la
Figura 2.

Cuando se necesitan ms detalles acerca de los vecinos, el comando show llldp
neighbors puede proporcionar informacin, como versin de IOS, direccin 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 administracin, seguridad, solucin de problemas,
y planificacin 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 da y la hora de manera manual.
Configurar protocolo de tiempo de red (NTP).
El Ejemplo 1 muestra cmo configurar manualmente el reloj en un dispositivo Cisco.
A medida que una red crece, se hace difcil garantizar que todos los dispositivos de
infraestructura operen con una hora sincronizada. Incluso en un entorno de red ms
pequeo, el mtodo manual no es lo ideal. Cmo obtener una fecha y una marca de hora
precisas si se reinicia un router?
Una mejor solucin consiste en configurar el NTP en la red. Este protocolo permite que los
Routers de la red sincronicen la configuracin de la hora con un servidor NTP. Si un grupo
de clientes de NTP obtiene informacin de fecha y hora de un nico origen, tiene una
configuracin de tiempo ms 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 pblico en Internet.
El NTP utiliza el puerto UDP 123 y se registra en RFC 1305.

5.1. FUNCIONAMIENTO DEL NTP
Las redes NTP utilizan un sistema jerrquico de fuentes horarias. Cada nivel en este
sistema jerrquico se denomina estrato. El nivel de estrato se define como la cantidad
de saltos desde fuente autorizada. La hora sincronizacin 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 precisin que son presuntamente precisos y con poco o ningn
retraso asociado con los mismos. Los dispositivos del estrato 0 estn representados
por el reloj en la Figura 1.
Estrato 1
Los dispositivos del estrato 1 estn conectados directamente a las fuentes horarias
vlidas. Actan como el estndar horario de la red principal.
Estrato 2 y ms bajos
Los servidores del estrato 2 estn conectados a dispositivos del estrato 1 a travs 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. Podran tambin actuar
como servidores para dispositivos del estrato 3.
Los nmeros ms bajos de estratos indican que el servidor est ms cerca de la fuente
horaria autorizada que los nmeros de estrato ms altos. Cuanto mayor sea el nmero
de estrato, menor es el nivel del estrato. El recuento de saltos mximo 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

un par con otros servidores horarios en el mismo nivel de estratos para la verificacin 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 estn 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 opcin detail, tambin 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 configuracin 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. RECUPRACION DE CONTRASEAS
Las contraseas de los dispositivos se utilizan para evitar el acceso no autorizado. Las
contraseas encriptadas, como las contraseas "enable secret", se deben reemplazar
despus de su recuperacin. De acuerdo con el dispositivo, el procedimiento detallado
para la recuperacin de contraseas vara; sin embargo, todos los procedimientos de
recuperacin de contraseas siguen el mismo principio:
Paso 1. Ingresar en el modo ROMMON.
Paso 2. Cambiar el registro de configuracin a 0x2142 para ignorar el archivo de
configuracin de inicio.
Paso 3. Realizar los cambios necesarios en el archivo original de configuracin de inicio.
Paso 4. Guardar la configuracin nueva.
Para la recuperacin de contraseas, se requiere el acceso a la consola del dispositivo a
travs 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 interrupcin durante el proceso de arranque o eliminando la memoria flash
externa cuando el dispositivo est apagado.
Nota: La secuencia de interrupcin para PuTTY es Ctrl+Break. Puede encontrar una lista
de secuencias estndar 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 bsicos, como confreg. El
comando confreg 0x2142 permite que el usuario configure el registro de configuracin a
0x2142. Con el registro de configuracin en 0x2142, el dispositivo ignorar el archivo de

configuracin de inicio durante el arranque. El archivo de configuracin de inicio es donde
se almacenan las contraseas olvidadas. Despus de configurar el registro de
configuracin en 0x2142, escriba reset en la peticin de entrada para reiniciar el
dispositivo. Introduzca la secuencia de interrupcin 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 despus de usar una secuencia de interrupcin durante el
proceso de arranque.
Despus de que el dispositivo haya finalizado la recarga, copie la configuracin de inicio

(startup-config) a la configuracin en ejecucin (running-config), como se muestra en el
Ejemplo 2.
PRECAUCIN: No introduzca copy running-config startup-config. Este comando borra

la configuracin de inicio original.
Dado que est en el modo EXEC privilegiado, ahora puede configurar todas las
contraseas necesarias. Una vez que se configuran las nuevas contraseas, cambie el
registro de configuracin a 0x2102 mediante el comando config-register 0x2102 en el
modo de configuracin global. Guarde la configuracin en ejecucin (running-config) en la
configuracin de inicio (starup-config) y vuelva a cargar el dispositivo, como se muestra en
el Ejemplo 3.
Nota: La contrasea cisco no es una contrasea segura y se utiliza aqu solo como
ejemplo.
El dispositivo ahora utiliza las contraseas para autenticacin recin configuradas.
Asegrese de utilizar los comandos show para verificar que todas las configuraciones
estn en su lugar. Por ejemplo, verifique que las interfaces adecuadas no estn apagadas
despus de recuperar la contrasea.
El siguiente enlace proporciona instrucciones detalladas para el procedimiento de
recuperacin de contraseas para un dispositivo especfico:
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. RECUPERACIN DE LA CONTRASEA DE UN ROUTER

ESCALAMIENTO DE REDES CCNA 3
PUENTE SCAN: DESCRIPCION GENERAL
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 dinmico (DTP).
Solucionar problemas comunes de configuracin 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 agregacin del chasis en una LAN
pequea conmutada.
Implementar HSRP.
Resolver problemas de entradas de rutas faltantes en las tablas de routing OSPFv2 y
OSPFv3 multirea.
1. DESCRIPCION GENERAL DE VTP

A medida que aumenta el nmero de Switches en una red de empresas pequeas o
medianas, la administracin general requerida para administrar las VLAN y los enlaces
troncales en una red se convierte en un desafo. 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 incluira la configuracin
de switches 12. En redes ms grandes, la administracin 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 informacin 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 configuracin.
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 versin 1 o versin 2
de VTP. La versin 3 del VTP admite VLAN extendidas, pero no entra dentro del mbito de
este curso.

Nota: El VTP guarda configuraciones VLAN en una base de datos llamada vlan.dat.
La Tabla 1 ofrece una breve descripcin de los componentes principales del VTP.
Nota: Las publicaciones del VTP no se intercambiarn 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 nmero de revisin
de configuracin ms alto que el servidor VTP existente actualiza toda la informacin
de la VLAN en el dominio VTP. Los nmeros de revisin de configuracin se analizan
ms adelante en este captulo.
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 nmero de revisin de configuracin.
Solicitud de publicacin: responde a un mensaje de publicacin de resumen
cuando la publicacin de resumen contiene un nmero de revisin de
configuracin ms alto que el valor actual.
Publicaciones de subgrupos: contienen informacin 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 nmero de revisin de la
configuracin.
El nmero de revisin de la configuracin es un nmero de 32 bits que indica el nivel de
revisin para un paquete VTP. Cada dispositivo de VTP rastrea el nmero de revisin
de configuracin del VTP que se le asigna.
Esta informacin se utiliza para determinar si la informacin recibida es ms reciente
que la versin actual. Cada vez que modifica una VLAN en un dispositivo VTP, la
revisin de la configuracin se incrementa en uno.
Nota: Para reiniciar una revisin de configuracin en un switch, cambie el nombre de
dominio VTP, y luego vuelva a cambiarlo al nombre original.
Cuando un switch recibe un paquete de publicacin 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

revisin de configuracin con su propia revisin. Si el nmero de revisin de la
configuracin es mayor o igual al nmero de revisin de configuracin del paquete, se
ignora el paquete. Si el nmero de revisin de la configuracin es ms bajo, se enva
una solicitud de publicacin que solicita para el mensaje de publicacin del subgrupo.
El mensaje de publicacin de subgrupo contiene informacin de la VLAN con cualquier
cambio. Al agregar, eliminar o cambiar una VLAN en el servidor VTP, el servidor del
VTP aumenta la revisin de configuracin y emite una publicacin de resumen. Una o
varias publicaciones de subgrupos siguen la publicacin de resumen que incluye la
informacin de VLAN que incluye cualquier cambio. El proceso se muestra en la Figura
1.
1.3. VERSIONES DE VTP

La versin 1 y la versin 2 de VTP se describen en la Tabla 1. Los switches en el
mismo dominio VTP deben utilizar la misma versin 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 versin de VTP es la versin 3.
Sin embargo, la versin 3 de VTP no entra dentro del mbito de este curso.

1.4. CONFIGURACION PREDETERMINADA DEL VTP
El comando EXEC privilegiado show vtp status muestra el estado del VTP. La
ejecucin del comando en un switch Cisco 2960 Plus genera el resultado que se
La Tabla 1 describe brevemente los parmetros show VTP status.
1.5. ADVERTENCIAS SOBRE VTP

Algunos administradores de redes evitan el VTP porque podra presentar informacin
errnea de la VLAN en el dominio VTP existente. Se utiliza el nmero de revisin de
configuracin para determinar si un switch debe mantener su base de datos de VLAN
existente, o sobrescribirla con la actualizacin del VTP enviada por otro switch en el
mismo dominio con la misma contrasea.
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 nmero de revisin de configuracin ms alto que el servidor
VTP existente. El nuevo switch puede ser servidor VTP o switch de cliente. Esta
propagacin puede ser difcil de corregir. Por lo tanto, cuando un switch se agrega a
una red, asegrese de que tenga la configuracin predeterminada del VTP

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 estn en el dominio cisco1 y la versin actual del VTP es 17. Adems
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 tcnico de redes agrega el S4 a la red debido a la necesidad de contar con capacidad
adicional. Sin embargo, el tcnico no borr la configuracin 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 nmero de revisin es 35, que es un nmero ms alto que
el nmero de revisin 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 nmero de
revisin ms alto, el resto de los switches en el dominio se sincronizarn con la revisin
del S4. Como consecuencia las VLAN 10 y 20 no existirn ms en los switches, lo que
deja sin conectividad a los clientes que estn conectados a los puertos que pertenecen
a VLAN no existentes.
El nmero de revisin de configuracin del VTP se almacena en la NVRAM (o Flash en
algunas plataformas) y no se restablece si borra la configuracin del switch y lo vuelve
a cargar. Para restablecer el nmero de revisin de configuracin 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 nmero de revisin de configuracin del VTP
se analizan en el prximo tema.

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 topologa de referencia para configurar y verificar una
implementacin de VTP. El switch S1 ser el servidor VTP mientras que el S2 y el S3
sern los clientes.
Confirme que todos los switches estn configurados con las configuraciones
predeterminadas para evitar cualquier problema con los nmeros de revisin de

configuracin. Configure el S1 como servidor VTP con comandos de configuracin
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 nmero de revisin de configuracin todava est configurado en 0 y la

cantidad de VLAN existentes es 5. Esto sucede porque no se configur ninguna VLAN
todava y el switch no pertenece a un dominio VTP. Las 5 VLAN son la VLAN 1
predeterminada y las VLAN 1002-1005

Paso 2: Configure el nombre de dominio y la contrasea del VTP.
sern los clientes.
El nombre de dominio est configurado con el comando de configuracin global vtp

domain domain-name. En el ejemplo 1, el nombre de dominio se configura
como CCNAen el S1. El switch S1 luego enva una publicacin del VTP al S2 y el S3.
Si el S2 y el S3 tienen la configuracin predeterminada con el nombre de dominio
NULL, entonces ambos switches aceptarn 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 contrasea usando el comando vtp
password. En el Ejemplo 2, la contrasea de dominio del VTP se configura
en cisco12345. Todos los switches en el dominio del VTP deben utilizar la misma
contrasea de dominio del VTP.
Paso 3: Configure los clientes VTP

sern los clientes.
Configure S2 y S3 como clientes VTP en el dominio CCNA utilizando la contrasea de

VTP cisco12345. La configuracin para el S2 se muestra en el Ejemplo 1. El S3 tiene
una configuracin idntica.

Paso 4: Configure la VLAN en el servidor VTP.
sern los clientes.
Actualmente no hay ninguna VLAN configurada en el S1 con excepcin de las VLAN

predeterminadas. Configure 3 VLAN, como se muestra en el Ejemplo 1.
Observe que las 3 VLAN ahora estn en la base de datos de VLAN. Verifique el
estado del VTP, como se muestra en el Ejemplo 3.

Observe que el nmero de revisin de configuracin 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 nmero 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 informacin de la
VLAN
sern 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.

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 nmero de revisin de configuracin en el S2 es el mismo que el

nmero 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

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 cmo crear una VLAN de rango extendido.

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

3. MODOS DE ENLACE TRONCAL DEL DTP
El protocolo de enlace troncal dinmico (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
utilizacin del DTP para configurar un enlace troncal con su puerto par.
El DTP se configura mediante el comando de configuracin 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 tambin puede deshabilitarse en una interfaz con el comando de

configuracin 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 especfica.
Nota: No puede eliminar VLAN predeterminadas (es decir, VLAN 1, 1002 a 1005).
La siguiente situacin ilustra cmo 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 configuracin global no
vlanvlan-id. El Ejemplo 2 muestra cmo eliminar la VLAN 99 en el S1 y verificar que
se haya eliminado la VLAN 99.

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 estn relacionados con las configuraciones
incorrectas. Segn 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:

4. CONCEPTOS PARA EL APILAMIENTO DE SWITCHES
Una pila de switch puede contener hasta nueve switches Catalyst 3750 conectados a
travs de sus puertos StackWise. Uno de los switches controla la operacin 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 cmo estn conectados en una pila.
Cada miembro se identifica mediante su propio nmero de miembro de la pila. Todos los
miembros se pueden elegir como maestros. Si el maestro deja de estar disponible, existe
un proceso automtico 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 ms 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 direccin IP. La direccin IP es una configuracin a nivel del sistema y
no es especfica para el maestro u otro miembro. Puede administrar la pila a travs de la
misma direccin IP incluso si se quita el maestro o cualquier otro miembro de la pila.
El maestro contiene archivos guardados y de configuracin de ejecucin para la pila. Por lo
tanto, hay solo un archivo de configuracin a administrar y mantener. Los archivos de
configuracin 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 contraseas, VLAN e interfaces. El
Ejemplo 1 muestra las interfaces en una pila de switches con cuatro switches de 52 puertos.
Observe que el primer nmero luego del tipo de interfaz es el nmero de miembro de la pila.
4.1. ARBOL DE EXPANSIN Y PILAS DE SWITCH

Otro beneficio del apilado de switch es la capacidad de agregar ms switches a una
nica instancia del STP sin aumentar el dimetro del STP. El dimetro es la cantidad
mxima de switches que debe atravesar para conectar dos switches. El IEEE
recomienda un dimetro mximo de siete switches para los temporizadores de STP
predeterminados. Por ejemplo, en la Figura 1 el dimetro de S1-4 a S3-4 es de nueve
switches. Este diseo infringe la recomendacin de IEEE.
El dimetro 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 mxima (20 segundos): la cantidad mxima de tiempo
que un switch guarda informacin de BPDU.
Temporizador de retraso en el envo (15 segundos): el tiempo que transcurre
en los estados de escuchar y aprender.
Nota: Las frmulas usadas para calcular el dimetro exceden el mbito de este curso.
Consulte el siguiente documento de Cisco para obtener ms
informacin:http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-treeprotocol/19120-122.html
Las pilas de switch ayudan a mantener o reducir el impacto del dimetro 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 expansin determinada. Esto significa que, si
los switches de la Figura 1 estn apilados, como se muestra en la Figura 2, el
dimetro mximo es de 3 en lugar de 9.
Recursos:
Administracin 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.)
Configuracin 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.)
Instalacin 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

5. DESCRIPCION GENERAL DE HSRP
El Protocolo de router de reserva activa (HSRP) fue diseado por Cisco para permitir la
redundancia de gateway sin una configuracin 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 automticamente el rol de router
activo. Asumir la funcin del gateway predeterminado para los terminales. No se
requieren cambios de configuracin en los terminales.
El router activo del HSRP y el router de reserva presentan a una nica direccin de
gateway predeterminado a los terminales. La direccin de gateway predeterminado es una
direccin IP virtual junto con una direccin MAC virtual compartida entre ambos routers
HSRP. Los terminales utilizan esta direccin IP virtual como su direccin de gateway
predeterminado. El administrador de redes configura la direccin IP virtual del HSRP. La
direccin MAC virtual se crea automticamente. Sin importar que router fsico se utilice, la
IP virtual y las direcciones MAC proporcionan la asignacin de direcciones al gateway
predeterminado para los terminales.
Solo el router activo recibir y reenviar el trfico enviado al gateway predeterminado. Si
falla el router activo, o falla la comunicacin al router activo, el router de reserva asume el
rol de router activo.

5.1. VERSIONES DEL HSRP
La versin predeterminada para Cisco IOS 15 es la 1. La versin 2 del HSRP
proporciona las siguientes mejoras:
HSRPv2 aumenta la cantidad de grupos admitidos. La versin 1 de HSRP

admite los nmeros de grupo de 0 a 255. La versin 2 de HSRP admite los
nmeros de grupo de 0 a 4095.
HSRPv1 usa la direccin de multidifusin 224.0.0.2. El HSRP versin 2 utiliza
la direccin de multidifusin IPv4 224.0.0.102 o a la direccin IPv6 de
multidifusin 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 dgitos hexadecimales indican el
nmero 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 dgitos hexadecimales de
la direccin MAC indican el nmero de grupo del HSRP.
HSRPv2 incorpora la compatibilidad para autenticacin MD5, tema que no se
encuentra dentro del mbito de este curso.
Nota: Los nmeros de grupo se utilizan para configuraciones HSRP ms avanzadas

que estn fuera del mbito de este curso. Para nuestros fines, utilizaremos el nmero
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 eleccin
del HSRP. De manera predeterminada, el router con la direccin IP numricamente
ms alta se elige como router activo. Sin embargo, siempre es mejor conocer cmo
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 ms alta ser el router activo. De manera predeterminada, la prioridad
HSRP es 100. Si las prioridades son iguales, el router con la direccin IP
numricamente ms 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, despus de que un router se convierte en el router activo,
seguir siendo el router activo incluso si otro router est disponible en lnea con una
prioridad HSRP ms alta.
Para forzar un nuevo proceso de eleccin 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 eleccin. Con este
intento de prioridad activado, un router disponible en lnea con una prioridad HSRP
ms 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 ms alta. Un router habilitado para intento de propiedad, con una

prioridad equivalente pero una direccin IP ms alta no realizar desplazar la
prioridad de un router activo. Consulte la topologa 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 ms alta, el R1 es el router activo y el R2 es el router de
reserva. Debido a un corte de energa que solo afecta al R1, el router activo ya no est
disponible y el router de reserva R2 asume el rol de router activo. Despus de que se
restaura la energa, el R1 vuelve a estar en lnea. Dado que R1 tiene una prioridad
ms alta y el intento de prioridad se encuentra habilitado, forzar un nuevo proceso de
eleccin. 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 lnea durante el proceso de eleccin.
5.3. ESTADOS DE HSRP
Un router puede ser el router HSRP activo responsable del reenvo del trfico 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 configuracin HSRP existente, el router enva 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 envan
paquetes de saludo a la direccin de multidifusin del grupo HSRP cada 3 segundos.
El router de reserva se convertir en activo si no recibe un mensaje de saludo del
router activo despus 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 versin 2 del HSRP.
Paso 2. Configure la direccin 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 lnea despus del router de reserva.
La Tabla 1 muestra la sintaxis de comandos utilizada para completar los pasos de
configuracin.

5.7. EJEMPLO DE CONFIGURACION DE HSRP
El Ejemplo 1 muestra las configuraciones del R1 y el R2 en la Figura 1.
5.8. VERIFICACIN DEL HSRP

Utilice los comandos show para verificar la configuracin 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: Verificacin de HSRP en el R1 y el R2
Nota: Puede cambiar el nombre de grupo predeterminado con el comando de

configuracin de interfaz standby [ group-number] name group-name.
Tambin puede utilizar el comando show standby brief, como se muestra en el
Ejemplo 2 para R1 y R2.

5.9. FALLA DE HSRP
Para solucionar problemas de HSRP, debe comprender el funcionamiento bsico. La
mayora 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 cundo el control de IP virtual para el grupo se debe
brindar a otro router.
Las terminales no pueden configurar correctamente la direccin IP virtual
como gateway predeterminado.
5.10. COMANDOS DE DEPURACION DE HSRP
Los comandos de depuracin del HSRP le permiten ver el funcionamiento del HSRP
cuando un router falla o est administrativamente apagado. Los comandos de
depuracin de HSRP disponibles pueden verse ingresando el comando debug
standby?, como se muestra en el Ejemplo 1.
Use debug standby packets para ver la recepcin y el envo 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 iniciarn un cambio de estado
despus 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 funcin 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 continuacin. 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 enva 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 despus el R2 asume el
rol de router activo de HSRP.
Observe que el R2 inicia un temporizador de espera pasivo para el R1. Despus 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 pgina anterior ilustran el funcionamiento esperado del
HSRP. Tambin puede utilizar los comandos debug para detectar problemas
comunes de configuracin:

Los routers en HSRP no estn conectados al mismo segmento de red. Si bien
esto podra ser un problema de la capa fsica, tambin podra ser un problema
de configuracin de la subinterfaz de VLAN.
Los routers en HSRP no estn configurados con las direcciones IP de la
misma subred. Los paquetes de saludo del HSRP son locales. No se enrutan
ms all del segmento de red. Por lo tanto, un router de reserva no sabra
cundo falla el router activo.
Los routers en HSRP no estn configurados con la misma direccin IP virtual.
La direccin IP virtual es el gateway predeterminado para terminales.
Los routers en HSRP no estn configurados con el mismo nmero de grupo
HSRP. Esto har que cada router asuma un rol activo.
Los terminales no se configuran con la direccin 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
significara que los terminales tendran solo conectividad a redes remotas
cuando dicho router HSRP est activo.
5.12. SOLUCIN DE PROBLEMAS DEL HSRP

6. HABILIDADES PARA LA SOLUCIN DE PROBLEMAS DE OSPF MULTIAREA
Antes de comenzar a diagnosticar y solucionar los problemas relacionados con una
implementacin de OSPF multirea, debe poder hacer lo siguiente:
Comprender los procesos que OSPF utiliza para distribuir, guardar y seleccionar la
informacin de routing.
Comprender cmo fluye la informacin de OSPF dentro de las reas y entre las
mismas.
Utilizar los comandos de Cisco IOS para recopilar e interpretar la informacin
necesaria para solucionar problemas de funcionamiento de OSPF.
6.1. ESTRUCTURA DE DATOS OSPF MULTIAREA
OSPF almacena la informacin 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 travs 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 informacin de la topologa de la red. Incluye
informacin topolgica completa sobre cada rea a la que el router OSPF est
conectado, as como cualquier ruta que est disponible alcanzar otras redes o
sistemas autnomos.
Tabla de routing: despus de que se calcula el algoritmo SPF, se ofrecen a la
tabla de enrutamiento las mejores rutas para cada red.
6.2. SITUACIN DE PROBLEMAS DE OSPF MULTIAREA

Con respecto a la topologa de la Figura 1, la informacin detallada en la Tabla 1
debera aparecer en las cuatro estructuras de datos principales.
Usted utilizara este conocimiento acerca de qu informacin debe estar visible en

estructuras de datos OSPF para comparar con lo que se ve realmente al utilizar los
comandos show de Cisco IOS.

CONEXION A LAS REDES CCNA 4
PUENTE CN: DESCRIPCION GENERAL
Explicar el propsito 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 cmo mitigar los ataques comunes de seguridad LAN.
Configurar SNMP para supervisar las operaciones en una red de una empresa
pequea a mediana.
Resolver un problema de red utilizando SPAN.
Explicar el propsito y las caractersticas de QoS.
Explicar la forma en la que los dispositivos de red implementan QoS.
Explicar por qu la computacin en la nube y la virtualizacin son necesarias para
redes en evolucin.
Explicar por qu la programabilidad de la red es necesaria para las redes en evolucin.
Utilizar un IP SLA basado en eco ICMP para resolver problemas de conectividad de
red.
1. TOPOLOGIAS DE WAN
La interconexin de varios sitios a travs de WAN puede incluir una variedad de tecnologas
del proveedor de servicios y de topologas de WAN. Las topologas de WAN ms comunes
son:
PUNTO A PUNTO
Una topologa 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 lneas alquiladas
dedicadas como las lneas T1/E1. Una conexin punto a punto implica un servicio de
transporte de capa 2 a travs de la red del proveedor de servicios. Los paquetes enviados
desde un sitio se entregan a otro sitio y viceversa. Una conexin punto a punto es
transparente para la red del cliente, como si hubiera un enlace fsico directo entre dos
terminales.

DE ESTRELLA
Si se requiere una conexin de red privada entre varios sitios, entonces una topologa punto
a punto con mltiples circuitos punto a punto es una opcin. Cada circuito punto a punto
requiere su propia interfaz de hardware dedicada que requiere mltiples routers con tarjetas
de interfaz WAN. Suele ser una opcin costosa. Una opcin menos costosa es una
topologa de punto a multipunto (Figura 2), tambin conocida como topologa de estrella
(hub and spoke). Con una topologa 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 travs del sitio de hubs mediante circuitos virtuales y subinterfaces
enrutadas del hub. Una topologa de estrella (hub and spoke) tambin es un ejemplo de una
topologa de conexin nica.
MALLA COMPLETA
Una de las desventajas de las topologas de estrella es que la comunicacin debe pasar a
travs del hub. Con una topologa 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.

TOPOLOGIA DE DOBLE CONEXIN
Una topologa de doble conexin ofrece redundancia, como se muestra en la Figura 4. La
desventaja de las topologas de doble conexin es que son ms costosas de implementar
que las topologas de seguridad nica. Esto es porque requieren hardware de red, como
routers y switches adicionales. Las topologas de doble conexin son ms difciles de
implementar porque requieren configuraciones adicionales y complejas. Sin embargo, la
ventaja de las topologas de doble conexin es que ofrecen redundancia de red, equilibrio
de carga, computacin o proceso distribuido mejorados, y la capacidad de implementar las
conexiones del proveedor de servicio de respaldo.
2. DMVPN
La VPN dinmica multipunto (DMVPN) es una solucin de Cisco para crear VPN mltiples
de forma fcil, dinmica y escalable. El objetivo es simplificar la configuracin 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

Con los DMVPN, las sucursales tambin pueden comunicarse directamente con otras
sucursales, como se muestra en la Figura 2.
El DMVPN se crea utilizando las siguientes tecnologas:
Next Hop Resolution Protocol (NHRP).

Tneles de encapsulacin de routing genrico multipunto (mGRE).
Cifrado de protocolo de seguridad IP (IPsec).
NHRP es un protocolo de resolucin y de almacenamiento en cach de capa 2 similar al

protocolo de resolucin de direcciones (ARP). NHRP crea una base de datos de asignacin
distribuida de direcciones IP pblicas para todos los radios del tnel. 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).
Encapsulacin de routing genrico (GRE) es un protocolo de tnel desarrollado por Cisco
que puede encapsular una amplia variedad de tipos de paquetes de protocolo dentro de
tneles IP. Una interfaz de tnel mGRE permite que una nica interfaz de GRE admita
tneles IPSec mltiples. Con la interfaz mGRE, se crean tneles asignados de manera
dinmica a travs de un origen de tnel permanente en el hub y de los destinos de tnel
asignados de manera dinmica que se crean en los radios segn sea necesario. Esto
reduce el tamao y simplifica la complejidad de la configuracin.
Al igual que otros tipos de VPN, la DMVPN depende de IPsec para proporcionar el
transporte seguro de informacin privada en redes pblicas, 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 direccin IPv4 asignada automticamente 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 direccin asignada a la interfaz del marcador. La
segunda ruta de host es la direccin IPv4 del ISP. La instalacin 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
informacin 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 SOLUCIN DE PROBLEMAS DE PPPoE

Despus de asegurarse de que el router cliente y el mdem DSL estn conectados a
los cables correctos, uno o ms de los siguientes motivos generalmente son la causa
de una conexin de PPPoE que no funciona correctamente:
Falla en el proceso de negociacin de PPP.

Falla en el proceso de autenticacin de PPP.
Falla en el ajuste del tamao mximo del segmento de TCP.
3.2. NEGOCIACIN PPPoE

Verifique la negociacin PPP utilizando el comando debug ppp negotiation. El
ejemplo 1 muestra una parte del resultado de la depuracin una vez que se ha
habilitado la interfaz G0/1 del R1.
Hay cuatro puntos principales de fallas en una negociacin PPP:
No hay respuesta del dispositivo remoto (el ISP).

Protocolo de control de enlaces (LCP) no abierto.
Falla de autenticacin.
Falla del protocolo de control de IP (IPCP).
3.3. AUTENTICACION PPPoE

Despus de confirmar con el proveedor de servicios de Internet (ISP) que utiliza CHAP,
verifique que el nombre de usuario y la contrasea de CHAP sean correctos. El
ejemplo 1 muestra la configuracin de CHAP en la interfaz dialer2.

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 contrasea de CHAP fueran incorrectos, el resultado del

comando debug ppp negotiation mostrar un mensaje de error de autenticacin, como
se muestra en el Ejemplo 3.
3.4. TAMAO DE PPPoE MTU

El acceso a algunas pginas web puede ser un problema con PPPoE. Cuando un
cliente solicita una pgina web, se produce un protocolo TCP de enlace de tres vas
entre el cliente y el servidor web. Durante la negociacin, el cliente especifica el valor
del tamao mximo del segmento (MSS) de TCP. El MSS del TCP es el tamao
mximo de la porcin de datos del segmento TCP.
Un host determina el valor de su campo de MSS restando los encabezados IP y TCP
de unidad mxima de transmisin (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 tamao del valor predeterminado MSS ser
de 1460 bytes, como se muestra en la Figura 1
El tamao predeterminado de MSS es de 1460 bytes, cuando el MTU predeterminado

es de 1500 bytes. Sin embargo, PPPoE admite un MTU de slo 1492 bytes que para
adaptarse al encabezado PPPoE adicional de 8 bytes que se muestra en la Figura 2.
Puede verificar el tamao de MTU de PPPoE en la configuracin en ejecucin, como

se muestra en el Ejemplo 1.
Esta disparidad entre el host y el tamao 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 vas. En la mayora de los casos, el valor ptimo para el argumento maxsegment-size es de 1452 bytes. En el Ejemplo 2, se muestra esta configuracin en la
interfaz LAN de R1.
El valor de MSS del TCP de 1452, ms 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 trfico dentro
de sus redes. Los IGP se utilizan para intercambiar informacin de routing dentro de una red
de una empresa o de un sistema autnomo (AS).
El protocolo de puerta de enlace fronteriza (BGP) es un protocolo de gateway exterior (EGP)
utilizado para el intercambio de informacin de routing entre sistemas autnomos, como
ISP, empresas, y proveedores de contenido (por ejemplo, YouTube, Netflix, etc.).
En el BGP, se asigna a cada AS un nmero AS de 16 o 32 bits nico que lo identifica de
manera nica en Internet. En la Figura 1, se muestra un ejemplo de cmo se utilizan los
IGP.
Nota: Tambin hay nmeros AS privados. Sin embargo, los nmeros AS privados estn
ms all del alcance de este curso.
Los protocolos de routing internos utilizan una mtrica especfica, como el costo de OSPF,
para determinar las mejores rutas hacia las redes de destino. BGP no utiliza una sola
mtrica, a diferencia de los IGP. Los routers BGP intercambian varios atributos de ruta que
incluyen una lista de nmeros 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

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 determinacin 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 conexin 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 trfico dentro de la misma
organizacin, y son administrados por una sola organizacin. 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 autnomos, en el resto de Internet.
4.1. eBGP e iBGP
Se denomina "pares BGP" a dos routers que intercambian informacin 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 autnomos 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 estn ms all del alcance de este curso.

4.2. CUANDO UTILIZAE EL BGP
El uso de BGP resulta muy apropiado cuando un AS tiene conexiones a sistemas
autnomos mltiples. Esto se conoce como alojamiento mltiple. Cada AS en la
Figura 1 es un entorno de host mltiples porque cada AS tiene conexiones con al
menos otros dos sistemas autnomos o pares BGP.
Antes de ejecutar BGP, es importante que el administrador de red conozca y entienda
bien el BGP. Una configuracin 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 conexin 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 utilizarn rutas estticas, 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 comprensin limitada del BGP. Una configuracin incorrecta
de un router BGP puede producir errores de gran alcance ms 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 poltica de routing especfica. Sin embargo, las
polticas de routing estn ms all del alcance de este curso.

4.4. OPCIONES DE BGP
El BGP es utilizado por los sistemas autnomos 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 autnomos.
Por ejemplo, una empresa que se conecta al ISP utilizando BGP publicara sus
direcciones de red en su ISP. El ISP luego publicara dichas redes en otros ISP (pares
BGP). Finalmente, el resto de los sistemas autnomos en Internet aprenden sobre las
redes originadas inicialmente por la empresa.
Existen tres maneras comunes mediante las cuales una organizacin puede elegir
implementar el BGP en un entorno de alojamientos mltiples:
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 mtodo ms 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 enva 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 opcin permite que la empresa A reenve el trfico al ISP
correspondiente para las redes anunciadas por ese ISP. Por ejemplo, la empresa A
elegira el ISP-1 para redes publicadas por el ISP-1. Para todas las dems redes, se
puede usar una de las dos rutas predeterminadas, lo que significa que el routing por
debajo del nivel ptimo an 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
trfico 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 ms de 550 000 redes.

4.5. IDENTIFICAR LA TERMINOLOGIA DE BGP
4.6. IDENTIFICAR EL DISEO DE BGP

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 descripcin para la configuracin
bsica del protocolo eBGP.
4.8. EJEMPLO DE CONFIGURACION DE BGP

La Figura 1 muestra una topologa 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 configuracin sencilla.
El ejemplo 1 muestra la configuracin de BGP para la empresa A. Los clientes

utilizarn generalmente el espacio privado para la direccin 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 pblicas, publicadas por el protocolo BGP en el ISP.

El comando router bgp habilita el BGP e identifica el nmero de AS para la empresa
A. Un router slo 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 nmero de AS. Observe que el AS
del ISP es diferente que el nmero 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 opcin 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 mscara de subred /24, as que, en este caso,
la opcin mask no se requiere. Si el cliente A estuviera anunciando la red
198.133.0.0/16, sera necesaria la opcin mask. De lo contrario, el protocolo BGP
publicara de red con una mscara /24 con clase.
El comando network introduce la direccin-red en la tabla local de BGP. La tabla de
BGP contiene todas las rutas aprendidas a travs del BGP o publicadas mediante el
BGP. El eBGP luego publicar la direccin-red a sus vecinos de eBGP.
Nota: A diferencia de un protocolo IGP, la direccin-red utilizada en el
comando network no tiene que ser una red conectada directamente. El router slo
necesita tener una ruta hacia esta red en su tabla de routing.
El ejemplo 2 muestra la configuracin de BGP para el ISP-1.
Los comandos de eBGP en el router ISP-1 son similares a la configuracin en la

empresa A. Observe cmo 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 opcin de configuracin vlida de
BGP, hay mejores maneras para anunciar una ruta predeterminada en el EBGP. Sin
embargo, estos mtodos estn ms 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 topologa de configuracin de eBGP.
Observe cmo el cdigo de origen B identifica que la ruta fue aprendida mediante el
BGP. Especficamente, 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 mayora de las
entradas de la tabla de BGP muestran los nmeros del sistema autnomo mltiple en

la ruta y detallan la secuencia de nmeros 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 direccin 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 conexin de BGP en la Empresa A.
La primera lnea muestra la direccin IPv4 local utilizada para establecer una
interconexin con otro vecino de BGP y el nmero local de AS de este router.
Aparecer la direccin y el nmero de AS del vecino BGP remoto en la parte inferior
del resultado.
4.10.
CONFIGURAR Y COMPROBAR BGP

5. DESCRIPCION GENERAL DE LA SOLUCIN DE PROBLEMAS DE ACL DE IPV6
Si despus 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 tpicos de la ACL. Si
bien la mayora de los errores ms comunes incluyen la introduccin de las ACE en el orden
equivocado y la ausencia de especificacin de las reglas adecuadas de ACL, otros errores
comunes implican la aplicacin de ACL con el nombre incorrecto, la interfaz incorrecta, o la
direccin incorrecta.
5.1. SOLUCIN DE PROBLEMAS DE ACL DE IPV6: ESCENARIO 1
Este escenario de solucin de problemas de las ACL de IPv6 utiliza la topologa 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, despus de configurar la ACL, la PC1 todava 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 declaracin de permiso, pero no se muestran las declaraciones de negacin
Solucin: Los ACE en las ACL no muestran ningn problema en el orden o en los
criterios de las reglas. El siguiente paso es ver cmo se aplica la ACL en la interfaz
utilizando ipv6 traffic-filter. La ACL se aplic utilizando el nombre correcto, la interfaz
correcta y la direccin correcta? Para revisar errores de configuracin de interfaz,
visualice la configuracin en ejecucin, como se muestra en el Ejemplo. 2.
La ACL se aplic con el nombre correcto, pero con una direccin incorrecta. La
direccin in o out se toma desde la perspectiva del router, lo cual significa que la ACL
actualmente se aplica al trfico antes de que se reenve desde la interfaz G0/0 e
ingrese en la red :10. Para corregir el problema, elimine ipv6 traffic-filter NO-FTP-TO11 outy reemplcelo 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.

Este escenario de solucin de problemas de ACL de IPv6 utiliza la topologa que se
R3 est configurada con una ACL de IPv6 llamada RESTRICTED-ACCESS que debe
aplicar la siguiente poltica 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, despus 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
Solucin: En esta situacin, el problema no se debe a cmo se aplic la ACL. En la
interfaz, la ACL no se escribe mal y la direccin y la ubicacin son correctas, como se
Una mirada ms 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 declaracin de permiso debera permitir el acceso a la red :10. Sin

embargo, el administrador configur una instruccin 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 nmero 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 poltica

especifica que los hosts en la LAN del R3 deben poder utilizar SSH en el host
2001:DB8:CAFE:11::11. Sin embargo, la declaracin deny para la red :11 se encuentra
antes de la declaracin permit. Por lo tanto, todos los intentos para acceder al: se
deniega la red 11 antes de que la instruccin 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.

Este escenario de solucin de problemas de ACL de IPv6 utiliza la topologa que se
R1 est configurada con una ACL de IPv6 llamada DENY-ACCESS que debe aplicar la
siguiente poltica 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 configuracin y la aplicacin de ACL de IPv6.

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, despus de aplicar la ACL a la interfaz: la red 10
an es accesible desde la red :30.
Solucin: En esta situacin, el problema no tiene que ver con la manera en la que se
escribieron las declaraciones de las ACL, sino con la ubicacin de la ACL. Dado que
las ACL de IPv6 deben configurarse con un origen y un destino, debe aplicarse lo ms
cerca posible del origen del trfico. La ACL DENY-ACCESS se aplic en la direccin
saliente en la interfaz R1 G0/1 que est ms cerca del destino. Como resultado, el
trfico a la red: 10 no se ve no se ve afectado porque alcanza la red: 10 a travs 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 ubicacin sera
configurar y aplicar la ACL lo ms cerca posible del origen del trfico. El ejemplo 2
muestra la eliminacin de la ACL en el R1 y la configuracin y la aplicacin correctas
de la ACL en el R3.
6. DETECCION DHCP
Un ataque de suplantacin de DHCP se produce cuando un servidor DHCP dudoso se
conecta a la red y brinda parmetros de configuracin IP falsos a los clientes legtimos. La
suplantacin de DHCP es peligrosa porque los clientes pueden recibir informacin de
concesin de IP, como servidores DNS maliciosos, puertas de enlace predeterminadas
maliciosas y asignaciones IP maliciosas.
Las mejores prcticas de seguridad recomiendan el uso de la deteccin DHCP para mitigar
los ataques de suplantacin de DHCP.
La deteccin DHCP crea y mantiene una base de datos denominada base de datos de
enlaces de deteccin DHCP (tambin conocida como tabla de enlaces de deteccin DHCP).
Esta base de datos incluye la direccin MAC del cliente, la direccin IP, el tiempo de la
concesin de DHCP, el tipo de enlace, el nmero de VLAN, y la informacin de interfaz en
cada puerto de switch o interfaz no confiables. El administrador de redes debe definir qu
puertos son confiables. Al combinar la informacin en la base de datos de enlace de
deteccin DHCP con los puertos confiables, el switch puede filtrar los mensajes DHCP de
fuentes no confiables.
Cuando la deteccin 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 informacin del paquete de

origen con la informacin que se mantiene en la base de datos de enlaces de deteccin
DHCP. El switch negar los paquetes que contengan la siguiente informacin:
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
deteccin DHCP o con los lmites de velocidad.
Paquetes de agente de retransmisin DHCP que incluyan informacin de la opcin
82 proveniente de un puerto no confiable.
Nota: La opcin 82 proporciona seguridad y se utiliza para enviar informacin sobre los
clientes DHCP a servidor DHCP. Sin embargo, un puerto no confiable no debe recibir
paquetes de opcin 82.
En una red grande, la creacin de la base de datos de enlaces de deteccin DHCP puede
llevar tiempo una vez que se habilita. Por ejemplo, la deteccin DHCP puede tardar 2 das
para completar la base de datos, si el tiempo de la concesin de DHCP es de 4 das.
La deteccin 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 trfico a los
servidores DHCP que respondan con mensajes de DHCP Offer y DHCP Ack. Los
puertos confiables se deben identificar explcitamente en la configuracin.
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 cmo los puertos de deteccin
DHCP se deben asignar en una red.

Observe cmo los puertos confiables siempre conducen al servidor de DHCP legtimo,
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 configuracin de deteccin DHCP va ms 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 especficos. Tambin
limita los servicios o las opciones que estn disponibles despus de que se concede el
acceso.
El control de acceso bsico en los dispositivos de red se activa mediante la autenticacin.
Existen diferentes mtodos para implementar la autenticacin en un dispositivo Cisco, y
cada mtodo ofrece varios niveles de seguridad. A continuacin, se describen dos mtodos
comunes:
Autenticacin de contrasea simple: Esto implica el uso de los comandos de

configuracin password y login para proteger la consola, las lneas vty, y los
puertos auxiliares. Lamentablemente, este mtodo es tambin el mtodo ms dbil
y menos seguro porque no proporciona ninguna responsabilidad. Por ejemplo,
cualquier persona que tenga la contrasea puede obtener acceso al dispositivo y
modificar la configuracin.
Autenticacin local de bases de datos: Esto implica la creacin de las cuentas de
usuario local con el comando de configuracin global username name secret
password y luego configurar el comando de configuracin de lnea 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 contrasea. Tambin
proporciona ms responsabilidad porque el nombre de usuario queda registrado
cuando un usuario inicia sesin.
Sin embargo, el mtodo de la base de datos local no escala mucho ms 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. Adems, la configuracin de la base de datos local no
proporciona ningn mtodo de autenticacin de reserva. Por ejemplo, qu sucede si el
administrador olvida el nombre de usuario y la contrasea para ese dispositivo? Sin el
mtodo de respaldo disponible para la autenticacin, la recuperacin de la contrasea se
convierte en la nica opcin.
Una solucin mejor y ms escalable es lograr que todos los dispositivos remitan a una base
de datos de nombres de usuario y contraseas alojados en un servidor central. Para admitir
esto, los dispositivos Cisco admiten el marco de trabajo de autenticacin, autorizacin y
auditora (AAA) que ayuda a asegurar el acceso de los dispositivos. En los dispositivos
Cisco, se utilizan dos protocolos de autenticacin 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
telefnico de autenticacin remota).
Un dispositivo compatible con AAA se puede configurar para remitir a una base de datos de
usuarios externa para la autenticacin de usuarios, licencias y contabilizacin. El dispositivo

se comunica con el servidor AAA mediante el protocolo TACACS+ o RADIUS. Cada
protocolo admite capacidades y funcionalidades diferentes. La seleccin de TACACS+ o
RADIUS depende de las necesidades de la organizacin. Por ejemplo, un ISP grande puede
seleccionar RADIUS porque admite la contabilizacin detallada necesaria para la
facturacin de los usuarios. Una organizacin con varios grupos de usuarios puede
seleccionar TACACS+ porque requiere polticas de autorizacin 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 autenticacin y la autorizacin.

Cifra todas las comunicaciones.
Utiliza el puerto TCP 49.
A continuacin, se enumeran cuatro factores cruciales para RADIUS:
Combina la autenticacin de RADIUS y autorizacin como un solo proceso.

Cifra solamente la contrasea.
Utiliza UDP.
Admite tecnologas de acceso remoto, 802.1x y el protocolo SIP (Session Initiation
Protocol).
Mientras ambos protocolos pueden usarse para la comunicacin entre un router y los
servidores AAA, TACACS+ se considera el protocolo ms seguro. Esto se debe a que se
cifran todos los intercambios de protocolos TACACS+, mientras que RADIUS solo cifra la
contrasea del usuario. RADIUS no cifra nombres de usuario, informacin de la cuenta, o
cualquier otra informacin que contenga el mensaje de RADIUS.
Nota: la configuracin de AAA va ms all del alcance de este curso.
8. 802.1X
El estndar IEEE 802.1X define un control de acceso y un protocolo de autenticacin
basado en puertos que evita que las estaciones de trabajo no autorizadas se conecten a
una LAN a travs de los puertos de switch acceso pblico. El servidor de autenticacin
autentica cada estacin de trabajo que est conectada a un puerto del switch antes habilitar
cualquier servicio ofrecido por el switch o la LAN.
Con la autenticacin 802.1x basada en puertos, los dispositivos de la red tienen funciones
especficas, 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 estndar 802.1X.
Switch (autenticador): Controla el acceso fsico a la red segn el estado de
autenticacin del cliente. El switch funciona como acta intermediario (proxy) entre
el cliente y el servidor de autenticacin. Solicita la identificacin de la informacin
del cliente, verifica dicha informacin al servidor de autenticacin 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
autenticacin extensible (EAP) y de interactuar con el servidor de autenticacin.
Servidor de autenticacin: realiza la autenticacin real del cliente. El servidor de
autenticacin 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 acta como el proxy, el servicio de autenticacin es transparente para el
cliente. El sistema de seguridad RADIUS con extensiones de EAP es el nico
servidor de autenticacin admitido.
9. IDENTIFICAR LA MEJOR PRACTICA DE SEGURIDAD
10. DESCRIPCIN GENERAL DE SNMPv3

El protocolo simple de administracin de redes versin 3 (SNMPv3) autentica y cifra los
paquetes de toda la red para proporcionar un acceso seguro a los dispositivos. El agregado
de la autenticacin y el cifrado a SNMPv3 brinda una solucin a las vulnerabilidades de las
versiones anteriores de SNMP.
10.1. PASOS DE CONFIGURACIN 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

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 configuracin de una visualizacin para limitar los mensajes
SNMP a acceso de slo lectura.
Router(config)# snmp-server view view-name oidtree {included | excluded}
Paso 3. Configurar caractersticas de grupo SNMP con el comandosnmp-server
group:
1.
2.
3.
4.
Configure un nombre para el grupo.

Establezca la versin de SNMP en 3 con la palabra clave v3.
Requerir autenticacin y el cifrado con la palabra clave priv.
Asocie una visualizacin al grupo y otrguele 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 caractersticas 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 versin de SNMP en 3 con la palabra clave v3.
3. Establezca el tipo de autenticacin en md5 o sha y configurar una contrasea de
autenticacin. Se prefiere el SHA y debe ser admitido por el software de
administracin de SNMP.
4. Requiera cifrado con la palabra clave priv y configure una contrasea de cifrado.
Router(config)# snmp-server user username group-name v3
auth {md5 | sha} authpassword priv {des | 3des | aes {128 | 192 | 256}}privpassword
En el Ejemplo 1, una ACL estndar con nombre PERMIT-ADMIN est configurada para
admitir slo la red 192.168.1.0/24. Todos los hosts conectados a esta red tendrn
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 produccin, el administrador de red
probablemente configurara esta vista para incluir slo 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 versin
3 con autenticacin 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 versin 3. La autenticacin se establece para usar SHA, y se configura
una contrasea de autenticacin. Aunque el R1 admite hasta el cifrado AES 256,
software de administracin SNMP solo admite AES 128. Por lo tanto, el cifrado se
establece en AES 128 y se configura una contrasea de cifrado.

Un anlisis completo de las opciones de configuracin para SNMPv3 excede el alcance
de este curso.
10.2. VERIFICACIN SNMPv3

Utilice el comando ping para verificar la conectividad entre los agentes y los clientes.
Utilice el comando show snmp group para mostrar informacin sobre cada grupo
SNMP en la red, como se muestra en el Ejemplo 1.
Utilice el comando show snmp user para mostrar informacin sobre las caractersticas
configuradas de un usuario SNMP, como se muestra en el Ejemplo. 2.

10.3. CONFIGURAR Y VERIFICAR SNMPv3

11.PUERTOS REFLEJADOS
Un analizador de paquetes (tambin conocido como analizador de protocolos, detector de
paquetes o analizador de trfico) 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 comnmente para capturar y analizar
los paquetes en una computadora local.
Qu sucedera si un administrador de red deseara capturar los paquetes de muchos otros
dispositivos fundamentales y no solos la NIC local? Una solucin consiste en configurar los
dispositivos de red para copiar y enviar el trfico que va a los puertos de inters a un puerto
conectado a un analizador de paquetes. El administrador luego podra analizar el trfico de
red de diversas fuentes en la red
Sin embargo, la operacin bsica de una red conmutada moderna inhabilita la capacidad del
analizador de paquetes para capturar el trfico de otras fuentes. Por ejemplo, un usuario
que ejecuta Wireshark puede capturar slo el trfico que entra a su NIC. No puede capturar
el trfico 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 direccin MAC de origen y el puerto de ingreso de la
trama de Ethernet. Una vez que se crea la tabla, el switch solamente reenva el trfico
destinado a una direccin MAC directamente al puerto correspondiente. Esto evita que un
analizador de paquetes conectado a otro puerto del switch "escuche" otro trfico del switch.
La solucin a este dilema es habilitar los puertos reflejados. La funcin de puertos reflejados
permite que un switch copie y enve tramas de Ethernet desde puertos especficos al puerto
de destino conectado a un analizador de paquetes. La trama original an se reenva de la
manera habitual. En la Figura 1, se muestra un ejemplo de puertos reflejados.
En la figura, el trfico entre la PC1 y la PC2 tambin se enva a la computadora porttil que
tiene un analizador de paquetes instalado.
12.SPAN LOCAL
La funcin Analizador de puertos con switches (SPAN) de los switches Cisco es un tipo de
puertos reflejados que enva copias de la trama que ingresa a un puerto, desde otro puerto
del mismo switch. Es comn encontrar un dispositivo ejecutando un analizador de paquetes,
un sistema de deteccin de intrusiones (IDS), o un sistema de prevencin de intrusiones
(IPS) conectado a ese puerto.

En la Tabla 1, se describen los trminos de uso general con el SPAN.
Una sesin SPAN es la asociacin entre los puertos de origen (o VLAN) y un puerto de
destino.
El trfico 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 mltiples puertos de varias fuentes en una
misma sesin o toda una VLAN como el origen del trfico, una sesin SPAN no admite a
ambos. Los puertos de capa 2 y de capa 3 se pueden configurar como puertos de origen.
Existen tres cosas ms 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 nmero de puerto de destino depende de la plataforma. Algunas plataformas
permiten ms de un puerto de destino.
El puerto de destino ya no es un puerto de switch normal. A travs de ese puerto
solo pasa trfico supervisado.

Se dice que la funcin SPAN es local cuando todos los puertos supervisados se encuentran
en el mismo switch que el puerto de destino. Esta funcin contrasta con del SPAN remoto
(RSPAN).
12.1. SPAN REMOTO
El RSPAN permite que los puertos de origen y destino estn 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 trfico.
En la Tabla 1, se describen los trminos de uso general con el RSPAN.
SPAN remoto utiliza dos sesiones, una sesin como origen y una sesin para copiar o
recibir el trfico de una VLAN. La Figura 1 muestra un ejemplo de RSPAN. Observe el
enlace troncal utilizado para transportar la VLAN de SPAN remoto a travs de la red.

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 sesin SPAN:
S1(config)# monitor session number source {interface | vlans}
S1(config)# monitor
session number destination {interface | vlans}
Nota: El ID de sesin utilizado para definir los puertos de origen y destino debe ser
igual para asignar los puertos a la misma sesin SPAN.
En la Figura 1, el administrador debe captar todo el trfico que se enva 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 sesin 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 configuracin bsica de SPAN para la Figura 1.
Para verificar la configuracin de la sesin 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 direccin del trfico y el puerto de destino.
12.4. SOLUCIN DE PROBLEMAS CON LA DESCRIPCIN GENERAL DE SPAN

La funcin Analizador de puertos con switches (SPAN) permite que los administradores
distribuyan el trfico a los dispositivos especializados, como los analizadores de
paquete y los sistemas de proteccin contra intrusiones (IPS). Esto permite que los
administradores analicen el trfico y resuelvan problemas antes de enviar el trfico
hacia el destino. Los IPS buscan patrones especficos en el trfico. A medida que el
trfico atraviesa los IPS, puede analizar el trfico en tiempo real y tomar medidas al
detectar un patrn de trfico 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
trfico en una red. Debido a que las redes modernas son entornos conmutados, el
SPAN es fundamental para la operacin eficaz de los IPS.
Algunos patrones de ataques son ms complejos que otros. Por ejemplo, un ataque
LAND (ataque de red de rea local) enva un paquete TCP SYN suplantado (inicio de
conexin) con la misma direccin 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 mquina 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
fcilmente que estos paquetes ingresen a la red en su totalidad.
Adems de los IPS, otro dispositivo comn utilizado para recibir el trfico de SPAN el
analizador de paquetes. Mientras que los IPS se centran ms en el aspecto de
seguridad del trfico, los analizadores de paquete se suelen utilizar para la solucin de
problemas. Por ejemplo, si una aplicacin de red particular demora demasiado en
ejecutar las tareas, un administrador de red puede utilizar SPAN para duplicar y
redirigir el trfico hacia un analizador de paquetes para capturarlo. El administrador
luego puede analizar el trfico de todos los dispositivos para solucionar problemas de
funcionamiento por debajo del nivel ptimo de la aplicacin de red.

13.PRIORIZACIN DEL TRAFICO (CALIDAD DE SERVICIO QoS)
La calidad de servicio (QoS) es un requisito cada vez ms importante para las redes hoy en
da. Las nuevas aplicaciones disponibles para los usuarios, como las transmisiones de voz y
de video en vivo generan expectativas ms altas sobre la calidad de los servicios que se
proporcionan.
La congestin se produce cuando la demanda de ancho de banda excede la cantidad
disponible. Cuando se producen intentos de comunicaciones simultneas a travs de la red,
la demanda de ancho de banda puede exceder su disponibilidad, lo que provoca congestin
en la red.
Cuando el volumen del trfico es mayor que lo que se puede transportar travs 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 nmero de paquetes en cola contina 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 congestin de la red produce demoras. Las variaciones en la demora producen
fluctuaciones. Una interfaz experimenta congestin cuando tiene ms trfico del que
puede gestionar. Los puntos de congestin de la red son candidatos fuertes para los
mecanismos de QoS. La Figura 1 muestra tres ejemplos tpicos de puntos de
congestin.
Nota: Un dispositivo implementa nicamente QoS cuando experimenta algn tipo de

congestin.
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 fluctuacin de fase es la variacin en la demora de paquetes. En el extremo emisor,

los paquetes se envan de manera permanente con los paquetes de espacio uniforme
por separado. Debido a la congestin en la red, la espera incorrecta o los errores de
configuracin, 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 trfico en tiempo real e interactivo.
13.2. PRDIDA 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 congestin, 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 descartarn con la misma frecuencia que los
datos que no sean urgentes, como el correo electrnico y la exploracin web.
Por ejemplo, cuando un router recibe un flujo de audio digital del protocolo de
transmisin 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 funcin es el bfer de demora de reproduccin. El bfer de demora de
reproduccin debe almacenar en bfer estos paquetes y luego reproducirlos en un flujo

constante que se convertir en un flujo de audio analgico, 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 bfer, se descartan los paquetes que estn fuera del rango, y se
escuchan interrupciones en el audio, como se muestra en la Figura 2.
Para las prdidas tan pequeas como un paquete, el procesamiento digital de seales
(DSP) interpola lo que considera que debe ser el audio y no hay ningn 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 prdida de paquetes es una causa comn de los problemas de calidad de voz en
una red IP. En una red diseada correctamente, la prdida de paquetes debe estar
cerca de cero. Los cdecs de voz utilizados por DSP pueden tolerar cierto grado de
prdida 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 prdida de
paquetes sea igual a cero. Se garantiza el ancho de banda para las llamadas de voz
dando prioridad al trfico de voz sobre el trfico que no es sensible al tiempo.

13.3. IDENTIFICAR LA TERMINOLOGIA DE LA CALIDAD DE LA TRANSMISION DE LA
RED
13.4. TENDENCIAS DEL TRFICO DE LA RED

A principios de la dcada del 2000, los tipos de trfico IP predominantes eran voz y
datos. El trfico de voz tiene una necesidad de ancho de banda predecible y tiempos
de llegada de paquete conocidos. El trfico de datos no es en tiempo real, y tiene una
necesidad impredecible de ancho de banda. El trfico 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.
Ms recientemente, el trfico de video se ha vuelto cada vez ms importante para las
comunicaciones y las operaciones empresariales. Segn Cisco Virtual Networking
Index (VNI) (Enlaces a un sitio externo.), en 2014, el trfico de video represent el 67%
de todo el trfico. Para 2019, representar el 80% de todo el trfico. Adems, el trfico
de video mvil aumentar ms del 600%, de 113 672 TB a 768 334 TB.
Los tipos de demandas de voz, video y trfico de datos en la red son muy diferentes.
13.5. VOZ
El trfico de voz es predecible y uniforme, como se muestra en la Figura 1. El trfico 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 ms alta.
Por ejemplo, los productos de Cisco utilizan el rango de puerto de 16384 a 32767 de
RTP para priorizar el trfico de voz. La voz puede tolerar cierta cantidad de latencia,
fluctuacin y la prdida sin ningn efecto notable. La latencia no debe superar los 150
milisegundos (ms). Las fluctuaciones no deben superar los 30 ms y la prdida de
paquetes de voz no debe ser superior al 1%. El trfico 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 cmara lenta. El audio de la fuente puede perder la sincronizacin con el video.
El trfico de video tiende a ser imprevisible, inconsistente y a transmitirse por rfagas,
en comparacin con el trfico de voz. En comparacin con la transmisin de voz, el
video es menos resistente a prdidas y tiene un mayor volumen de los datos por
paquete, como se muestra en la Figura 1. Observe cmo los paquetes de voz llegan
cada 20 ms y son de 200 bytes predecibles cada uno. En cambio, la cantidad y el
tamao de los paquetes de video varan cada 33 ms segn el contenido del video. Por
ejemplo, si la transmisin de video se compone de contenido que no cambia mucho de
un cuadro a otro, los paquetes de video sern pequeos, y se necesitarn menos para
mantener una experiencia de usuario aceptable. Sin embargo, si la transmisin de
video est compuesta por contenido que cambia rpidamente (por ejemplo, una
secuencia de accin en una pelcula), los paquetes de video sern ms grandes y se
requerirn ms por cada mdulo de tiempo de 33 ms para mantener una experiencia
de usuario aceptable.

En la Tabla 2, se resumen las caractersticas del trfico de video. Los puertos UDP,
como 554 utilizados para el protocolo de transmisin en tiempo real (RSTP), deben
tener prioridad sobre otro trfico de red menos sensible al tiempo. Al igual que la voz, el
video puede tolerar cierta cantidad de latencia, fluctuacin, y prdida sin ningn efecto
notable. La latencia no debe ser superior a 400 milisegundos (ms). Las fluctuaciones
no deben ser de ms de 50 ms, y la prdida de paquetes de video no debe ser superior
al 1%. El trfico de video requiere por lo menos 384 kb/s de ancho de banda.
13.7. DATOS
La mayora de las aplicaciones utilizan TCP o UDP. A diferencia de UDP, TCP realiza
la recuperacin de errores. Aplicaciones de datos que no tienen tolerancia a la prdida
de datos, como el correo electrnico y las pginas web, el uso de TCP para asegurarse
de que, si los paquetes se pierden en trnsito, se enven nuevamente. El trfico de
datos puede ser fluido o puede tener estallidos. El trfico de control de red
generalmente es elegante y predecible. Cuando hay un cambio de topologa, el trfico
de control de red puede tener estallidos durante unos segundos. Pero la capacidad de
las redes actuales permite administrar fcilmente el aumento del trfico de control de
red mientras la red converge.
Sin embargo, algunas aplicaciones TCP pueden ser muy expansivas y consumir una
gran porcin de la capacidad de la red. El FTP ocupar tanto ancho de banda como
pueda obtener cuando usted descargue un archivo grande, como una pelcula o un
juego. En la Tabla 1, se resumen las caractersticas del trfico de datos.

Aunque el trfico de datos es relativamente insensible a las cadas y demoras en
comparacin 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 trfico de datos
por los que un administrador de red debe preguntar son los siguientes:
13.8. DESCRIPCION GENERAL DE LA PUESTA EN COLA

La poltica de QoS implementada por el administrador de la red se activa cuando se
produce una congestin en el enlace. La puesta en cola es una herramienta
administrativa para la congestin que puede almacenar en bfer, 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 ms sencilla, la cola FIFO (tambin conocida como "primero en entrar,
primero en salir" o FCFS) implica almacenar en bfer y reenviar paquetes en el orden
de llegada.
FIFO no tiene ningn concepto de prioridad o clase de trfico y, por lo tanto, no toma
ninguna decisin sobre la prioridad del paquete. Hay una sola cola, y todos los
paquetes se tratan por igual. Se enva una interfaz a los paquetes en el orden en el que
llegan, como se muestra en la Figura 1. Aunque el trfico sea ms importante o
sensible al tiempo segn la clasificacin de prioridad, observe que el trfico se enva en
el orden en que se recibe.
Cuando se utiliza FIFO, el trfico importante o sensible al tiempo se puede descartar

cuando se produce una congestin 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 mtodo ms rpido de espera, es eficaz para enlaces grandes que
tienen poco retraso y congestin mnima. Si su enlace tiene una congestin muy
pequea, la cola FIFO puede ser la nica cola que necesite usar.
MECANISMO DE COLA EQUITATIVO PONDERADO (WFQ)
La WFQ es un mtodo de programacin automatizada que proporciona la asignacin
del ancho de banda justo a todo el trfico de red. La WFQ aplica la prioridad o las
ponderaciones al trfico identificado y lo clasifica en conversaciones o flujos, como se

El WFQ luego determina la cantidad de ancho de banda que se le permite a cada flujo
en relacin con otros flujos. El algoritmo basado en el flujo utilizado por la WFQ
planifica simultneamente el trfico 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 trfico de bajo
volumen e interactivo, como las sesiones Telnet y de voz, sobre el trfico de gran
volumen, como las sesiones de FTP. Cuando se producen simultneamente los flujos
de las transferencias de archivo mltiples, se asigna un ancho de banda similar a las
transferencias.
La WFQ clasifica el trfico en distintos flujos basados en el encabezado de manejo de
paquetes, lo que incluye caractersticas como las direcciones IP de origen y de destino,
las direcciones MAC, los nmeros de puerto, el protocolo y el valor del tipo de servicio
(ToS). El valor ToS en el encabezado IP puede utilizarse para clasificar el trfico. El
ToS se describir ms adelante en el captulo.
Los flujos de trfico de bajo ancho de banda, que conforman el mayor parte del trfico,
reciben servicio preferencial, lo que permite que todas sus cargas ofrecidas se enven
oportunamente. Los flujos de trfico de gran volumen comparten la capacidad restante
proporcionalmente entre s.
Limitaciones
La WFQ no se utiliza con los tneles y el cifrado porque estas funciones modifican la
informacin de contenido de paquete requerida por la WFQ para la clasificacin.
Si bien la WFQ se adapta automticamente a las condiciones de trfico de red
cambiantes, no ofrece el grado de control de precisin sobre la asignacin 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 estndar de la cola equitativa ponderada (WFQ)
para admitir las clases de trfico definidas por el usuario. Para el CBWFQ, se definen
las clases de trfico 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 trfico para esa
clase. Se reserva una cola FIFO para cada clase, y el trfico que pertenece a una clase
se dirige a la cola para esa clase, como se muestra en la Figura 1.

Cuando se ha definido una clase segn sus criterios de coincidencia, puede asignarle
caractersticas. Para cuantificar una clase, le asigna el ancho de banda, el peso, y el
lmite de paquete mximo. El ancho de banda asignado a una clase es el ancho de
banda garantizado que se entrega a la clase durante la congestin.
Para caracterizar una clase, tambin especifica el lmite de cola para esa clase, que es
la cantidad mxima de paquetes que se pueden acumular en la cola de esa clase. Los
paquetes que pertenecen a una clase estn sujetos al ancho de banda y a los lmites
de cola que caracterizan a la clase.
Una vez que una cola haya alcanzado su lmite de cola configurado, el agregado de
ms paquetes a la clase hace que surtan efecto el descarte de cola o el descarte de
paquetes, segn cmo est configurada la poltica 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 retencin de paquetes. Esta es
la respuesta de espera predeterminada para la congestin. El descarte de cola trata
todo el trfico por igual y no distingue entre las clases de servicio.
MECANISMO DE COLA DE BAJA LATENCIA (LLQ)
La funcin de LLQ proporciona la cola de prioridad estricta (PQ) a CBWFQ. La
asignacin de cola de prioridad estricta permite que los datos susceptibles a la demora,
como la voz, se enven 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 segn las clases definidas sin una cola de
prioridad estricta disponible para el trfico en tiempo real. El peso para un paquete que
pertenece a una clase especfica 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 envan 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 trfico de voz, que en gran
medida no admite retrasos, especialmente variaciones en el retraso. Para el trfico de
voz, las variaciones en la demora introducen irregularidades en la transmisin que se
manifiestan como fluctuaciones en la conversacin escuchada.
Con la LLQ, los datos susceptibles a la demora se envan primero, antes de que se
procesen los paquetes de otras colas. La LLQ permite que los datos susceptibles a la

demora, como la voz, se enven 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 trfico. Si bien se pueden poner varios tipos de trfico en
tiempo real en la cola de prioridad estricta, Cisco recomienda enviar solamente el
trfico de voz.
COMPARAR LOS ALGORITMOS DE COLA
La cantidad de bits que se pueden transmitir a travs de una red en un solo

segundo: ANCHO DE BANDA.
13.9. SELECCIN DE UN MODELO ADECUADO DE POLITICA DE CALIDAD DE

SERVICIO (QoS)
Cmo se puede implementar QoS en una red? Existen tres modelos para
implementar QoS. La Tabla 1 resume estos tres modelos:

QoS se implementa realmente en una red que utiliza IntServ o DiffServ. Aunque IntServ
proporciona la garanta ms alta de QoS, utiliza muchos recursos y por lo tanto su
escalabilidad es limitada. En cambio, DiffServ consume menos recursos y es ms
escalable. En algunas ocasiones, los dos se emplean juntos para la implementacin de
QoS en redes.
MODELO DE MEJOR ESFUERZO
El diseo bsico de Internet ofrece la entrega de paquetes mediante el modelo de
mejor esfuerzo y no brinda ninguna garanta. Este enfoque an predomina en Internet
actualmente y sigue siendo adecuado en la mayora 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 electrnico. 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 estndar. Su carta se trata exactamente de la misma manera que las otras
cartas. Con el modelo de mejor esfuerzo, la carta podra no llegar y, a menos que haya
llegado a un acuerdo de notificacin 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, visualizacin y realidad virtual, motivaron el desarrollo del modelo de
arquitectura IntServ en 1994 (RFC 1633, 2211 y 2212). IntServ es un modelo de
servicio mltiple que puede acomodar mltiples requisitos de Calidad de Servicio
(QoS).
IntServ proporciona una manera de entregar la QoS completa que las aplicaciones en
tiempo real requieren al administrar explcitamente los recursos de red para
proporcionar QoS a las transmisiones de paquetes especficas de usuario, a veces
denominados microflujos. Utiliza reserva de recursos y mecanismos de control de
admisin como mdulos de construccin para establecer y mantener QoS. Esta
prctica es similar a un concepto conocido como hard QoS. Hard QoS garantiza las
caractersticas de trfico, como el ancho de banda, la demora y las velocidades de
prdida de paquetes, de extremo a extremo. Hard QoS asegura niveles de servicios
predecibles y garantizados para las aplicaciones crticas.
La Figura 1 es una simple ilustracin del modelo de IntServ.
IntServ utiliza un enfoque orientado a la conexin heredado del diseo de una red de
telefona. Cada comunicacin individual debe especificar explcitamente su descriptor
de trfico y los recursos solicitados a la red. El router perimetral realiza el control de
admisin para garantizar que los recursos disponibles son suficientes en la red. El
estndar de IntServ asume que los routers a lo largo de una ruta configuran y
mantienen el estado de cada comunicacin individual.
En el modelo de IntServ, la aplicacin solicita a un tipo especfico de servicio a la red
antes de enviar datos. La aplicacin informa a la red su perfil de trfico 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 sealar las
necesidades de QoS del trfico de una aplicacin junto con los dispositivos en la ruta
de extremo a extremo a travs de la red. Si los dispositivos de red a lo largo de la ruta
pueden reservar el ancho de banda necesario, la aplicacin de origen puede comenzar
a transmitir. Si reserva solicitada falla a lo largo de la ruta, la aplicacin de origen no
enva ningn dato.
La red realiza el control de admisin en base a la informacin de aplicaciones y los
recursos de red disponibles. La red cumple con los requisitos de QoS de la aplicacin
siempre que el trfico est dentro de las especificaciones del perfil. La red cumple su
compromiso al mantener el estado por flujo y llevar a cabo luego la clasificacin de
paquetes, de polticas, y espera inteligente basada en ese estado.

SERVICIOS DIFERENCIADOS
El modelo de Calidad de Servicio (QoS) de servicios diferenciados (DiffServ) especifica
un mecanismo simple y escalable para clasificar y administrar el trfico de red y
proporcionar las garantas de QoS en redes IP modernas. Por ejemplo, DiffServ puede
proporcionar servicio garantizado de baja latencia al trfico de red crtico, como voz o
video, al mismo tiempo que proporciona garantas del mejor trfico a servicios no
crticos como trfico web o transferencias de archivos.
El diseo 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 enva 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, segn lo que usted solicit.
DiffServ no es una estrategia de QoS de extremo a extremo porque no puede otorgar
garantas de extremo a extremo. Sin embargo, el modelo DiffServ es un enfoque ms
escalable para implementar QoS. A diferencia de IntServ y "hard QoS" (QoS fuerte) en
los que los hosts terminales sealan sus necesidades de QoS a la red, DiffServ no
utiliza la sealizacin. 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 trfico cada uno con requisitos de QoS
diferentes.
Mientras el host enva trfico a un router, el router clasifica los flujos en agregados
(clases) y proporciona la poltica QoS apropiada para las clases. DiffServ impone y
aplica los mecanismos de QoS en base a saltos, aplicando uniformemente el

significado global a cada clase de trfico 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 hara IntServ.
Adems de clasificar el trfico, DiffServ minimiza los requisitos de mantenimiento de
sealizacin y estado en cada nodo de la red.
Especficamente, DiffServ divide el trfico de red en clases segn 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 segn esa clase. Con
DiffServ, es posible elegir muchos niveles de servicio. Por ejemplo, al trfico de voz
desde telfonos IP se le otorga generalmente un trato preferencial sobre el resto del
trfico de aplicaciones, al correo electrnico se le da generalmente el servicio de mejor
esfuerzo, y al trfico 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 volmenes crecientes de trfico sensible a demoras y fluctuaciones, en ocasiones
IntServ y RSVP se implementan juntos.
13.10. EVITAR LA PERDIDA DE PAQUETES

La prdida de paquetes es generalmente el resultado de la congestin en una interfaz.
La mayora de las aplicaciones que utilizan el TCP experimentan una disminucin de
velocidad debido a que el TCP se ajusta automticamente a la congestin en la red.
Los segmentos cados del TCP hacen que las sesiones del TCP reduzcan su tamao
de ventana. Algunas aplicaciones no utilizan TCP y no pueden manejar las cadas
(flujos frgiles).

Los siguientes enfoques pueden evitar las cadas de aplicaciones sensibles:
Aumentar la capacidad de enlace para facilitar o evitar la congestin.

Garantizar el suficiente ancho de banda y aumentar el espacio en bfer para
acomodar las rfagas de trfico de flujos frgil. 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 reenvo prioritario a las
aplicaciones sensibles a las cadas. Algunos ejemplos son WFQ, CBWFQ y
LLQ.
Evitar la congestin el descartar paquetes de prioridad ms baja antes de que
se produzca la congestin. QoS de Cisco IOS proporciona mecanismos de
espera que comienzan a descartar paquetes de prioridad ms baja antes de
que se produzca la congestin. Un ejemplo es la Deteccin Temprana
Aleatoria Ponderada (WRED).
13.11. HERRAMIENTAS DE CALIDAD DE SERVICIO (QoS)

Hay tres categoras de herramientas de QoS como se describe en la Tabla 1.
Consulte la Figura 1 para comprender la secuencia de cmo se utilizan estas

herramientas cuando se aplica QoS a los flujos de paquetes.

Como se muestra en la ilustracin, se clasifican los paquetes de ingreso (cuadros
grises) y se marca su encabezado IP respectivo (cuadros de color). Para evitar la
congestin, luego se asignan recursos a los paquetes en base a las polticas definidas.
Los paquetes son luego puestos en la cola y reenviados a la interfaz de egreso segn
la poltica definida de modelado y regulacin de trfico de QoS.
Nota: La clasificacin y la marcacin se pueden aplicar en el ingreso o en el egreso,
mientras que las otras acciones de QoS, como la organizacin 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 poltica de QoS, el mismo tiene que
ser clasificado. La clasificacin y la marcacin nos permiten identificar o marcar los
tipos de paquetes. La clasificacin determina la clase de trfico al cual los paquetes o
tramas pertenecen. Solamente se pueden aplicar polticas al trfico despus de que
este se haya identificado.
Cmo se clasifica un paquete depende de la implementacin de QoS. Los mtodos de
clasificacin de flujos de trfico en la capa 2 y 3 incluyen el uso de interfaces, ACL y
mapas de clase. El trfico tambin 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 funcin de clasificacin y deteccin del protocolo del software
Cisco IOS que funciona con funciones de QoS. NBAR excede el mbito de este curso.
La marcacin 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 poltica definida. La marcacin debe realizarse tan cerca de la fuente como
sea posible. Esto determina el lmite de confianza.
13.13. MARCACIN DE TRFICO

La forma en la que se marca el trfico generalmente depende de la tecnologa. La
Tabla 1 describe algunos de los campos de marcacin utilizados en las diferentes
tecnologas. La decisin de marcar el trfico 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 estndar IEEE que admite VLAN en una red Ethernet. El estndar
tambin incluye el esquema de priorizacin de calidad de servicio, denominado IEEE
802.1p.

13.14. MARCACIN EN CAPA 2
El estndar 802.1Q es una especificacin 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 despus del campo de direccin de origen.
El identificador de protocolo de etiqueta (TPID) est establecido actualmente, y se le ha

asignado el valor 0x8100. La informacin de control de etiqueta (TCI) contiene el
campo de PRI de 3 bits (prioridad) que identifica las marcaciones de clase de servicio
(CoS). La marcacin 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.

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 trfico de 8 bits.
Estos campos se utilizan para transportar la marcacin de paquete asignada por las
herramientas de la clasificacin de QoS. Luego, los dispositivos receptores remiten al
campo para reenviar los paquetes segn la poltica QoS asignada correspondiente.
La Figura 2 muestra el contenido (es decir, de 7 a 0) del campo de 8 bits.
Nota: Los bits notificacin de congestin extendida (ECN) se utilizan para identificar
una marcacin 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 cdigo de servicios diferenciados
(DSCP). Seis bits ofrecen un mximo de 64 clases de servicio posibles. Los routers de
reconocimiento de DiffServ implementan los comportamientos por salto (PHB), que
definen las propiedades de reenvo de paquetes asociadas a una clase de trfico.
Especficamente, existen cuatro categoras de PBH, como se describe en la Figura 1.

13.16. LIMITES DE CONFIANZA
Dnde deberan producirse las marcaciones? El trfico se debe clasificar y marcar lo
ms cerca su origen como sea tcnicamente y administrativamente posible. Esto define
el lmite de confianza, como se muestra en la Figura 1.
Los terminales confiables tienen las capacidades y la inteligencia para marcar

el trfico 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
telfonos IP, puntos de acceso inalmbrico, gateways y sistemas de
videoconferencia, estaciones de conferencia IP y ms.
Los terminales seguros pueden hacer que el trfico se marque en el switch de
la capa 2.
El trfico tambin puede marcarse en los switches/routers de la capa 3.
Generalmente, es necesario volver a marcar el trfico. Por ejemplo, la remarcacin de

los valores de CoS a valores de prioridad IP o DSCP.
13.17. PREVENCIN DE CONGESTIN
La administracin de congestin incluye los mtodos de espera y de programacin,
donde el trfico excesivo se almacena en bfer o se pone en cola (y a veces se
descarta) mientras espera ser enviado en una interfaz de egreso. Las herramientas
para evitar la congestin son ms simples. Las cargas de trfico de la red, en un
esfuerzo por anticipar y evitar la congestin en los cuellos de botella de la red comn y
de internetwork antes de que la congestin se convierta en un problema. Estas
tcnicas proporcionan un trato preferencial para el trfico superior (prioridad) cuando
hay una congestin, mientras que en paralelo maximiza el uso del rendimiento de la
red y de la capacidad, y minimiza prdida de paquetes y el retardo. Por ejemplo, Cisco
IOS QoS incluye la deteccin temprana aleatoria y ponderada (WRED) como una
solucin posible para evitar la congestin.
El algoritmo WRED permite evitar la congestin en las interfaces de red al brindar
administracin del bfer y permitir que el trfico 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
congestin para el trfico basado en el protocolo de datagrama de usuario (UDP),
como el trfico de voz. En el caso del trfico basado en UDP, los mtodos como la

puesta en cola y las tcnicas de compresin ayudan a reducir, e incluso a prevenir, la
prdida de paquetes UDP.
13.18. MODELADO Y VIGILANCIA
Las polticas de modelado y de vigilancia del son dos mecanismos proporcionados por
el software Cisco IOS QoS para evitar la congestin.
El modelado del trfico conserva los paquetes en exceso en una cola y luego programa
el exceso para la transmisin posterior en incrementos de tiempo. El resultado del
modelado del trfico 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 bfer los paquetes retardados, mientras que la vigilancia no hace esto.
En cambio, la vigilancia del trfico propaga los estallidos. Cuando la velocidad del
trfico alcanza el la velocidad mxima, se descarta el trfico 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 trfico
entrante en una interfaz.
Asegrese de tener memoria suficiente cuando active el modelado. Adems, la
formacin requiere una funcin de programacin para la transmisin posterior de
cualquier paquete con retardo. Esta funcin de programacin le permite organizar la
cola de modelado en distintas colas. Entre las funciones de programacin son CBWFQ
y LLQ.
14.DESCRIPCION GENERAL DE LA NUBE

La computacin en la nube implica una gran cantidad de computadoras conectadas a travs
de una red que puede estar ubicada fsicamente cualquier lugar. Los proveedores dependen
en mayor medida de la virtualizacin para brindar sus servicios de computacin en la nube.
La computacin en la nube puede reducir costos operativos al utilizar los recursos con
mayor eficacia. La computacin en la nube admite una variedad de problemas de
administracin de datos:
Permite el acceso a los datos de organizacin en cualquier momento y lugar.

Optimiza las operaciones de TI de la organizacin suscribindose nicamente a los
servicios necesarios.
Elimina o reduce la necesidad de equipos, mantenimiento y administracin de TI en
las instalaciones.
Reduce el costo de equipos y energa, los requisitos fsicos de la planta y las
necesidades de capacitacin del personal.
Permite respuestas rpidas a los crecientes requisitos de volumen de datos.
La computacin en la nube, con su modelo de pago segn el consumo, permite que las
organizaciones consideren los gastos de computacin y almacenamiento ms como un
servicio que como una inversin en infraestructura. Los gastos de capital se transforman en
gastos operativos.
14.1. SERVICIOS EN LA NUBE
Los servicios en la nube estn disponibles en una variedad de opciones diseadas
para cumplir con los requisitos del cliente. Los tres servicios principales de
computacin en la nube definidos por el Instituto Nacional de Normas y Tecnologa
(NIST) de los Estados Unidos en su publicacin especial 800-145 son los siguientes:
Software como servicio (SaaS): El proveedor de la nube es responsable del

acceso a los servicios, como correo electrnico, comunicacin y Office 365 que
se ofrecen a travs de Internet. El usuario slo 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
tambin soporte de TI para cada uno de los servicios de computacin en la nube
(ITaaS).
Para las empresas, los ITaaS pueden extender las funcionalidades de TI sin necesidad
de invertir en infraestructura nueva, capacitacin de personal nuevo o licencias de
software nuevo. Estos servicios estn disponibles a peticin y se proporcionan de
forma econmica 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 pblicas: Las aplicaciones basadas en la nube y los servicios que se

ofrecen en una nube pblica estn a disposicin de la poblacin en general.
Los servicios pueden ser gratuitos u ofrecerse en el formato de pago segn el
uso, como el pago de almacenamiento en lnea. La nube pblica utiliza Internet

para proporcionar servicios.
Nubes privadas: Las aplicaciones y los servicios basados en una nube
privada que se ofrecen en una nube privada estn destinados a una
organizacin o una entidad especfica, como el gobierno. Se puede configurar
una nube privada utilizando la red privada de la organizacin, si bien el armado
y el mantenimiento pueden ser costosos. Una organizacin externa que cuente
con una seguridad de acceso estricta tambin puede administrar una nube
privada.
Nubes hbridas: Una nube hbrida consta de dos o ms nubes (por ejemplo,
una parte personalizada y otra parte pblica); donde cada una de las partes
sigue siendo un objeto separado, pero ambas estn conectadas a travs de
una nica arquitectura. En una nube hbrida, las personas podran tener grados
de acceso a diversos servicios segn los derechos de acceso de los usuarios.
Nubes personalizadas: Estas son nubes desarrolladas para satisfacer las
necesidades de una industria especfica, como los servicios de salud o los
medios de comunicacin. Las nubes personalizadas pueden ser privadas o
pblicas.
14.3. COMPARACIN ENTRE LA COMPUTACIN EN LA NUBE Y EL CENTRO DE

DATOS
Los trminos "centro de datos" y "computacin en la nube" a menudo se usan de
manera incorrecta. Estas son las definiciones correctas de centro de datos y
computacin en la nube:
Centro de datos: Generalmente, consiste en una instalacin de

almacenamiento y procesamiento de datos gestionados por un departamento
de TI interno o arrendado fuera de las instalaciones.
Computacin en la nube: Generalmente, consiste en un servicio fuera de las
instalaciones que ofrece acceso a pedido a un grupo compartido de recursos
informticos configurables. Estos recursos se pueden aprovisionar y lanzar
rpidamente con un esfuerzo de administracin mnimo.
La computacin en la nube es posible gracias a los centros de datos. Un centro de

datos es una instalacin utilizada para alojar sistemas de computacin y componentes
relacionados. Un centro de datos puede ocupar una habitacin en un edificio, un piso o
ms, o un edificio entero. Por lo general, la creacin y el mantenimiento de centros de
datos son muy costosos. Por esta razn, solo las grandes organizaciones utilizan
centros de datos privados creados para alojar sus datos y proporcionar servicios a los
usuarios. Las organizaciones ms pequeas, 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 organizacin en
la nube con un centro de datos ms grande.
A menudo, la computacin 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

14.5. COMPUTACION EN LA NUBE Y VIRTUALIZACION
Los trminos computacin en la nube y virtualizacin suelen usarse indistintamente;
Sin embargo, significan diferentes cosas. La virtualizacin es la base de la computacin
en la nube. Sin ella, la computacin en la nube ms ampliamente utilizada no sera
posible.
La computacin en la nube separa la aplicacin del hardware. La virtualizacin separa
el SO hardware. Los diferentes proveedores ofrecen servicios en la nube virtuales que
pueden proveer dinmicamente los servidores segn sea necesario. Por ejemplo, el
servicio web Amazon Elastic Compute Cloud (Amazon EC2) proporciona una manera
simple para que los clientes proporcionen dinmicamente los recursos informticos 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 virtualizacin, primero es necesario entender un
poco parte la historia de la tecnologa de los servidores. Histricamente, los servidores
empresariales consistan en un sistema operativo (SO) del servidor, como Windows
Server o Linux Server, instalado en el hardware especfico, 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 electrnico, etc.).
El principal problema con esta configuracin 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
perodos de tiempo, esperando hasta que hubiera una necesidad de ofrecer un servicio
especfico que estos proporcionaban. Estos servidores malgastaban energa y
ocupaban ms espacio del que estaba garantizado por la cantidad de servicio. Esto se
conoce como proliferacin de servidores.

14.7. VIRTUALIZACIN DE SERVIDORES
La virtualizacin de servidores saca provecho de los recursos inactivos y consolida el
nmero de servidores requeridos. Esto tambin permite que mltiples 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 mltiples de
los sistemas operativos.
El hipervisor es un programa, un firmware o un hardware que suma una capa de

abstraccin a la parte superior del hardware fsico real. La capa de abstraccin se
utiliza para crear mquinas virtuales que tienen acceso a todo el hardware de la
mquina fsica, como CPU, memoria, controladores de disco y NIC. Cada una de esas
mquinas virtuales ejecuta un sistema operativo completo y separado. Con la
virtualizacin, las empresas ahora pueden consolidar el nmero de servidores. Por
ejemplo, no es raro que 100 servidores fsicos se consoliden como mquinas virtuales
sobre los 10 servidores fsicos que utilicen hipervisores.
El uso de la virtualizacin normalmente incluye redundancia para brindar proteccin
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. Adems, la
misma VM se puede ejecutar en dos hipervisores simultneamente copiando las
instrucciones de RAM y de CPU entre estos. Si falla un hipervisor, la VM contina
ejecutndose en el otro supervisor. Los servicios que se ejecutan en las VM tambin
son virtuales y se pueden instalar o deshabilitar dinmicamente, segn sea necesario.

14.8. VENTAJAS DE LA VIRTUALIZACIN
Una de las ventajas ms importantes de la virtualizacin es un menor costo total:
Se necesitan menos equipos: La virtualizacin permite la consolidacin de

los servidores, que requiere menos servidores fsicos, menos dispositivos de
red y menos infraestructura de soporte. Tambin significa menores costos de
mantenimiento.
Se consume menos energa: La consolidacin de los servidores reduce los
costos de energa y de refrigeracin mensuales. El consumo reducido ayuda a
las empresas a alcanzar una huella de carbono ms pequea.
Se requiere menos espacio La consolidacin de servidores con la
virtualizacin 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 virtualizacin:
Creacin de prototipos ms sencilla: se pueden crear rpidamente

laboratorios autnomos que funcionen en redes aisladas para probar y crear
prototipos de implementacin de redes. Si se comete un error, un
administrador puede volver simplemente a una versin anterior. Los entornos
de prueba pueden estar en lnea, pero deben estar aislados de los usuarios
finales. Una vez completada la prueba, se pueden implementar los servidores y
los sistemas.
Aprovisionamiento ms rpido de servidores: crear un servidor virtual es
mucho ms rpido que el aprovisionamiento de un servidor fsico.
Mayor tiempo de actividad del servidor: La mayora de las plataformas de
virtualizacin de servidores ahora ofrecen funciones avanzadas redundantes
con tolerancia a fallas, como la migracin en vivo, la migracin de
almacenamiento, la alta disponibilidad y la programacin distribuida de
recursos. Tambin admiten la capacidad de mover una mquina virtual de un
servidor a otro.
Recuperacin tras un desastre mejorada: La virtualizacin ofrece soluciones
avanzadas de continuidad de los negocios. Brinda la capacidad de abstraccin
de hardware de modo que el sitio de recuperacin ya no necesite tener
hardware que sea idntico al hardware del entorno de produccin. La mayora
de las plataformas de virtualizacin de servidores de la empresa tambin
tienen software que puede ayudar a probar y automatizar las fallas antes de
que suceda un desastre.
Soporte heredado: La virtualizacin puede extender la vida til de los OSS y
de las aplicaciones, y esto brinda ms tiempo a las organizaciones para migrar
a nuevas soluciones.

14.9. CAPAS DE ABSTRACCIN
Para ayudar a explicar cmo funciona la virtualizacin, es conveniente utilizar capas de
abstraccin en arquitecturas de PC. Un sistema de computacin consta de las capas
de abstraccin siguientes, como se muestra en la Figura 1:
En cada una de estas capas de abstraccin, se utiliza algn tipo de cdigo de

programacin como interfaz entre la capa inferior y la capa superior. Por ejemplo, el
lenguaje de programacin C se suele utilizar para programar el firmware que accede al
hardware.
En la Figura 2, se muestra un ejemplo de virtualizacin. 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 ms VM, es un equipo host. Los
hipervisores de tipo 2 tambin 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

administracin no es necesario.

Los hipervisores de tipo 2 son muy populares entre los consumidores y en las
organizaciones que experimentan con la virtualizacin. 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 ms

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 tambin se denominan el enfoque de infraestructura fsica
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 ms 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, slo se muestra la
informacin bsica, como la versin de SO, la cantidad de RAM y la direccin IP. Una
instancia de OS no se puede crear a partir de esta pantalla. Los hipervisores de tipo 1
requieren una consola de administracin para administrar el hipervisor. El software de
administracin se utiliza para administrar varios servidores con el mismo hipervisor. La
consola de administracin puede consolidar los servidores automticamente y
encender o apagar los servidores, segn sea necesario.
Por ejemplo, suponga que el Servidor1 de la Figura 1 se queda con menos recursos.
Para hacer que haya ms recursos disponibles, la consola de administracin mueve la
instancia de Windows al hipervisor en el Servidor2.
La consola de administracin proporciona la recuperacin ante las fallas de hardware.

Si falla un componente del servidor, la consola de administracin mueve la VM a otro
servidor automticamente y sin inconvenientes.
Algunas consolas de administracin tambin permiten la sobreasignacin. La
sobreasignacin se produce cuando se instalan varias instancias de SO, pero su
asignacin de memoria excede la cantidad total de memoria que tiene un servidor. Por

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 asignacin 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 virtualizacin del servidor oculta los recursos del servidor (por ejemplo, la cantidad y
la identidad de los servidores fsicos, de los procesadores y del SO) de los usuarios del
servidor. Esta prctica 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 fsico 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 difcil de hacer con los switches de red
tradicionales.
Otro problema es que los flujos de trfico difieren considerablemente del modelo
cliente-servidor tradicional. Generalmente, un centro de datos tiene una cantidad
considerable de trfico que se intercambia entre los servidores virtuales (denominado
"trfico entre nodos"). Estos flujos cambian en la ubicacin y la intensidad en el tiempo,
lo que requiere un enfoque flexible a la administracin de recursos de red.
Las infraestructuras de red existentes pueden responder a los requisitos cambiantes
relacionados con la administracin de los flujos de trfico 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 reconfiguracin necesaria
puede llevar mucho tiempo.
Podra la infraestructura de red tambin beneficiarse de la virtualizacin? Si esto es
as, de qu manera podra 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 reenvo. El plano de control
contiene los mecanismos de reenvo de ruta de capa 2 y capa 3, como las
tablas de vecinos de protocolo de routing y las tablas de topologa, las tablas
de routing IPv4 e IPv6, STP, y la tabla ARP. La informacin que se enva al
plano de control es procesada por la CPU.
Plano de datos: Este plano, tambin denominado "plano de reenvo",
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 trfico. Los routers y los switches utilizan la informacin
del plano de control para reenviar el trfico entrante desde la interfaz de egreso
correspondiente. Por lo general, la informacin del plano de datos es
procesada por un procesador especial del plano de datos, como un procesador
de seal digital (DSP) sin que se involucre a la CPU.

El ejemplo de la Figura 1 muestra cmo Cisco Express Forwarding (CEF) utiliza el
plano de control y el plano de datos para procesar los paquetes:
CEF es una tecnologa de switching de IP de capa 3 que permite que el reenvo 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
informacin de reenvo (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 informacin incluida en la FIB y en la
tabla de adyacencia, sin necesidad de consultar la informacin en el plano de control.
Para virtualizar la red, un controlador centralizado realiza y elimina la funcin 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 envo de datos mientras el controlador
centralizado administra el flujo de datos, mejora la seguridad y proporciona otros
servicios.

14.16. VIRTUALIZACION DE LA RED
Hace ms de una dcada, VMware desarroll una tecnologa de virtualizacin que
permita a un SO host admitir uno o ms SO clientes. La mayora de las tecnologas de
virtualizacin ahora se basan en esta tecnologa. La transformacin de los servidores
exclusivos para los servidores virtualizados se ha adoptado y se implementa
rpidamente en el centro de datos y las redes empresariales.
Se han desarrollado dos arquitecturas de red principales para admitir la virtualizacin
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 solucin de
hardware diseada especficamente para la integracin de computacin en la
nube y administracin de centros de datos.
Estas son otras tecnologas de virtualizacin 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 trfico entre los routers, los switches, los puntos de acceso
inalmbrico y un controlador. El protocolo OpenFlow es un elemento bsico en
el desarrollo de soluciones de SDN.
OpenStack: Este enfoque es una plataforma de virtualizacin y organizacin
disponible para desarrollar entornos de nube escalables y proporcionar una
infraestructura como una solucin (IaaS) de servicio. OpenStack se usa
frecuentemente en conjunto con Cisco ACI. La organizacin 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 interconexin 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 envo 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.
Tambin 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 polticas fabricacin denominada controlador de SDN. Las dos arquitecturas se
muestran en la Figura 1.
El controlador de SDN es una entidad lgica que permite que los administradores de
red administren y determinen cmo el plano de datos de switches fsicos y virtuales de
los routers debe administrar el trfico de red. Coordina, media y facilita la comunicacin
entre las aplicaciones y los elementos de red.
El marco de SDN se ilustra en la Figura 2. Observe el uso de interfaces de
programacin de aplicaciones (API) dentro del marco de SDN. Una API es un conjunto
de solicitudes estandarizadas que definen la forma adecuada para que una aplicacin
solicite servicios de otra aplicacin. El controlador de SDN usa los API ascendentes
para comunicarse con las aplicaciones ascendentes. Estos administradores de red de
ayuda de API forman el trfico e implementan los servicios. El controlador de SDN
tambin 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 estndar de OpenFlow.
Nota: El trfico 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 ms informacin 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 comunicacin sea permisible segn la poltica 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 estn 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 travs de la red. Cada switch de
OpenFlow se conecta con otros switches de OpenFlow. Tambin 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 travs del switch. Para el switch, un flujo
es una secuencia de paquetes que coincide con una entrada especfica 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 mltiples que funcionan a modo de canalizacin.
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 ms 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 mayora de las
organizaciones desea automatizar la red, acelerar la implementacin 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 ms avanzadas y ms 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 solucin de hardware diseada especficamente
para la integracin de la computacin en la nube y de la administracin de centros de

datos. En un nivel alto, el elemento de polticas de la red se elimina del plano de datos.
Esto simplifica el modo en que se crean redes del centro de datos.
Para obtener ms informacin 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 ms informacin sobre los aspectos bsicos 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 polticas 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
ms complejo.
Controlador de infraestructura de polticas 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 diseado para la programabilidad y la
administracin centralizada. Traduce las polticas de las aplicaciones a la
programacin 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 fsica.
Como se muestra en la ilustracin, el APIC se ubica entre el APN y la infraestructura de

red habilitada con ACI. El APIC traduce los requisitos de aplicaciones a una
configuracin de red para cumplir con esas necesidades.

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 topologa 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 ncleo (no se muestran). En
esta topologa de dos niveles, todo est a un salto de todo lo dems.
Los APIC de Cisco y todos los dems dispositivos de la red se adjuntan fsicamente a
los switches de nodo secundario.
En comparacin con una SDN, el controlador de APIC no manipula la ruta de datos
directamente. En cambio, el APIC centraliza la definicin de polticas y programas a los
que cambia el nodo secundario para reenviar trfico segn las polticas definidas.
Para la virtualizacin, la ACI es compatible con entornos de varios proveedores de
hipervisor que se conectaran 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 poltica de aplicacin (mdulo para empresas
[APIC-EM]) de Cisco extiende la ACI destinada a la aplicacin en empresas y
campus. Para comprender mejor el APIC-EM, es til dar una mirada ms amplia a los
tres tipos de SDN.

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 trfico en la red. El controlador SDN Cisco Open es una
distribucin 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 polticas incluye una capa de polticas adicional que
funciona a un nivel de abstraccin mayor. Utiliza las aplicaciones integradas que
automatizan tareas de configuracin avanzada mediante un flujo de trabajo guiado y

una GUI fcil de usar que no requiere habilidades de programacin. 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
polticas son las ms resistentes, lo que proporciona un mecanismo simple para
controlar y administrar polticas en toda la red. Cisco APIC-EM proporciona las
siguientes funciones:
Descubrimiento: Admite una funcionalidad de deteccin 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 informacin detallada
de los dispositivos dentro de la red incluidos el nombre del dispositivo, el
estado del dispositivo, la direccin MAC, las direcciones IPv4/IPv6, el
IOS/firmware, la plataforma, el tiempo de actividad y la configuracin.
Inventario de host: Recopila informacin detallada de los hosts con la red,
que incluye el nombre del host, la identificacin del usuario, la direccin MAC,
las direcciones IPv4/IPv6 y el punto de conexin de red.
Topologa: Admite una visin grfica de la red (vista de topologa). Cisco
APIC-EM detecta automticamente y asigna dispositivos a una topologa fsica
con datos detallados de nivel del dispositivo. Adems, la visualizacin
automtica de las topologas de capa 2 y 3 sobre la topologa fsica
proporciona una vista detallada para la planificacin de diseo y la solucin de
problemas simplificada. La Figura 1 muestra un ejemplo de una vista de
topologa generada por Cisco APIC-EM.
Poltica: Capacidad de ver y polticas de control en toda la red, incluido el QoS.
Anlisis de poltica: Inspeccin y anlisis de las polticas de control de acceso
a la red. Capacidad de rastrear las rutas especficas de la aplicacin entre los
terminales para identificar rpidamente las ACL en uso y las reas
problemticas. Habilita la administracin de cambios de permisos mediante
ACL con una identificacin ms 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 ms importantes del controlador APIC-EM es la capacidad de
administrar polticas en toda la red. Las polticas operan en un nivel de abstraccin ms
alto. La configuracin de dispositivos tradicional se aplica de a un dispositivo por la vez,
mientras que las polticas de SDN se aplican a toda la red.
El anlisis y el seguimiento de ruta de APIC-EM ACL proporcionan herramientas para
permitir que el administrador analice y comprenda las polticas y las configuraciones de
las ACL. Crear nuevas ACL o editar las ACL existentes a travs de la red para
implementar una nueva poltica de seguridad puede ser desafiante. Los
administradores son reticentes a cambiar las ACL por miedo a romperlos y a causar
nuevos problemas. El anlisis y el seguimiento de ruta de las ACL permiten que el
administrador visualice fcilmente flujos de trfico y descubra las entradas de ACL
conflictivas, duplicadas o 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 anlisis de las ACL permite el examen y la
interrogacin 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 especficas 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 funcin de IOS de Cisco que permite
el anlisis de los niveles de servicio de IP. Los IP SLA generaron el trfico para medir el
rendimiento de la red entre dos dispositivos de red, ubicaciones de red mltiples, 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 informacin de rendimiento de la red en tiempo real. La
supervisin del rendimiento puede realizarse en cualquier momento, en cualquier lugar, sin
implementar una sonda fsica.
Nota: Ping y traceroute son herramientas de sondeo. Una sonda fsica es diferente. Es un
dispositivo que puede insertarse en algn lugar en la red para recopilar y monitorear el
trfico. El uso de sondas fsicas 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 solucin de problemas. Los
beneficios adicionales para utilizar los IP SLA se indican a continuacin:
Supervisin, medicin y verificacin del acuerdo de nivel de servicio.

Monitoreo de rendimiento de la red:
Mide las fluctuaciones, la latencia, o la prdida de paquetes en la red.
Proporciona las mediciones continuas, confiables y predecibles.
Evaluacin del estado de la red de servicio IP para verificar que la QoS existente es
suficiente para nuevos servicios IP.
Supervisin de contorno contra contorno de disponibilidad de red para la verificacin
de la conectividad dinmica de los recursos de red.
Las operaciones de IP SLA mltiples se pueden ejecutar en la red o en un dispositivo en

cualquier momento. Los IP SLA se pueden lograr mediante la interfaz de lnea de comandos
(CLI) o a travs del protocolo simple de administracin de redes (SNMP).
Nota: Las notificaciones de SNMP segn datos reunidos por una operacin de IP SLA estn
ms all del alcance de este curso.

15.1. CONFIGURACION DE IP SLA
UTILIZACIN DE IP SLA PARA SOLUCIN DE PROBLEMAS
En lugar de utilizar el ping manualmente, un ingeniero de redes puede utilizar la
operacin 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 operacin de eco ICMP de IP SLA proporciona
las siguientes mediciones:
Supervisin de disponibilidad (estadsticas de prdida de paquetes).

Supervisin de rendimiento (latencia y tiempo de respuesta).
Operacin de red (conectividad completa).
COMPROBACIN DE LA DISPONIBILIDAD DE LA OPERACIN DE ECO ICMP DE

IP SLA
Utilice el comando show ip sla application en el modo EXEC con privilegios para
comprobar que la operacin deseada de IP SLA est disponible en el dispositivo de
origen. La opcin de eco ICMP de IP SLA aparece como disponible en el Ejemplo 1.
PASOS Y COMANDOS UTILIZADOS PARA CONFIGURAR LA OPERACIN 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 operacin de eco ICMP de IP SLA en un
dispositivo Cisco.
Para deshabilitar la operacin de IP SLA, introduzca el comando no ip sla operationnumber en el modo de configuracin global.
CONFIGURACIN DE LA MUESTRA DE ECO ICMP DE IP SLA
En la Figura 1 se muestra la topologa de muestra que se utilizar en nuestro ejemplo
de configuracin.
El ejemplo 1 muestra la configuracin de eco ICMP de IP SLA en R1.
El comando ip sla crea una operacin IP SLA con un nmero de operacin igual a 1.
Se pueden configurar varias operaciones IP SLA en un dispositivo y se puede consultar
cada operacin mediante el nmero de operacin correspondiente.
El comando icmp-echo identifica la direccin 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 nmero de operacin 1 de IP SLA
comience inmediatamente (now) y contine hasta que se cancele manualmente
(forever).
Nota: Utilice el comando no ip sla schedule (operation-number) para cancelar la
operacin de SLA. La configuracin de la operacin de SLA se preserva y se puede
reprogramar cuando sea necesario.
VERIFICACIN DE LA CONFIGURACIN DE IP SLA
Utilice el comando show ip sla configuration [operation-number] para mostrar los
valores de configuracin, incluidos todos los valores predeterminados para las
operaciones IP SLA o para una operacin especfica. El ejemplo 3 consiste en utilizar
el comando show ip sla configuration para mostrar la configuracin 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 configuracin
VISUALIZACION DE ESTADISTICAS DE LA OPERACIN DE IP SLA
Utilice el comando show ip sla statistics [operation-number] para visualizar las
estadsticas de supervisin de la operacin de IP SLA, como se muestra en el ejemplo.
4.
El ejemplo muestra que el ltimo ping a la interfaz S1 del R3 tiene un tiempo de viaje
de ida y vuelta de 12 milisegundos. Desde que se inici la operacin, ha probado la
conectividad 57 veces sin errores.

Ccna Nuevo v6

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ccna Nuevo v6

Transféré par

Droits d'auteur :

Formats disponibles

Ing.

Jos Dennis Estela Zumaeta

INTRODUCCION A LA REDES CCNA 1

Comando traceroute extendido

El destino responde con una respuesta de eco ICMP.

Ing. Jos Dennis Estela Zumaeta

El usuario interrumpe el seguimiento con la secuencia de escape.

Nota: En IOS, puede invocar esta secuencia de escape presionando Ctrl+Mays+6. En

Aunque el comando tracert de Windows permite la entrada de varios parmetros, no es guiado

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

ENFOQUES PARA LA SOLUCIN DE PROBLEMAS BSICOS

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

PROCESOS DE SOLUCIN DE PROBLEMAS

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

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

Ing. Jos Dennis Estela Zumaeta

PROBLEMAS CON EL GATEWAY PREDETERMINADO

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

1. RUTAS DE HOST LOCALES INSTALADAS AUTOMATICAMENTE

Instalarla automticamente cuando se configura una direccin IP en el Router.

Ing. Jos Dennis Estela Zumaeta

2. RUTAS DE HOST CONFIGURADAS MANUALMENTE

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

3. DESCRIPCION GENERAL DEL CDP

Ing. Jos Dennis Estela Zumaeta

El ejemplo 3 muestra el CDP inhabilitado globalmente mediante el comando no cdp

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

3.2. DETECCIN DE DISPOSITIVOS CON CDP

Identificadores de dispositivos - El nombre de host del dispositivo vecino (S1)

Si se necesita ms informacin, el comando show cdp neighbors tambin puede

Ing. Jos Dennis Estela Zumaeta

Al tener acceso al S1 de manera remota a travs de SSH o fsicamente a travs del

Otro switch, S2, se revela en el resultado. El administrador de redes despus tiene

Ing. Jos Dennis Estela Zumaeta

El nico dispositivo conectado al S2 es el S1. Por lo tanto, no hay ms dispositivos a

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

4. DESCRIPCION GENERAL DE LLDP

Al igual que el CDP, el LLDP se puede configurar en interfaces especficas. Sin

Ing. Jos Dennis Estela Zumaeta

Mediante el comando show lldp neighbors, como se muestra en el Ejemplo 1, el

La letra B en capacidad de S2 representa un puente (Bridge). Para este resultado, la

Ing. Jos Dennis Estela Zumaeta

CONFIGURAR Y COMPROBAR LLDP

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

5. CONFIGURACION DEL RELOJ DEL SISTEMA NTP

Ing. Jos Dennis Estela Zumaeta

Ing. Jos Dennis Estela Zumaeta

Como se muestra en el Ejemplo 2, utilice el comando ntp server ip-address en el

Ing. Jos Dennis Estela Zumaeta

El reloj en el S1 est configurado para sincronizarse con el R1. El reloj en el S1 est

El ejemplo 6 muestra que el reloj en el S1 ahora est sincronizado con el R1 en

Ing. Jos Dennis Estela Zumaeta