CcnaPrimero Es

||||||||||||||||||||
Capítulo 1. Introducción al
transporte y las
aplicaciones TCP/IP
En este capítulo se tratan los siguientes temas de examen:
1.0 Fundamentos de la red

1.5 Comparar TCP con UDP
4.0 Servicios IP
4.3 Explicar el papel de DHCP y DNS en la red
El examen CCNA se centra principalmente en las

funciones de las capas inferiores de TCP/IP, que definen
cómo las redes IP pueden enviar paquetes IP de host a
host mediante LAN y WAN. Este capítulo explica los
fundamentos de algunos temas que reciben menos
atención en los exámenes: la capa de transporte TCP/IP
y la capa de aplicación TCP/IP. Las funciones de estas
capas superiores juegan un papel importante en las redes
TCP/IP reales.
Adicionalmente, muchos de los tópicos de seguridad en
las Partes I y II de este libro, y algunos de los tópicos
de servicios IP en la Parte III, requieren que conozcas
los fundamentos de cómo funcionan las capas de
transporte y aplicación de TCP/IP. Este capítulo sirve
como introducción.
||||||||||||||||||||
||||||||||||||||||||
Este capítulo comienza examinando las funciones de dos

protocolos de la capa de transporte: El Protocolo de
Control de Transmisión (TCP) y el Protocolo de
Datagramas de Usuario (UDP). La segunda sección
principal del capítulo examina la capa de aplicación
TCP/IP, incluyendo algunas discusiones sobre cómo
funciona la resolución de nombres del Sistema de
Nombres de Dominio (DNS).
"¿ESTO YA LO SÉ?" PREGUNTA

Realice el cuestionario (aquí o utilizando el software
PTP) si desea utilizar la puntuación para decidir cuánto
tiempo dedicar a este capítulo. Las respuestas a las letras
aparecen al final de la página que sigue al cuestionario.
El Apéndice C, que se encuentra tanto al final del libro
como en el sitio web complementario, incluye tanto las
respuestas como las explicaciones. También puedes
encontrar tanto las respuestas como las explicaciones en
el software de pruebas PTP.
Tabla 1-1 "¿Ya sé esto?" Asignación de secciones a

preguntas de los temas básicos
Sección de Temas Fundamentales Preguntas
Protocolos TCP/IP de capa 4: TCP y UDP 1-4
Aplicaciones TCP/IP 5-6
1. ¿Cuál de los siguientes campos de cabecera

identifica qué aplicación TCP/IP recibe los datos
del ordenador? (Elija dos respuestas.)
1. Tipo de Ethernet
2. Tipo de protocolo SNAP
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
3. Protocolo IP
4. Número de puerto TCP
5. Número de puerto UDP
2. ¿Cuáles de las siguientes son funciones típicas de

TCP? (Elija cuatro respuestas).
1. Control de flujo (windowing)
2. Recuperación de errores
3. Multiplexación mediante números de puerto
4. Enrutamiento
5. Cifrado
6. Transferencia de datos ordenada
3. ¿Cuál de las siguientes funciones realizan tanto

TCP como UDP?
1. Ventana
2. Recuperación de errores
3. Multiplexación mediante números de puerto
4. Enrutamiento
5. Cifrado
6. Transferencia de datos ordenada
4. ¿Cómo se llaman los datos que incluyen la

cabecera del protocolo de la Capa 4 y los datos
entregados a la Capa 4 por las capas superiores, sin
incluir las cabeceras y los remolques de las Capas
1 a 3? (Elija dos respuestas.)
1. L3PDU
2. Chunk
3. Segmento
4. Paquete
5. Marco
6. L4PDU
5. En la URI http://blog.certskills.com/config-labs,
¿qué parte identifica al servidor web?
1. http
||||||||||||||||||||
||||||||||||||||||||
2. blog.certskills.com
3. certskills.com
4. http://blog.certskills.com
5. El nombre del archivo.html incluye el nombre del host.
6. Fred abre un navegador web y se conecta al sitio

web www.certskills.com. ¿Cuáles de las siguientes
afirmaciones son típicamente ciertas sobre lo que
ocurre entre el navegador web de Fred y el servidor
web? (Elija dos respuestas).
1. Los mensajes que fluyen hacia el servidor utilizan el puerto de destino UDP 80.
2. Los mensajes que fluyen desde el servidor suelen utilizar RTP.
3. Los mensajes que fluyen hacia el cliente suelen utilizar un
número de puerto TCP de origen 80.
4. Los mensajes que fluyen hacia el servidor suelen utilizar TCP.
Respuestas al cuestionario "¿Lo sé ya?
1 D, E
2 A, B, C, F
3C
4 C, F
5B
6 C, D
Temas básicos
PROTOCOLOS TCP/IP DE CAPA 4: TCP Y
UDP
Technet24
||||||||||||||||||||
||||||||||||||||||||
La capa de transporte OSI (Capa 4) define varias

funciones, las más importantes de las cuales son la
recuperación de errores y el control de flujo. Del mismo
modo, los protocolos de la capa de transporte TCP/IP
también implementan estos mismos tipos de funciones.
Nótese que tanto el modelo OSI como el modelo
TCP/IP denominan a esta capa capa de transporte. Pero
como es habitual, cuando se hace referencia al modelo
TCP/IP, el nombre y el número de la capa se basan en
OSI, por lo que cualquier protocolo de capa de
transporte TCP/IP se considera protocolo de capa 4.
La diferencia clave entre TCP y UDP es que TCP

proporciona una amplia variedad de servicios a las
aplicaciones, mientras que UDP no. Por ejemplo, los
routers descartan paquetes por muchas razones, como
errores de bits, congestión y casos en los que no se
conocen rutas correctas. Como ya has leído, la mayoría
de los protocolos de enlace de datos detectan errores (un
proceso llamado detección de errores) pero luego
descartan las tramas que tienen errores. TCP proporciona
retransmisión (recuperación de errores) y ayuda a evitar
la congestión (control de flujo), mientras que UDP no lo
hace. Por ello, muchos protocolos de aplicación optan
por utilizar TCP.
Sin embargo, no dejes que la falta de servicios de UDP te

haga pensar que UDP es peor que TCP. Al ofrecer
menos servicios, UDP necesita menos bytes en su
cabecera en comparación con TCP, lo que se traduce en
menos bytes de sobrecarga en la red. El software UDP
no ralentiza la transferencia de datos en casos en los que
TCP puede ralentizarla a propósito. Además, algunas
aplicaciones, sobre todo hoy en día Voz sobre IP (VoIP)
||||||||||||||||||||
||||||||||||||||||||
y vídeo sobre IP, no necesitan recuperación de errores,

por lo que utilizan UDP. Así pues, UDP también ocupa
un lugar importante en las redes TCP/IP actuales.
La Tabla 1-2 enumera las principales características

soportadas por TCP/UDP. Tenga en cuenta que sólo el
primer elemento de la tabla es compatible con UDP,
mientras que todos los elementos de la tabla son
compatibles con TCP.
Tabla 1-2 Características de la capa de transporte TCP/IP

Función Descripción
Multiplexació Función que permite a los hosts receptores elegir

n mediante la aplicación correcta a la que se destinan los
puertos datos, basándose en el número de puerto.
Recuperació Proceso de numeración y acuse de recibo de los

n de errores datos con los campos de cabecera Sequence y
(fiabilidad) Acknowledgment.
Control de Proceso que utiliza tamaños de ventana para

flujo proteger el espacio de búfer y los dispositivos de
mediante enrutamiento de la sobrecarga de tráfico.
ventanas
Establecimient Proceso utilizado para inicializar los números de

oy puerto y los campos Secuencia y Confirmación.
finalización de
la conexión
Transferenci Flujo continuo de bytes de un proceso de capa

a ordenada y superior que se "segmenta" para su transmisión y
segmentació se entrega a procesos de capa superior en el
n de datos dispositivo receptor, con los bytes en el mismo
orden.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
A continuación, esta sección describe las características

de TCP, seguidas de una breve comparación con UDP.
Protocolo de control de transmisión

Cada aplicación TCP/IP suele elegir utilizar TCP o
UDP en función de los requisitos de la aplicación.
Por ejemplo, TCP proporciona recuperación de errores,
pero para ello consume más ancho de banda y utiliza
más ciclos de procesamiento. UDP no realiza
recuperación de errores, pero consume menos ancho de
banda y utiliza menos ciclos de procesamiento.
Independientemente de cuál de estos dos protocolos de
capa de transporte TCP/IP decida utilizar la aplicación,
debe comprender los aspectos básicos del
funcionamiento de cada uno de estos protocolos de
capa de transporte.
TCP, tal y como se define en la Request For Comments

(RFC) 793, realiza las funciones enumeradas en la Tabla
1-2 a través de mecanismos en los ordenadores finales.
TCP depende de IP para la entrega de los datos de
extremo a extremo, incluyendo cuestiones de
enrutamiento. En otras palabras, TCP realiza sólo parte
de las funciones necesarias para entregar los datos entre
aplicaciones. Además, el papel que desempeña está
dirigido a proporcionar servicios para las aplicaciones
que se encuentran en los ordenadores finales.
Independientemente de si dos ordenadores están en la
misma Ethernet o separados por toda Internet, TCP
realiza sus funciones de la misma manera.
La Figura 1-1 muestra los campos de la cabecera TCP. Aunque

||||||||||||||||||||
||||||||||||||||||||
no es necesario que memorice los nombres de los

campos ni su ubicación, el resto de esta sección hace
referencia a varios de los campos, por lo que se incluye
aquí toda la cabecera como referencia.
Figura 1-1 Campos de la cabecera TCP
El mensaje creado por TCP que comienza con la

cabecera TCP, seguida de cualquier dato de aplicación,
se denomina segmento TCP. Alternativamente, también
se puede utilizar el término más genérico de PDU de
Capa 4, o L4PDU.
Multiplexación mediante números de puerto TCP

Tanto TCP como UDP utilizan un concepto llamado
multiplexación. Por lo tanto, esta sección comienza con
una explicación de la multiplexación con TCP y UDP.
Después, se exploran las características únicas de TCP.
La multiplexación por TCP y UDP implica el proceso de

cómo piensa un ordenador cuando recibe datos. El
ordenador puede estar ejecutando muchas aplicaciones,
como un navegador web, un paquete de correo
electrónico o una aplicación VoIP de Internet (por
ejemplo, Skype). TCP y UDP
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
La multiplexación indica al ordenador receptor a qué

aplicación debe entregar los datos recibidos.
Algunos ejemplos ayudarán a hacer evidente la

necesidad de la multiplexación. La red de ejemplo
consta de dos ordenadores, Hannah y George. Hannah
utiliza una aplicación que ha escrito para enviar anuncios
que aparecen en la pantalla de George. La aplicación
envía un nuevo anuncio a George cada 10 segundos.
Hannah utiliza una segunda aplicación, una aplicación
de transferencia bancaria, para enviar dinero a George.
Por último, Hannah utiliza un navegador web para
acceder al servidor web que se ejecuta en el PC de Jorge.
La aplicación de anuncios y la aplicación de
transferencias son imaginarias, sólo para este ejemplo.
La aplicación web funciona igual que en la vida real.
La Figura 1-2 muestra la red de ejemplo, con George

ejecutando tres aplicaciones:
Una aplicación de publicidad basada en
UDP Una aplicación de transferencia
por cable basada en TCP U n a
aplicación de servidor web TCP
||||||||||||||||||||
||||||||||||||||||||
Figura 1-2 Hannah enviando paquetes a George, con

tres aplicaciones
George necesita saber a qué aplicación dar los datos,

pero los tres paquetes provienen de la misma Ethernet y
dirección IP. Podrías pensar que George podría mirar si
el paquete contiene una cabecera UDP o TCP, pero
como ves en la figura, dos aplicaciones (transferencia y
web) están usando TCP.
TCP y UDP resuelven este problema utilizando un

campo de número de puerto en la cabecera TCP o UDP,
respectivamente. Cada uno de los segmentos TCP y
UDP de Hannah utiliza un número de puerto de destino
diferente para que George sepa a qué aplicación entregar
los datos. La Figura 1-3 muestra un ejemplo.
Figura 1-3 Hannah Enviando Paquetes a George, con

Tres Aplicaciones Usando Números de Puerto para
Multiplexar
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
La multiplexación se basa en un concepto llamado

socket. Un socket consiste en tres cosas:
Una dirección IP
Un protocolo de
transporte Un
número de puerto
Así, para una aplicación de servidor web en George, el

socket sería (10.1.1.2, TCP, puerto 80) porque, por
defecto, los servidores web usan el conocido puerto 80.
Cuando el navegador web de Hannah se conecta al
servidor web, Hannah también utiliza un socket,
posiblemente uno como este: (10.1.1.1, TCP, 49160). ¿Por
qué 49160? Bueno, Hannah sólo necesita un número de
puerto que sea único en Hannah, así que Hannah ve ese
puerto 49160.
La Autoridad de Asignación de Números de Internet

(IANA), la misma organización que gestiona la
asignación de direcciones IP en todo el mundo,
subdivide los rangos de números de puerto en tres rangos
principales. Los dos primeros rangos reservan números
que IANA puede luego asignar a protocolos de
aplicación específicos mediante un proceso de solicitud
y revisión, mientras que la tercera categoría reserva
puertos que se asignan dinámicamente según se utilicen
para clientes, como ocurre con el ejemplo del puerto
49160 del párrafo anterior. Los nombres y rangos de
números de puerto (como se detalla en RFC 6335) son
Puertos conocidos (del sistema): Números del 0 al 1023,
asignados por IANA, con un proceso de revisión para asignar nuevos
puertos más estricto que el de los puertos de usuario.
Puertos de usuario (registrados): Números del 1024 al 49151,

asignados por IANA con un proceso menos estricto para asignar
||||||||||||||||||||
||||||||||||||||||||
nuevos puertos en comparación con los puertos conocidos.
||||||||||||||||||||
||||||||||||||||||||
Puertos efímeros (dinámicos, privados): Números del 49152 al

65535, no asignados y destinados a ser asignados dinámicamente
y utilizados temporalmente para una aplicación cliente mientras la
app está en ejecución.
La Figura 1-4 muestra un ejemplo que utiliza tres

puertos efímeros en el dispositivo de usuario de la
izquierda, mientras que el servidor de la derecha utiliza
dos puertos conocidos y un puerto de usuario. Los
ordenadores utilizan tres aplicaciones al mismo tiempo;
por lo tanto, hay tres conexiones de socket abiertas.
Dado que un socket en un único ordenador debe ser
único, una conexión entre dos sockets debe identificar
una conexión única entre dos ordenadores. Esta unicidad
significa que puedes utilizar varias aplicaciones al
mismo tiempo, hablando con aplicaciones que se
ejecutan en el mismo ordenador o en ordenadores
diferentes. La multiplexación, basada en sockets,
garantiza que los datos lleguen a las aplicaciones
correctas.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 1-4 Conexiones entre tomas
Los números de puerto son una parte vital del

concepto de socket. Los servidores utilizan puertos
conocidos (o puertos de usuario), mientras que los
clientes utilizan puertos dinámicos. Las aplicaciones
que proporcionan un servicio, como FTP, Telnet y
servidores web, abren un socket utilizando un puerto
conocido y escuchan las peticiones de conexión. Dado
que estas peticiones de conexión de los clientes deben
incluir tanto el número de puerto de origen como el
de destino, los números de puerto utilizados por los
servidores deben conocerse de antemano. Por lo tanto,
cada servicio utiliza un número de puerto conocido
específico o un número de puerto de usuario. Tanto los
puertos conocidos como los de usuario están listados
en www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.txt.
En las máquinas cliente, donde se originan las

peticiones, se puede asignar cualquier número de puerto
no utilizado localmente. El resultado es que cada cliente
del mismo host utiliza un número de puerto diferente,
pero un servidor utiliza el mismo número de puerto para
todas las conexiones. Por ejemplo, 100 navegadores web
en el mismo ordenador podrían conectarse a un servidor
web, pero el servidor web con 100 clientes conectados
sólo tendría un socket y, por tanto, un único número de
puerto (puerto 80, en este caso). El servidor puede saber
qué paquetes se envían desde cada uno de los 100
clientes mirando el puerto de origen de los segmentos
TCP recibidos. El servidor puede enviar datos al cliente
web correcto (navegador) enviando datos a ese mismo
||||||||||||||||||||
||||||||||||||||||||
número de puerto listado como puerto de destino. La

combinación de origen y
||||||||||||||||||||
||||||||||||||||||||
Los sockets de destino permiten a todos los hosts

participantes distinguir entre el origen y el destino de
los datos. Aunque el ejemplo explica el concepto
utilizando 100 conexiones TCP, el mismo concepto de
numeración de puertos se aplica a las sesiones UDP de
la misma manera.
Nota
Puede encontrar todas las RFC en línea en www.rfc-

editor.org/rfc/rfcxxxx.txt, donde xxxx es el número
de la RFC. Si no conoce el número de la RFC,
puede intentar buscar por tema en www.rfc-
editor.org.
Aplicaciones TCP/IP populares

A lo largo de su preparación para el examen CCNA, se
encontrará con una gran variedad de aplicaciones
TCP/IP. Debería conocer al menos algunas de las
aplicaciones que pueden utilizarse para ayudar a
gestionar y controlar una red.
La aplicación World Wide Web (WWW) existe a través

de navegadores web que acceden al contenido disponible
en servidores web. Aunque a menudo se piensa en ella
como una aplicación de usuario final, en realidad se
puede utilizar WWW para gestionar un router o switch.
Se habilita una función de servidor web en el router o
switch y se utiliza un navegador para acceder al router o
switch.
El Sistema de Nombres de Dominio (DNS) permite a los usuarios utilizar

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
para referirse a los ordenadores, y el DNS se utiliza para

encontrar las direcciones IP correspondientes. DNS
también utiliza un modelo cliente/servidor, con
servidores DNS controlados por personal de redes y
funciones de cliente DNS que forman parte de casi
cualquier dispositivo que utilice TCP/IP hoy en día. El
cliente simplemente pide al servidor DNS que le
proporcione la dirección IP que corresponde a un
nombre determinado.
El Protocolo Simple de Gestión de Red (SNMP) es un

protocolo de capa de aplicación utilizado
específicamente para la gestión de dispositivos de red.
Por ejemplo, Cisco suministra una gran variedad de
productos de gestión de redes, muchos de ellos en la
familia de productos de software de gestión de redes
Cisco Prime. Pueden utilizarse para consultar, recopilar,
almacenar y mostrar información sobre el
funcionamiento de una red. Para consultar los
dispositivos de red, el software Cisco Prime utiliza
principalmente protocolos SNMP.
Tradicionalmente, para mover archivos hacia y desde un

router o switch, Cisco utilizaba el Protocolo de
Transferencia de Archivos Trivial (TFTP). TFTP define
un protocolo para la transferencia básica de archivos, de
ahí la palabra trivial. Alternativamente, los routers y
switches pueden utilizar el Protocolo de Transferencia de
Archivos (FTP), que es un protocolo mucho más
funcional, para transferir archivos. Ambos funcionan
bien para mover archivos dentro y fuera de los
dispositivos Cisco. FTP permite muchas más funciones,
por lo que es una buena opción para la población general
de usuarios finales. Las aplicaciones cliente y servidor
||||||||||||||||||||
||||||||||||||||||||
TFTP son muy sencillas, lo que las convierte en buenas

herramientas como partes integradas de los dispositivos
de red.
Algunas de estas aplicaciones utilizan TCP y otras UDP.
||||||||||||||||||||
||||||||||||||||||||
Por ejemplo, el Protocolo Simple de Transferencia de

Correo (SMTP) y el Protocolo de Oficina de Correos
versión 3 (POP3), ambos utilizados para transferir
correo, requieren una entrega garantizada, por lo que
utilizan TCP.
Independientemente del protocolo de capa de

transporte que se utilice, las aplicaciones utilizan un
número de puerto bien conocido para que los clientes
sepan a qué puerto intentar conectarse. La Tabla 1-3
enumera varias aplicaciones populares y sus números
de puerto bien conocidos.
Tabla 1-3 Aplicaciones populares y sus números de

puerto bien conocidos
Número de puerto Protocolo Aplicación
20 TCP Datos FTP
21 TCP Control FTP
22 TCP SSH
23 TCP Telnet
25 TCP SMTP
P1
53 UDP, TC DNS
67 UDP Servidor DHCP
68 UDP Cliente DHCP
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
69 UDP TFTP
80 TCP HTTP (WWW)
110 TCP POP3
161 UDP SNMP
443 TCP SSL
514 UDP Syslog
1
DNS utiliza tanto UDP como TCP en diferentes instancias. Utiliza
el puerto 53 tanto para TCP como para UDP.
Establecimiento y finalización de la conexión

El establecimiento de la conexión TCP se produce antes
de que cualquiera de las otras funciones TCP puedan
comenzar su trabajo. El establecimiento de la conexión
se refiere al proceso de inicializar los campos de
Secuencia y Confirmación y acordar los números de
puerto utilizados. La Figura 1-5 muestra un ejemplo del
flujo de establecimiento de conexión.
Figura 1-5 Establecimiento de la conexión TCP
||||||||||||||||||||
||||||||||||||||||||
Este flujo tripartito de establecimiento de la conexión

(también llamado "handshake tripartito") debe
completarse antes de que pueda comenzar la
transferencia de datos. La conexión existe entre los dos
sockets, aunque la cabecera TCP no tiene un único
campo de socket. De las tres partes de un socket, las
direcciones IP están implícitas basándose en las
direcciones IP de origen y destino de la cabecera IP.
TCP está implícito porque se está utilizando una
cabecera TCP, tal y como especifica el valor del campo
de protocolo en la cabecera IP. Por lo tanto, las únicas
partes del socket que necesitan ser codificadas en la
cabecera TCP son los números de puerto.
El protocolo TCP señala el establecimiento de una

conexión mediante dos bits dentro de los campos de
bandera de la cabecera TCP. Denominados banderas
SYN y ACK, estos bits tienen un significado
especialmente interesante. SYN significa "sincronizar
los números de secuencia", que es un componente
necesario en la inicialización de TCP.
La Figura 1-6 muestra la terminación de una conexión

TCP. Esta secuencia de terminación de cuatro vías es
directa y utiliza una bandera adicional, llamada bit FIN.
(Una nota interesante: antes de que el dispositivo de la
derecha envíe el tercer segmento TCP de la secuencia,
notifica a la aplicación que la conexión se está cayendo.
A continuación, espera el acuse de recibo de la
aplicación antes de enviar el tercer segmento de la
figura. En caso de que la aplicación tarde un poco en
responder, el PC de la derecha envía el segundo flujo de
la figura, reconociendo que el otro PC de la derecha no
ha respondido.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
PC quiere cortar la conexión. De lo contrario, el PC de la

izquierda podría reenviar el primer segmento
repetidamente.
Figura 1-6 Terminación de la conexión TCP
TCP establece y termina conexiones entre y los puntos

finales, mientras que UDP no lo hace. Muchos
protocolos operan bajo estos mismos conceptos, por lo
que los términos orientado a conexión y sin conexión se
utilizan para referirse a la idea general de cada uno.
Más formalmente, estos términos pueden definirse de la
siguiente manera:
Protocolo orientado a la conexión: Un protocolo que

requiere un intercambio de mensajes antes de que comience
la transferencia de datos, o que tiene una correlación
preestablecida requerida entre dos puntos finales.
Protocolo sin conexión: Protocolo que no requiere un

intercambio de mensajes ni una correlación preestablecida entre
dos puntos finales.
Recuperación de errores y fiabilidad

TCP proporciona una transferencia de datos fiable, lo
que también se denomina fiabilidad o recuperación de
errores , dependiendo del documento que lea. Para
||||||||||||||||||||
||||||||||||||||||||
lograr la fiabilidad, TCP
||||||||||||||||||||
||||||||||||||||||||
numera los bytes de datos utilizando los campos

Sequence y Acknowledgment de la cabecera TCP. TCP
logra la fiabilidad en ambas direcciones, utilizando el
campo Número de secuencia de una dirección
combinado con el campo Acuse de recibo en la dirección
opuesta.
La Figura 1-7 muestra un ejemplo de cómo los campos

Secuencia TCP y Acuse de recibo permiten al PC enviar
3000 bytes de datos al servidor, con el servidor acusando
recibo de los datos. Los segmentos TCP de la figura
aparecen en orden, de arriba a abajo. Para simplificar,
todos los mensajes tienen 1000 bytes de datos en la parte
de datos del segmento TCP. El primer número de
secuencia es un bonito número redondo (1000), también
por simplicidad. La parte superior de la figura muestra
tres segmentos, en los que cada número de secuencia es
1000 más que el anterior, identificando el primero de los
1000 bytes del mensaje. (Es decir, en este ejemplo, el
primer segmento contiene los bytes 1000-1999; el
segundo, los bytes 2000- 2999; y el tercero, los bytes
3000-3999).
Figura 1-7 Confirmación TCP sin errores
El cuarto segmento TCP de la figura -el único
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
que fluye de vuelta del servidor al navegador- acusa

recibo de los tres segmentos. ¿Cómo? El valor de acuse
de recibo de 4000 significa "He recibido todos los datos
con números de secuencia hasta uno menos que 4000,
así que estoy listo para recibir tu byte 4000 a
continuación". (Tenga en cuenta que esta convención de
acusar recibo enumerando el siguiente byte esperado, en
lugar del número del último byte recibido, se denomina
forward acknowledgment).
Sin embargo, este primer ejemplo no se recupera de

ningún error; simplemente muestra los fundamentos de
cómo el host emisor utiliza el campo de número de
secuencia para identificar los datos, y el host receptor
utiliza los acuses de recibo para confirmar los datos. El
debate más interesante gira en torno a cómo utilizar estas
mismas herramientas para recuperar errores. TCP utiliza
los campos de secuencia y acuse de recibo para que el
host receptor pueda detectar datos perdidos, pedir al host
emisor que los reenvíe y, a continuación, confirmar que
los datos reenviados han llegado.
Existen muchas variaciones sobre cómo TCP realiza la

recuperación de errores. La Figura 1-8 muestra sólo uno
de estos ejemplos, con detalles similares a los de la
figura anterior. El navegador web envía de nuevo tres
segmentos TCP, de nuevo de 1000 bytes cada uno, de
nuevo con números de secuencia fáciles de recordar.
Sin embargo, en este ejemplo, el segundo segmento
TCP no consigue cruzar la red.
||||||||||||||||||||
||||||||||||||||||||
Figura 1-8 Confirmación TCP con errores
La figura señala tres conjuntos de ideas sobre cómo

piensan los dos hosts. En primer lugar, a la derecha, el
servidor se da cuenta de que no ha recibido todos los
datos. Los dos segmentos TCP recibidos contienen
bytes numerados 1000-1999 y 3000-3999. Claramente,
el servidor no recibió los bytes numerados entre ambos.
El servidor decide entonces acusar recibo de todos los
datos hasta los datos perdidos, es decir, devolver un
segmento con el campo Acknowledgment igual a 2000.
La recepción de un acuse de recibo que no confirme

todos los datos enviados hasta el momento indica al host
emisor que debe volver a enviar los datos. El PC de la
izquierda puede esperar unos instantes para asegurarse
de que no llegan otros acuses de recibo (utilizando un
temporizador llamado temporizador de retransmisión),
pero
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
pronto deciden que el servidor quiere decir "realmente

necesito el siguiente reenvío de 2000". El PC de la
izquierda así lo hace, como se muestra en el quinto de
los seis segmentos TCP de la figura.
Por último, ten en cuenta que el servidor puede acusar

recibo no sólo de los datos reenviados, sino de cualquier
dato anterior que se hubiera recibido correctamente. En
este caso, el servidor recibió el segundo segmento TCP
reenviado (los datos con números de secuencia 2000-
2999), pero el servidor ya había recibido el tercer
segmento TCP (los datos numerados 3000-3999). El
siguiente campo de acuse de recibo del servidor
reconoce los datos de ambos segmentos, con un campo
de acuse de recibo de 4000.
Control de flujo mediante ventanas

TCP implementa el control de flujo utilizando un
concepto de ventana que se aplica a la cantidad de datos
que pueden estar pendientes y a la espera de acuse de
recibo en un momento dado. El concepto de ventana
permite al host receptor indicar al emisor la cantidad de
datos que puede recibir en ese momento, lo que ofrece al
host receptor una forma de hacer que el host emisor
reduzca o acelere la velocidad. El receptor puede subir y
bajar el tamaño de la ventana -llamada ventana
deslizante o ventana dinámica- para cambiar la cantidad
de datos que puede enviar el host emisor.
El mecanismo de la ventana deslizante tiene mucho más

sentido con un ejemplo. El ejemplo, mostrado en la
Figura 1-9, utiliza las mismas reglas básicas que los
ejemplos de las figuras anteriores. En este caso, ninguno
de los segmentos TCP tiene errores, y la discusión
||||||||||||||||||||
||||||||||||||||||||
comienza un segmento TCP
||||||||||||||||||||
||||||||||||||||||||
antes que en las dos cifras anteriores.
Figura 1-9 Ventana TCP
Comienza con el primer segmento, enviado por el

servidor al PC. El campo de acuse de recibo ya debería
resultarte familiar: indica al PC que el servidor espera un
segmento con el número de secuencia 1000 a
continuación. El nuevo campo, el campo de ventana, se
establece en 3000. Dado que el segmento fluye hacia el
PC, este valor indica al PC que no puede enviar más de
3000 bytes a través de esta conexión antes de recibir un
acuse de recibo. Así, como se muestra a la izquierda, el
PC se da cuenta de que sólo puede enviar 3000 bytes, y
deja de enviar, esperando un acuse de recibo, después de
enviar tres segmentos TCP de 1000 bytes.
Siguiendo con el ejemplo, el servidor no sólo
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
acusa recibo de los datos (sin ninguna pérdida), pero el

servidor decide aumentar un poco más el tamaño de la
ventana. Observa que el segundo mensaje fluye de
derecha a izquierda en la figura, esta vez con una
ventana de 4000. Una vez que el PC recibe este
segmento TCP, se da cuenta de que puede enviar otros
4000 bytes (una ventana ligeramente mayor que el valor
anterior).
Nótese que, aunque las últimas figuras muestran

ejemplos con el propósito de explicar cómo funcionan
los mecanismos, los ejemplos pueden dar la impresión
de que TCP hace que los hosts se queden sentados
esperando acuses de recibo muchas veces.
TCP no quiere que el host emisor tenga que esperar para
enviar datos. Por ejemplo, si se recibe un acuse de recibo
antes de que se agote la ventana, comienza una nueva
ventana y el remitente continúa enviando datos hasta que
se agota la ventana actual. A menudo, en una red que
tiene pocos problemas, pocos segmentos perdidos y poca
congestión, las ventanas TCP permanecen relativamente
grandes con hosts que raramente esperan para enviar.
Protocolo de datagramas de usuario

UDP proporciona un servicio para que las aplicaciones
intercambien mensajes. A diferencia de TCP, UDP no
tiene conexión y no proporciona fiabilidad, ni ventanas,
ni reordenación de los datos recibidos, ni segmentación
de grandes trozos de datos en el tamaño adecuado para
su transmisión. Sin embargo, UDP ofrece algunas
funciones de TCP, como la transferencia de datos y la
multiplexación mediante números de puerto, y lo hace
con menos bytes de sobrecarga y menos procesamiento.
||||||||||||||||||||
||||||||||||||||||||
que TCP.
La transferencia de datos UDP difiere de la transferencia

de datos TCP en que no se realiza ninguna reordenación
o recuperación. Las aplicaciones que utilizan UDP son
tolerantes a la pérdida de datos, o disponen de algún
mecanismo de aplicación para recuperar los datos
perdidos. Por ejemplo, VoIP utiliza UDP porque si se
pierde un paquete de voz, para cuando se pueda notar la
pérdida y retransmitir el paquete, se habrá producido
demasiado retardo y la voz será ininteligible. Además,
las peticiones DNS utilizan UDP porque el usuario
reintentará una operación si falla la resolución DNS.
Como otro ejemplo, el Sistema de Archivos de Red
(NFS), una aplicación de sistema de archivos remoto,
realiza la recuperación con código de capa de aplicación,
por lo que las características de UDP son aceptables para
NFS.
La Figura 1-10 muestra el formato de la cabecera UDP.

Lo más importante es observar que la cabecera incluye
los campos de puerto de origen y destino, con el mismo
propósito que TCP. Sin embargo, la cabecera UDP tiene
sólo 8 bytes, en comparación con la cabecera TCP de 20
bytes mostrada en la Figura 1-1. UDP necesita una
cabecera más corta que TCP simplemente porque UDP
tiene menos trabajo que hacer.
Figura 1-10 Cabecera UDP
||||||||||||||||||||
||||||||||||||||||||
APLICACIONES TCP/IP
Technet24
||||||||||||||||||||
||||||||||||||||||||
El objetivo de crear una red empresarial, o de conectar

una pequeña red doméstica o de oficina a Internet, es
utilizar aplicaciones como la navegación web, los
mensajes de texto, el correo electrónico, la descarga de
archivos, la voz y el vídeo. Esta sección examina una
aplicación en particular: la navegación web mediante el
Protocolo de Transferencia de Hipertexto (HTTP).
La World Wide Web (WWW) está formada por todos

los servidores web conectados a Internet en el mundo,
además de todos los hosts conectados a Internet con
navegadores web. Los servidores web, que consisten en
software de servidor web que se ejecuta en
un ordenador, almacenan información (en forma de
páginas web) que puede ser útil para distintas personas.
Un navegador web, que es un programa informático
instalado en el ordenador de un usuario final,
proporciona los medios para conectarse a un servidor
web y visualizar las páginas web almacenadas en él.
Nota
Aunque la mayoría de la gente utiliza el término

navegador web, o simplemente navegador, los
navegadores web también se denominan clientes web,
porque obtienen un servicio de un servidor web.
Para que este proceso funcione, deben producirse varias

funciones específicas de la capa de aplicación. El
usuario debe identificar de algún modo el servidor, la
página web específica y el protocolo utilizado para
obtener los datos del servidor. El cliente debe encontrar
||||||||||||||||||||
||||||||||||||||||||
la dirección IP del servidor, basándose en la dirección

IP del servidor.
||||||||||||||||||||
||||||||||||||||||||
nombre, normalmente mediante DNS. El cliente debe

solicitar la página web, que en realidad consta de varios
archivos independientes, y el servidor debe enviar los
archivos al navegador web. Por último, para las
aplicaciones de comercio electrónico (e-commerce), la
transferencia de datos, en particular los datos financieros
sensibles, debe ser segura. Las siguientes secciones
abordan cada una de estas funciones.
Identificadores uniformes de recursos

Para que un navegador muestre una página web, debe
identificar el servidor que tiene la página web, además de
otra información que identifique la página web en
particular. La mayoría de los servidores web tienen
muchas páginas web. Por ejemplo, si utilizas un
navegador para navegar por www.cisco.com y haces clic
en esa página web, verás otra. Si vuelve a hacer clic, verá
otra página web. En cada caso, la acción de hacer clic
identifica la dirección IP del servidor, así como la página
web específica, con los detalles casi ocultos para ti. (Estos
elementos clicables en una página web, que a su vez te
llevan a otra página web, se llaman enlaces).
El usuario del navegador puede identificar una página

web cuando hace clic en algo de una página web o
cuando introduce un Identificador Uniforme de Recursos
(URI) en el área de direcciones del navegador. Ambas
opciones -hacer clic en un enlace y escribir un URI- remiten a
un URI, porque cuando se hace clic en un enlace de una
página web, ese enlace remite en realidad a un URI.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Nota
La mayoría de los navegadores admiten alguna forma

de ver el URI oculto al que hace referencia un enlace.
En varios navegadores, sitúe el puntero del ratón sobre
un enlace, haga clic con el botón derecho y seleccione
Propiedades. La ventana emergente debería mostrar
el URI al que se dirigiría el navegador si hiciera clic
en ese enlace.
En el lenguaje común, mucha gente utiliza los términos
dirección web o los términos similares relacionados
Localizador Universal de Recursos (o Localizador
Uniforme de Recursos [URL]) en lugar de URI, pero
URI es, de hecho, el término formal correcto. De hecho,
URL ha sido más comúnmente utilizado que URI
durante más de unos años. Sin embargo, el IETF (el
grupo que define TCP/IP), junto con el consorcio W3C
(W3.org, un consorcio que desarrolla estándares web) ha
realizado un esfuerzo concertado para estandarizar el uso
de URI como término general. Véase el RFC 7595 para
algunos comentarios al respecto.
Desde una perspectiva práctica, las URI utilizadas para

conectarse a un servidor web incluyen tres componentes
clave, tal y como se indica en la Figura 1-11. La figura
muestra los nombres formales de los campos URI. Más
importante para esta discusión, observe que el texto
antes de :// identifica el protocolo utilizado para
conectarse al servidor, el texto entre // y / identifica el
servidor por su nombre, y el texto después de / /
identifica el servidor por su nombre.
||||||||||||||||||||
||||||||||||||||||||
identifica la página web.
Figura 1-11 Estructura de un URI utilizado para

recuperar una página web
En este caso, el protocolo es Hypertext Transfer

Protocol (HTTP), el nombre de host es
www.certskills.com y el nombre de la página web es
blog.
Cómo encontrar el servidor web mediante DNS

Un host puede utilizar DNS para descubrir la dirección
IP que corresponde a un determinado nombre de host.
Los URI suelen indicar el nombre del servidor, un
nombre que puede utilizarse para conocer
dinámicamente la dirección IP utilizada por ese mismo
servidor. El navegador web no puede enviar un paquete
IP a un nombre de destino, pero puede enviar un paquete
a una dirección IP de destino. Por lo tanto, antes de que
el navegador pueda enviar un paquete al servidor web,
normalmente necesita resolver el nombre dentro del URI
a la dirección IP correspondiente a ese nombre.
Para aunar varios conceptos, la Figura 1-12 muestra el

proceso DNS iniciado por un navegador web, así como
otra información relacionada. A partir de una
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
perspectiva, el usuario introduce el URI (en este caso,

http://www.cisco.com/go/learningnetwork), resuelve
el nombre www.cisco.com en la dirección IP correcta y
comienza a enviar paquetes al servidor web.
Figura 1-12 Resolución DNS y Solicitud de una

Página Web
Los pasos que se muestran en la figura son los siguientes:

1. El usuario introduce el URI, http://www.cisco.com/go/learningnetwork,
||||||||||||||||||||
||||||||||||||||||||
en el área de direcciones del navegador.
2. El cliente envía una solicitud DNS al servidor DNS. Normalmente, el

cliente obtiene la dirección IP del servidor DNS a través de DHCP.
Tenga en cuenta que la solicitud DNS utiliza un encabezado UDP,
con un puerto de destino del DNS bien conocido puerto de 53.
(Véase la Tabla 1-3, anteriormente en este capítulo, para obtener
una lista de puertos conocidos populares).
3. El servidor DNS envía una respuesta, indicando la dirección IP
198.133.219.25 como dirección IP de www.cisco.com. Observa
también que la respuesta muestra una dirección IP de destino de
64.100.1.1, la dirección IP del cliente. También muestra una
cabecera UDP, con el puerto de origen 53; el puerto de origen es
53 porque los datos son originados, o enviados, por el servidor
DNS.
4. El cliente comienza el proceso de establecer una nueva conexión

TCP con el servidor web. Observe que la dirección IP de destino es
la dirección IP recién aprendida del servidor web. El paquete incluye
una cabecera TCP, porque HTTP utiliza TCP. Observa también que el
puerto TCP de destino es 80, el puerto bien conocido para HTTP. Por
último, se muestra el bit SYN, como recordatorio de que el proceso
de establecimiento de la conexión TCP comienza con un segmento
TCP con el bit SYN activado (binario 1).
El ejemplo de la Figura 1-12 muestra lo que ocurre

cuando el host cliente no conoce la dirección IP asociada
al nombre de host pero la empresa sí conoce la dirección.
Sin embargo, los hosts pueden almacenar en caché los
resultados de las peticiones DNS para que durante un
tiempo el cliente no necesite pedir al DNS que resuelva el
nombre. También, el servidor DNS puede almacenar en
caché los resultados de peticiones DNS previas; por
ejemplo, el servidor DNS de la empresa en la Figura 1-12
normalmente no habría configurado información sobre
nombres de host en dominios fuera de esa empresa, así
que ese ejemplo dependía de que el DNS hubiera
almacenado en caché la dirección asociada con el nombre
de host www.cisco.com.
||||||||||||||||||||
Cuando el DNS local no conoce la dirección asociada a
||||||||||||||||||||
un nombre de host, necesita pedir ayuda.
Technet24
||||||||||||||||||||
||||||||||||||||||||
La Figura 1-13 muestra un ejemplo con el mismo cliente

que en la Figura 1-12. En este caso, el DNS de la
empresa actúa como un servidor DNS recursivo,
enviando repetidos mensajes DNS en un esfuerzo por
identificar el servidor DNS autoritativo.
Figura 1-13 Búsqueda DNS recursiva
Los pasos que se muestran en la figura son los siguientes:

1. El cliente envía una solicitud DNS para www.cisco.com al servidor
DNS que conoce, que es el servidor DNS de la empresa.
2. El servidor DNS (recursivo) de la empresa aún no conoce la
respuesta, pero no rechaza la petición DNS del cliente. En su lugar,
sigue un proceso repetitivo (recursivo) (mostrado como pasos 2, 3
y 4), comenzando con la petición DNS enviada a un servidor DNS
raíz. La raíz tampoco proporciona la dirección, pero proporciona la
dirección IP de otro servidor DNS, uno responsable del dominio
de primer nivel .com.
3. El DNS empresarial recursivo envía la siguiente solicitud DNS al

servidor DNS aprendido en el paso anterior, esta vez el servidor DNS
de TLD para
||||||||||||||||||||
||||||||||||||||||||
el dominio .com. Este DNS tampoco conoce la dirección, pero

conoce el servidor DNS que debería ser el servidor DNS autoritativo
para el dominio cisco.com, por lo que proporciona la dirección de
ese servidor DNS.
4. El DNS de la empresa envía otra petición DNS, al servidor DNS

cuya dirección se aprendió en el paso anterior, solicitando de
nuevo la resolución del nombre www.cisco.com. Este servidor
DNS, el servidor autoritativo para cisco.com, proporciona la
dirección.
5. El servidor DNS de la empresa devuelve al cliente una respuesta
DNS con la dirección IP solicitada en el paso 1.
Transferencia de archivos con HTTP

Una vez que un cliente web (navegador) ha creado una
conexión TCP con un servidor web, el cliente puede
empezar a solicitar la página web al servidor. En la
mayoría de los casos, el protocolo utilizado para
transferir la página web es HTTP. El protocolo de capa
de aplicación HTTP, definido en el RFC 7230, define
cómo se pueden transferir archivos entre dos
ordenadores. HTTP se creó específicamente para
transferir archivos entre servidores y clientes web.
HTTP define varios comandos y respuestas, siendo la

más utilizada la petición HTTP GET. Para obtener un
archivo de un servidor web, el cliente envía una petición
HTTP GET al servidor, indicando el nombre del archivo.
Si el servidor decide enviar el archivo, el servidor envía
una respuesta HTTP GET, con un código de retorno de
200 (que significa OK), junto con el contenido del
archivo.
Nota
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Existen muchos códigos de retorno para las

peticiones HTTP. Por ejemplo, cuando el servidor
no tiene el archivo solicitado, emite un código de
retorno 404, que significa "archivo no encontrado".
La mayoría de los navegadores web no muestran los
códigos de retorno HTTP numéricos específicos,
sino que muestran una respuesta como "página no
encontrada" en reacción a la recepción de un código
de retorno 404.
Las páginas web suelen estar formadas por varios
archivos, denominados objetos. La mayoría de las
páginas web contienen texto, así como varias imágenes
gráficas, anuncios animados y, posiblemente, voz o
vídeo. Cada uno de estos componentes se almacena
como un objeto (archivo) diferente en el servidor web.
Para obtenerlos todos, el navegador web obtiene el
primer archivo. Este archivo puede (y normalmente lo
hace) incluir referencias a otros URIs, por lo que el
navegador también solicita los otros objetos. La Figura
1-14 muestra la idea general, con el navegador
obteniendo el primer fichero y luego otros dos.
||||||||||||||||||||
||||||||||||||||||||
Figura 1-14 Múltiples peticiones/respuestas

HTTP GET
En este caso, después de que el navegador web obtiene

el primer archivo -el denominado "/go/ccna" en la URI-,
el navegador lee e interpreta ese archivo. Además de
contener partes de la página web, el archivo hace
referencia a otros dos archivos, por lo que el navegador
emite dos peticiones HTTP GET adicionales. Nótese
que, aunque no se muestra en la figura, todos estos
comandos fluyen a través de una (o posiblemente más)
conexión TCP entre el cliente y el servidor. Esto
significa que TCP proporcionaría recuperación de
errores, asegurando que los datos fueran entregados.
Cómo identifica el host receptor la

aplicación receptora correcta
Este capítulo concluye con un análisis del proceso por el que
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
que un host, al recibir cualquier mensaje a través de

cualquier red, puede decidir cuál de sus muchos
programas de aplicación debe procesar los datos
recibidos.
Como ejemplo, considere el host A mostrado en la parte

izquierda de la Figura 1-15. El host tiene tres ventanas
de navegador web diferentes abiertas, cada una usando
un único puerto TCP. El host tiene tres ventanas de
navegador web abiertas, cada una usando un único
puerto TCP.
El host A también tiene abiertos un cliente de correo
electrónico y una ventana de chat, ambos utilizan TCP.
Tanto la aplicación de correo electrónico como la de
chat utilizan un único número de puerto TCP en el host
A, como se muestra en la figura.
Figura 1-15 Dilema: Cómo elige el host A la

aplicación que debe recibir estos datos
Este capítulo ha mostrado varios ejemplos de cómo los

protocolos de capa de transporte utilizan el campo del
número de puerto de destino en la cabecera TCP o
UDP para identificar la aplicación receptora. Por
ejemplo, si el valor del puerto TCP de destino en la Figura
1-15 es 49124, el host A sabrá que los datos están
||||||||||||||||||||
||||||||||||||||||||
destinados a la primera de las tres ventanas del

navegador web.
Antes de que un host receptor pueda siquiera examinar los archivos TCP o
||||||||||||||||||||
||||||||||||||||||||
UDP, y encontrar el campo de puerto de destino,

primero debe procesar las cabeceras externas del
mensaje. Si el mensaje entrante es una trama Ethernet
que encapsula un paquete IPv4, las cabeceras tienen el
aspecto detallado en la Figura 1-16.
Figura 1-16 Tres campos clave para identificar la

siguiente cabecera
El host receptor tiene que mirar varios campos, uno por

cabecera, para identificar la siguiente cabecera o campo
del mensaje recibido. Por ejemplo, el host A utiliza una
NIC Ethernet para conectarse a la red, por lo que el
mensaje recibido es una trama Ethernet. El campo Tipo
Ethernet identifica el tipo de cabecera que sigue a la
cabecera Ethernet, en este caso, con un valor de 0800
hexadecimal, una cabecera IPv4.
La cabecera IPv4 tiene un campo similar llamado campo

Protocolo IP. El campo Protocolo IPv4 tiene una lista
estándar de valores que identifican la siguiente cabecera,
con el decimal 6 utilizado para TCP y el decimal 17
utilizado para UDP. En este caso, el valor 6 identifica la
cabecera TCP que sigue a la cabecera IPv4. Una vez que
el host receptor se da cuenta de que existe una cabecera
TCP, puede procesar el campo del puerto de destino para
determinar qué proceso de aplicación local debe recibir
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
los datos.
Revisión de capítulos
Una de las claves para obtener buenos resultados en los
exámenes es realizar sesiones de repaso espaciadas y
repetitivas. Repase el material de este capítulo
utilizando las herramientas del libro o las herramientas
interactivas para el mismo material que se encuentran
en el sitio web complementario del libro. Consulte el
elemento "Su plan de estudio" para obtener más
detalles. En la Tabla 1-4 se describen los elementos
clave de repaso y dónde encontrarlos. Para hacer un
mejor seguimiento de su progreso en el estudio, registre
cuándo completó estas actividades en la segunda
columna.
Tabla 1-4 Seguimiento de la revisión de capítulos
Elemento de revisión Fecha(s) de revisión Recurso

utilizado
Repasar los temas clave Libro, página web
Repasar los términos clave Libro, página web
Repetir las preguntas DIKTA Libro, PTP
Revisar las tablas de Libro, página web

memoria
REPASAR TODOS LOS TEMAS CLAVE
Tabla 1-5 Temas clave del capítulo 1

||||||||||||||||||||
||||||||||||||||||||
Elemento Descripción Número

temático clave de página
Tabla 1-2 Funciones de TCP y UDP 6
Tabla 1-3 Números de puerto TCP y UDP 11

conocidos
Figura 1-5 Ejemplo de establecimiento de una 12

conexión TCP
Lista Definiciones de orientado a la 13

conexión y sin conexión
Figura 1-12 Resolución de nombres DNS 18
Figura 1-16 Campos de cabecera que identifican 21

la cabecera siguiente
TÉRMINOS CLAVE QUE DEBE CONOCER

establecimiento de la conexión
detección de errores
recuperación de errores
control de flujo
acuse de recibo
HTTP
transferencia de datos ordenada
Technet24
||||||||||||||||||||
||||||||||||||||||||
puerto
segmento
ventanas correderas
URI
servidor web
Servidor DNS
servidor DNS recursivo
||||||||||||||||||||
||||||||||||||||||||
Capítulo 2. Listas de control

de acceso IPv4 básicas
Listas básicas de control de
acceso IPv4
5.0 Fundamentos de seguridad

5.6 Configurar y verificar las listas de control de acceso
Las listas de control de acceso (ACL) IPv4 ofrecen a los

ingenieros de red la posibilidad de programar un filtro en
un router. Cada router, en cada interfaz, tanto para la
dirección de entrada como de salida, puede habilitar una
ACL diferente con reglas diferentes. Las reglas de cada
ACL indican al router qué paquetes debe descartar y
cuáles debe dejar pasar.
Este capítulo discute los fundamentos de las ACLs

IPv4, y en particular, un tipo de ACL IP: las ACLs IP
numeradas estándar. Las ACLs numeradas estándar
usan una lógica simple, coincidiendo sólo con el campo
de dirección IP de origen, y usan un estilo de
configuración que hace referencia a la ACL usando un
número. Este capítulo se propone ayudarte a aprender
primero este tipo más simple de ACL. El siguiente
capítulo, titulado, "Listas de Control de Acceso IPv4
Avanzadas", completa la discusión describiendo otros
tipos de ACLs IP. Los otros tipos de ACLs usan
||||||||||||||||||||
||||||||||||||||||||
características que se basan en los conceptos que

aprendiste en este capítulo, pero con más detalles.
Technet24
||||||||||||||||||||
||||||||||||||||||||
complejidad y opciones de configuración adicionales.


Conceptos básicos de la lista de control de acceso 1

IP
ACL IPv4 numeradas estándar 2-5
Práctica de aplicación de ACL IP estándar 6
1. Barney es un host con dirección IP 10.1.1.1 en la

subred 10.1.1.0/24. ¿Cuáles de las siguientes son
cosas para las que se podría configurar una ACL IP
estándar? (Elija dos respuestas).
1. Coincidir con la dirección IP de origen exacta.
2. Coincidencia de direcciones IP 10.1.1.1 a 10.1.1.4 con una lista de acceso
sin coincidir con otras direcciones IP.
3. Hacer coincidir todas las direcciones IP de la subred de Barney con una lista de acceso
sin coincidir con otras direcciones IP.
||||||||||||||||||||
||||||||||||||||||||
4. Coincide sólo con la dirección IP de destino del paquete.
2. ¿Cuál de las siguientes respuestas enumera un

número válido que se puede utilizar con ACL IP
numeradas estándar? (Elija dos respuestas).
1. 1987
2. 2187
3. 187
4. 87
3. ¿Cuál de las siguientes máscaras comodín es

más útil para hacer coincidir todos los
paquetes IP en la subred 10.1.128.0, máscara
255.255.255.0?
1. 0.0.0.0
2. 0.0.0.31
3. 0.0.0.240
4. 0.0.0.255
5. 0.0.15.0
6. 0.0.248.255
4. ¿Cuál de las siguientes máscaras comodín es

más útil para hacer coincidir todos los
paquetes IP en la subred 10.1.128.0, máscara
255.255.240.0?
1. 0.0.0.0
2. 0.0.0.31
3. 0.0.0.240
4. 0.0.0.255
5. 0.0.15.255
6. 0.0.248.255
5. ACL 1 tiene tres sentencias, en el siguiente orden,

con los siguientes valores de dirección y máscara
comodín:
1.0.0.0 0.255.255.255, 1.1.0.0 0.0.255.255, y
1.1.1.0 0.0.0.255. Si un enrutador intentara hacer
coincidir un paquete procedente de la dirección IP
||||||||||||||||||||
||||||||||||||||||||
1.1.1.1 utilizando esta ACL, que
Technet24
||||||||||||||||||||
||||||||||||||||||||
¿Considera el router que el paquete coincide con la

sentencia ACL?
1. En primer lugar
2. Segundo
3. Tercera
4. Denegación implícita al final de la ACL
6. ¿Cuál de los siguientes comandos de lista de

acceso coincide con todos los paquetes
enviados desde hosts en la subred
172.16.4.0/23?
1. access-list 1 permit 172.16.0.5 0.0.255.0
3. access-list 1 permit 172.16.5.0
1 A, C
2 A, D
3D
4 E
5A
6 B
Temas básicos
FUNDAMENTOS DE LA LISTA DE CONTROL DE ACCESO
IPV4
Las listas de control de acceso IPv4 (IP ACL) ofrecen a los ingenieros de red
||||||||||||||||||||
||||||||||||||||||||
una forma de identificar diferentes tipos de paquetes.

Para ello, la configuración ACL enumera los valores
que el router puede ver en las cabeceras IP, TCP, UDP
y otras. Por ejemplo, una ACL puede coincidir con
paquetes cuya dirección IP de origen sea 1.1.1.1, o con
paquetes cuya dirección IP de destino sea alguna
dirección de la subred 10.1.1.0/24, o con paquetes cuyo
puerto de destino sea el puerto TCP 23 (Telnet).
Las ACLs IPv4 realizan muchas funciones en los routers

Cisco, siendo el uso más común el de filtro de paquetes.
Los ingenieros pueden habilitar ACLs en un router para
que la ACL se sitúe en la ruta de reenvío de los paquetes
a medida que pasan a través del router. Una vez
habilitada, el router considera si cada paquete IP será
descartado o se le permitirá continuar como si la ACL no
existiera.
Sin embargo, las ACLs también se pueden utilizar para

muchas otras funciones de IOS. Por ejemplo, las ACL se
pueden utilizar para hacer coincidir paquetes con el fin
de aplicar funciones de calidad de servicio (QoS).
La QoS permite a un router dar un mejor servicio a
algunos paquetes y un peor servicio a otros. Por ejemplo,
los paquetes que contienen voz digitalizada deben tener
un retardo muy bajo, por lo que las ACL pueden
coincidir con los paquetes de voz, y la lógica de la QoS,
a su vez, reenvía los paquetes de voz más rápidamente
que los de datos.
Esta primera sección introduce las ACLs IP como se

usan para el filtrado de paquetes, centrándose en estos
aspectos de las ACLs: las ubicaciones y la dirección en
la que habilitar las ACLs, emparejando paquetes
||||||||||||||||||||
||||||||||||||||||||
mediante el examen de las cabeceras, y tomando acción

después de que un paquete ha sido emparejado.
Technet24
||||||||||||||||||||
||||||||||||||||||||
ACL Ubicación y dirección

Los routers Cisco pueden aplicar la lógica ACL a los
paquetes en el punto en el que los paquetes IP entran en
una interfaz, o en el punto en el que salen de una
interfaz. En otras palabras, la ACL se asocia con una
interfaz y para una dirección de flujo de paquetes (ya
sea de entrada o de salida). Es decir, la ACL puede
aplicarse en la entrada del router, antes de que el
router tome su decisión de reenvío (enrutamiento), o
en la salida, después de que el router tome su decisión
de reenvío y haya determinado la interfaz de salida a
utilizar.
Las flechas de la Figura 2-1 muestran las ubicaciones en

las que podrías filtrar los paquetes que fluyen de
izquierda a derecha en la topología.
Por ejemplo, imagina que quieres permitir los paquetes
enviados por el host A al servidor S1, pero descartar los
paquetes enviados por el host B al servidor S1. Cada
línea de flecha representa una ubicación y dirección en la
que un router podría aplicar una ACL, filtrando los
paquetes enviados por el host B.
Figura 2-1 Ubicaciones para Filtrar Paquetes desde

||||||||||||||||||||
||||||||||||||||||||
los Hosts A y B hacia el Servidor S1
||||||||||||||||||||
||||||||||||||||||||
Las cuatro líneas con flechas de la figura señalan la

ubicación y dirección de las interfaces del router
utilizadas para reenviar el paquete desde el host B al
servidor S1. En este ejemplo en particular, esas
interfaces y dirección son de entrada en la interfaz F0/0
de R1, de salida en la interfaz S0/0/0 de R1, de entrada
en la interfaz S0/0/1 de R2 y de salida en la interfaz
F0/0 de R2. Si, por ejemplo, activara una ACL en la
interfaz F0/1 de R2, en cualquier dirección, esa ACL no
podría filtrar el paquete enviado desde el host B al
servidor S1, porque la interfaz F0/1 de R2 no forma
parte de la ruta de B a S1.
En resumen, para filtrar un paquete, debe activar una

ACL en una interfaz que procese el paquete, en la
misma dirección en la que el paquete fluye a través de
esa interfaz.
Cuando se activa, el router procesa cada paquete IP

entrante o saliente utilizando esa ACL. Por ejemplo, si
se activa en el R1 para paquetes entrantes en la interfaz
F0/0, el R1 compararía cada paquete IP entrante en F0/0
con la ACL para decidir el destino de ese paquete:
continuar sin cambios o ser descartado.
Paquetes de correspondencia
Cuando piensas en la ubicación y dirección para una
ACL, ya debes estar pensando en qué paquetes planeas
filtrar (descartar), y cuáles quieres permitir que pasen.
Para decirle al router esas mismas ideas, tú
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
debe configurar el router con una ACL IP que coincida

con los paquetes. Hacer coincidir paquetes se refiere a
cómo configurar los comandos ACL para mirar cada
paquete, listando cómo identificar qué paquetes deben
ser descartados y cuáles deben ser permitidos.
Cada ACL IP consiste en uno o más comandos de

configuración, con cada comando listando detalles sobre
valores a buscar dentro de las cabeceras de un paquete.
Generalmente, un comando ACL usa lógica como
"busca estos valores en la cabecera del paquete, y si los
encuentra, descarta el paquete". (La acción podría ser
permitir el paquete, en lugar de descartarlo.)
Específicamente, la ACL busca campos de cabecera que
ya deberías conocer bien, incluyendo las direcciones IP
de origen y destino, además de los números de puerto
TCP y UDP.
Por ejemplo, considera un ejemplo con la Figura 2-2, en

el que quieres permitir paquetes del host A al servidor
S1, pero descartar paquetes del host B que van a ese
mismo servidor. Todos los hosts tienen ahora direcciones
IP, y la figura muestra el pseudocódigo para una ACL en
R2. La figura 2-2 también muestra la ubicación elegida
para activar la ACL: entrante en la interfaz S0/0/1 del
R2.
||||||||||||||||||||
||||||||||||||||||||
Figura 2-2 Pseudocódigo para demostrar la

lógica de coincidencia de comandos ACL
La Figura 2-2 muestra una ACL de dos líneas en un

rectángulo en la parte inferior, con una lógica de
coincidencia simple: ambas declaraciones sólo buscan
coincidir con la dirección IP de origen en el paquete.
Cuando está activada, el R2 mira cada paquete IP
entrante en esa interfaz y compara cada paquete con esos
dos comandos ACL. Se permite el paso de los paquetes
enviados por el host A (dirección IP de origen 10.1.1.1)
y se descartan los enviados por el host B (dirección IP de
origen 10.1.1.2).
Actuar cuando se produce una coincidencia

Cuando se usan ACLs IP para filtrar paquetes, sólo se
puede elegir una de dos acciones. Los comandos de
configuración utilizan las palabras clave deny y permit,
y significan (respectivamente) descartar el paquete o
permitir que siga adelante como si la ACL no existiera.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Este libro se centra en el uso de ACLs para filtrar

paquetes, pero IOS utiliza ACLs para muchas más
funciones. Esas características típicamente usan la
misma lógica de concordancia. Sin embargo, en otros
casos, las palabras clave deny o permit implican alguna
otra acción.
Tipos de ACL IP
Cisco IOS ha soportado ACLs IP desde los primeros
días de los routers Cisco. Comenzando con las ACLs IP
numeradas estándar originales en los primeros días de
IOS, que podían habilitar la lógica mostrada
anteriormente alrededor de la Figura 2-2, Cisco ha
añadido muchas características ACL, incluyendo las
siguientes:
ACL numeradas estándar (1-99) ACL
numeradas ampliadas (100-199)
Números ACL adicionales (1300-1999 estándar, 2000-2699

ampliado)
ACL con
nombre
Edición mejorada con números de secuencia
Este capítulo se centra únicamente en las ACLs IP

numeradas estándar, mientras que el siguiente capítulo
trata las otras tres categorías principales de ACLs IP.
Brevemente, las ACLs IP serán numeradas o nombradas en
el sentido de que la configuración identifica la ACL
usando un número o un nombre.
Las ACLs también serán estándar o extendidas,
teniendo las ACLs extendidas capacidades mucho más
robustas para emparejar paquetes. La Figura 2-3 resume
||||||||||||||||||||
||||||||||||||||||||
las grandes ideas relacionadas con las categorías de

ACLs IP .
||||||||||||||||||||
||||||||||||||||||||
Figura 2-3 Comparación de los tipos de ACL IP
ESTÁNDAR NUMERADO IPV4 ACLS

El título de esta sección sirve como una gran
introducción, si puedes decodificar lo que Cisco quiere
decir con cada palabra específica. Esta sección trata
sobre un tipo de filtro de Cisco (ACL) que sólo coincide
con la dirección IP de origen del paquete (estándar),
está configurado para identificar la ACL utilizando
números en lugar de nombres (numerado), y mira
paquetes IPv4.
Esta sección examina las particularidades de las ACLs

IP numeradas estándar. Primero, examina la idea de
que una ACL es una lista y que lógica usa esa lista. A
continuación,
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
el texto examina detenidamente cómo hacer coincidir el

campo de dirección IP de origen en la cabecera del
paquete, incluida la sintaxis de los comandos. Esta
sección termina con una mirada completa a los
comandos de configuración y verificación para
implementar ACLs estándar.
Lógica de listas con ACL IP

Una ACL es tanto una entidad única como, al mismo
tiempo, una lista de uno o más comandos de
configuración. Como entidad única, la configuración
habilita toda la ACL en una interfaz, en una dirección
específica, como se muestra anteriormente en la Figura
2-1. Como lista de comandos, cada comando tiene una
lógica de coincidencia diferente que el router debe
aplicar a cada paquete cuando filtra usando esa ACL.
Al procesar la ACL, el router procesa el paquete,

comparándolo con la ACL, de la siguiente manera:
Las ACLs utilizan la lógica de la primera

coincidencia. Una vez que un paquete coincide con
una línea de la ACL, el router toma la acción indicada
en esa línea de la ACL y deja de buscar más en la
ACL.
Para ver exactamente lo que esto significa, considere el

ejemplo construido alrededor de la Figura 2-4. La
figura muestra un ejemplo de ACL 1 con tres líneas de
pseudocódigo. Este ejemplo aplica la ACL 1 en la
interfaz S0/0/1 de R2, entrante (la misma ubicación que
en la anterior Figura 2-2).
||||||||||||||||||||
||||||||||||||||||||
Figura 2-4 Antecedentes para el debate sobre el

proceso de listas con ACL IP
Considere la lógica ACL de primera coincidencia para

un paquete enviado por el host A al servidor S1. La
dirección IP de origen será 10.1.1.1, y se enrutará de forma
que entre en la interfaz S0/0/1 de R2, activando la lógica
ACL 1 de R2. R2 compara este paquete con la ACL,
haciendo coincidir el primer elemento de la lista con una
acción de permiso. Por lo tanto, este paquete debe ser
permitido, como se muestra en la Figura 2-5, a la
izquierda.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 2-5 Comparación de elementos ACL para

paquetes de los hosts A, B y C de la Figura 2-4
A continuación, consideremos un paquete enviado por el host B, dirección IP

de origen
10.1.1.2. Cuando el paquete entra en la interfaz S0/0/1
de R2, R2 compara el paquete con la primera sentencia
de ACL 1 y no encuentra ninguna coincidencia
(10.1.1.1 no es igual a 10.1.1.2). R2 pasa entonces a la
segunda declaración, que requiere algunas
aclaraciones. El pseudocódigo de la ACL, en la figura
2-4, muestra 10.1.1.x, lo que significa que en el último
octeto puede haber cualquier valor. Comparando sólo
los tres primeros octetos, el R2 decide que este último
paquete tiene una dirección IP de origen que empieza
con los tres primeros octetos 10.1.1, por lo que el R2
considera que coincide con la segunda sentencia. El R2
realiza la acción indicada (denegar) y descarta el
paquete. El R2 también detiene el procesamiento de la
ACL en el paquete, ignorando la tercera línea de la
ACL.
Por último, consideremos un paquete enviado por el host

C, de nuevo al servidor S1. El paquete tiene la dirección
IP de origen 10.3.3.3, así que cuando entra en la interfaz
S0/0/1 del R2 y activa el procesamiento ACL en el R2,
éste mira el primer comando en ACL 1. El R2 no
coincide con el primer comando ACL (10.1.1.1 en el
comando no es igual a 10.3.3.3 del paquete). R2 mira el
segundo comando, compara los tres primeros octetos
(10.1.1) con la dirección IP de origen del paquete
(10.3.3) y sigue sin encontrar coincidencias. A
continuación, R2 examina el tercer comando. En este
caso, el comodín significa ignorar los tres últimos
||||||||||||||||||||
||||||||||||||||||||
octetos y comparar sólo el primer octeto (10), por lo que

el paquete coincide. R2 realiza entonces la acción
indicada (permitir),
||||||||||||||||||||
||||||||||||||||||||
permitiendo que el paquete siga avanzando.
Esta secuencia de procesamiento de una ACL como lista

ocurre para cualquier tipo de ACL de IOS: IP, otros
protocolos, estándar o extendida, con nombre o
numerada.
Por último, si un paquete no coincide con ninguno de los

elementos de la ACL, el paquete se descarta. La razón
es que cada ACL IP tiene una sentencia deny all
implícita al final de la ACL. No existe en la
configuración, pero si un router sigue buscando en la
lista, y no hay ninguna coincidencia al final de la lista,
IOS considera que el paquete ha coincidido con una
entrada que tiene una acción deny.
Lógica de concordancia y sintaxis

de comandos
Las ACL IP numeradas estándar utilizan el siguiente
comando global:
Haga clic aquí para ver la imagen del código
access-list {1-99 | 1300-1999} {permit | deny} matching-parameters

{permit | deny} matching-parameters
Cada ACL numerada estándar tiene uno o más

comandos de lista de acceso con el mismo número,
cualquier número de los rangos mostrados en la línea
precedente de sintaxis. (Un número no es mejor que el
otro.) IOS se refiere a cada línea de una ACL como una
Entrada de Control de Acceso (ACE), pero muchos
ingenieros simplemente las llaman sentencias ACL.
Además del número de ACL, cada comando de lista de

acceso también enumera la acción (permitir o
||||||||||||||||||||
||||||||||||||||||||
denegar), además de las coincidencias
Technet24
||||||||||||||||||||
||||||||||||||||||||
lógica. El resto de esta sección examina cómo

configurar los parámetros de coincidencia, lo que, para
las ACL estándar, significa que sólo puede coincidir
con la dirección IP de origen o partes de la dirección
IP de origen utilizando algo llamado máscara comodín
ACL.
Coincidencia de la dirección IP exacta

Para que coincida con una dirección IP de origen
específica, la dirección IP completa, todo lo que tienes
que hacer es escribir esa dirección IP al final del
comando. Por ejemplo, el ejemplo anterior utiliza
pseudocódigo para "permit if source = 10.1.1.1". El
siguiente comando configura esa lógica con la sintaxis
correcta utilizando la ACL número 1:
access-list 1 permit 10.1.1.1
Coincidir con la dirección IP completa exacta es así de sencillo.
En versiones anteriores de IOS, la sintaxis incluía una

palabra clave de host. En lugar de escribir simplemente
la dirección IP completa, primero se escribía la palabra
clave host y luego la dirección IP. Ten en cuenta que en
versiones posteriores de IOS, si utilizas la palabra clave
host, IOS acepta el comando pero luego elimina la
palabra clave.
access-list 1 permit host 10.1.1.1
Coincidencia de un subconjunto de la dirección con comodines

A menudo, los objetivos empresariales que se quieren implantar con un
||||||||||||||||||||
||||||||||||||||||||
Las ACL no coinciden con una única dirección IP

concreta, sino con un rango de direcciones IP. Tal vez
quiera hacer coincidir todas las direcciones IP de una
subred. Puede que quieras que coincidan todas las
direcciones IP de un rango de subredes. En cualquier
caso, quieres comprobar más de una dirección IP en un
rango de direcciones.
IOS permite que las ACL estándar coincidan con un

rango de direcciones utilizando una herramienta llamada
máscara comodín . Tenga en cuenta que esto no es una
máscara de subred. La máscara comodín (que este libro
abrevia como máscara WC) le da al ingeniero una
manera de decirle a IOS que ignore partes de la
dirección cuando hace comparaciones, esencialmente
tratando esas partes como comodines, como si ya
coincidieran.
Puedes pensar en las máscaras WC en decimal y en

binario, y ambas tienen su utilidad. Para empezar, piensa
en las máscaras WC en decimal, utilizando estas reglas:
Decimal 0: El router debe comparar este octeto de

forma normal.
Decimal 255: El router ignora este octeto,

considerándolo ya coincidente.
Teniendo en cuenta estas dos reglas, considere la

Figura 2-6, que demuestra esta lógica utilizando tres
máscaras WC diferentes pero populares: una que le dice
al enrutador que ignore el último octeto, otra que le
dice al enrutador que ignore los dos últimos octetos y
otra que le dice al enrutador que ignore el último
||||||||||||||||||||
||||||||||||||||||||
octeto.
Technet24
||||||||||||||||||||
||||||||||||||||||||
tres octetos.
Figura 2-6 Lógica para las máscaras WC 0.0.0.255,

0.0.255.255 y 0.255.255.255
Los tres ejemplos en los recuadros de la Figura 2-6

muestran dos números que son claramente diferentes.
La máscara WC hace que IOS compare sólo algunos de
los octetos, ignorando otros octetos. Los tres ejemplos
resultan en una coincidencia, porque cada máscara
comodín le dice a IOS que ignore algunos octetos. El
ejemplo de la izquierda muestra la máscara WC
0.0.0.255, que le dice al router que trate el último octeto
como un comodín, esencialmente ignorando ese octeto
para la comparación. De forma similar, el ejemplo del
medio muestra la máscara WC 0.0.255.255, que indica
al router que ignore los dos octetos de la derecha. El
caso más a la derecha muestra la máscara WC
0.255.255.255, que le dice al router que ignore los tres
últimos octetos al comparar valores.
Para ver la máscara WC en acción, piense en el ejemplo

anterior relacionado con la Figura 2-4 y la Figura 2-5.
El pseudocódigo ACL en esas dos figuras usaba lógica
que puede crearse usando la máscara WC. El
pseudocódigo ACL en esas dos figuras usaba lógica
que puede ser creada usando una máscara WC. Como
||||||||||||||||||||
||||||||||||||||||||
recordatorio, la lógica en el pseudocódigo ACL en esas

dos figuras incluía el comando
||||||||||||||||||||
||||||||||||||||||||
siguiente:
Línea 1: Coincidir y permitir todos los paquetes con

una dirección de origen exactamente 10.1.1.1.
Línea 2: Coincidir y denegar todos los paquetes con

direcciones de origen con los tres primeros octetos
10.1.1.
Línea 3: Concuerda y permite todas las direcciones

con el primer octeto 10.
La Figura 2-7 muestra la versión actualizada de la Figura

2-4, pero con la sintaxis completa y correcta, incluyendo
las máscaras WC. En particular, observe el uso de la
máscara WC 0.0.0.255 en el segundo comando, que le
dice a R2 que ignore el último octeto del número
10.1.1.0, y la máscara WC 0.255.255.255 en el tercer
comando, que le dice a R2 que ignore los últimos tres
octetos del valor 10.0.0.0.
Figura 2-7 ACL sintácticamente correcta sustituye al

pseudocódigo de la Figura 2-4
Por último, tenga en cuenta que cuando se utiliza una

máscara WC, el parámetro de origen del comando
access- list, definido de forma imprecisa, debe
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
ser un 0 en cualquier octeto donde la máscara WC sea un

255. IOS especificará una dirección de origen que será 0
para las partes que serán ignoradas, incluso si se
configuraron valores distintos de cero.
Máscaras comodín binarias

Las máscaras comodín, como valores numéricos
decimales punteados (DDN), representan en realidad un
número binario de 32 bits. Como número de 32 bits, la
máscara WC en realidad dirige la lógica del enrutador
bit a bit. En resumen, un bit de máscara WC de 0
significa que la comparación debe hacerse de forma
normal, pero un 1 binario significa que el bit es un
comodín y puede ignorarse al comparar los números.
Afortunadamente, para los propósitos de estudio

CCNA, y para la mayoría de las aplicaciones del mundo
real, puede ignorar la máscara binaria WC. ¿Por qué?
Bueno, generalmente queremos coincidir con un rango
de direcciones que pueden ser fácilmente identificadas
por un número de subred y máscara, ya sea una subred
real, o una ruta de resumen que agrupa subredes. Si
puedes describir el rango de direcciones con un número
de subred y una máscara, puedes encontrar los números
a usar en tu ACL con unas simples matemáticas
decimales, como se discute a continuación.
Nota
Si realmente desea conocer la lógica de la máscara

binaria, tome los dos números DDN que comparará la
ACL (uno del comando access-list y el otro de
||||||||||||||||||||
||||||||||||||||||||
la cabecera del paquete) y convierte ambas a binario.

A continuación, convierte también la máscara WC a
binario. Compara los dos primeros números binarios
bit a bit, pero ignora también cualquier bit para el
que la máscara WC muestre un 1 binario, porque eso
te dice que ignores el bit. Si todos los bits que has
comprobado son iguales, ¡coinciden!
Cómo encontrar la máscara comodín adecuada para una subred

En muchos casos, una ACL debe coincidir con todos
los hosts de una subred concreta. Para hacer coincidir
una subred con una ACL, puede utilizar el siguiente
método abreviado:
Utilice el número de subred como valor de origen en la lista de acceso

mando.
Utilice una máscara comodín que se obtiene restando la máscara de

subred de 255.255.255.255.
Por ejemplo, para la subred 172.16.8.0 255.255.252.0,

utilice el número de subred (172.16.8.0) como
parámetro de dirección y, a continuación, realice los
siguientes cálculos matemáticos para encontrar la
máscara comodín:
255.255.255.255
- 255.255.252.0
0. 0. 3.255
Continuando con este ejemplo, un comando completado

para esta misma subred sería el siguiente:
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
access-list 1 permit 172.16.8.0 0.0.3.255
La sección "Practicar la aplicación de ACLs IP estándar" le

da la oportunidad de practicar la correspondencia de
subredes al configurar ACLs.
Coincidencia de todas/algunas direcciones

En algunos casos, querrá que un comando ACL
coincida con todos y cada uno de los paquetes que
lleguen a ese punto en la ACL. Primero, debe conocer
la forma (simple) de hacer coincidir todos los paquetes
usando la palabra clave any. Y lo que es más
importante, tiene que pensar cuándo hacer coincidir
todos y cada uno de los paquetes.
En primer lugar, para que coincidan todos y cada uno de

los paquetes con un comando ACL, basta con utilizar la
palabra clave any para la dirección. Por ejemplo, para
permitir todos los paquetes:
access-list 1 permit any
Entonces, ¿cuándo y dónde deberías usar un comando

de este tipo? Recuerda, todas las ACLs IP de Cisco
terminan con un concepto implícito deny any al final
de cada ACL. Es decir, si un router compara un paquete
con la ACL, y el paquete no coincide con ninguna de
las sentencias configuradas, el router descarta el
paquete. ¿Quiere anular ese comportamiento por
defecto?
Configure un permit any al final de la ACL.
También es posible que desee configurar explícitamente

un comando para denegar todo el tráfico (por ejemplo,
||||||||||||||||||||
||||||||||||||||||||
access-list 1 deny any) al final de una ACL. ¿Por qué,

cuando la misma lógica ya
||||||||||||||||||||
||||||||||||||||||||
al final de la ACL? Bueno, los comandos show de la

ACL listan contadores para el número de paquetes
coincidentes por cada comando en la ACL, pero no hay
contador para ese concepto implícito de deny any al
final de la ACL. Así que, si quieres ver los contadores
de cuántos paquetes coinciden con la lógica deny any al
final de la ACL, configura un deny any explícito.
Implementación de ACL IP estándar

Este capítulo ya ha introducido todos los pasos de
configuración por partes. Esta sección resume esas
piezas como un proceso de configuración. El proceso
también se refiere al comando access-list, cuya sintaxis
genérica se repite aquí como referencia:
access-list access-list-number {deny | permit} source [source-wildc
Paso 1. Planifique la ubicación (enrutador e

interfaz) y la dirección (entrada o salida) en
esa interfaz:
A. Las ACL estándar deben colocarse cerca
del destino de los paquetes para que no
descarten involuntariamente paquetes que
no deberían descartarse.
B. Dado que las ACL estándar sólo pueden
coincidir con la dirección IP de origen
de un paquete, identifique la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
direcciones IP de origen de los paquetes

cuando van en la dirección que la ACL
está examinando.
Paso 2. Configure uno o más comandos de
configuración global access-list para crear
la ACL, teniendo en cuenta lo siguiente:
A. La lista se busca secuencialmente,
utilizando la lógica de primera
coincidencia.
B. La acción por defecto, si un paquete no
coincide con ninguno de los comandos de
la lista de acceso, es denegar (descartar)
el paquete.
Paso 3. Habilite la ACL en la interfaz del router
elegida, en la dirección correcta, utilizando el
subcomando de interfaz ip access-group
number {in | out}.
El resto de esta sección muestra un par de ejemplos.
ACL numerada estándar Ejemplo 1

El primer ejemplo muestra la configuración para los
mismos requisitos demostrados con la Figura 2-4 y
Figura 2-5. En otras palabras, los requisitos de esta
ACL son los siguientes:
1. Active la ACL de entrada en la interfaz S0/0/1 de R2.
2. Permitir paquetes procedentes del host A.
3. Denegar paquetes procedentes de otros hosts de la subred del host A.

4. Permitir paquetes procedentes de cualquier otra dirección de la
red de clase A 10.0.0.0.
5. El ejemplo original no comentaba qué hacer por defecto, así que

simplemente deniega el resto del tráfico.
||||||||||||||||||||
||||||||||||||||||||
El Ejemplo 2-1 muestra una configuración correcta

completa, comenzando con el proceso de
configuración, seguido por la salida del comando show
running-config.
Ejemplo 2-1 Configuración de ACL numeradas

estándar Ejemplo 1
R2# configurar terminal

Introduzca los comandos de configuración, uno por línea. Termine
con CNTL/Z. R2(config)# access-list 1 permit 10.1.1.1
R2(config)# access-list 1 deny 10.1.1.0 0.0.0.255
R2(config)# access-list 1 permit 10.0.0.0 0.255.255.255
R2(config)# interfaz S0/0/1
R2(config-if)# ip access-group 1
in R2(config-if)# ^Z
R2# show running-config
¡! Líneas omitidas en aras de la brevedad

access-list 1 deny 10.1.1.0 0.0.0.255
Primero, presta mucha atención al proceso de

configuración en la parte superior del ejemplo. Observa
que el comando access-list no cambia el prompt del
comando desde el prompt del modo de configuración
global, porque el comando access-list es un comando de
configuración global. Luego, compara eso con la salida
del comando show running-config: los detalles son
idénticos comparados con los comandos que fueron
agregados en el modo de configuración. Por último,
asegúrese de observar el comando ip access-group 1 in,
en la interfaz S0/0/1 de R2, que habilita la lógica de
ACL (tanto la ubicación como la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
dirección).
El Ejemplo 2-2 lista alguna salida del Router R2 que

muestra información sobre esta ACL. El comando
show ip access-lists muestra detalles sobre ACLs
IPv4
mientras que el comando show access-lists muestra
detalles sobre las ACLs IPv4 más cualquier otro tipo de
ACL que esté configurado; por ejemplo, ACLs IPv6.
Ejemplo 2-2 Comandos ACL show en R2
R2# show ip access-lists

Lista de acceso IP estándar 1
10 permit 10.1.1.1 (107 coincidencias)
20 deny10 .1.1.0, bits comodín 0.0.0.255 (4 coincidencias)
30 permit 10.0.0.0, wildcard bits 0.255.255.255 (10 matches)
R2# show access-lists
10 permit 10.1.1.1 (107 coincidencias)
20 deny10 .1.1.0, bits comodín 0.0.0.255 (4 coincidencias)
30 permit 10.0.0.0, wildcard bits 0.255.255.255 (10 matches)
R2# show ip interface s0/0/1
La dirección de Internet es 10.1.2.2/24
La dirección de difusión es
255.255.255.255 Dirección determinada
por el comando setup La MTU es 1500
bytes
La dirección del ayudante no está configurada
El reenvío de difusión dirigido está
desactivado Grupos reservados multidifusión
unidos: 224.0.0.9
La lista de acceso saliente no está configurada
La lista de acceso entrante es 1
La salida de estos comandos muestra dos elementos

importantes. En este caso, la primera línea de salida
indica el tipo (estándar) y el número. Si existiera más
de una ACL, vería varias estrofas de salida, una
||||||||||||||||||||
||||||||||||||||||||
por ACL, cada uno con una línea de encabezado como

ésta. A continuación, estos comandos listan los recuentos
de paquetes para el número de paquetes que el router ha
emparejado con cada comando. Por ejemplo, 107
paquetes hasta ahora han coincidido con la primera línea
de la ACL.
Finalmente, al final del ejemplo se muestra la salida del

comando show ip interface. Este comando lista, entre
muchos otros elementos, el número o nombre de
cualquier ACL IP habilitada en la interfaz por el
subcomando ip access-group interface.
ACL numerada estándar Ejemplo 2

Para el segundo ejemplo, utiliza la Figura 2-8 e imagina
que tu jefe te da algunos requisitos apresuradamente en
el pasillo. Al principio, te dice que quiere filtrar los
paquetes que van desde los servidores de la derecha
hacia los clientes de la izquierda. Luego, te dice que
quiere que permitas el acceso de los hosts A, B y otros
hosts de su misma subred al servidor S1, pero que
deniegues el acceso a ese servidor a los hosts de la
subred del host C. A continuación, te dice que, además, a
los hosts de la subred del host A se les debe denegar el
acceso al servidor S2, pero a los hosts de la subred del
host C se les debe permitir el acceso al servidor S2, todo
ello filtrando sólo los paquetes que van de derecha a
izquierda. Luego te dice que pongas la ACL de entrada
en la interfaz F0/0 de R2.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 2-8 Ejemplo 2 de ACL numerada estándar
Si se repasan todos los comentarios del jefe, los

requisitos podrían reducirse a lo siguiente:
1. Active la ACL de entrada en la interfaz F0/0 de R2.
2. Permitir paquetes desde el servidor S1 hacia hosts en la subred de A.
3. Denegar paquetes del servidor S1 que vayan a hosts de la subred de C.

4. Permitir paquetes desde el servidor S2 que van a hosts en la subred de C.
5. Denegar paquetes del servidor S2 que vayan a hosts de la subred de A.

6. (No se ha comentado qué hacer por defecto; utilice la opción implícita
denegar todo por defecto).
Resulta que no puedes hacer todo lo que te pide tu jefe

con una ACL estándar. Por ejemplo, considere el
comando obvio para el requisito número 2: access-list
2 permit 10.2.2.1. Eso permite todo el tráfico cuya IP
de origen sea 10.2.2.1 (servidor S1). Esto permite todo
el tráfico cuya IP de origen sea 10.2.2.1 (servidor S1).
El siguiente requisito le pide que filtre (deniegue) los
paquetes procedentes de esa misma dirección IP.
Incluso si añadiera otro comando que comprobara la
dirección IP de origen 10.2.2.1, el router nunca llegaría
a ella, porque los routers utilizan la lógica de primera
coincidencia cuando buscan en la ACL. No se puede
comprobar tanto la dirección IP de destino como la de
origen, porque el estándar
||||||||||||||||||||
||||||||||||||||||||
Las ACL no pueden comprobar la dirección IP de destino.
Para resolver este problema, ¡deberías buscarte un

nuevo jefe! No, en serio, tienes que replantearte el
problema y cambiar las reglas. En la vida real,
probablemente utilizarías en su lugar una ACL
extendida, que te permite comprobar tanto la dirección
IP de origen como la de destino.
Para practicar otra ACL estándar, imagine que su jefe le

permite cambiar los requisitos. Primero, usará dos
ACLs de salida, ambas en el Router R1. Cada ACL
permitirá que el tráfico de un único servidor sea
reenviado a esa LAN conectada, con los siguientes
requisitos modificados:
1. Utilizando una ACL de salida en la interfaz F0/0 de R1, permita los
paquetes del servidor S1 y deniegue todos los demás paquetes.
2. Utilizando una ACL de salida en la interfaz F0/1 de R1, permita los
paquetes del servidor S2 y deniegue todos los demás paquetes.
El ejemplo 2-3 muestra la configuración que completa

estos requisitos.
Ejemplo 2-3 Configuración Alternativa en el Router R1
access-list 2 remark Esta ACL permite el tráfico del servidor S1

al host A access-list 2 permit 10.2.2.1
¡!
al host C access-list 3 permit 10.2.2.2
¡!
interfaz F0/0
ip access-group 2 out
¡!
interfaz F0/1
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Como se destaca en el ejemplo, la solución con la ACL

número 2 permite todo el tráfico del servidor S1, con
esa lógica activada para los paquetes que salen de la
interfaz F0/0 de R1. El resto del tráfico será descartado
debido a la denegación implícita de todo al final de la
ACL. Además, la ACL 3 permite el tráfico desde el
servidor S2, que a su vez puede salir por la interfaz F0/1
de R1. Además, observe que la solución muestra el uso
del parámetro access-list remark, que le permite dejar
documentación de texto que permanece con la ACL.
Nota
Cuando los routers aplican una ACL para filtrar

paquetes en la dirección de salida, como se muestra
en el Ejemplo 2-3, el router comprueba los paquetes
que enruta contra la ACL. Sin embargo, un router no
filtra paquetes que el mismo router crea con una
ACL saliente. Ejemplos de esos paquetes incluyen
mensajes de protocolo de enrutamiento y paquetes
enviados por los comandos ping y traceroute en ese
enrutador.
Solución de problemas y consejos de verificación

La resolución de problemas de ACL IPv4 requiere
cierta atención a los detalles. En particular, tienes que
estar preparado para mirar la dirección y la máscara
comodín y predecir con confianza las direcciones que
coinciden con esos dos parámetros combinados.
||||||||||||||||||||
||||||||||||||||||||
Los problemas de práctica que aparecen un poco más

adelante en este capítulo pueden ayudarte a prepararte
para esa parte del trabajo. Pero algunos otros consejos
pueden ayudarle a verificar y solucionar problemas de
ACL en los exámenes también.
Primero, puedes saber si el router está emparejando

paquetes o no con un par de herramientas. El ejemplo 2-
2 ya mostró que IOS mantiene estadísticas sobre los
paquetes coincidentes con cada línea de una ACL.
Además, si añade la palabra clave log al final de un
comando access-list, IOS emite mensajes de registro con
estadísticas ocasionales sobre las coincidencias de esa
línea particular de la ACL. Tanto las estadísticas como
los mensajes de registro pueden ser útiles para decidir
con qué línea de la ACL coincide un paquete.
Por ejemplo, el Ejemplo 2-4 muestra una versión

actualizada de la ACL 2 del Ejemplo 2-3, esta vez con la
palabra clave log añadida. La parte inferior del ejemplo
muestra un mensaje de registro típico, este mostrando la
coincidencia resultante basada en un paquete con
dirección IP de origen 10.2.2.1 (como coincide con la
ACL), a la dirección de destino 10.1.1.1.
Ejemplo 2-4 Creación de mensajes de registro para estadísticas ACL
||||||||||||||||||||
||||||||||||||||||||
R1# show running-config

! líneas eliminadas por brevedad
al host A access-list 2 permit 10.2.2.1 log
¡!
interfaz F0/0
R1#
Feb 4 18:30:24.082: %SEC-6-IPACCESSLOGNP: lista 2 permitido 0
10.2
paquete
Technet24
||||||||||||||||||||
||||||||||||||||||||
Cuando solucione un problema de ACL por primera

vez, antes de entrar en los detalles de la lógica de
coincidencia, tómese su tiempo para pensar tanto en la
interfaz en la que está habilitada la ACL como en la
dirección del flujo de paquetes. A veces, la lógica de
coincidencia es perfecta, pero la ACL se ha activado en
la interfaz incorrecta, o para la dirección incorrecta,
para que coincida con los paquetes configurados para
la ACL.
Por ejemplo, la Figura 2-9 repite la misma ACL

mostrada anteriormente en la Figura 2-7. La primera
línea de esa ACL coincide con la dirección de host
específica 10.1.1.1. La primera línea de esa ACL
coincide con la dirección de host específica 10.1.1.1. Si
esa ACL existe en el Router R2, colocar esa ACL como
una ACL de entrada en la interfaz S0/0/1 del R2 puede
funcionar, porque los paquetes enviados por el host
10.1.1.1-en el lado izquierdo de la figura-pueden entrar
en la interfaz S0/0/1 del R2. Sin embargo, si R2 activa
la ACL 1 en su interfaz F0/0, para los paquetes
entrantes, la ACL nunca coincidirá con un paquete con
la dirección IP de origen 10.1.1.1, porque los paquetes
enviados por el host 10.1.1.1 nunca entrarán en esa
interfaz. Los paquetes enviados por 10.1.1.1 saldrán de
la interfaz F0/0 de R2, pero nunca entrarán en ella,
simplemente debido a la topología de la red.
||||||||||||||||||||
||||||||||||||||||||
Figura 2-9 Ejemplo de comprobación de la interfaz

y la dirección de una ACL
PRÁCTICA DE APLICACIÓN DE LA NORMA IP ACLS

Algunos temas CCNA, como las ACL, simplemente
requieren más ejercicios y práctica que otros. Las ACL
requieren que pienses en parámetros que coincidan con
rangos de números, y eso, por supuesto, requiere cierto
uso de las matemáticas y cierto uso de los procesos.
Esta sección proporciona algunos problemas de práctica

y consejos, desde dos perspectivas. Primero, esta sección
te pide que construyas ACLs estándar de una línea para
coincidir con algunos paquetes. En segundo lugar, esta
sección le pide que interprete comandos ACL existentes
para describir qué paquetes coincidirán con la ACL.
Ambas habilidades son útiles para los exámenes.
Práctica de creación de comandos

access-list
En esta sección, practica para sentirte cómodo con el
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
sintaxis del comando access-list, particularmente con la

elección de la lógica de coincidencia correcta. Estas
habilidades serán útiles cuando leas sobre ACLs
extendidas y con nombre en el próximo capítulo.
En primer lugar, la siguiente lista resume algunos

consejos importantes a tener en cuenta a la hora de
elegir parámetros coincidentes con cualquier comando
access-list:
Para buscar una dirección concreta, basta con indicarla.
Para que coincidan todas y cada una de las direcciones, utilice la palabra clave any.
Para obtener coincidencias basadas sólo en los primeros uno, dos o

tres octetos de una dirección, utilice los códigos 0.255.255.255,
0.0.255.255 y 0.0.0.255 WC.
respectivamente. Además, haga que el parámetro de origen
(dirección) tenga 0s en los octetos comodín (aquellos octetos con
255 en la máscara comodín).
Para que coincida con una subred, utilice el ID de subred como

origen y encuentre la máscara WC restando la máscara de subred
DDN de 255.255.255.255.
La Tabla 2-2 enumera los criterios de varios problemas

de práctica. Su tarea: Crear una ACL estándar de una
línea que coincida con los paquetes. Las respuestas
están listadas en la sección "Respuestas a Problemas de
Práctica Anteriores," más adelante en este capítulo.
Tabla 2-2 Creación de ACL estándar de una línea:

Práctica
Problema Criterios
1 Paquetes desde 172.16.5.4
||||||||||||||||||||
||||||||||||||||||||
2 Paquetes de hosts con 192.168.6 como los tres

primeros octetos
3 Paquetes de hosts con 192.168 como los dos primeros

octetos
4 Paquetes de cualquier host
5 Paquetes de la subred 10.1.200.0/21
Ingeniería inversa de ACL a rango de

direcciones
En algunos casos, puede que no estés creando tu
propia ACL. En su lugar, puede que necesites
interpretar algunos comandos access-list existentes.
Para responder a este tipo de
en los exámenes, deberá determinar el intervalo de
direcciones IP con el que coincide una determinada
combinación de dirección/máscara comodín en cada
sentencia ACL.
Bajo ciertas suposiciones que son razonables para las

certificaciones CCNA, calcular el rango de direcciones
emparejadas por una ACL puede ser relativamente
simple. Básicamente, el rango
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
de direcciones comienza con la dirección configurada en

el comando ACL. El rango de direcciones termina con la
suma del campo de dirección y la máscara comodín. Eso
es todo.
Por ejemplo, con el comando access-list 1 permit

172.16.200.0 0.0.7.255, el extremo inferior del rango
es simplemente 172.16.200.0, tomado directamente del
propio comando. Entonces, para encontrar el extremo
alto del rango, simplemente añade este número a la
máscara WC, como sigue:
172.16.200.0
+ 0. 0. 7.255
172.16.207.255
Para esta última práctica, mira los comandos de lista de

acceso existentes en la Tabla 2-3. En cada caso, anota
la dirección IP exacta o el rango de direcciones IP que
coincide con el comando. En cada caso, anota la
dirección IP exacta, o rango de direcciones IP, que
coincide con el comando.
Tabla 2-3 Búsqueda de direcciones IP/rangos

coincidentes con ACL existentes
ProblemaComandos para los que predecir el rango de direcciones
de origen
1 access-list 1 permit 10.7.6.5
2 access-list 2 permit 192.168.4.0 0.0.0.127
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Curiosamente, IOS permite al usuario CLI escribir un

comando access-list en modo configuración, e IOS
cambiará potencialmente el parámetro de dirección
antes de colocar el comando en el archivo running-
config. Este proceso de sólo encontrar el rango de
direcciones emparejadas por el comando access-list
espera que el comando access-list provenga del router,
de modo que cualquier cambio de este tipo haya sido
completado.
El cambio que IOS puede hacer con un comando access-

list es convertir a 0 cualquier octeto de una dirección
para la cual el octeto de la máscara comodín es 255. Por
ejemplo, con una máscara comodín de 0.0.255.255, IOS
ignora los dos últimos octetos. Por ejemplo, con una
máscara comodín de 0.0.255.255, IOS ignora los dos
últimos octetos. IOS espera que el campo de dirección
termine con dos 0s. Si no es así, IOS sigue aceptando el
comando access-list, pero cambia los dos últimos
octetos de la dirección a 0s.
El Ejemplo 2-5 muestra un ejemplo, donde la
configuración muestra la dirección 10.1.1.1, pero la
máscara comodín 0.0.255.255.
Ejemplo 2-5 IOS Cambiando el Campo de Dirección en un

Comando access-list
||||||||||||||||||||
||||||||||||||||||||

con CNTL/Z.
Technet24
||||||||||||||||||||
||||||||||||||||||||
R2(config)# access-list 21 permit 10.1.1.1 0.0.255.255

R2(config)# ^Z
R2#
R2# show ip access-lists
10 permit 10.1.0.0, bits comodín 0.0.255.255
La matemática para encontrar el rango de direcciones se

basa en el hecho de que o bien el comando es totalmente
correcto o que IOS ya ha establecido estos octetos de
dirección a 0, como se muestra en el ejemplo.
Nota
Las máscaras WC más útiles, en binario, no

intercalan 0s y 1s. Este libro asume el uso de sólo
este tipo de máscaras WC. Sin embargo, Cisco IOS
permite máscaras WC que intercalan 0s y 1s, pero el
uso de estas máscaras WC rompe el método simple
de calcular el rango de direcciones. A medida que
avances en los estudios CCIE, prepárate para
profundizar en el aprendizaje de cómo determinar
qué coincide con una ACL.
Una de las claves para salir bien en los exámenes es
realizar sesiones de repaso espaciadas y repetitivas.
Repase el material de este capítulo utilizando las
herramientas del libro o las herramientas interactivas
para el mismo material que se encuentran en la página
web del libro
||||||||||||||||||||
||||||||||||||||||||
página web complementaria. Consulte el elemento "Su

plan de estudios" para obtener más detalles. En la Tabla
2-4 se describen los elementos clave del examen y
dónde puede encontrarlos. Para hacer un mejor
seguimiento de su progreso en el estudio, anote cuándo
completó estas actividades en la segunda columna.

utilizado
Revisar las tablas de Reserve

comandos

Clave Descripción Página

Tema Número
Elemento
Párrafo Resumen de la regla general de 27

ubicación y dirección de una ACL
Figura 2-3 Resumen de las cuatro categorías 29

principales de ACL IPv4 en Cisco IOS
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Párrafo Resumen de la lógica de primera 29

coincidencia utilizada por todas las ACL
Lista Lógica de máscara comodín para 32

decimales 0 y 255
Lista Lógica de máscara comodín para coincidir 33

con una subred
Lista Pasos para planificar e implantar una 34

ACL IP estándar
Lista Consejos para crear una lógica de 39

concordancia para el campo de
dirección de origen en el comando
access-list

lista de acceso estándar
máscara comodín
PRÁCTICA ADICIONAL PARA LOS

PROCESOS DE ESTE CAPÍTULO
Para practicar más el análisis de subredes, puede realizar
el mismo conjunto de problemas de práctica utilizando
las herramientas que prefiera:
Aplicación: Utilice las dos aplicaciones de ejercicios

prácticos ACL que figuran en el sitio web
complementario.
PDF: Alternativamente, practique los mismos

problemas que se encuentran en estas aplicaciones
utilizando el Apéndice E en línea, "Práctica para el
Capítulo 2: Listas básicas de control de acceso IPv4".
||||||||||||||||||||
||||||||||||||||||||
REFERENCIAS DE COMANDOS
Las tablas 2-6 y 2-7 enumeran los comandos de
configuración y verificación utilizados en este capítulo.
Como ejercicio fácil de repaso, cubra la columna
izquierda de una tabla, lea la columna derecha e intente
recordar el comando sin mirar. Luego repita el ejercicio,
cubriendo la columna derecha, y trate de recordar lo que
hace el comando.
Tabla 2-6 Capítulo 2 Referencia de comandos de

configuración
Comando Descripción
access-list access-list- Comando global para listas de acceso

number {deny | permit} numeradas estándar. Utilice un número
source [source-wildcard] comprendido entre 1 y 99 o entre 1300
[log] y 1999, ambos inclusive.
access-list access-list- Comando que define una observación

number remark text para ayudarle a recordar lo que se
supone que debe hacer la ACL.
ip access-group number Subcomando de interfaz para

{in | out} activar las listas de acceso.
Tabla 2-7 Capítulo 2 Referencia de comandos EXEC
show ip interface [número de Incluye una referencia a

tipo] las listas de acceso
habilitadas en la interfaz
show access-lists [número de Muestra detalles de las listas de

lista de acceso | nombre de acceso configuradas para todos
lista de acceso] los protocolos
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
show ip access-lists [access- Muestra las listas de acceso IP

list-number | access-list-name]
RESPUESTAS A PROBLEMAS PRÁCTICOS

ANTERIORES
La Tabla 2-8 enumera las respuestas a los problemas
enumerados anteriormente en la Tabla 2-2.
Tabla 2-8 Creación de ACL estándar de una línea:

Respuestas
Problema Respuestas
1 access-list 1 permit 172.16.5.4
4 access-list 4 permit any
||||||||||||||||||||
||||||||||||||||||||
La Tabla 2-9 enumera las respuestas a los problemas

enumerados anteriormente en la Tabla 2-3.
Tabla 2-9 Rangos de direcciones para los problemas

de la Tabla 2- 3: Respuestas
Problema Direcciones
1 Una dirección: 10.7.6.5
2 192.168.4.0 - 192.168.4.127
3 192.168.6.0 - 192.168.6.31
4 172.30.96.0 - 172.30.99.255
5 172.30.96.0 - 172.30.96.63
6 10.1.192.0 - 10.1.192.31
7 10.1.192.0 - 10.1.193.255
8 10.1.192.0 - 10.1.255.255
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 3. Listas de control

de acceso IPv4 avanzadas
Listas de control de acceso
IPv4 avanzadas

5.6 Configurar y verificar las listas de control de acceso
Las ACL IPv4 son ACL estándar o ACL extendidas,

siendo las ACL estándar las que coinciden sólo con la
dirección IP de origen, y las extendidas las que coinciden
con diversos campos de la cabecera del paquete. Al
mismo tiempo, las ACLs IP pueden ser numeradas o
con nombre. La Figura 3-1 muestra las categorías y las
características principales de cada una, tal y como se
han introducido en el capítulo anterior.
||||||||||||||||||||
||||||||||||||||||||
Figura 3-1 Comparación de los tipos de ACL IP
Este capítulo discute las otras tres categorías de ACLs

más allá de las ACLs IP numeradas estándar y termina
con algunas características misceláneas para asegurar los
routers y switches Cisco.

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||

Listas de control de acceso IP ampliadas 1-3
ACL con nombre y edición de ACL 4-6
1. ¿Cuál de los siguientes campos no se puede

comparar basándose en una ACL IP extendida?
(Elija dos respuestas).
1. Protocolo
2. Dirección IP de origen
3. Dirección IP de destino
4. Byte TOS
5. URL
6. Nombre de archivo para transferencias FTP
2. ¿Cuál de los siguientes comandos de lista de

acceso permite los paquetes que van desde el
host 10.1.1.1 a todos los servidores web cuyas
direcciones IP empiecen por 172.16.5? (Elija
dos respuestas.)
1. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255
eq www
2. access-list 1951 permit ip host 10.1.1.1 172.16.5.0
0.0.0.255 eq www
3. access-list 2523 permit ip host 10.1.1.1 eq www 172.16.5.0
0.0.0.255
4. access-list 2523 permit tcp host 10.1.1.1 eq www 172.16.5.0
0.0.0.255
5. access-list 2523 permit tcp host 10.1.1.1 172.16.5.0
0.0.0.255 eq www
||||||||||||||||||||
||||||||||||||||||||
3. ¿Cuál de los siguientes comandos access-list

permite paquetes que van a cualquier cliente web
desde todos los servidores web cuyas direcciones IP
comienzan con 172.16.5?
1. access-list 101 permit tcp host 10.1.1.1 172.16.5.0 0.0.0.255
eq www
2. access-list 1951 permit ip host 10.1.1.1 172.16.5.0
0.0.0.255 eq www
3. access-list 2523 permit tcp any eq www 172.16.5.0
0.0.0.255
4. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq www
172.16.5.0 0.0.0.255
5. access-list 2523 permit tcp 172.16.5.0 0.0.0.255 eq
www any
4. En un router que ejecuta una versión reciente de

IOS (al menos la versión 15.0), un ingeniero
necesita eliminar la segunda línea en ACL 101, que
actualmente tiene cuatro comandos configurados.
¿Cuál de las siguientes opciones se podría utilizar?
1. Elimine toda la ACL y vuelva a configurar las tres sentencias
ACL que deben permanecer en la ACL.
2. Elimine una línea de la ACL mediante el comando global no
access-list....
3. Elimine una línea de la ACL entrando en el modo de configuración
ACL para la ACL y, a continuación, eliminando sólo la segunda
línea en función de su número de secuencia.
4. Elimine las tres últimas líneas de la ACL desde el modo de
configuración global y, a continuación, vuelva a añadir las dos
últimas declaraciones a la ACL.
5. Consulte la siguiente salida de comando, que detalla

una ACL habilitada en el puerto G0/0 para la
dirección de entrada. ¿Qué respuestas enumeran un
modo de configuración y un comando que
resultarían en la eliminación de la línea que coincide
con la subred 172.16.1.0/24? (Elija dos
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
respuestas).
show ip access-lists dikta-list

Lista de acceso IP estándar dikta-list
1. En modo de configuración global: no 10

2. En el modo de configuración de la interfaz G0/0: no 10
3. En el modo de configuración ACL dikta-list: no 10
4. En el modo de configuración ACL dikta-list: no permit 172.16.1.0 0.0.0.255
5. En modo de configuración global: no permit 172.16.1.0 0.0.0.255
6. Un ingeniero configura una ACL pero olvida

guardar la configuración. En ese momento, ¿cuál de
los siguientes comandos muestra la configuración
de una ACL IPv4, incluidos los números de línea?
1. show running-config
2. mostrar configuración de inicio
3. mostrar listas de acceso ip
4. mostrar listas de acceso
1 E, F
2 A, E
3E
4 A, C
5 C, D
||||||||||||||||||||
||||||||||||||||||||
6 C, D
Temas básicos
LISTAS DE CONTROL DE ACCESO IP
NUMERADAS AMPLIADAS
Las listas de acceso IP extendidas tienen muchas
similitudes comparadas con las ACLs IP numeradas
estándar discutidas en el capítulo anterior. Al igual que
las ACLs IP estándar, usted habilita las listas de acceso
extendidas en las interfaces para los paquetes que entran
o salen de la interfaz. IOS busca en la lista
secuencialmente. Las ACLs extendidas también utilizan
la lógica de primera coincidencia, porque el router
detiene la búsqueda a través de la lista tan pronto como
la primera sentencia coincide, tomando la acción
definida en la primera sentencia coincidente. Todas estas
características también son válidas para las listas de
acceso numeradas estándar (y las ACL con nombre).
Las ACLs extendidas difieren de las ACLs estándar

principalmente por la mayor variedad de campos de
cabecera de paquete que pueden ser usados para
coincidir con un paquete. Una ACE extendida (sentencia
ACL) puede examinar múltiples partes de las cabeceras
de los paquetes, requiriendo que todos los parámetros
coincidan correctamente para coincidir con esa ACE.
Esta potente lógica hace que las listas de acceso
extendidas sean más útiles y complejas que las ACL IP
estándar.
Coincidencia de protocolo, IP de origen y

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
IP de destino
Al igual que las ACLs IP numeradas estándar, las
ACLs IP numeradas extendidas también utilizan el
comando global access-list. La sintaxis es idéntica, al
menos hasta la palabra clave permit o deny. En ese
punto, el comando lista los parámetros de
coincidencia, y estos difieren, por supuesto. En
particular, el comando access-list de ACL extendida
requiere tres parámetros de coincidencia: el tipo de
protocolo IP, la dirección IP de origen y la dirección
IP de destino.
El campo Protocolo de la cabecera IP identifica la

cabecera que sigue a la cabecera IP. La Figura 3-2
muestra la ubicación del campo Protocolo IP, el
concepto de que apunta al tipo de cabecera que le sigue,
junto con algunos detalles de la cabecera IP como
referencia.
Figura 3-2 Cabecera IP, con especial atención a

los campos obligatorios en ACLs IP extendidas
IOS requiere que configures parámetros para las tres

partes resaltadas de la Figura 3-2. Para el tipo de
protocolo, simplemente se utiliza una palabra clave,
como tcp, udp o icmp, que coincide con los paquetes IP
que tienen un protocolo TCP, UDP o icmp.
||||||||||||||||||||
||||||||||||||||||||
ICMP, respectivamente, a continuación de la cabecera

IP. O puede usar la palabra clave ip, que significa
"todos los paquetes IPv4". También debe configurar
algunos valores para los campos de dirección IP de
origen y destino que siguen; estos campos usan la
misma sintaxis y opciones para emparejar las
direcciones IP como se discutió en el Capítulo 2, "Listas
Básicas de Control de Acceso IPv4." La Figura 3-3 muestra
la sintaxis.
Figura 3-3 Sintaxis ACL ampliada, con campos

obligatorios
Nota
Al buscar direcciones IP en los campos de origen y

destino, hay una diferencia con las ACL estándar:
Cuando se busca una dirección IP específica, la ACL
ampliada requiere el uso del host
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
palabra clave. No puede limitarse a enumerar

únicamente la dirección IP.
La Tabla 3-2 lista varios ejemplos de comandos access-
list que usan sólo los parámetros de coincidencia
requeridos. Siéntete libre de cubrir el lado derecho y usar
la tabla para un ejercicio, o simplemente revisa las
explicaciones para tener una idea de la lógica en algunos
comandos de ejemplo.
Tabla 3-2 Comandos de lista de acceso ampliada y

explicaciones lógicas
lista de acceso Declaración de

coincidencia
access-list 101 Cualquier paquete IP que tenga una cabecera

deny tcp any any TCP

deny udp any UDP
any

deny icmp any ICMP
any
access-list 101 Todos los paquetes IP del host 1.1.1.1 que

deny ip host van al host 2.2.2.2, independientemente de
1.1.1.1 anfitrión la cabecera después de la cabecera IP
2.2.2.2
lista de acceso Todos los paquetes IP que tienen una

101 cabecera UDP a continuación de la cabecera
deny udp 1.1.1.0 IP, desde la subred 1.1.1.0/24 y que van a
0.0.0.255 cualquier destino.
cualquiera
||||||||||||||||||||
||||||||||||||||||||
La última entrada en la Tabla 3-2 ayuda a hacer un

punto importante sobre cómo IOS procesa ACLs
extendidas:
En un comando de lista de acceso ACL extendida,

todos los parámetros coincidentes deben coincidir
con el paquete para que el paquete coincida con el
comando.
Por ejemplo, en el último ejemplo de la Tabla 3-2, el

comando comprueba UDP, una dirección IP de
origen de la subred 1.1.1.0/24, y cualquier dirección
IP de destino. Si se examinara un paquete con la
dirección IP de origen 1.1.1.1, coincidiría con la
comprobación de la dirección IP de origen, pero si
tuviera una cabecera TCP en lugar de UDP, no
coincidiría con este comando access-list. Todos los
parámetros deben coincidir.
Correspondencia de números de puerto TCP y UDP

Las ACL ampliadas también pueden examinar partes de
las cabeceras TCP y UDP, en particular los campos de
número de puerto de origen y destino. Los números de
puerto identifican la aplicación que envía o recibe los
datos.
Los puertos más útiles para comprobar son los puertos

bien conocidos utilizados por los servidores. Por
ejemplo, los servidores web utilizan por defecto el
conocido puerto 80. La Figura 3-4 muestra la ubicación
de los números de puerto en la cabecera TCP, a
continuación de la cabecera IP.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 3-4 Cabecera IP, seguida de una cabecera

TCP y campos de número de puerto
Cuando un comando ACL extendido incluye la palabra

clave tcp o udp, ese comando puede hacer referencia
opcionalmente al puerto de origen y/o destino. Para
realizar estas comparaciones, la sintaxis utiliza palabras
clave para igual, no igual, menor que, mayor que y para
un rango de números de puerto. Además, el comando
puede utilizar los números de puerto decimales literales
o palabras clave más convenientes para algunos puertos
de aplicación bien conocidos. La Figura 3-5 muestra las
posiciones de los campos de puerto de origen y destino
en el comando access-list y estas palabras clave de
número de puerto.
||||||||||||||||||||
||||||||||||||||||||
Figura 3-5 Sintaxis de ACL ampliada con

números de puerto TCP y UDP activados
Por ejemplo, considere la red simple mostrada en la

Figura 3-6. El servidor FTP se sitúa a la derecha, con el
cliente a la izquierda. El servidor FTP se sitúa a la
derecha, con el cliente a la izquierda. La figura muestra
la sintaxis de una ACL que coincide con lo siguiente:
Paquetes que incluyen una cabecera TCP
Paquetes enviados desde la subred
cliente Paquetes enviados a la subred
servidor
Paquetes con puerto de destino TCP 21 (puerto de control del servidor FTP)
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 3-6 Filtrado de paquetes según el puerto de

destino
Para apreciar plenamente la coincidencia del puerto

de destino con los parámetros eq 21, considere los
paquetes que se mueven de izquierda a derecha, desde
PC1 al servidor. Asumiendo que el servidor utiliza el
conocido puerto 21 (puerto de control FTP), la cabecera
TCP del paquete tiene un valor de puerto de destino de
21. La sintaxis ACL incluye los parámetros eq 21
después de la dirección IP de destino. La sintaxis ACL
incluye los parámetros eq 21 después de la dirección
IP de destino. La posición después de los parámetros de
dirección de destino es importante: esa posición
identifica el hecho de que los parámetros eq 21 deben
compararse con el puerto de destino del paquete. Como
resultado, la sentencia ACL mostrada en la Figura 3-6
coincidiría con este paquete y el puerto de destino de
21 si se utiliza en cualquiera de las cuatro ubicaciones
implicadas por las cuatro líneas de flecha discontinuas
en la figura.
Por el contrario, la Figura 3-7 muestra el flujo inverso,

con un paquete enviado por el servidor de vuelta hacia
PC1. En este caso, la cabecera TCP del paquete tiene un
puerto de origen de 21, por lo que la ACL debe
comprobar el valor del puerto de origen de 21, y la ACL
debe estar ubicada en diferentes interfaces. En este caso,
los parámetros eq 21 siguen al campo de dirección de
origen pero vienen antes del campo de dirección de
destino.
||||||||||||||||||||
||||||||||||||||||||
Figura 3-7 Filtrado de paquetes según el puerto de origen
Cuando examine ACLs que coinciden con números de

puerto, primero considere la ubicación y dirección en la
que se aplicará la ACL. Esa dirección determina si el
paquete se está enviando al servidor o desde el servidor.
En ese momento, puede decidir si necesita comprobar el
puerto de origen o de destino en el paquete. Como
referencia, la Tabla 3-3 lista muchos de los números de
puerto más populares y sus protocolos de capa de
transporte y aplicaciones. Tenga en cuenta que la
sintaxis de los comandos access-list acepta tanto los
números de puerto como una versión abreviada del
nombre de la aplicación.
Tabla 3-3 Aplicaciones populares y sus números de

puerto bien conocidos
Número(s) Protocolo Aplicación palabra

de puerto clave del
comando
access-list
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
20 TCP Datos FTP datos ftp
21 TCP Control FTP ftp
22 TCP SSH -
23 TCP Telnet telnet
25 TCP SMTP smtp
53 UDP, DNS dominio

TCP
67 UDP Servidor DHCP arranque
68 UDP Cliente DHCP bootpc
69 UDP TFTP tftp
80 TCP HTTP www

(WWW)
110 TCP POP3 pop3
161 UDP SNMP snmp
443 TCP SSL -
514 UDP Syslog -
16,384- UDP RTP (voz, -

32,767 vídeo)
La Tabla 3-4 enumera varios ejemplos de comandos

access-list que coinciden en función de los números de
puerto. Cubra el lado derecho
||||||||||||||||||||
||||||||||||||||||||
de la tabla, e intenta caracterizar los paquetes

emparejados por cada comando. A continuación,
comprueba la parte derecha de la tabla para ver si estás
de acuerdo con la evaluación.
Tabla 3-4 Ejemplos de comandos y explicaciones

lógicas de Extended access-list
lista de acceso Declaración de

coincidencia
access-list 101 Paquetes con una cabecera TCP, cualquier

deny tcp any dirección IP de origen, con un puerto de origen
gt 49151 host mayor que (gt) 49151, una dirección IP de
10.1.1.1 ec 23 destino de exactamente 10.1.1.1, y un puerto de
destino igual a (eq) 23.
access-list 101 Igual que en el ejemplo anterior, pero coincide

deny tcp any cualquier puerto de origen, ya que en este caso
host 10.1.1.1 se omite ese parámetro.
eq 23
access-list 101 Igual que en el ejemplo anterior. La opción telnet

deny tcp any en lugar del puerto 23.
host 10.1.1.1
eq telnet
access-list 101 Un paquete con un origen en la red 1.0.0.0/8,

deny udp utilizando UDP con un puerto de origen inferior a
1.0.0.0 (lt) 1023, con cualquier dirección IP de destino.
0.255.255.255
lt 1023
cualquier
Configuración de ACL IP extendida

Dado que las ACL ampliadas pueden coincidir con
tantos campos diferentes en las distintas cabeceras de
un paquete IP, la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
no puede resumirse fácilmente en un único comando

genérico. Sin embargo, los dos comandos de la Tabla 3-5
resumen las opciones de sintaxis tal y como se tratan en
este libro.
Tabla 3-5 Comandos de configuración de la lista de

acceso IP ampliada
Comando Modo de
configuración y
descripción
access-list access-list-number {deny Comando global para

| permit} protocol source source- listas de acceso
wildcard destination destination- numeradas extendidas.
wildcard [log | log-input] Utilice un número entre
100 y 199 o 2000 y
2699,
inclusive.
access-list access-list-number {deny Una versión del

| permit} {tcp | udp} source source- comando access- list con
comodín [operador [puerto]] parámetros específicos
destination destination- comodín para TCP y/o UDP.
[operador [puerto]] [establecido]
[log]
El proceso de configuración de las ACL extendidas

coincide en su mayor parte con el utilizado para las ACL
estándar. Debe elegir la ubicación y la dirección en la
que habilitar la ACL, especialmente la dirección, para
poder caracterizar si determinadas direcciones y puertos
serán el origen o el destino. Configure la ACL utilizando
los comandos access-list y, cuando haya terminado,
habilite la ACL utilizando el mismo comando ip access-
group que se utiliza con las ACL estándar. Todos estos
pasos
||||||||||||||||||||
||||||||||||||||||||
reflejan lo que se hace con las ACL estándar; sin

embargo, al configurarlas, tenga en cuenta las
siguientes diferencias:
Coloque las ACL extendidas lo más cerca posible del origen de los
paquetes que se van a filtrar. Filtrar cerca del origen de los paquetes
ahorra algo de ancho de banda.
Recuerda que todos los campos de un comando access-list deben

coincidir con un paquete para que se considere que el paquete
coincide con esa sentencia access-list.
Utilice los números 100-199 y 2000-2699 en la lista de acceso

comandos; ningún número es intrínsecamente mejor que otro.
Listas de Acceso IP Extendidas: Ejemplo 1

Este ejemplo se centra en la comprensión de la sintaxis
básica. En este caso, la ACL le niega a Bob el acceso a
todos los servidores FTP en la Ethernet de R1, y le niega
a Larry el acceso al servidor web de Server1. La Figura
3-8 muestra la topología de la red; el Ejemplo 3-1
muestra la configuración en R1.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 3-8 Diagrama de red para el ejemplo 1 de

lista de acceso ampliada
Ejemplo 3-1 Lista de Acceso Extendida de R1: Ejemplo 1
Haga clic aquí para ver la

imagen del código
interfaz Serial0
dirección ip 172.16.12.1 255.255.255.0
ip access-group 101 en
¡!
interfaz Serial1
dirección ip 172.16.13.1 255.255.255.0
¡!
access-list 101 remark Stop Bob to FTP servers, and Larry to
Serv access-list 101 deny tcp host 172.16.3.10 172.16.1.0
0.0.0.255 eq access-list 101 deny tcp host 172.16.2.10 host
172.16.1.100 eq ww access-list 101 permit ip any any
La primera sentencia ACL impide el acceso de Bob a

los servidores FTP de la subred 172.16.1.0. La segunda
sentencia impide el acceso de Larry a los servicios web
del Servidor1. La segunda sentencia impide el acceso de
Larry a los servicios web del Servidor1. La dirección
||||||||||||||||||||
||||||||||||||||||||
La declaración final permite el resto del tráfico.
Si nos centramos en la sintaxis por un momento,

podemos ver varios elementos nuevos a revisar. En
primer lugar, el número de lista de acceso para las listas
de acceso extendidas se encuentra en el rango de 100 a
199 o 2000 a 2699. Después de la acción permitir o
denegar, el parámetro protocolo define si quieres
comprobar todos los paquetes IP o cabeceras específicas,
como las cabeceras TCP o UDP. Cuando compruebe los
números de puerto TCP o UDP, debe especificar el
protocolo TCP o UDP.
Tanto el FTP como la Web utilizan TCP.
Este ejemplo utiliza el parámetro eq, que significa

"igual", para comprobar los números de puerto de
destino para el control FTP (palabra clave ftp) y el
tráfico HTTP (palabra clave www). Puede utilizar los
valores numéricos-o, para las opciones más populares,
es válida una versión de texto más obvia. (Si escribiera
eq 80, la configuración mostraría eq www).
Este ejemplo habilita la ACL en dos lugares en R1:

entrante en cada interfaz serie. Estas ubicaciones logran
el objetivo de la ACL. Sin embargo, esa ubicación
inicial fue hecha para hacer el punto de que Cisco
sugiere que las ubique lo más cerca posible de la fuente
del paquete. Por lo tanto, el Ejemplo 3-2 logra el mismo
objetivo que el Ejemplo 3-1 de detener el acceso de Bob
a los servidores FTP en el sitio principal, y lo hace con
una ACL en R3.
Ejemplo 3-2 Lista de Acceso Extendida de R3

Impidiendo a Bob Alcanzar Servidores FTP Cercanos a
R1
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
interfaz Ethernet0
dirección ip 172.16.3.1 255.255.255.0
access-list 103 remark deny Bob to FTP servers in subnet

172.16.1 access-list 103 deny tcp host 172.16.3.10 172.16.1.0
0.0.0.255 eq access-list 103 permit ip any any
La nueva configuración en R3 cumple con los objetivos

de filtrar el tráfico de Bob, mientras que también cumple
con el objetivo general de diseño de mantener la ACL
cerca de la fuente de los paquetes. La ACL 103 en el R3
se parece mucho a la ACL 101 en el R1 del Ejemplo 3-1,
pero esta vez, la ACL no se molesta en comprobar los
criterios para que coincida con el tráfico de Larry,
porque el tráfico de Larry nunca entrará en la interfaz
Ethernet 0 del R3. La ACL 103 filtra el tráfico FTP de
Bob a destinos en la subred 172.16.1.0/24, y el resto del
tráfico que entra en la interfaz E0 de R3 llega a la red.
Listas de acceso IP ampliadas: Ejemplo 2

El Ejemplo 3-3, basado en la red mostrada en la Figura
3-9, muestra otro ejemplo de cómo usar listas de acceso
IP extendidas. Este ejemplo utiliza los siguientes
criterios:
Sam no puede acceder a la subred de Bugs o Daffy.
Los hosts de la Ethernet de Sevilla no pueden acceder a los hosts

de la Ethernet de Yosemite.
Todas las demás combinaciones están permitidas.
||||||||||||||||||||
||||||||||||||||||||
Figura 3-9 Diagrama de red para el ejemplo 2

de lista de acceso ampliada
Ejemplo 3-3 Configuración de Yosemite para la lista

de acceso ampliada Ejemplo 2
interface ethernet 0
ip access-group 110
in
¡!
access-list 110 deny ip host 10.1.2.1 10.1.1.0 0.0.0.255
access-list 110 deny ip 10.1.2.0 0.0.0.255 10.1.3.0 0.0.0.255
access-list 110 permit ip any any
Technet24
||||||||||||||||||||
||||||||||||||||||||
Esta configuración resuelve el problema con pocas

sentencias a la vez que mantiene la directriz de diseño
de Cisco de colocar las ACL extendidas lo más cerca
posible del origen del tráfico. La ACL filtra los paquetes
que entran por la interfaz E0 de Yosemite, que es la
primera interfaz del router por la que entran los paquetes
enviados por Sam. Si la ruta entre Yosemite y las otras
subredes cambia con el tiempo, la ACL se sigue
aplicando. Además, el filtrado exigido por el segundo
requisito (impedir que los hosts de la LAN de Sevilla
accedan a la de Yosemite) se cumple con la segunda
declaración de la lista de acceso. Detener el flujo de
paquetes desde la subred LAN de Yosemite a la subred
LAN de Sevilla detiene la comunicación efectiva entre
las dos subredes.
Alternativamente, la lógica opuesta podría haberse
configurado en Sevilla.
Práctica de creación de comandos

access-list
La Tabla 3-6 proporciona un ejercicio de práctica para
ayudarle a sentirse cómodo con la sintaxis del comando
extended access-list, particularmente con la elección de
la lógica de coincidencia correcta. Su tarea: crear una
ACL extendida de una línea que coincida con los
paquetes. Las respuestas están en la sección "Respuestas
a problemas de práctica anteriores", más adelante en este
capítulo. Tenga en cuenta que si los criterios mencionan
un protocolo de aplicación en particular, por ejemplo,
"cliente web", significa que debe coincidir
específicamente con ese protocolo de aplicación.
||||||||||||||||||||
||||||||||||||||||||
Tabla 3-6 Creación de ACL extendidas de una línea:
||||||||||||||||||||
||||||||||||||||||||
Práctica
Problema Criterios
1 Desde el cliente web 10.1.1.1, enviado a un servidor web

en la subred 10.1.2.0/24.
2 Desde el cliente Telnet 172.16.4.3/25, enviado a un

servidor Telnet en la subred 172.16.3.0/25. Coincide
también con todos los hosts de la subred del cliente.
3 Mensajes ICMP desde la subred en la que reside

192.168.7.200/26 a todos los hosts de la subred en la
que reside 192.168.7.14/29.
4 Desde la subred del servidor web 10.2.3.4/23 a clientes

en la misma subred que el host 10.4.5.6/22.
5 Desde la subred del servidor Telnet 172.20.1.0/24,

enviado a cualquier host en la misma subred que el
host 172.20.44.1/23.
6 Desde el cliente web 192.168.99.99/28, enviado a un

servidor web en la subred 192.168.176.0/28. Coincide
también con todos los hosts de la subred del cliente.
7 Mensajes ICMP desde la subred en la que reside

10.55.66.77/25 a todos los hosts de la subred en la
que reside 10.66.55.44/26.
8 Todos y cada uno de los paquetes IPv4.
EDICIÓN DE ACLS Y ACL CON NOMBRE

Ahora que ya conoce los conceptos básicos de las
ACL IP del IOS, en esta sección se examinan
algunas mejoras del soporte del IOS para las ACL:
ACL con nombre
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
y la edición de ACL con números de secuencia.

Aunque ambas funciones son útiles e importantes,
ninguna añade ninguna función en cuanto a lo que un
router puede y no puede filtrar.
En cambio, las ACL con nombre y los números de
secuencia de ACL facilitan recordar los nombres de
ACL y editar las ACL existentes cuando es necesario
cambiar una ACL.
Listas de acceso IP con nombre

Las ACLs IP con nombre tienen muchas similitudes con
las ACLs IP numeradas. Pueden ser usadas para filtrar
paquetes, además de para muchos otros propósitos.
También pueden coincidir con los mismos campos: las
ACL numeradas estándar pueden coincidir con los
mismos campos que una ACL con nombre estándar, y
las ACL numeradas extendidas pueden coincidir con los
mismos campos que una ACL con nombre extendida.
Por supuesto, existen diferencias entre las ACL con

nombre y las ACL numeradas. Las ACL con nombre
originalmente tenían tres grandes diferencias en
comparación con las ACL numeradas:
Utilización de nombres en lugar de números para identificar la ACL,

lo que facilita recordar el motivo de la ACL.
Uso de subcomandos ACL, no comandos globales, para definir la

acción y los parámetros de coincidencia
Uso de funciones de edición de ACL que permiten al usuario de la

CLI eliminar líneas individuales de la ACL e insertar líneas nuevas.
Puedes aprender fácilmente la configuración de ACLs

con nombre simplemente convirtiendo ACLs numeradas
||||||||||||||||||||
||||||||||||||||||||
para usar la configuración equivalente de ACLs con

nombre. La Figura 3-10 muestra una
||||||||||||||||||||
||||||||||||||||||||
conversión, utilizando una simple ACL estándar de tres

líneas número 1. Para crear los tres subcomandos
permit para la ACL nombrada, se copian literalmente
partes de los tres comandos ACL numerados,
empezando por la palabra clave permit.
Figura 3-10 Configuración de ACL con nombre

frente a ACL con número
La única parte realmente nueva de la configuración de

ACL con nombre es el comando de configuración
global ip access-list.
Este comando define si una ACL es una ACL estándar o
extendida y define el nombre. También mueve al
usuario al modo de configuración ACL, como se
muestra en el próximo Ejemplo 3-4. Una vez en el
modo de configuración ACL, se configuran los
comandos permit, deny y remark que reflejan la
sintaxis de los comandos ACL access-list numerados.
Si está configurando una ACL con nombre estándar,
estos comandos coinciden con la sintaxis de las ACL
numeradas estándar; si está configurando ACL con
nombre extendidas, coinciden con la sintaxis de las
ACL numeradas extendidas.
El ejemplo 3-4 muestra la configuración de una ACL

extendida con nombre. Preste especial atención a la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
que muestran el modo de configuración ACL.
Ejemplo 3-4 Configuración de listas de acceso con nombre

imagen del código
Router# configurar terminal
Introduzca los comandos de configuración, uno por línea.
Termine con CNTL/Z. Router(config)# ip access-list extended
barney Router(config-ext-nacl)# permit tcp host 10.1.1.2 eq
www any
Router(config-ext-nacl)# deny udp host 10.1.1.1 10.1.2.0 0.0.0.25
Router(config-ext-nacl)# deny ip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.
Router(config-ext-nacl)# deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0.0.
Router(config-ext-nacl)# permit ip any any
Router(config-ext-nacl)# interface serial1
Router(config-if)# ip access-group barney
out Router(config-if)# ^Z
Router# show running-config
Configuración del edificio...
Configuración actual:
! líneas omitidas por brevedad
interfaz serial 1
ip access-group barney out
¡!
ip access-list extended barney
permit tcp host 10.1.1.2 eq www
any
denyudp host 10.1.1.1 10.1.2.0 0.0.0.255
denyip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
denyip 10.1.2.0 0.0.0.255 10.2.3.0
0.0.0.255
permit ip any any
El Ejemplo 3-4 comienza con la creación de una ACL

llamada barney. El comando ip access-list extended
barney crea la ACL, nombrándola barney y colocando
al usuario en el modo de configuración ACL. Este
comando también le indica al IOS que barney es una
ACL extendida. A continuación, cinco sentencias
permit y deny diferentes definen la lógica de
coincidencia y la acción que se llevará a cabo en caso de
coincidencia. En
||||||||||||||||||||
||||||||||||||||||||
La salida del comando show running-config

muestra la configuración de ACL con nombre
antes de que se elimine la entrada única.
Las ACL con nombre permiten al usuario eliminar y

añadir nuevas líneas a la ACL desde el modo de
configuración de ACL.
El Ejemplo 3-5 muestra cómo, con el comando no deny
ip... borrando una sola entrada de la ACL. Observe que
la salida del comando show access-list al final del
ejemplo aún lista la ACL, con cuatro comandos permit
y deny en lugar de cinco.
Ejemplo 3-5 Eliminar un comando de una ACL con

nombre
Router# configurar terminal

con CNTL/Z. Router(config)# ip access-list extended barney
Router(config-ext-nacl)# no deny ip 10.1.2.0 0.0.0.255 10.2.3.0 0
Router(config-ext-nacl)# ^Z
Router# show access-list
Lista de acceso IP ampliada barney

10 permit tcp host 10.1.1.2 eq www any
20 denyudp host 10.1.1.1 10.1.2.0 0.0.0.255
30 denyip 10.1.3.0 0.0.0.255 10.1.2.0 0.0.0.255
50 permit ip any any
Edición de ACL mediante números

de secuencia
Las ACL numeradas han existido en IOS desde los
primeros días de los routers Cisco e IOS; sin embargo,
durante muchos años,
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
A través de muchas versiones de IOS, la capacidad de

editar una ACL IP numerada era pobre. Por ejemplo,
para eliminar simplemente una línea de la ACL, el
usuario tenía que eliminar toda la ACL y luego volver a
configurarla.
La función de edición de ACL utiliza un número de

secuencia de ACL que se añade a cada sentencia
permit o deny de ACL, y cuyos números
representan la secuencia de sentencias de la ACL. Los
números de secuencia de ACL proporcionan las
siguientes funciones para ACL numeradas y con
nombre:
Nuevo estilo de configuración para numeradas:

Las ACL numeradas utilizan un estilo de
configuración como las ACL con nombre, así como
el estilo tradicional, para la misma ACL; el nuevo
estilo es necesario para realizar la edición avanzada
de ACL.
Eliminación de líneas individuales: Una

declaración individual de permiso o denegación de
ACL se puede eliminar con un subcomando de
número de secuencia no.
Inserción de nuevas líneas: Los comandos permit

y deny recién añadidos pueden configurarse con un
número de secuencia antes del comando deny o
permit, que dicta la ubicación de la declaración
dentro de la ACL.
Numeración automática de secuencias: IOS añade

||||||||||||||||||||
||||||||||||||||||||
números de secuencia a los comandos a medida que

los configura, incluso si no incluye la secuencia
||||||||||||||||||||
||||||||||||||||||||
números.
Para aprovechar la posibilidad de eliminar e insertar

líneas en una ACL, tanto las ACL numeradas como las
nombradas deben utilizar el mismo estilo de
configuración general y los mismos comandos utilizados
para las ACL nombradas. La única diferencia en la
sintaxis es si se utiliza un nombre o un número. El
ejemplo 3-6 muestra la configuración de una ACL IP
numerada estándar, utilizando este estilo de
configuración alternativo. El ejemplo muestra el poder
del número de secuencia de la ACL para la edición. En
este ejemplo, ocurre lo siguiente:
Paso 1. La ACL numerada 24 se configura

utilizando este nuevo estilo de
configuración, con tres comandos permit.
Paso 2. El comando show ip access-lists muestra
los tres comandos permit con los números
de secuencia 10, 20 y 30.
Paso 3. El ingeniero elimina sólo el segundo
comando permit utilizando el subcomando
no 20 ACL, que simplemente hace
referencia al número de secuencia 20.
Paso 4. El comando show ip access-lists confirma
que la ACL ahora sólo tiene dos líneas
(números de secuencia 10 y 30).
Paso 5. El ingeniero añade un nuevo comando deny
al principio de la ACL, utilizando el 5 deny
10.1.1.1 Subcomando ACL.
nuevamente los cambios, esta vez listando
||||||||||||||||||||
||||||||||||||||||||
tres
Technet24
||||||||||||||||||||
||||||||||||||||||||
comandos, números de secuencia 5, 10 y 30.
Nota
En este ejemplo, observe que el usuario no abandona

el modo de configuración, sino que utiliza el
comando do para indicar a IOS que emita el
comando show ip access-lists EXEC desde el modo
de configuración.
Ejemplo 3-6 Edición de ACLs utilizando números de secuencia
¡! Paso 1: Se configura la ACL IP numerada estándar de 3

líneas. R1# configure terminal
con CNTL/Z. R1(config)# ip access-list standard 24
R1(config-std-nacl)# permis 10.1.1.0 0.0.0.255
o
o
o
¡! Paso 2: Mostrar el contenido de la ACL, sin salir de configur

R1(config-std-nacl)# do show ip access-lists 24
10 permis 10.1.1.0, comodín bits 0.0.0.255
o
o
o
¡! Paso 3: Todavía en el modo de configuración ACL 24, la línea

con seque R1(config-std-nacl)# no 20
¡! Paso 4: Visualizar de nuevo el contenido de la ACL, sin salir de co

¡! Observe que la línea número 20 ya no aparece
en la lista. R1(config-std-nacl)#do show ip
access-lists 24 Lista de acceso IP estándar 24
¡! Paso 5: Insertar una nueva primera línea en

la ACL. R1(config-std-nacl)# 5 deny 10.1.1.1
¡! Paso 6: Visualización del contenido de la ACL por última vez, con el botón n
||||||||||||||||||||
||||||||||||||||||||
(secuencia número 5) en primer lugar.

R1(config-std-nacl)# do show ip access-lists 24
5 negar 10.1.1.1
Tenga en cuenta que aunque el Ejemplo 3-6 utiliza una

ACL numerada, las ACL con nombre utilizan el mismo
proceso para editar (añadir y eliminar) entradas.
Configuración de ACL numeradas

frente a configuración de ACL con
nombre
Como breve apunte sobre las ACLs numeradas, ten en
cuenta que IOS permite en realidad dos formas de
configurar ACLs numeradas en las versiones más
recientes de IOS. Primero, IOS soporta el método
tradicional, usando los comandos globales access-list
mostrados anteriormente en los Ejemplos 3-1, 3-2, y 3-
3. IOS también soporta la configuración de ACL
numeradas con comandos iguales a los comandos
globales access-list. IOS también admite la
configuración de ACL numeradas con comandos
iguales a los de las ACL con nombre, como se muestra
en el Ejemplo 3-6.
Curiosamente, IOS siempre almacena las ACL

numeradas con el estilo original de configuración, como
comandos globales access-list, sin importar el método
que se utilice para configurar la ACL. El Ejemplo 3-7
demuestra estos hechos, retomando donde terminó el
Ejemplo 3-6, con los siguientes pasos adicionales:
Paso 7. El ingeniero muestra la configuración

||||||||||||||||||||
||||||||||||||||||||
(show running-config). El ingeniero

enumera la configuración (show running-
config), que enumera los comandos de
configuración de estilo antiguo, aunque el
comando
Technet24
||||||||||||||||||||
||||||||||||||||||||
ACL se creó con los comandos del

nuevo estilo.
Paso 8. El ingeniero añade una nueva sentencia al
final de la ACL utilizando el comando de
configuración global de estilo antiguo access-
list 24 permit 10.1.4.0 0.0.0.255.
que el antiguo comando access-list del paso
anterior seguía la regla de añadirse sólo al
final de la ACL.
Paso 10. El ingeniero muestra la configuración para
confirmar que las partes de la ACL 24
configuradas tanto con comandos de estilo
nuevo como con comandos de estilo antiguo
aparecen todas en la misma ACL de estilo
antiguo (show running-config).
Ejemplo 3-7 Adición y visualización de una

configuración ACL numerada

imagen del código
¡! Paso 7: Un fragmento de configuración para
ACL 24. R1# show running-config
¡! Las únicas líneas que se muestran son las de
ACL 24de
lista 24 denegar
acceso 10.1.1.1
lista de 24 permiso 0.0.0.255
acceso 10.1.1.0
lista de 24 permiso 0.0.0.255
¡! Paso 8: Añadir
acceso un nuevo comando global access-list
10.1.3.0
24 R1# configure terminal
Termine con CNTL/Z. R1(config)# access-list 24 permit 10.1.4.0
0.0.0.255 R1(config)# ^Z
¡! Paso 9: Visualizar de nuevo el contenido de la ACL, con el

número de secuenciab
A la nueva declaración se le ha asignado automáticamente una
secuencia nu R1# show ip access-lists 24
||||||||||||||||||||
||||||||||||||||||||

5 negar 10.1.1.1
¡! Pasode10: La
lista 24 configuración
denega 10.1.1.1ACL numerada permanece en la
acceso r
configuración antigua R1# show running-config
lista
¡! Las de
únicas24líneas
permis
que10.1.1.0 0.0.0.255
se muestran son las de ACL 24
acceso o
lista de 24 permis 10.1.3.0 0.0.0.255
acceso o
lista de 24 permis 10.1.4.0 0.0.0.255
acceso o
Consideraciones sobre la implementación de ACL

Las ACL pueden ser una gran herramienta para mejorar
la seguridad de una red, pero los ingenieros deben pensar
en algunas cuestiones más amplias antes de limitarse a
configurar una ACL para solucionar un problema. Para
ayudar, Cisco hace las siguientes recomendaciones
generales en los cursos en los que se basa el examen
CCNA:
Coloque las ACL extendidas lo más cerca posible del origen del
paquete. Esta estrategia permite a las ACL descartar los paquetes
antes de tiempo.
Coloque las ACL estándar lo más cerca posible del destino del
paquete. Esta estrategia evita el error de las ACL estándar (que sólo
coinciden con la dirección IPv4 de origen) de descartar
involuntariamente paquetes que no era necesario descartar.
Coloque declaraciones más específicas al principio del ACL.
Desactivar una ACL de su interfaz (mediante la opción no ip access-group

subcomando de interfaz) antes de realizar cambios en la ACL.
El primer punto se refiere al concepto de dónde ubicar

las ACL. Si pretendes filtrar un paquete, filtrar más cerca
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
a la fuente del paquete significa que el paquete ocupa

menos ancho de banda en la red, lo que parece ser más
eficiente-y lo es. Por lo tanto, Cisco sugiere ubicar las
ACL extendidas lo más cerca posible del origen.
Sin embargo, el segundo punto parece contradecir el

primero, al menos para las ACL estándar, situarlas cerca
del destino. ¿Por qué? Bueno, como las ACL estándar
sólo miran la dirección IP de origen, tienden a filtrar
más de lo que quieres que se filtre cuando se colocan
cerca del origen.
Por ejemplo, imagina que Fred y Barney están separados
por cuatro routers. Si filtras el tráfico de Barney enviado
a Fred en el primer router, Barney no podrá alcanzar
ningún host cercano a los otros tres routers. Así, los
cursos de Cisco hacen una recomendación general de
situar las ACL estándar más cerca del destino para evitar
filtrar tráfico que no se quiere filtrar.
Para el tercer elemento de la lista, al colocar parámetros

de coincidencia más específicos al principio de cada
lista, es menos probable que se cometan errores en la
ACL. Por ejemplo, imagine que la ACL enumera
primero un comando que permite el tráfico que va a
10.1.1.0/24, y el segundo comando deniega el tráfico que
va al host 10.1.1.1. Los paquetes enviados al host
10.1.1.1 coincidirían con el primer comando. Los
paquetes enviados al host 10.1.1.1 coincidirían con el
primer comando y nunca coincidirían con el segundo
comando más específico. Tenga en cuenta que las
versiones posteriores de IOS evitan este error durante la
configuración en algunos casos.
Por último, Cisco recomienda que desactive las ACL de

||||||||||||||||||||
||||||||||||||||||||
las interfaces antes de modificar las declaraciones en el

archivo
||||||||||||||||||||
||||||||||||||||||||
lista. Al hacerlo, se evitan problemas con la ACL

durante un estado intermedio. En primer lugar, si elimina
una ACL completa y deja la ACL IP habilitada en una
interfaz con el comando ip access- group, IOS no filtra
ningún paquete (¡no siempre era así en versiones
anteriores de IOS!). Sin embargo, tan pronto como
añades un comando ACL a esa ACL habilitada, IOS
empieza a filtrar paquetes basándose en esa ACL. Esas
configuraciones ACL provisionales podrían causar
problemas.
Por ejemplo, suponga que tiene activada la ACL 101 en

S0/0/0 para los paquetes de salida. Usted borra la lista
101 para que todos los paquetes sean permitidos.
Luego ingresa un único comando access-list 101. Tan
pronto como presione Enter, la lista existe, y el router
filtra todos los paquetes que salen de S0/0/0 basados
en la lista de una línea. Si quieres introducir una ACL
larga, ¡podrías filtrar temporalmente paquetes que no
quieres filtrar! Por lo tanto, la mejor manera es
deshabilitar la lista de la interfaz, hacer los cambios a
la lista, y luego volver a habilitarla en la interfaz.
Lecturas adicionales sobre ACL

Cisco lleva mucho tiempo incluyendo las ACL IP en el
examen CCNA. Antes del actual examen CCNA 200-
301, el examen CCNA R&S 200-125 incluía la solución
de problemas de ACL IP. Si desea obtener más
información sobre las ACL, en particular sobre la
solución de problemas de ACL, así como algunos
comportamientos inesperados con las ACL y los
paquetes generados por el router, consulte la sección
titulada "Solución de problemas con ACL IPv4," en el
||||||||||||||||||||
||||||||||||||||||||
Apéndice D, "Temas de ediciones anteriores."
Technet24
||||||||||||||||||||
||||||||||||||||||||
columna.

utilizado

memoria

comandos

||||||||||||||||||||
||||||||||||||||||||

Tema Número
Elemento
Figura 3-3 Sintaxis y notas sobre los tres campos de 47

coincidencia obligatorios del comando
access-list de ACL ampliada
Párrafo Resumen de la lógica ACL ampliada 48

según la cual todos los parámetros
deben coincidir en una única
declaración de lista de acceso para
que se produzca una coincidencia
Figura 3-4 Dibujo de la cabecera IP seguida de una 48

cabecera TCP
Figura 3-5 Sintaxis y notas sobre la coincidencia 48

de puertos TCP y UDP con
comandos ACL access-list
ampliados
Figura 3-7 Lógica y sintaxis para hacer coincidir los 49

puertos de origen TCP
Lista Directrices para el uso de ACL IP 51

numeradas ampliadas
Lista Diferencias entre ACL con nombre y 55

ACL numeradas cuando se introducen
ACL con nombre
Lista Funciones activadas por números de 57

secuencia ACL
Lista Recomendaciones para la aplicación del 60

ACL
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
lista de acceso ampliada
lista de acceso con nombre
hace el comando.
Tabla 3-9 Referencia de comandos de configuración

de ACL del Capítulo 3
access-list access-list-number Comando global para

{deny | permit} protocol source listas de acceso numeradas
source-wildcard destination extendidas. Utilice un
destination-wildcard [log] número entre 100 y 199 o
2000 y 2699, ambos
inclusive.
access-list access-list-number Una versión del comando

{deny | permit} tcp source access-list con parámetros
source-wildcard [operador específicos de TCP.
[puerto]] destination
destination-wildcard [operador
[puerto]] [log]
access-list access-list-number Comando que define una

texto de comentario observación para ayudarle
a recordar lo que se supone
que debe hacer la ACL.
||||||||||||||||||||
||||||||||||||||||||
ip access-group {número | nombre Subcomando de interfaz

[in | out]} para activar las listas de
acceso.
número de clase de acceso | Subcomando de línea para

nombre [en | habilitar listas de acceso
fuera] estándar o extendidas en
líneas vty.
ip access-list {standard | Comando global para

extendido} nombre configurar una ACL
estándar o extendida con
nombre y entrar en el modo
de configuración de ACL.
{deny | permit} source [source ACL para configurar los

wildcard] [log] detalles de coincidencia y
la acción para una ACL
estándar con nombre.
{deny | permit} protocol source ACL mode para configurar

source-wildcard destination los detalles de coincidencia
destination-wildcard [log] y la acción para una ACL
extendida con nombre.
{deny | permit} tcp source ACL mode para configurar

source-wildcard [operador los detalles de coincidencia
[puerto]] destination y la acción para una ACL
destination-wildcard [operador con nombre que coincida
[puerto]] [log] con segmentos TCP.
texto de comentario ACL para configurar una

descripción de una ACL
con nombre.
Tabla 3-10 Capítulo 3 Referencia de comandos

EXEC
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
show ip interface Incluye una referencia a

[número de tipo] las listas de acceso
habilitadas en la interfaz
show access-lists [número de Muestra detalles de las listas de

lista de acceso | nombre de acceso configuradas para todos
lista de acceso] los protocolos
show ip access-lists [access- Muestra las listas de acceso IP

list-number | access-list-name]
RESPUESTAS A PROBLEMAS PRÁCTICOS

ANTERIORES
La Tabla 3-11 lista las respuestas a los problemas de
práctica listados en la Tabla 3-6. Tenga en cuenta que
para cualquier pregunta que haga referencia a un cliente,
podría haber elegido coincidir con números de puerto
mayores que 49151, coincidiendo con todos los puertos
dinámicos. Las respuestas en esta tabla en su mayoría
ignoran esa opción, pero sólo para mostrar un ejemplo,
la respuesta al primer problema lista una con una
referencia a puertos de cliente mayores a 49151 y una sin
ella. El resto de respuestas simplemente omiten esta
parte de la lógica.
Tabla 3-11 Construcción de ACLs extendidas de una

línea: Respuestas
Criterios
1 access-list 101 permit tcp host 10.1.1.1 10.1.2.0

0.0.0.255 eq www
o
access-list 101 permit tcp host 10.1.1.1 gt 49151 10.1.2.0
0.0.0.255 eq www
||||||||||||||||||||
||||||||||||||||||||
2 access-list 102 permit tcp 172.16.4.0 0.0.0.127

172.16.3.0 0.0.0.127 eq telnet
3 access-list 103 permit icmp 192.168.7.192 0.0.0.63

192.168.7.8 0.0.0.7
4 access-list 104 permit tcp 10.2.2.0 0.0.1.255 eq www

10.4.4.0 0.0.3.255
5 access-list 105 permit tcp 172.20.1.0 0.0.0.255 eq 23

172.20.44.0 0.0.1.255
6 access-list 106 permit tcp 192.168.99.96 0.0.0.15

192.168.176.0 0.0.0.15 eq www
7 access-list 107 permit icmp 10.55.66.0 0.0.0.127

10.66.55.0 0.0.0.63
8 access-list 108 permit ip any any
Technet24
||||||||||||||||||||
||||||||||||||||||||
Parte I. Revisión
Siga el progreso de su revisión de piezas con la lista de
comprobación de la Tabla P1-1. Los detalles sobre cada
tarea siguen a la tabla.
Tabla P1-1 Lista de comprobación de la revisión de la Parte I
Actividad 1ª Fecha 2ª Fecha

Realizada Finalizada
Repita todas las

preguntas DIKTA
Responder a las
preguntas de repaso
Repasar los temas clave
Laboratorios Do
REPETIR TODAS LAS PREGUNTAS DIKTA

Para esta tarea, utilice el software PTP para
responder de nuevo a las preguntas "¿Sé esto ya?" de
los capítulos de esta parte del libro.
RESPONDER A LAS PREGUNTAS DE REPASO

Para esta tarea, utilice el PTP para responder a las
preguntas de repaso de esta parte del libro.
||||||||||||||||||||
||||||||||||||||||||
REPASAR LOS TEMAS CLAVE

Repase todos los temas clave de todos los capítulos de
esta parte, ya sea hojeando los capítulos o utilizando la
aplicación Temas clave del sitio web complementario.
DO LABS
Dependiendo de la herramienta de laboratorio que
elijas, aquí tienes algunas sugerencias sobre qué hacer
en el laboratorio:
Simulador de red Pearson: Si utiliza el simulador

Pearson CCNA completo, céntrese más en los
laboratorios de escenarios de configuración y
escenarios de solución de problemas asociados a los
temas de esta parte del libro. Estos tipos de
laboratorios incluyen un conjunto más amplio de
temas y funcionan bien como actividades de repaso de
la parte. (Consulte la Introducción para obtener más
detalles sobre cómo encontrar los laboratorios
relacionados con los temas de esta parte del libro).
Laboratorios de configuración: En sus momentos

de ocio, revise y repita cualquiera de los Config Labs
para esta parte del libro en el blog del autor; navegue
a blog.certskills.com/config- labs para obtener
instrucciones sobre cómo navegar a los laboratorios.
Otros: Si estás usando otras herramientas de

laboratorio, aquí tienes algunas sugerencias: cuando
construyas laboratorios ACL, puedes probar con
Telnet (puerto 23), SSH (puerto 22), ping (ICMP), y
traceroute (UDP) tráfico como el generado desde un
router extra. Por lo tanto, no te limites a configurar la
ACL; crea una ACL que pueda coincidir con estos
||||||||||||||||||||
tipos de tráfico, denegando algunos y permitiendo
||||||||||||||||||||
otros, y luego haz pruebas.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Parte II: Servicios de seguridad
Capítulo 4: Arquitecturas de seguridad
Capítulo 5: Protección de los dispositivos de red
Capítulo 6: Implementación de la seguridad de puertos de conmutación
Capítulo 7: Implementación de DHCP
Capítulo 8: DHCP Snooping e inspección ARP
Revisión de la Parte II
Con la introducción de la nueva certificación CCNA a

principios de 2020, Cisco amplió el número de temas de
seguridad en comparación con la antigua certificación
CCNA Routing and Switching. La Parte II incluye la
mayoría de los nuevos temas de seguridad añadidos a la
nueva certificación CCNA 200-301, así como algunos de
los temas clásicos que se encontraban en los anteriores
exámenes CCNA R&S.
El capítulo 4 inicia la Parte II con una amplia

descripción de las amenazas a la seguridad, las
vulnerabilidades y los exploits. Este capítulo
introductorio prepara el terreno para ayudarte a pensar
más como un ingeniero de seguridad.
||||||||||||||||||||
||||||||||||||||||||
Los capítulos 5, 6 y 8 se centran en una amplia gama

de temas de seguridad. Estos temas incluyen la discusión
del Capítulo 5 sobre cómo proteger los inicios de sesión
y contraseñas de routers y switches, junto con una
introducción a las funciones y roles de los firewalls o
sistemas de protección contra intrusiones (IPSs). Los
capítulos 6 y 8 se centran en tres funciones de
seguridad independientes integradas en los switches
Cisco: seguridad de puertos (capítulo 6), DHCP
Snooping (capítulo 8) e inspección dinámica de ARP
(DAI). Las tres características de seguridad requieren
que un switch examine las tramas cuando entran en la
interfaz del switch. Esta información permite a la
seguridad de puertos, DHCP Snooping y DAI decidir si
permiten que el mensaje continúe su camino.
El Capítulo 7 discute el Protocolo de Configuración

Dinámica de Host (DHCP) como un fin en sí mismo.
Aunque este tema es en realidad un Servicio IP y
encajaría perfectamente en la Parte III (Servicios IP), los
temas del Capítulo 8 requieren que conozcas DHCP, así
que el Capítulo 7 prepara el terreno.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 4. Arquitecturas de
seguridad Arquitecturas de
seguridad

5.1 Definir los conceptos clave de seguridad
(amenazas, vulnerabilidades, exploits y técnicas de
mitigación).
5.2 Describa los elementos del programa de
seguridad (concienciación de los usuarios,
formación y control de acceso físico)
5.4 Describir los elementos de las políticas de
contraseñas de seguridad, como la gestión, la
complejidad y las alternativas a las contraseñas
(autenticación multifactor, certificados y biometría).
5.8 Diferenciar los conceptos de autenticación,
autorización y contabilidad
A medida que ha ido aprendiendo sobre diversas

tecnologías de red, su atención se ha centrado
probablemente en el uso de dispositivos de red para
construir redes funcionales. Después de todo, las redes
deben permitir que los datos fluyan libremente para que
todos los usuarios conectados tengan una buena
experiencia, ¿verdad? El hecho desafortunado es que no
||||||||||||||||||||
||||||||||||||||||||
se puede confiar en que todos los usuarios conectados

obedezcan las reglas y sean buenos ciudadanos de la red.
En este capítulo, aprenderás sobre muchos aspectos de
una red.
||||||||||||||||||||
||||||||||||||||||||
red de la empresa que pueden ser explotados, así como

algunas formas de protegerlos.


preguntas
Terminología de seguridad 1-2
Amenazas comunes a la seguridad 3-7
Controlar y supervisar el acceso de los usuarios 8
Desarrollar un programa de seguridad para educar a los 9

usuarios
1. ¿Cuál de los siguientes términos significa

cualquier cosa que pueda considerarse un punto
débil que pueda comprometer la seguridad?
1. Explote
2. Vulnerabilidad
3. Ataque
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
4. Amenaza
2. ¿Cuál de los siguientes términos se refiere a la

posibilidad real de explotar una
vulnerabilidad?
1. Vulnerabilidad
2. Ataque
3. Explote
4. Amenaza
3. En un ataque de suplantación de identidad,

¿cuáles de los siguientes parámetros suelen
suplantarse? (Elija dos respuestas.)
1. Dirección MAC
2. Dirección IP de origen
3. Dirección IP de destino
4. Dirección ARP
4. Supongamos que un atacante envía una serie de

paquetes hacia una dirección IP de destino con la
bandera TCP SYN activada pero no envía ningún
otro tipo de paquete. ¿Cuál de los siguientes
ataques es probable que se esté produciendo?
1. Ataque de suplantación de identidad
2. Ataque de reflexión
3. Ataque de reconocimiento
4. Ataque de denegación de servicio
5. Ninguna de las opciones es correcta.
5. En un ataque de reflexión, la dirección IP de

origen en los paquetes de ataque se falsifica para
que contenga ¿cuál de las siguientes entidades?
1. La dirección del atacante
2. La dirección del reflector
3. Dirección de la víctima
4. La dirección del router
||||||||||||||||||||
||||||||||||||||||||
6. Durante un ataque man-in-the-middle con

éxito, ¿cuáles son las dos acciones siguientes
que es más probable que realice un atacante?
1. Espiar el tráfico que pasa entre hosts
2. Inducir un desbordamiento de búfer en varios hosts
3. Modificar el paso de datos entre hosts
4. Utilice barridos ping y escaneos de puertos para descubrir la red
7. ¿Cuál de los siguientes es el objetivo de un ataque

de fuerza bruta?
1. Pruebe todos los puertos TCP posibles hasta que un servicio responda
2. Pruebe todas las combinaciones posibles de caracteres del teclado
para adivinar la contraseña de un usuario.
3. Iniciar una operación de denegación de servicio en cada host
posible de una subred.
4. Suplantación de todas las direcciones IP posibles de una organización
8. ¿Cuál de los siguientes es un ejemplo de servidor

AAA?
1. DHCP
2. DNS
3. SNMP
4. ISE
9. ¿Por cuál de las siguientes razones es importante el

control de acceso físico?
1. Impide que personas no autorizadas se sienten en el escritorio
de un usuario corporativo y utilicen su ordenador.
2. Evita que los usuarios se enfaden y dañen los equipos
informáticos.
3. Impide el acceso no autorizado a los armarios de red.
4. Evita que los incendios destruyan los centros de datos.
Respuestas al cuestionario "¿Lo sé ya? 1 B
Technet24
||||||||||||||||||||
||||||||||||||||||||
2D
3 A, B
4D
5C
6 A, C
7B
8D
9C
Temas básicos
TERMINOLOGÍA DE SEGURIDAD
En un mundo perfecto, podrías construir una red que
soporte a cada usuario en una empresa, con la
suposición de que cada usuario es conocido, cada
usuario está aprobado para acceder a todo en la red, y
cada usuario usará los recursos disponibles exactamente
de acuerdo con algunas directrices corporativas. La red
mostrada en la Figura 4-1 podría representar este
escenario. Incluso este sistema ideal y cerrado no es
completamente seguro porque un usuario podría decidir
comportarse mal para molestar a un compañero de
trabajo o para ver información en el servidor corporativo
que debería ser restringida o confidencial.
||||||||||||||||||||
||||||||||||||||||||
Figura 4-1 Ejemplo de sistema cerrado de empresa
Consideremos ahora que casi ninguna empresa utiliza un

entorno tan limitado y cerrado. Después de todo, la
empresa probablemente querrá conectarse de alguna
manera a la Internet pública y tal vez a algunos socios
corporativos. También es probable que quiera permitir
que sus trabajadores sean móviles y lleven portátiles,
tabletas y teléfonos inteligentes dentro y fuera de los
límites de la empresa para mayor comodidad. La
empresa puede querer proporcionar acceso a la red a los
invitados que la visiten. Si la empresa ofrece
conectividad inalámbrica a sus empleados (e invitados),
también podría, sin saberlo, ofrecer su acceso
inalámbrico a personas que se encuentren dentro del
alcance de las señales. Y la lista sigue y sigue. A medida
que la red y su conectividad se expanden, como muestra
la Figura 4-2, la empresa tendrá más dificultades para
mantener los límites seguros y cerrados a su alrededor.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 4-2 Un ejemplo de empresa que se extiende

más allá de sus propios límites
Para empezar a proteger una red, primero hay que

entender qué puede fallar en ella. Piensa en una red de
empresa como una simple instalación con forma de
caja, como se muestra en la parte A de la Figura 4-3.
Cuando todas las paredes, el suelo y el techo están
hechos de un material muy resistente y son muy
gruesos, el contenido dentro de la caja probablemente
permanecerá a salvo de daños o robos. Sin embargo, el
propietario
||||||||||||||||||||
||||||||||||||||||||
podría tener dificultades para entrar y salir de la caja.
Figura 4-3 Terminología de seguridad ilustrada
Supongamos que se introduce una puerta por comodidad,

como se muestra en la parte B de la Figura 4-3. Ahora el
propietario puede entrar, pero también puede hacerlo
cualquier otra persona. El propietario puede entrar y
salir, pero también cualquier otra persona. Aunque la
puerta esté cerrada con llave, alguien podría encontrar la
forma de abrirla y acceder a los tesoros del interior.
Como ninguna puerta es impenetrable, la puerta se
convierte en una vulnerabilidad . En términos de
seguridad, una vulnerabilidad es cualquier cosa que
pueda considerarse una debilidad que puede
comprometer la seguridad de otra cosa, como la
integridad de los datos o el funcionamiento de un
sistema.
Sólo porque exista una vulnerabilidad, nada está

necesariamente en peligro. En el ejemplo de la puerta
cerrada, nadie salvo el propietario de confianza puede
abrir la puerta a menos que se utilice algún tipo de
herramienta distinta de la llave. Dicha herramienta puede
utilizarse para explotar una vulnerabilidad. De hecho, la
||||||||||||||||||||
herramienta en sí misma se llama exploit, como muestra
||||||||||||||||||||
la barra de palanca en la parte C de la Figura 4-3.

Un exploit no es muy eficaz si se utiliza contra
Technet24
||||||||||||||||||||
||||||||||||||||||||
cualquier otra cosa que no sea la debilidad o

vulnerabilidad objetivo.
Técnicamente, un exploit como la palanca no es muy

eficaz por sí mismo. Alguien debe cogerla y utilizarla
contra la vulnerabilidad. En la parte D de la Figura 4-3,
un usuario malicioso posee la palanca y pretende
utilizarla para abrir la puerta cerrada. Ahora existe la
posibilidad real de entrar, destruir, robar o modificar
algo sin permiso. Esto se conoce como amenaza .
En el mundo informático de redes, sistemas, estaciones

de trabajo y aplicaciones, existen muchísimas
vulnerabilidades y exploits diferentes que pueden ser
aprovechados por usuarios malintencionados para
convertirse en amenazas para una organización y sus
datos. El resto de este capítulo proporciona una visión
general de muchos de ellos, junto con algunas técnicas
que puedes aprovechar para contrarrestar o prevenir la
actividad maliciosa . Tales medidas se conocen como
técnicas de mitigación. Podrías estar pensando en
algunas formas en las que el propietario del edificio
Figura 4-3 podría mitigar las amenazas a las que se
enfrenta. Tal vez podría añadir cerraduras más fuertes y
seguras a la puerta, un marco de puerta más robusto para
resistir las fuerzas indiscretas o un sistema de alarma
para detectar una intrusión y alertar a las autoridades.
AMENAZAS COMUNES A LA SEGURIDAD
||||||||||||||||||||
||||||||||||||||||||
Dado que las redes empresariales modernas suelen estar

formadas por muchas partes que funcionan todas juntas,
asegurarlas puede convertirse en una tarea muy
compleja. Al igual que con la simple analogía de la
caja, no se puede intentar protegerla eficazmente hasta
que no se hayan identificado muchas de las
vulnerabilidades, evaluado los numerosos exploits que
existen y comprendido de dónde pueden proceder las
amenazas. Sólo entonces se pueden poner en marcha las
contramedidas y mitigaciones adecuadas.
También debe considerar algunos atributos importantes

de los recursos de la empresa que deben ser protegidos
y preservados. A medida que trabajes con las muchas
amenazas que se discuten en este capítulo, piensa en la
vulnerabilidad y el exploit que hace posible la amenaza.
Fíjate en cuántas partes diferentes de la red de la
empresa presentan vulnerabilidades y cómo se diseñan
las amenazas para aprovecharse de las debilidades.
Ataques de suplantación de direcciones

Cuando los sistemas se comportan con normalidad, se
puede confiar en los parámetros y servicios y utilizarlos
con eficacia. Por ejemplo, cuando una máquina envía un
paquete IP, todo el mundo espera que la dirección IP de
origen sea la propia dirección IP de la máquina. Se
espera que la dirección MAC de origen en la trama
Ethernet sea la propia dirección MAC del remitente.
Incluso servicios como DHCP y DNS deberían seguir
este ejemplo; si una máquina envía una petición DHCP o
DNS, espera que cualquier respuesta DHCP o DNS
provenga de un servidor legítimo y de confianza.
||||||||||||||||||||
Los ataques de suplantación de identidad se centran en una vulnerabilidad;
||||||||||||||||||||
las direcciones
Technet24
||||||||||||||||||||
||||||||||||||||||||
y los servicios tienden a ser de confianza implícita. Los

ataques suelen consistir en la sustitución de los valores
esperados por valores falsos. Los ataques de
suplantación de direcciones pueden ser simples y
directos, en los que se sustituye un valor de dirección por
otro.
Por ejemplo, un atacante puede enviar paquetes con una

dirección IP de origen falsificada en lugar de la suya
propia, como se muestra en la Figura 4-4. Cuando el
objetivo reciba los paquetes, enviará tráfico de retorno a
la dirección falsificada en lugar de a la dirección real del
atacante. Cuando el objetivo reciba los paquetes, enviará
tráfico de retorno a la dirección falsificada, en lugar de a
la dirección real del atacante. Si la dirección falsificada
existe, un host desprevenido con esa dirección recibirá el
paquete. Si la dirección no existe, el paquete se reenviará
y se descartará en otros puntos de la red.
Figura 4-4 Un ejemplo de ataque de suplantación de identidad
Un atacante también puede enviar direcciones MAC falsificadas, para añadir

||||||||||||||||||||
||||||||||||||||||||
información falsa a las tablas de reenvío utilizadas por

los switches de capa 2 o a las tablas ARP utilizadas por
otros hosts y routers. Las peticiones DHCP con
direcciones MAC falsificadas también pueden ser
enviadas a un servidor DHCP legítimo, llenando su tabla
de arrendamiento de direcciones y no dejando
direcciones IP libres para su uso normal.
Tenga en cuenta que en el Capítulo 6, "Implementación

de la seguridad de puertos de conmutación", se habla de
una herramienta que se puede utilizar para ayudar a
mitigar la suplantación de direcciones MAC. En el
Capítulo 8, "DHCP Snooping e Inspección ARP",
puede aprender más sobre la Inspección ARP Dinámica
(DAI) y cómo utilizarla para mitigar la suplantación de
direcciones IP utilizando ARP.
Ataques de denegación de servicio

En el funcionamiento normal de una aplicación
empresarial, los clientes abren conexiones a servidores
corporativos para intercambiar información. Esto puede
ocurrir en forma de sesiones basadas en web que están
abiertas tanto a usuarios internos como a usuarios
externos en la Internet pública. El proceso es sencillo:
los usuarios abren un navegador web hacia el sitio
corporativo, que a su vez abre una conexión TCP con el
servidor web corporativo; entonces puede tener lugar
alguna transacción. Si todos los usuarios se comportan
bien y realizan transacciones legítimas, los servidores
corporativos (con suerte) no se estresan y muchos
clientes pueden hacer negocios con normalidad.
Supongamos ahora que un usuario malicioso encuentra

la forma de abrir una conexión anómala al mismo
||||||||||||||||||||
||||||||||||||||||||
servidor corporativo. La conexión TCP comienza con el

usuario malicioso enviando una bandera SYN al
servidor, pero la dirección IP de origen se sustituye por
una dirección falsa. El servidor añade el TCP
Technet24
||||||||||||||||||||
||||||||||||||||||||
a su tabla de conexiones cliente y responde a la dirección

falsa con un SYN-ACK. Debido a que la dirección falsa
no está involucrada en la conexión TCP, no hay
respuesta ACK para completar el handshake TCP de tres
vías.
La conexión incompleta permanece en la tabla del
servidor hasta que se agota y se elimina. Durante este
tiempo, el atacante puede intentar abrir muchas, muchas
más conexiones anómalas a un ritmo tal que la tabla de
conexiones del servidor se llene. En ese momento, el
servidor ya no es capaz de mantener conexiones TCP
con usuarios legítimos, por lo que todas sus
transacciones comerciales se detienen. La Figura 4-5
ilustra este proceso.
||||||||||||||||||||
||||||||||||||||||||
Figura 4-5 Un ejemplo de ataque de denegación de servicio
Cuando un atacante es capaz de agotar un recurso del

sistema, los servicios y sistemas dejan de estar
disponibles o se bloquean. Esto
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
se denomina ataque de denegación de servicio (DoS) a

porque deniega el servicio a usuarios u operaciones
legítimos. Los ataques DoS pueden implicar algo tan
simple como paquetes de eco ICMP (ping), una
inundación de paquetes UDP y conexiones TCP, como el
ataque de inundación TCP SYN descrito anteriormente.
Tales ataques pueden tener éxito siempre que un sistema
tenga una vulnerabilidad con el protocolo o el tipo de
tráfico que se explota.
Los atacantes pueden llevar la idea del DoS aún más

lejos reclutando a muchos otros sistemas para que
participen. Para ello, el atacante establece un ordenador
de control maestro en algún lugar de Internet. A
continuación, primero hay que infectar muchos
ordenadores con código malicioso o malware
aprovechando vulnerabilidades presentes en esas
máquinas.
Cada máquina se convierte entonces silenciosamente en
un "bot", aparentando operar normalmente, mientras
espera órdenes del control maestro. Cuando llega el
momento de iniciar el ataque, el control maestro envía
una orden a cada bot y le indica que inicie un ataque de
denegación de servicio contra un único host objetivo .
Esto se denomina ataque de denegación de servicio
distribuido (DDoS) porque el ataque se distribuye
entre un gran número de bots, todos inundando o
atacando el mismo objetivo.
Ataques de reflexión y amplificación

Recordemos que en un ataque de suplantación de
identidad, el atacante envía paquetes con una dirección
de origen falsa a un objetivo. El objetivo es forzar al
||||||||||||||||||||
||||||||||||||||||||
objetivo a lidiar con el tráfico falsificado y enviar tráfico

de retorno hacia una fuente inexistente. El sitio
||||||||||||||||||||
||||||||||||||||||||
al atacante no le importa a dónde va el tráfico de

retorno o que no pueda ser entregado con éxito.
En un ataque algo relacionado, el atacante envía de

nuevo paquetes con una dirección de origen falsa hacia
un host activo. Sin embargo, el host no es el objetivo
previsto; el objetivo es conseguir que el host refleje el
intercambio hacia la dirección falsificada que es el
objetivo. Esto se conoce como un ataque de reflexión
como se ilustra en la Figura 4-6, y el host que refleja el
tráfico hacia el objetivo se llama el reflector. El atacante
también puede enviar los paquetes suplantados a
múltiples reflectores, haciendo que el objetivo reciba
múltiples copias del tráfico inesperado.
Figura 4-6 Un ejemplo de ataque por reflexión
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
El impacto de un ataque de reflexión puede parecer

limitado porque la víctima es un único host de destino, y
la cantidad de tráfico que se refleja hacia el objetivo es
proporcional a los paquetes enviados por el atacante. Si
un atacante es capaz de enviar una pequeña cantidad de
tráfico a un reflector y aprovechar un protocolo o
servicio para generar un gran volumen de tráfico hacia
un objetivo, entonces se ha producido un ataque de
amplificación . En efecto, un ataque de este tipo
amplifica los esfuerzos del atacante para perturbar el
objetivo. Otro resultado es que se pueden consumir
grandes cantidades de ancho de banda de la red
reenviando el tráfico amplificado hacia el objetivo,
especialmente si hay muchos reflectores implicados.
Algunos mecanismos de DNS y NTP han sido
explotados en el pasado para establecer nuevos récords
de enorme consumo de ancho de banda durante un
ataque de amplificación.
Ataques Man-in-the-Middle
Muchos tipos de ataques pretenden interrumpir o
comprometer directamente los sistemas objetivo, a
menudo con resultados notables. A veces, un atacante
puede querer espiar los datos que pasan de una
máquina a otra, evitando ser detectado. Un ataque man-
in-the-middle en hace precisamente eso, permitiendo al
atacante introducirse silenciosamente en la ruta de
comunicación como intermediario entre dos sistemas
objetivo.
Un tipo de ataque man-in-the-middle explota la tabla

ARP que cada host mantiene para comunicarse con
otros hosts en su segmento de red local. Normalmente,
||||||||||||||||||||
||||||||||||||||||||
si un host necesita enviar datos a otro, busca la
||||||||||||||||||||
||||||||||||||||||||
host de destino en su tabla ARP. Si se encuentra una

entrada, la trama Ethernet se puede enviar directamente a
la dirección MAC de destino; de lo contrario, el
remitente debe emitir una solicitud ARP que contenga la
dirección IP de destino y esperar a que el destino
responda con una respuesta ARP y su propia dirección
MAC.
La Figura 4-7 ilustra un ataque man-in-the-middle

exitoso.
Figura 4-7 Comienza un ataque Man-in-the-Middle
En el paso 1, un cliente envía una solicitud ARP para

averiguar qué dirección MAC utiliza el host con
dirección IP 198.51.100.10. En el paso 2, la solicitud
ARP se envía a todos los hosts del dominio de difusión.
En el paso 2, la solicitud ARP se envía a todos los hosts
del dominio de difusión. Esto permite al atacante
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
para escuchar la petición ARP y prepararse para explotar

la información aprendida. El propietario legítimo de
198.51.100.10 puede responder con su propia respuesta
ARP y su dirección MAC real, como era de esperar. Sin
embargo, en el paso 3, el atacante simplemente espera un
breve tiempo y luego envía una respuesta ARP
falsificada que contiene su propia dirección MAC, en
lugar de la del destino real. El objetivo es que el atacante
envíe la última respuesta ARP para que cualquier host a
la escucha actualice su tabla ARP con la información
más reciente.
Este proceso envenena efectivamente la entrada de la

tabla ARP en cualquier sistema que reciba la respuesta
ARP falsificada. A partir de ese momento, un sistema
envenenado reenviará ciegamente el tráfico a la
dirección MAC del atacante, que ahora se hace pasar por
el destino. El atacante es capaz de conocer la dirección
MAC de destino real porque recibió una respuesta ARP
anterior del host de destino. La Figura 4-8 muestra el
resultado final. El atacante puede repetir este proceso
envenenando las entradas ARP en múltiples hosts y
luego retransmitiendo tráfico entre ellos sin que sea fácil
detectarlo.
||||||||||||||||||||
||||||||||||||||||||
Figura 4-8 Éxito de un ataque Man-in-the-Middle
Una vez que un atacante se ha introducido entre dos

hosts, puede espiar e inspeccionar pasivamente todo el
tráfico que pasa entre ellos. El atacante también puede
adoptar un papel activo y modificar los datos que pasan.
Resumen del ataque de suplantación de direcciones

Mientras trabajas con los distintos tipos de ataques de
suplantación de direcciones, recuerda que el objetivo del
atacante es disfrazar su identidad y engañar a otros
sistemas de forma maliciosa. Utiliza la Tabla 4-2 para
repasar los conceptos y características de cada tipo de
ataque.
Tabla 4-2 Resumen de Ataques de Spoofing de Direcciones
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Objetivo DoS/DDoS Reflexión Amplificación

Hombre-
en el
centro
Agotar Sí No No No
un
servicio o
recurso
del
sistema;
bloquear
el
sistema
de
destino.
Engañar a No Sí Sí No
un host
cómplice
involuntari
o para que
envíe
tráfico al
objetivo
Espiar el No No No Sí
tráfico
Modificar No No No Sí
el tráfico
de paso
Ataques de reconocimiento
Cuando un atacante pretende lanzar un ataque contra un
objetivo, es posible que quiera identificar algunas
vulnerabilidades para que el ataque pueda centrarse y ser
más eficaz. Un ataque de reconocimiento puede
utilizarse para descubrir más detalles sobre el objetivo y
||||||||||||||||||||
||||||||||||||||||||
sus sistemas antes de un ataque real.
||||||||||||||||||||
||||||||||||||||||||
Durante un ataque de reconocimiento, el atacante puede

utilizar algunas herramientas comunes para descubrir
detalles públicos como quién es el propietario de un
dominio y qué rangos de direcciones IP se utilizan allí.
Por ejemplo, el comando nslookup existe en muchos
sistemas operativos y puede realizar una búsqueda DNS
para resolver una dirección IP a partir de un nombre de
dominio completo. Si un atacante conoce el nombre de
dominio de una empresa, nslookup puede revelar el
propietario del dominio y el espacio de direcciones IP
registrado en él. Los comandos whois y dig son
herramientas complementarias que pueden consultar la
información DNS para revelar información detallada
sobre los propietarios de los dominios, información de
contacto, servidores de correo, servidores de nombres
autoritativos, etc.
A continuación, el atacante puede utilizar barridos de

ping para enviar pings a cada dirección IP del rango
objetivo. Los hosts que respondan al barrido de ping se
convertirán en objetivos activos.
Las herramientas de escaneo de puertos pueden entonces
barrer un rango de puertos UDP y TCP para ver si un
host objetivo responde en algún número de puerto.
Cualquier respuesta indica que un servicio
correspondiente se está ejecutando en el host de destino.
Tenga en cuenta que un ataque de reconocimiento no es

un verdadero ataque porque no se explota nada como
resultado. Se utiliza para recopilar información sobre
los sistemas y servicios objetivo para poder descubrir
vulnerabilidades y explotarlas mediante otros tipos de
ataques.
||||||||||||||||||||
||||||||||||||||||||
Ataques de desbordamiento del búfer

Los sistemas operativos y las aplicaciones normalmente leen y
Technet24
||||||||||||||||||||
||||||||||||||||||||
escribir datos utilizando búferes y espacio de memoria

temporal. Los búferes también son importantes cuando
un sistema se comunica con otro, ya que los paquetes
IP y las tramas Ethernet van y vienen. Mientras el
espacio de memoria se mantenga correctamente y los
datos se coloquen dentro de los límites correctos del
búfer, todo debería funcionar como se espera.
Sin embargo, algunos sistemas y aplicaciones tienen

vulnerabilidades que pueden permitir que los búferes se
desborden. Esto significa que algunos datos entrantes
podrían almacenarse en ubicaciones de memoria
inesperadas si se permite que un búfer se llene más allá
de su límite. Un atacante puede aprovecharse de esta
situación enviando datos más grandes de lo esperado. Si
existe una vulnerabilidad, el sistema objetivo podría
almacenar esos datos, desbordando su búfer en otra zona
de la memoria y, finalmente, bloquear un servicio o todo
el sistema. El atacante también podría ser capaz de
manipular especialmente el mensaje de gran tamaño
insertando código malicioso en él. Si el sistema de
destino almacena esos datos como resultado de un
desbordamiento del búfer, entonces puede ejecutar
potencialmente el código malicioso sin darse cuenta.
Malware
Algunos tipos de amenazas a la seguridad pueden venir
en forma de software malicioso o malware . Por
ejemplo, un troyano es un software malicioso que se
oculta y empaqueta dentro de otro software que parece
normal y legítimo. Si un usuario bienintencionado decide
instalarlo, el software troyano también se instala
silenciosamente. Entonces el malware puede
||||||||||||||||||||
||||||||||||||||||||
ejecutar ataques propios en el sistema local o contra

otros sistemas. El malware troyano puede propagarse
de un ordenador a otro sólo a través de la interacción
del usuario, como la apertura de archivos adjuntos de
correo electrónico, la descarga de software de
Internet y la inserción de una unidad USB en un
ordenador.
Por el contrario, los virus son programas maliciosos que

pueden propagarse entre sistemas con mayor facilidad.
Para propagarse, el software del virus debe inyectarse en
otra aplicación y luego confiar en que los usuarios
transporten el software de la aplicación infectada a otras
víctimas.
Otro tipo de malware es capaz de propagarse e infectar

otros sistemas por sí mismo. Un atacante desarrolla el
software del gusano y lo deposita en un sistema. A partir
de ese momento, el gusano se replica y propaga a otros
sistemas a través de sus vulnerabilidades, y luego se
replica y propaga una y otra vez.
A modo de resumen, la Tabla 4-3 enumera las ideas

clave detrás de cada tipo de malware descrito en esta
sección.
Tabla 4-3 Resumen de tipos de malware
Característica Caball Virus Gusano

o de
Troya
Empaquetado dentro de otro Sí No No

software
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Autoinyección en otro No Sí No
software
Se propaga automáticamente No No Sí
Vulnerabilidades humanas
Muchos tipos de ataque deben aprovechar una
vulnerabilidad en un sistema operativo, servicio u otro
tipo de software de aplicación. En otras palabras, un
atacante o el malware implicado debe encontrar un
punto débil en el sistema informático objetivo. Hay
muchos otros ataques que pueden tener éxito
aprovechando las debilidades de los seres humanos que
utilizan los sistemas informáticos.
Un ataque bastante directo es el denominado ingeniería

social, en el que la confianza humana y los
comportamientos sociales pueden convertirse en
vulnerabilidades de seguridad. Por ejemplo, un atacante
puede hacerse pasar por un miembro del personal
informático e intentar ponerse en contacto con usuarios
finales reales a través de llamadas telefónicas, correos
electrónicos y redes sociales. El objetivo final podría ser
convencer a los usuarios para que revelen sus
credenciales o configuren sus contraseñas con un valor
"temporal" debido a algún mantenimiento informático
ficticio que vaya a tener lugar, lo que permitiría al
atacante acceder fácilmente a sistemas seguros. Los
atacantes también podrían estar físicamente presentes y
observar en secreto a los usuarios mientras introducen
sus credenciales.
El phishing es una técnica que utilizan los atacantes para

inducir a las víctimas a visitar sitios web maliciosos. La
||||||||||||||||||||
||||||||||||||||||||
idea es disfrazar la invitación como algo legítimo,

asustar a las víctimas para que sigan un enlace o engañar
a los usuarios de cualquier otra forma.
||||||||||||||||||||
||||||||||||||||||||
a navegar por contenidos que les convencen para

introducir su información confidencial.
El phishing adopta muchas formas. El spear phishing se

dirige a un grupo de usuarios similares que pueden
trabajar para la misma empresa, comprar en las mismas
tiendas, etc., y que reciben el mismo correo electrónico
convincente con un enlace a un sitio malicioso. El
"whaling" es similar, pero se dirige a personas de alto
perfil en empresas, gobiernos y organizaciones. El
phishing también puede producirse a través de las
comunicaciones tradicionales, como las llamadas de voz
(vishing) y los mensajes de texto SMS (smishing).
El pharming también intenta enviar a las víctimas a un

sitio web malicioso, pero adopta un enfoque más
drástico. En lugar de incitar a las víctimas a seguir un
enlace camuflado, el pharming implica comprometer los
servicios que dirigen a los usuarios hacia un sitio web
conocido o de confianza. Por ejemplo, un atacante
puede comprometer un servicio DNS o editar los
archivos hosts locales para cambiar la entrada de un
sitio legítimo. Cuando una víctima intenta visitar el sitio
utilizando su enlace real, la resolución de nombres
alterada devuelve en su lugar la dirección de un sitio
malicioso.
En un ataque watering hole, un atacante determina qué

usuarios visitan con frecuencia un sitio; a continuación,
se compromete ese sitio y se deposita en él malware. El
malware infecta únicamente a los usuarios objetivo que
visitan el sitio, dejando indemnes a los demás usuarios.
Puede consultar la Tabla 4-4 para repasar las ideas clave

que subyacen a cada tipo de vulnerabilidad humana
||||||||||||||||||||
||||||||||||||||||||
comúnmente
Technet24
||||||||||||||||||||
||||||||||||||||||||
explotado.
Tabla 4-4 Resumen de vulnerabilidades de seguridad

humana
Tipo de ataque Gol
Ingeniería social Explota la confianza humana y el comportamiento

social
Phishing Disimula una invitación maliciosa como algo

legítimo
Suplanta Se dirige a un grupo de usuarios similares

ción de
identida
d
La caza de Se dirige a personas de alto perfil

ballenas
Vishing Utiliza llamadas de voz
Smishing Utiliza mensajes de texto SMS
Pharming Utiliza servicios legítimos para enviar a los

usuarios a un sitio comprometido
Abrevadero Se dirige a víctimas específicas que visitan un sitio

comprometido
Vulnerabilidades de las contraseñas
||||||||||||||||||||
||||||||||||||||||||
La mayoría de los sistemas de una red empresarial

utilizan alguna forma de autenticación para conceder o
denegar el acceso a los usuarios. Cuando los usuarios
acceden a un sistema, normalmente intervienen un
nombre de usuario y una contraseña. Puede ser bastante
fácil adivinar el nombre de usuario de alguien basándose
en el nombre real de esa persona. Si la contraseña del
usuario está configurada con algún valor predeterminado
o con una palabra o cadena de texto fácil de adivinar, un
atacante también podría acceder fácilmente al sistema.
Piense como un atacante por un momento y vea si puede

hacer algunas conjeturas sobre las contraseñas que
podría probar si quisiera iniciar sesión en un sistema
aleatorio. Tal vez hayas pensado en contraseñas como
password, password123, 123456, etcétera. Quizás
podrías probar con el nombre de usuario admin y la
contraseña admin.
Un atacante puede lanzar un ataque en línea

introduciendo cada una de las contraseñas adivinadas
cuando el sistema solicita las credenciales del usuario.
Por el contrario, un ataque fuera de línea se produce
cuando el atacante es capaz de recuperar las contraseñas
cifradas o con hash antes de tiempo, luego se desconecta
a un ordenador externo y utiliza el software allí para
intentar recuperar repetidamente la contraseña real.
Los atacantes también pueden utilizar software para

realizar ataques de diccionario con el fin de descubrir la
contraseña de un usuario. El software intentará iniciar
sesión automáticamente con contraseñas extraídas de un
diccionario o lista de palabras. Puede que tenga que
pasar por miles o millones de intentos antes de descubrir
||||||||||||||||||||
||||||||||||||||||||
la contraseña real. Además, el software puede realizar un

ataque de fuerza bruta probando todas las contraseñas
posibles.
Technet24
||||||||||||||||||||
||||||||||||||||||||
combinación de cadenas de letras, números y

símbolos. Los ataques de fuerza bruta requieren
recursos informáticos muy potentes y una gran
cantidad de tiempo.
Para mitigar los ataques con contraseña, una empresa

debe implantar políticas de contraseñas para todos los
usuarios. Dicha política podría incluir directrices que
exijan una cadena de contraseñas larga compuesta por
una combinación de caracteres en mayúsculas y
minúsculas junto con números y algunos caracteres
especiales. El objetivo es exigir que todas las
contraseñas sean cadenas complejas que sean difíciles de
adivinar o revelar mediante un ataque con contraseña.
Además, la gestión de contraseñas debe exigir que todas
las contraseñas se cambien periódicamente para que ni
siquiera los ataques de fuerza bruta prolongados puedan
recuperar una contraseña antes de volver a cambiarla.
Alternativas a la contraseña
Una simple cadena de contraseñas es el único factor
que un usuario debe introducir para autenticarse.
Como una contraseña debe recordarse y no escribirse
en ningún sitio, puedes pensar en tu contraseña como
"algo que sabes". Esperemos que nadie más la sepa
también; de lo contrario, podrían utilizarla para
suplantar tu identidad al autenticarse.
Una empresa también puede plantearse utilizar

credenciales alternativas que aporten más complejidad y
más seguridad. Las credenciales multifactor requieren
que los usuarios proporcionen valores o factores que
proceden de distintas fuentes, lo que reduce la
posibilidad de que un atacante pueda poseer todos los
||||||||||||||||||||
||||||||||||||||||||
factores. Un viejo dicho describe el doble factor
||||||||||||||||||||
||||||||||||||||||||
credenciales como "algo que se tiene" (una clave

criptográfica que cambia dinámicamente o un mensaje
de texto que contiene un código de tiempo limitado) y
"algo que se sabe" (una contraseña).
Un certificado digital puede servir como factor

alternativo porque sirve como forma fiable de
identificación, se adhiere a un formato estandarizado y
contiene información cifrada. Si una empresa admite
el uso de certificados, el usuario debe solicitar y
obtener un certificado único para fines específicos. Por
ejemplo, los certificados utilizados para autenticar
usuarios deben ser aprobados para la autenticación.
Para ser fiables, los certificados deben ser concedidos
y firmados digitalmente por una autoridad de
certificación (CA) de confianza. Siempre que los
servicios utilizados por la empresa conozcan la CA y
confíen en ella, los certificados individuales firmados
por esa CA también serán de confianza.
Los certificados digitales también son sensibles al

tiempo, ya que cada uno se aprueba para un intervalo de
tiempo específico. Una vez que un certificado caduca,
cualquier intento de autenticarse con él será rechazado.
El usuario que posee el certificado puede solicitar uno
nuevo antes de la fecha de caducidad o en cualquier
momento posterior. Los certificados también pueden
ser revocados, si la empresa decide revocar los
privilegios de un usuario, si el usuario se separa de la
empresa, etcétera. Aunque el usuario aún posea un
certificado revocado, se le denegará el acceso cuando
intente autenticarse con él.
Dado que los certificados digitales existen como archivos en un ordenador o

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
dispositivo, podría pensarse que pueden copiarse

libremente y utilizarse para identificar a personas
distintas de los propietarios originales. Cada
certificado digital debe llevar además una prueba de
posesión que demuestre que ha sido realmente
concedido al usuario que lo presenta durante la
autenticación. Esta prueba se incorpora al contenido
cifrado del certificado, como resultado de combinar
claves públicas que la máquina del usuario y el
servidor de autenticación pueden compartir
públicamente, junto con claves privadas que cada parte
mantiene privadas y secretas. Mientras el servidor de
autenticación pueda verificar que el certificado se creó
utilizando las claves públicas y privadas correctas, el
certificado debe pertenecer al propietario previsto. Si
no es así, se rechazará la autenticación para evitar la
entrada de un impostor.
Las credenciales biométricas llevan el esquema aún

más lejos al proporcionar un factor que representa
"algo que eres". La idea es utilizar algún atributo físico
del cuerpo de un usuario para identificar de forma única
a esa persona. Los atributos físicos suelen ser
exclusivos de la estructura corporal de cada individuo
y no pueden robarse ni duplicarse fácilmente. Por
ejemplo, la huella dactilar de un usuario puede
escanearse y utilizarse como factor de autenticación.
Otros ejemplos son el reconocimiento facial, las
huellas palmares, el reconocimiento de voz, el
reconocimiento del iris y los escáneres de retina. Como
es de esperar, algunos métodos son más fiables que
otros.
A veces, los sistemas de reconocimiento facial pueden
||||||||||||||||||||
||||||||||||||||||||
ser engañados cuando se les presentan fotografías o

máscaras de personas de confianza. Las lesiones y el
proceso de envejecimiento también pueden alterar
patrones biométricos como las huellas dactilares o las
formas faciales,
||||||||||||||||||||
||||||||||||||||||||
y patrones de iris. Para ayudar a mitigar los posibles

puntos débiles, también se pueden recopilar y utilizar
múltiples credenciales biométricas para autenticar a los
usuarios.
A modo de resumen, la Tabla 4-5 enumera las ideas

clave utilizadas en cada alternativa a la autenticación
mediante contraseña.
Tabla 4-5 Resumen de autenticación de contraseña y

alternativas
Característica Sólo con Dos Certificados Biometría

contraseña factores digitales
Algo que sabes Sí Sí
Algo que has Sí Sí
Algo que eres Sí
CONTROLAR Y SUPERVISAR EL ACCESO

DE LOS USUARIOS
Puedes gestionar la actividad de los usuarios hacia y a
través de los sistemas con mecanismos de
autenticación, autorización y contabilidad (AAA,
también pronunciado "triple A"). AAA utiliza métodos
estandarizados para cuestionar las credenciales de los
usuarios antes de permitir o autorizar el acceso.
Los protocolos de contabilidad también pueden
registrar la actividad de los usuarios en los sistemas
de la empresa. El AAA se utiliza habitualmente para
controlar y supervisar el acceso a dispositivos de red
||||||||||||||||||||
||||||||||||||||||||
como los routers,
Technet24
||||||||||||||||||||
||||||||||||||||||||
conmutadores, cortafuegos, etc.
En pocas palabras, se puede pensar en AAA de la

siguiente manera:
Autenticación: ¿Quién es el usuario?
Autorización: ¿Qué puede hacer el usuario?
Contabilización: ¿Qué ha hecho el usuario?
A modo de ejemplo, un administrador de red puede

disponer de varios métodos para gestionar los usuarios
que podrían intentar iniciar sesión en un switch para
realizar alguna operación. En el nivel más básico, podría
autenticar a los usuarios con simples contraseñas que se
configuran en la consola del conmutador y en las líneas
VTY. La autorización podría ser igualmente simple:
cuando los usuarios inician sesión con éxito, son
autorizados para privilegios de nivel EXEC.
Introduciendo la contraseña secreta de habilitación
correcta, los usuarios podrían ser autorizados para un
nivel de privilegio superior.
En el escenario simple, si un usuario conoce la

contraseña correcta, puede conectarse al conmutador.
Pero, ¿quién es ese usuario? Es posible que nunca se
sepa quién se ha conectado realmente y ha cambiado la
configuración o reiniciado el conmutador.
En su lugar, podrías configurar nombres de usuario y
contraseñas individuales en el switch. Esto solucionaría
el problema del anonimato del usuario, pero su red
podría estar formada por muchos usuarios
administrativos y muchos conmutadores, lo que
requeriría bastante configuración y mantenimiento de los
||||||||||||||||||||
||||||||||||||||||||
nombres de usuario.
||||||||||||||||||||
||||||||||||||||||||
Una solución más escalable consiste en aprovechar las

funciones AAA centralizadas, estandarizadas,
resistentes y flexibles. Por ejemplo, un servidor de
autenticación centralizado puede contener una base de
datos de todos los usuarios posibles y sus contraseñas,
así como políticas para autorizar las actividades de los
usuarios. A medida que los usuarios entran y salen, sus
cuentas pueden actualizarse fácilmente en un único
lugar. Todos los switches y routers consultarían al
servidor AAA para obtener información actualizada
sobre un usuario. Para mayor seguridad, los servidores
AAA también pueden admitir credenciales de usuario
multifactor y mucho más. Cisco implementa los
servicios AAA en su plataforma Identity Services
Engine (ISE).
Los servidores AAA suelen admitir los dos protocolos

siguientes para comunicarse con los recursos de la
empresa:
TACACS+: Un protocolo propietario de Cisco que separa cada una
de las funciones AAA. La comunicación es segura y cifrada a
través del puerto TCP 49.
RADIUS: protocolo basado en estándares que combina

autenticación y autorización en un único recurso. La comunicación
utiliza los puertos UDP 1812 y 1813 (contabilidad), pero no está
completamente cifrada.
Tanto TACACS+ como RADIUS están organizados

como un modelo cliente/servidor, donde un dispositivo
de autenticación actúa como un cliente que habla con un
servidor AAA. La Figura 4-9 muestra una vista
simplificada del proceso, donde un usuario está
intentando conectarse a un switch para propósitos de
gestión. En el rol de cliente AAA, el switch es a menudo
llamado Dispositivo de Acceso a la Red (NAD) o Servidor
||||||||||||||||||||
||||||||||||||||||||
de Acceso a la Red (NAS). Cuando un usuario intenta

conectarse al conmutador, el conmutador solicita las
credenciales al usuario, luego pasa las credenciales a lo
largo del proceso.
Technet24
||||||||||||||||||||
||||||||||||||||||||
al servidor AAA. En términos sencillos, si el usuario

pasa la autenticación, el servidor AAA devuelve un
mensaje de "aceptación" al conmutador. Si el servidor
AAA requiere credenciales adicionales, como en la
autenticación multifactor, devuelve un mensaje de
"desafío" al switch. En caso contrario, devuelve un
mensaje de "rechazo", denegando el acceso al usuario.
Figura 4-9 Vista simplificada de AAA
DESARROLLAR UN PROGRAMA DE
SEGURIDAD PARA EDUCAR A LOS
USUARIOS
Un enfoque eficaz que puede adoptar una empresa para
mejorar la seguridad de la información es educar a su
comunidad de usuarios a través de un programa de
seguridad corporativo. La mayoría de los usuarios no
tienen formación en TI, por lo que es posible que no
reconozcan las vulnerabilidades o no se den cuenta de
las consecuencias de sus propias acciones. Por ejemplo,
si los usuarios corporativos reciben un mensaje de
correo electrónico que contiene un mensaje relativo a
una orden legal para su arresto o una amenaza para
||||||||||||||||||||
||||||||||||||||||||
exponer algún supuesto comportamiento ilegal, podrían

verse tentados a
||||||||||||||||||||
||||||||||||||||||||
seguir un enlace a un sitio malicioso. Esta acción podría

infectar el ordenador de un usuario y abrir una puerta
trasera o introducir malware o un gusano que podría
afectar a las operaciones de la empresa.
Un programa de seguridad eficaz debe tener los

siguientes elementos básicos:
Concienciación de los usuarios: Todos los usuarios deben ser

conscientes de la necesidad de la confidencialidad de los datos para
proteger la información corporativa, así como sus propias
credenciales e información personal. También deben ser conscientes
de las amenazas potenciales, los esquemas para engañar y los
procedimientos adecuados para informar de incidentes de seguridad.
También se debe instruir a los usuarios para que sigan unas
directrices estrictas en relación con la pérdida de datos. Por ejemplo,
los usuarios no deben incluir información sensible en correos
electrónicos o archivos adjuntos, no deben guardar ni transmitir esa
información desde un teléfono inteligente, ni almacenarla en
servicios en la nube o unidades de almacenamiento extraíbles.
Formación de los usuarios: Se debe exigir a todos los usuarios

que participen en formaciones formales periódicas para que se
familiaricen con todas las políticas de seguridad de la empresa.
(Esto también implica que la empresa debe desarrollar y publicar
políticas de seguridad formales para que las sigan sus empleados,
usuarios y socios comerciales).
Control de acceso físico: Los lugares de infraestructura, como los

armarios de red y los centros de datos, deben permanecer cerrados de
forma segura. El acceso mediante tarjeta identificativa a lugares
sensibles es una solución escalable, que ofrece un registro de
auditoría de identidades y marcas de tiempo cuando se concede el
acceso. Los administradores pueden controlar el acceso de forma
granular y retirarlo rápidamente cuando se despide a un empleado.
Una de las claves para salir bien en los exámenes es realizar
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
sesiones de repaso espaciadas y repetitivas. Repase el

material de este capítulo utilizando las herramientas del
libro o las herramientas interactivas para el mismo
material que se encuentran en el sitio web
complementario del libro. Consulte el elemento "Su
plan de estudio" para obtener más detalles. En la Tabla
4-6 se describen los elementos clave de repaso y dónde
encontrarlos. Para hacer un mejor seguimiento de su
progreso en el estudio, registre cuándo completó estas
actividades en la segunda columna.

utilizado
Responder a las preguntas Libro, PTP

DIKTA
Revisar las tablas de Página web

memoria
Tema clave Descripción Página

Elemento Número
Figura 4-3 Terminología de seguridad 71
Sección Amenazas comunes a la 72

seguridad
||||||||||||||||||||
||||||||||||||||||||
Tabla 4-3 Tipos de malware 79
Tabla 4-4 Vulnerabilidades de la 80

seguridad humana
Párrafo Vulnerabilidades de las 80

contraseñas
Lista Funciones AAA 82
Lista Educación de los usuarios 83

AAA
ataque de amplificación
ataque de fuerza bruta
ataque de desbordamiento del búfer
ataque de denegación de servicio (DoS)
ataque de diccionario
ataque distribuido de denegación de servicio (DDoS)
exploit
malware
ataque de intermediario
Technet24
||||||||||||||||||||
||||||||||||||||||||
técnica de mitigación
autenticación multifactor
adivinar contraseña
pharming
phishing
ataque de reconocimiento
ataque por reflexión
ingeniería social
phishing dirigido
ataque de suplantación de identidad
amenaza
caballo de Troya
virus
vulnerabilidad
ataque al abrevadero
caza de ballenas
||||||||||||||||||||
||||||||||||||||||||
gusano
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 5. Seguridad de
los dispositivos de red
Seguridad de los
dispositivos de red

1.1 Explicar el papel de los componentes de red
1.1.c Cortafuegos de nueva generación e IPS
4.0 Servicios IP
4.8 Configurar dispositivos de red para acceso
remoto usando SSH

5.3 Configurar el control de acceso a los
dispositivos mediante contraseñas locales
Todos los dispositivos de la red -puntos finales,

servidores y dispositivos de infraestructura como
routers y switches- incluyen algunos métodos para que
los dispositivos se comuniquen legítimamente
utilizando la red. Para proteger esos dispositivos, el plan
de seguridad incluirá una amplia variedad de
herramientas y técnicas de mitigación, con los capítulos
de la Parte II de este libro discutiendo una gran variedad
de esas herramientas y técnicas.
||||||||||||||||||||
||||||||||||||||||||
Este capítulo se centra en dos necesidades particulares

de seguridad en una red empresarial. En primer lugar,
es necesario proteger el acceso a la CLI de los
dispositivos de red. El equipo de ingeniería de red
necesita poder acceder a los dispositivos remotamente,
por lo que los dispositivos necesitan permitir el acceso
remoto SSH (y posiblemente Telnet). La primera mitad
de este capítulo discute cómo configurar las contraseñas
para mantenerlas seguras y cómo filtrar los intentos de
inicio de sesión en los propios dispositivos.
La segunda mitad del capítulo se centra en dos

funciones de seguridad diferentes que se implementan
con mayor frecuencia con dispositivos diseñados
específicamente: los cortafuegos y los IPS. Estos
dispositivos supervisan conjuntamente el tráfico en
tránsito para determinar si el tráfico es legítimo o si
puede formar parte de algún exploit. Si se considera
parte de un exploit, o si es contrario a las reglas
definidas por los dispositivos, pueden descartar los
mensajes, deteniendo cualquier ataque antes de que se
inicie.

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||

Proteger las contraseñas de IOS 1-4
Cortafuegos y sistemas de prevención de intrusiones 5, 6
1. Imagine que ha configurado el comando enable

secret, seguido del comando enable password,
desde la consola. Sales del switch y vuelves a entrar
en la consola. ¿Qué comando define la contraseña
que tuvo que introducir para acceder al modo
privilegiado?
1. activar contraseña
2. activar secreto
3. Ni
4. El comando contraseña, si está configurado
2. Algunos comandos IOS almacenan las contraseñas

como texto sin cifrar, pero puedes cifrar las
contraseñas con el comando global service
password-encryption. En comparación, otros
comandos almacenan un hash calculado de la
contraseña en lugar de almacenar la contraseña.
Comparando las dos opciones, ¿cuál de las
respuestas es la más acertada sobre por qué un
método es mejor que el otro?
1. Es preferible utilizar hashes porque las contraseñas cifradas de
IOS se pueden descifrar fácilmente.
2. El uso de hashes es preferible debido al gran esfuerzo de CPU
necesario para el cifrado.
||||||||||||||||||||
||||||||||||||||||||
3. Es preferible utilizar el cifrado porque proporciona una

protección de contraseña más sólida.
4. Es preferible utilizar el cifrado debido al gran esfuerzo de
CPU que requieren los hashes.
3. Un ingeniero de redes emite un comando show

running-config y sólo ve una línea de salida que
menciona el comando enable secret, como se
muestra a continuación:
enable secret 5 $1$ZGMA$e8cmvkz4UjiJhVp7.maLE1
¿Cuál de las siguientes afirmaciones es cierta sobre

los usuarios de este router?
1. El usuario debe teclear
$1$ZGMA$e8cmvkz4UjiJhVp7.maLE1 para acceder al
modo de habilitación.
2. El router hará hash de la contraseña en texto claro que el
usuario escriba para compararla con la contraseña hash.
3. Un comando de configuración no service password-
encryption descifraría esta contraseña.
4. El router descifrará la contraseña en la configuración para
compararla con la contraseña en texto claro tecleada por
el usuario.
4. Se ha añadido una ACL de una sola línea a la

configuración de un enrutador mediante el
comando ip access-list 1 permit 172.16.4.0
0.0.1.255. La configuración también incluye el
comando access-class 1 in en el modo de
configuración VTY. ¿Qué respuesta describe con
exactitud cómo utiliza el router la ACL 1?
1. Sólo los hosts de la subred 172.16.4.0/23 pueden hacer telnet en el router.
2. Los usuarios de la CLI no pueden hacer telnet desde el
router sólo a los hosts de la subred 172.16.4.0/23.
3. Sólo los hosts de la subred 172.16.4.0/23 pueden iniciar
sesión, pero no pueden acceder al modo de habilitación del
||||||||||||||||||||
||||||||||||||||||||
router.
Technet24
||||||||||||||||||||
||||||||||||||||||||
4. El router sólo reenviará paquetes con direcciones de origen

en la subred 172.16.4.0/23.
5. Un cortafuegos de nueva generación se encuentra

en el extremo de la conexión de una empresa a
Internet. Se ha configurado para impedir que los
clientes Telnet que residen en Internet accedan a
los servidores Telnet dentro de la empresa. ¿Cuál
de los siguientes elementos podría utilizar un
cortafuegos de nueva generación que no utilizaría
un cortafuegos tradicional?
1. Coincidencia de destino de mensaje conocido puerto 23
2. Coincidencia de los datos de aplicación del mensaje
3. Mensaje coincidente Protocolo IP 23
4. Puertos TCP de origen de mensajes coincidentes superiores a 49152
6. ¿Qué acciones muestran un comportamiento

típicamente soportado por un IPS de próxima
generación de Cisco (NGIPS) más allá de las
capacidades de un IPS tradicional? (Elija dos
respuestas)
1. Recopilar y utilizar información basada en el host para el contexto
2. Comparaciones entre mensajes y una base de datos de
firmas de exploits
3. Registro de eventos para su posterior revisión por el equipo de seguridad
4. Filtrar URIs utilizando puntuaciones de reputación
1B
2A
3B
4 A
5B
||||||||||||||||||||
||||||||||||||||||||
6 A, D
Temas básicos
PROTEGER LAS CONTRASEÑAS D E IOS
La mejor forma de proteger las contraseñas en los
dispositivos Cisco IOS es no almacenarlas en los
dispositivos IOS. Es decir, para cualquier función que
pueda utilizar un servidor externo de autenticación,
autorización y contabilidad (AAA), utilícelo.
Sin embargo, es común almacenar algunas contraseñas
en la configuración de un router o switch, y esta
primera sección del capítulo discute algunas de las
formas de proteger esas contraseñas.
A modo de breve repaso, la Figura 5-1 resume algunas

configuraciones típicas de seguridad de inicio de sesión
en un router o switch. En la parte inferior izquierda, se
ve el soporte Telnet configurado, con el uso de una
contraseña solamente (no se requiere nombre de
usuario). A la derecha, la configuración agrega soporte
para login con nombre de usuario y contraseña,
soportando usuarios Telnet y SSH. La parte superior
izquierda muestra el comando necesario para definir una
contraseña de habilitación de forma segura.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 5-1 Ejemplo de configuración de seguridad de inicio de sesión
Nota
La configuración en el extremo derecho de la figura

soporta tanto SSH como Telnet, pero considera
permitir sólo SSH utilizando en su lugar el comando
transport input ssh. El protocolo Telnet envía todos
los datos sin cifrar, por lo que cualquier atacante que
copie el mensaje con un inicio de sesión Telnet
tendrá una copia de la contraseña.
El resto de esta primera sección trata sobre cómo hacer

que estas contraseñas sean seguras. En particular, esta
sección examina las formas de evitar mantener
contraseñas en texto claro en la configuración y
almacenar las contraseñas de manera que sea difícil para
los atacantes aprender la contraseña.
Cifrado de contraseñas antiguas de IOS con
||||||||||||||||||||
||||||||||||||||||||
servicio de cifrado de contraseñas

Algunas contraseñas antiguas de IOS crean una
exposición de seguridad porque las contraseñas existen
en el archivo de configuración como texto claro. Estas
contraseñas en texto claro pueden verse en versiones
impresas de los archivos de configuración, en una copia
de seguridad del archivo de configuración almacenada
en un servidor o en la pantalla de un ingeniero de redes.
Cisco intentó resolver este problema de texto claro

añadiendo un comando para cifrar esas contraseñas: el
comando de configuración global service password-
encryption. Este comando encripta las contraseñas que
normalmente se mantienen como texto claro,
específicamente las contraseñas para estos comandos:
contraseña contraseña (modo consola o vty)
nombre de usuario contraseña contraseña
(global) enable contraseña contraseña
(global)
Para ver cómo funciona, el Ejemplo 5-1 muestra cómo el

comando service password-encryption encripta la
contraseña de texto claro de la consola. El ejemplo
utiliza el comando show running-config | section
line con 0 tanto antes como después de la
encriptación; este comando lista sólo la sección de la
configuración sobre la consola.
Ejemplo 5-1 Cifrado y contraseña de servicio
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
cifrado Comando
Switch3# show running-config | section line con 0

línea con 0
contraseña cisco
login
Switch3# configurar terminal

Finalice con CNTL/Z. Switch3(config)# service encriptación-
contraseña Switch3(config)# ^Z
Switch3# show running-config | section line con 0

línea con 0
contraseña 7 070C285F4D06
login
Un examen detallado de la salida del comando show

running-config antes y después revela tanto el efecto
obvio como un nuevo concepto. El proceso de
encriptación ahora oculta la contraseña original en texto
claro. También, IOS necesita una manera de señalar que
el valor en el comando password lista una contraseña
encriptada en lugar del texto claro. IOS añade el tipo de
cifrado o codificación de "7" al comando, que se refiere
específicamente a las contraseñas cifradas con el
comando de cifrado de contraseña de servicio. (IOS
considera que las contraseñas en texto claro son de tipo
0; algunos comandos enumeran el 0 y otros no).
Mientras que el comando global service password-

encryption encripta las contraseñas, el comando
global no service password-encryption no
desencripta inmediatamente las contraseñas a su
estado claro.
||||||||||||||||||||
||||||||||||||||||||
estado del texto. En su lugar, el proceso funciona como

se muestra en la Figura 5-2. Básicamente, después de
introducir el comando no service password-
encryption, las contraseñas permanecen encriptadas
hasta que cambies una contraseña.
Figura 5-2 La encriptación es inmediata; la

desencriptación espera al siguiente cambio de
contraseña
Lamentablemente, el comando de cifrado de

contraseñas del servicio no protege muy bien las
contraseñas. Armado con el valor cifrado, puedes buscar
en Internet y encontrar sitios con herramientas para
descifrar estas contraseñas. De hecho, puedes tomar la
contraseña encriptada de este ejemplo, conectarla a uno
de estos sitios, y se desencripta a "cisco". Así pues, el
comando service password- encryption ralentizará a los
curiosos, pero no detendrá a un atacante experto.
Codificación de las contraseñas de

acceso con hash
En los primeros días de IOS, Cisco utilizó el comando
global enable password password para definir la
contraseña que los usuarios tenían que utilizar para
llegar al modo enable (después de utilizar el comando
enable EXEC). Sin embargo, a medida que
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
como se acaba de indicar, el comando enable

password password almacenaba la contraseña como
texto en claro, y el comando service password-
encryption encriptaba la contraseña de forma que
era fácil de desencriptar.
Cisco resolvió el problema de que sólo había formas

débiles de almacenar la contraseña del comando enable
password global haciendo un reemplazo más seguro: el
comando enable secret password global. Sin embargo,
ambos comandos existen en IOS incluso hoy en día.
Las siguientes páginas examinan estos dos comandos
desde un par de ángulos, incluyendo las interacciones
entre estos dos comandos, por qué el comando enable
secret es más seguro, junto con una nota sobre algunos
avances en cómo IOS asegura la contraseña enable
secret.
Interacciones entre Habilitar Contraseña y Habilitar

Secreto
Primero, para la vida real: usa el comando enable
secret password global, e ignora el comando enable
password password global. Esto es así desde hace
unos 20 años.
Sin embargo, para ser completos, Cisco nunca ha

eliminado de IOS el comando enable password,
mucho más débil. Así que, en un mismo switch (o
router), se puede configurar uno u otro, ambos, o
ninguno. Entonces, ¿qué espera el switch que
escribamos como contraseña para acceder al modo
enable? Se reduce a estas reglas:
||||||||||||||||||||
||||||||||||||||||||
Ambos comandos configurados: Los usuarios

deben utilizar la contraseña del comando enable
secret password (e ignorar el comando enable
password password).
Sólo hay un comando configurado: Utiliza la

contraseña en ese único comando.
Ningún comando configurado (por defecto): Los

usuarios de consola pasan directamente al modo de
habilitación sin que se les pida una contraseña; los
usuarios de Telnet y SSH son rechazados sin
opción de proporcionar una contraseña de
habilitación.
Cómo hacer que el secreto sea realmente secreto con un hash

El comando enable secret de Cisco protege el valor de
la contraseña al no almacenar nunca la contraseña en
texto claro en la configuración. Sin embargo, esa frase
puede causar un poco de confusión: Si el router o switch
no recuerda la contraseña en texto claro, ¿cómo puede el
switch saber que el usuario escribió la contraseña
correcta después de usar el comando enable? Esta
sección trabaja a través de algunos conceptos básicos
para mostrarle cómo y apreciar por qué el valor de la
contraseña es secreto.
En primer lugar, por defecto, IOS utiliza una función

hash llamada Message Digest 5 (MD5) para almacenar
un valor alternativo en la configuración, en lugar de la
contraseña en texto claro. Piensa en MD5 como una
fórmula matemática bastante compleja. Además, esta
fórmula se elige de modo que incluso si conoces el
resultado exacto de la fórmula-es decir, el resultado
después de alimentar la contraseña de texto claro a través
||||||||||||||||||||
||||||||||||||||||||
de la fórmula como
Technet24
||||||||||||||||||||
||||||||||||||||||||
es computacionalmente difícil calcular la contraseña

original en texto claro. La figura 5-3 muestra las ideas
principales:
Figura 5-3 Naturaleza unidireccional del hash MD5

para crear el secreto
Nota
"Computacionalmente difícil" es casi una frase en

clave, lo que significa que los diseñadores de la
función esperan que nadie esté dispuesto a tomarse
el tiempo de calcular el texto original en claro.
Entonces, si la contraseña original en texto claro no

puede volver a crearse, ¿cómo puede un switch o un
router utilizarla para compararla con la contraseña en
texto claro tecleada por el usuario? La respuesta
depende de otro hecho acerca de estos hashes de
seguridad como MD5: cada entrada de texto claro
resulta en un resultado único de la fórmula matemática.
El comando enable secret fred genera un hash MD5.

Si un usuario escribe fred al intentar entrar en enable
||||||||||||||||||||
||||||||||||||||||||
IOS ejecutará MD5 contra ese valor y obtendrá el

mismo hash MD5 que aparece en el comando enable
secret, por lo que IOS permite al usuario acceder al
modo enable. Si el usuario escribiera cualquier otro
valor además de fred, IOS calcularía un hash MD5
diferente al valor almacenado con el comando enable
secret, e IOS rechazaría el intento de ese usuario de
alcanzar el modo enable.
Sabiendo este hecho, el switch puede hacer una

comparación cuando un usuario escribe una
contraseña después de usar el comando enable
EXEC de la siguiente manera:
Paso 1. IOS calcula el hash MD5 de la contraseña

en el comando enable secret. IOS calcula el
hash MD5 de la contraseña en el comando
enable secret y almacena el hash de la
contraseña en la configuración.
Paso 2. Cuando el usuario escribe el comando
enable para alcanzar el modo enable, una
contraseña que necesita ser chequeada contra
ese comando de configuración, IOS hashes la
contraseña en texto claro como fue escrita por
el usuario.
Paso 3. IOS compara los dos valores hash. IOS
compara los dos valores hash: si son iguales, la
contraseña escrita por el usuario debe ser la
misma que la contraseña configurada.
Como resultado, IOS puede almacenar el hash de la
contraseña pero nunca almacenar la contraseña en texto
||||||||||||||||||||
||||||||||||||||||||
claro; sin embargo, aún puede determinar si el usuario

escribió la misma contraseña.
Los conmutadores y enrutadores ya utilizan la lógica descrita
Technet24
||||||||||||||||||||
||||||||||||||||||||
aquí, pero puede ver la evidencia mirando la

configuración del switch. El Ejemplo 5-2 muestra la
creación del comando enable secret, con algunos
detalles relacionados. Este ejemplo muestra el valor
almacenado (hash) como se revela en la salida del
comando show running-configuration. Esa salida
también muestra que IOS cambió el comando enable
secret fred para listar el tipo de encriptación 5 (lo que
significa que la contraseña listada es en realidad un
hash MD5 de la contraseña en texto claro). La cadena
de texto largo de jerigonza es el hash, evitando que
otros lean la contraseña.
Ejemplo 5-2 Cisco IOS codifica la contraseña "cisco"

como tipo 5 (MD5)
Switch3(config)# enable secreto fred

Switch3(config)# ^Z
Switch3# show running-config | include enable secret
enable secret 5
$1$ZGMA$e8cmvkz4UjiJhVp7.maLE1 Switch3#
configure terminal
con CNTL/Z. Switch3(config)# no enable secret
Switch3(config)# ^Z
El final del ejemplo también muestra un importante

punto secundario sobre la eliminación de la contraseña
secreta de habilitación: después de estar en modo de
habilitación, puede eliminar la contraseña secreta de
habilitación utilizando el comando no enable secret, sin
ni siquiera tener que introducir el valor de la contraseña.
También puedes sobreescribir la antigua contraseña
simplemente repitiendo el comando
||||||||||||||||||||
||||||||||||||||||||
enable secret. Pero no puedes ver la contraseña

original en texto claro.
Nota
El Ejemplo 5-2 muestra otro atajo que ilustra cómo

trabajar a través de una salida larga del comando
show, esta vez utilizando la tubería al comando
include. La parte | include enable secret del
comando procesa la salida de show running-
config para incluir sólo las líneas con el texto
"enable secret" que distingue mayúsculas de
minúsculas.
Hashes mejorados para Enable Secret de Cisco

El uso de cualquier función hash para codificar
contraseñas depende de varias características clave de la
función hash en particular. En particular, cada posible
valor de entrada debe dar como resultado un único valor
hash, de modo que cuando los usuarios escriban una
contraseña, sólo un valor de contraseña coincida con
cada valor hash.
Además, el algoritmo hash debe dar lugar a cálculos
matemáticos difíciles (en otras palabras, un dolor de
cabeza) para calcular la contraseña en texto claro
basada en el valor hash para disuadir a los atacantes.
El algoritmo hash MD5 existe desde hace 30 años.

Durante esos años, los ordenadores se han vuelto mucho
más rápidos y los investigadores han encontrado formas
creativas de atacar el algoritmo MD5, haciendo que
MD5 sea menos difícil de descifrar. Es decir, alguien
que viera tu configuración en ejecución podría
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
le resultará más fácil recrear sus contraseñas secretas en

texto claro que en los primeros años de MD5.
Estos hechos no pretenden decir que MD5 sea malo,

pero al igual que muchas funciones criptográficas
anteriores a MD5, se ha progresado y se necesitaban
nuevas funciones. Para proporcionar opciones más
recientes que crearan un desafío mucho mayor a los
atacantes, Cisco añadió dos hashes adicionales en la
década de 2010, como se indica en la Figura 5-4.
Figura 5-4 Cronología de Cifrados/Hashes de

Contraseñas Cisco IOS
IOS admite ahora dos tipos de algoritmos alternativos

en las imágenes IOS más recientes de routers y
conmutadores. Ambos utilizan un hash SHA-256 en
lugar de MD5, pero con dos opciones más nuevas, cada
una de las cuales tiene algunas diferencias en las
particularidades de cómo cada algoritmo utiliza SHA-
256. La Tabla 5-2 muestra la configuración de los tres
tipos de algoritmos en el comando enable secret.
Tabla 5-2 Comandos y tipos de codificación para el

enable secret Comando
Comando Tipo Algoritmo
||||||||||||||||||||
||||||||||||||||||||
enable [algorithm-type md5] secret 5 MD5

contraseña
enable algorithm-type sha256 secret 8 SHA-256

contraseña
activar algoritmo-tipo scrypt secreto 9 SHA-256

contraseña
El ejemplo 5-3 muestra el comando enable secret siendo

cambiado de MD5 al algoritmo scrypt. Cabe destacar
que el ejemplo muestra que sólo debe existir un
comando enable secret entre los tres comandos de la
Tabla 5-2. Básicamente, si configuras otro comando
enable secret con un tipo de algoritmo diferente, ese
comando reemplaza cualquier comando enable secret
existente. Básicamente, si configuras otro comando
enable secret con un tipo de algoritmo diferente, ese
comando reemplaza cualquier comando enable secret
existente.
Ejemplo 5-3 Cisco IOS codifica la contraseña

"mypass1" como tipo 9 (SHA-256)
R1# show running-config | include enable

enable secret 5
$1$ZSYj$725dBZmLUJ0nx8gFPTtTv0 R1# configure
terminal
con CNTL/Z. R1(config)# enable algorithm-type scrypt secret
mypass1 R1(config)# ^Z
R1#
R1# show running-config | include enable
enable secret 9 $9$II/EeKiRW91uxE$fwYuOE5EHoii16AWv2wSywkLJ/KNeGj
R1#
Siguiendo el proceso mostrado en el ejemplo, el primer

comando confirma que el secreto de habilitación
||||||||||||||||||||
||||||||||||||||||||
actual
Technet24
||||||||||||||||||||
||||||||||||||||||||
utiliza el tipo de codificación 5, lo que significa que

utiliza MD5. En segundo lugar, el usuario configura la
contraseña utilizando el tipo de algoritmo scrypt. El
último comando confirma que sólo existe un comando
enable secret en la configuración, ahora con
codificación tipo 9.
Codificación de las contraseñas de

los nombres de usuario locales
Cisco añadió el comando enable secret en la década
de 1990 para superar los problemas con el comando
enable password. Los comandos username
password y username secret tienen una historia
similar.
Originalmente, IOS soportaba el comando username
user password password-un comando que tenía esos
mismos problemas de ser una contraseña en texto
claro o un valor pobremente encriptado (con la
función de encriptación de contraseñas del
servicio). Muchos años después, Cisco añadió el
comando global username user secret password, que
codificaba la contraseña como un hash MD5, añadiendo
más tarde soporte para los nuevos hashes SHA-256.
Hoy en día, el comando username secret es preferido

sobre el comando username password; sin embargo,
IOS no utiliza la misma lógica para el comando
username que para permitir que ambos comandos
enable secret y enable password existan en la misma
configuración. IOS permite
||||||||||||||||||||
||||||||||||||||||||
Sólo un comando de nombre de usuario para un nombre de

usuario determinado, ya sea un comando de nombre de usuario
contraseña contraseña o un comando de nombre de usuario
contraseña secreta.
Una mezcla de comandos (nombre de usuario contraseña y

nombre de usuario secreto) en el mismo router o switch (para
diferentes nombres de usuario)
Siempre que sea posible, debe utilizar el comando

nombre de usuario secreto en lugar del comando
nombre de usuario contraseña.
Sin embargo, ten en cuenta que algunas funciones de
IOS requieren que el router conozca una contraseña en
texto claro a través del comando username (por
ejemplo, cuando se realizan algunos métodos de
autenticación comunes para enlaces serie llamados PAP
y CHAP). En estos casos, es necesario utilizar el
comando username password.
Como se mencionó, las versiones más recientes de IOS

tanto en switches como en routers usan las opciones de
codificación adicionales más allá de MD5, tal como se
soporta con el comando enable secret. La Tabla 5-3
muestra la sintaxis de esas tres opciones en el comando
username, con la opción MD5 mostrada como una
opción porque es la predeterminada usada con el
comando username secret.
Tabla 5-3 Comandos y tipos de codificación para el

nombre de usuario secreto Comando
Comando Tipo Algoritmo
nombre de usuario [algoritmo-tipo md5] 5 MD5

contraseña secreta
||||||||||||||||||||
||||||||||||||||||||
nombre de usuario algoritmo-tipo 8 SHA-256

sha256 secreto contraseña
Technet24
||||||||||||||||||||
||||||||||||||||||||
nombre de usuario algoritmo-tipo scrypt 9 SHA-256

secreto contraseña
Control de ataques a contraseñas

con ACLs
Los atacantes pueden tratar repetidamente de iniciar
sesión en sus dispositivos de red para obtener acceso,
pero IOS tiene una característica que utiliza ACLs para
evitar que el atacante vea siquiera una solicitud de
contraseña. Cuando un usuario externo se conecta a un
router o switch utilizando Telnet o SSH, IOS utiliza una
línea vty para representar esa conexión de usuario. IOS
puede aplicar una ACL a las líneas vty, filtrando las
direcciones que pueden conectarse por Telnet o SSH al
router o switch. Si se filtra, el usuario nunca ve un
prompt de login.
Por ejemplo, imagina que todos los dispositivos del

personal de ingeniería de red se conectan a la subred
10.1.1.0/24. La política de seguridad establece que sólo
al personal de ingeniería de red se le debe permitir
telnet o SSH en cualquiera de los routers Cisco en una
red. En tal caso, la configuración mostrada en el
Ejemplo 5-4 podría ser usada en cada router para
denegar el acceso desde direcciones IP que no estén en
esa subred.
Ejemplo 5-4 Control de acceso vty mediante el

comando access- class
line vty 0 4
login password
cisco
||||||||||||||||||||
||||||||||||||||||||
clase de acceso 3 en
¡!
¡! Siguiente comando es un comando global que coincide con los
paquetes IPv4 con
Una dirección de origen que empiece por 10.1.1.
El comando access-class se refiere a la lógica de

coincidencia en access-list 3. La palabra clave in se
refiere a las conexiones Telnet y SSH en este router-en
otras palabras, la gente que hace telnet en este router.
Tal y como está configurada, ACL 3 comprueba la
dirección IP de origen de los paquetes para conexiones
Telnet entrantes.
IOS también soporta el uso de ACLs para filtrar

conexiones Telnet y SSH salientes. Por ejemplo,
considere un usuario que primero utiliza Telnet o SSH
para conectarse a la CLI y ahora se encuentra en modo
de usuario o habilitación. Con un filtro vty de salida,
IOS aplicará la lógica ACL si el usuario intenta los
comandos telnet o ssh para conectarse fuera del
dispositivo local a otro dispositivo.
Para configurar una ACL de salida VTY, utilice el

comando access- class acl out en el modo de
configuración VTY. Una vez configurada, el router filtra
cualquier intento realizado por los usuarios vty actuales
de utilizar los comandos telnet y ssh para iniciar nuevas
conexiones a otros dispositivos.
De las dos opciones -proteger las conexiones entrantes y

salientes- proteger las conexiones entrantes es, con
diferencia, la más importante y la más común. Sin
embargo, para ser completos, las ACL VTY salientes
tienen una característica sorprendentemente extraña en
cómo usan la ACL. Cuando la palabra clave out
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
la ACL IP estándar listada en el comando access-

class realmente mira la dirección IP de destino, y no
la fuente. Es decir, filtra en función del dispositivo al
que intenta conectarse el comando telnet o ssh.
CORTAFUEGOS Y SISTEMAS DE
PREVENCIÓN DE INTRUSIONES
El siguiente tema examina las funciones de un par de
tipos diferentes de dispositivos de red: cortafuegos y
sistemas de prevención de intrusiones (IPS). Ambos
dispositivos trabajan para proteger las redes, pero con
objetivos y enfoques ligeramente diferentes.
Esta segunda sección principal del capítulo examina

cada uno de ellos. En primer lugar, esta sección analiza
las características principales tradicionales tanto de los
cortafuegos como de los IPS. La sección termina con
una descripción de las nuevas características de la
generación actual de estos productos, llamados
productos de nueva generación, que mejoran las
funciones de cada uno.
Cortafuegos tradicionales
Tradicionalmente, un cortafuegos se sitúa en la ruta de
reenvío de todos los paquetes para poder elegir qué
paquetes descartar y cuáles permitir. De este modo, el
cortafuegos protege la red de diferentes tipos de
problemas permitiendo que sólo los tipos de tráfico
previstos fluyan dentro y fuera de la red. De hecho, en su
forma más básica, los cortafuegos hacen el mismo tipo
de trabajo que los routers hacen con las ACL, pero los
cortafuegos pueden realizar ese filtrado de paquetes
||||||||||||||||||||
||||||||||||||||||||
con muchas más opciones, así como realizar otras

tareas de seguridad.
La Figura 5-5 muestra un diseño de red típico para un

sitio que utiliza un cortafuegos físico. La figura muestra
un cortafuegos, como el cortafuegos Cisco Adaptive
Security Appliance (ASA), conectado a un router
Cisco, que a su vez se conecta a Internet. Todo el
tráfico de la empresa que vaya a Internet o proceda de
Internet se enviaría a través del cortafuegos. El
cortafuegos tendría en cuenta sus reglas y decidiría para
cada paquete si debe permitirse su paso.
Figura 5-5 Posición del cortafuegos en la ruta de

reenvío de paquetes
Aunque los cortafuegos tienen algunas funciones

similares a las de un router (como el reenvío de paquetes
y el filtrado de paquetes), ofrecen funciones de seguridad
mucho más avanzadas que un router tradicional. Por
ejemplo, la mayoría de los cortafuegos pueden utilizar
los siguientes tipos de lógica para decidir si descartar o
permitir un paquete:
Al igual que las ACL de IP de router, coinciden con las
direcciones IP de origen y destino Al igual que las ACL de IP de
router, identifican las aplicaciones coincidiendo con su estática

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
puertos TCP y UDP conocidos
Observar los flujos de la capa de aplicación para saber qué puertos

TCP y UDP adicionales utiliza un flujo concreto, y filtrar en
función de esos puertos.
Comparar el texto del URI de una solicitud HTTP, es decir,

examinar y comparar el contenido de lo que suele denominarse
dirección web, y comparar patrones para decidir si se permite o
deniega la descarga de la página web identificada por ese URI.
Mantener información de estado almacenando información sobre

cada paquete, y tomar decisiones sobre el filtrado de paquetes
futuros basándose en la información de estado histórica (lo que se
denomina inspección de estado, o ser un cortafuegos de estado).
La función stateful firewall proporciona los medios para

prevenir una variedad de ataques y es una de las
diferencias más obvias entre el procesamiento ACL de
un router frente al filtrado de seguridad de un firewall.
Los routers deben pasar el menor tiempo posible
procesando cada paquete para que los paquetes
experimenten poco retraso al pasar por el router. El
router no puede tomarse el tiempo necesario para
recopilar información sobre un paquete y, a
continuación, para futuros paquetes, considerar alguna
información de estado guardada sobre paquetes
anteriores a la hora de tomar una decisión de filtrado.
Debido a que se centran en la seguridad de la red, los
cortafuegos sí guardan alguna información sobre los
paquetes y pueden considerar esa información para
futuras decisiones de filtrado.
Como ejemplo de las ventajas de utilizar un cortafuegos

con seguimiento de estado, considere un simple ataque
de denegación de servicio (DoS). Un atacante puede
realizar este tipo de ataque contra un servidor web
utilizando herramientas que creen (o empiecen a crear)
un gran volumen de conexiones TCP al servidor. El
||||||||||||||||||||
||||||||||||||||||||
cortafuegos podría permitir conexiones TCP a ese

servidor normalmente, pero
||||||||||||||||||||
||||||||||||||||||||
Imaginemos que el servidor puede recibir normalmente

10 nuevas conexiones TCP por segundo en condiciones
normales y 100 por segundo en los momentos de mayor
actividad. Un ataque DoS podría intentar miles o más
conexiones TCP por segundo, aumentando el uso de
CPU y RAM en el servidor y, finalmente, sobrecargar
el servidor hasta el punto de que no puede servir a los
usuarios legítimos.
Un cortafuegos con seguimiento de estado podría estar

rastreando el número de conexiones TCP por segundo,
es decir, registrando información de estado basada en
paquetes anteriores, incluido el número de solicitudes de
conexión TCP desde cada dirección IP de cliente a cada
dirección de servidor. El cortafuegos con seguimiento de
estado podría notar un gran número de conexiones TCP,
comprobar su información de estado y, a continuación,
darse cuenta de que el número de solicitudes es muy
grande desde un pequeño número de clientes a ese
servidor en particular, lo que es típico de algunos tipos
de ataques DoS. El cortafuegos con estado podría
entonces empezar a filtrar esos paquetes, ayudando al
servidor web a sobrevivir al ataque, mientras que un
cortafuegos sin estado o un router ACL no habrían
tenido la información de estado histórica para darse
cuenta de que se estaba produciendo un ataque DoS.
Zonas de seguridad
Los cortafuegos no sólo filtran paquetes, sino que
también prestan mucha atención a qué host inicia las
comunicaciones. Este concepto es más obvio con TCP
como protocolo de capa de transporte, donde el cliente
inicia la conexión TCP enviando un segmento TCP que
||||||||||||||||||||
sólo establece el bit SYN (como se ve en la Figura 1-5
||||||||||||||||||||
del Capítulo 1, "Introducción a TCP/IP").
Technet24
||||||||||||||||||||
||||||||||||||||||||
Transporte y aplicaciones").
Los cortafuegos utilizan una lógica que considera qué

host inició una conexión TCP observando estos
segmentos TCP iniciales. Para ver la importancia de
quién inicia las conexiones, piense en una red
empresarial típica con conexión a Internet, como se
muestra en la Figura 5-6. La empresa tiene usuarios
dentro de la empresa que abren navegadores web,
iniciando conexiones a servidores web a través de
Internet. La empresa tiene usuarios dentro de la
empresa que abren navegadores web, iniciando
conexiones a servidores web a través de Internet. Sin
embargo, al tener una conexión a Internet en
funcionamiento, esa misma empresa abre la posibilidad
de que un atacante intente crear una conexión TCP a los
servidores web internos de la empresa utilizados para el
procesamiento de nóminas. Por supuesto, la empresa no
quiere que usuarios aleatorios de Internet o atacantes
puedan conectarse a su servidor de nóminas.
Figura 5-6 Permitir conexiones salientes e impedir

||||||||||||||||||||
||||||||||||||||||||
conexiones entrantes
||||||||||||||||||||
||||||||||||||||||||
Los cortafuegos utilizan el concepto de zonas de

seguridad (también llamadas zonas para abreviar) para
definir qué hosts pueden iniciar nuevas conexiones. El
cortafuegos tiene reglas, y esas reglas definen qué host
puede iniciar conexiones de una zona a otra zona.
Además, mediante el uso de zonas, un cortafuegos
puede colocar varias interfaces en la misma zona, en los
casos en que varias interfaces deban tener las mismas
reglas de seguridad aplicadas. La Figura 5-7 representa
la idea con la parte interna de la empresa considerada en
una zona separada comparada con las interfaces
conectadas hacia Internet.
Figura 5-7 Uso de zonas de seguridad con cortafuegos
La regla de cortafuegos más básica cuando se utilizan

dos zonas como en la Figura 5-7 se reduce a esta
lógica:
Permitir a los hosts de la zona interior iniciar

conexiones con hosts de la zona exterior, para un
conjunto predefinido de puertos seguros y bien
conocidos (como el puerto HTTP 80, por ejemplo).
Tenga en cuenta que con esta simple regla, se permite el

tráfico correcto mientras se filtra el tráfico no deseado por
defecto. Los cortafuegos normalmente rechazan todo el
tráfico a menos que una regla permita específicamente el
paquete. Así que, con esta simple regla para
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
permiten a los usuarios internos iniciar conexiones

con la zona externa, y sólo eso, el cortafuegos también
impide a los usuarios externos iniciar conexiones con
los hosts internos.
La mayoría de las empresas tienen una zona interior y

otra exterior, así como una zona especial denominada
zona desmilitarizada (DMZ).
Aunque el nombre DMZ proviene del mundo real, se ha
utilizado en TI durante décadas para referirse a una zona
de seguridad de cortafuegos utilizada para colocar
servidores que necesitan estar disponibles para su uso
por los usuarios en la Internet pública. Por ejemplo, la
Figura 5-8 muestra un diseño típico de borde de
Internet, con la adición de un par de servidores web en
su DMZ conectados a través del cortafuegos. El
cortafuegos necesita entonces otra regla que permita a
los usuarios de la zona exterior
-es decir, los usuarios en Internet- para iniciar
conexiones a esos servidores web en la DMZ. Al
separar esos servidores web en la DMZ, lejos del resto
de la empresa, ésta puede impedir que los usuarios de
Internet intenten conectarse a los dispositivos internos
de la zona interior, evitando así muchos tipos de ataques
.
||||||||||||||||||||
||||||||||||||||||||
Figura 5-8 Uso de una DMZ para servidores de

empresa que necesitan ser accesibles desde
Internet
Sistemas de prevención de intrusiones (IPS)

Tradicionalmente, un cortafuegos funciona con un
conjunto de reglas configuradas por el usuario sobre por
dónde debe permitirse que fluyan los paquetes en una
red. El cortafuegos tiene que situarse en la ruta de los
paquetes para poder filtrarlos, redirigirlos para su
recogida y posterior análisis, o dejar que continúen hacia
su destino.
Un sistema tradicional de prevención de intrusiones

(IPS) puede situarse en la ruta que siguen los paquetes a
través de la red, y puede filtrar paquetes, pero toma sus
decisiones con una lógica diferente. El IPS descarga
primero una base de datos de firmas de exploits. Cada
firma define diferentes valores de campos de cabecera
que se encuentran en secuencias de paquetes utilizados
por diferentes exploits. A continuación, el IPS puede
examinar los paquetes, compararlos con las firmas de
||||||||||||||||||||
||||||||||||||||||||
exploits conocidas y darse cuenta de cuándo
Technet24
||||||||||||||||||||
||||||||||||||||||||
pueden formar parte de un exploit conocido. Una vez

identificados, el IPS puede registrar el evento, descartar
los paquetes o incluso redirigirlos a otra aplicación de
seguridad para un examen más detallado.
Un IPS tradicional se diferencia de los cortafuegos en

que, en lugar de que un ingeniero de la empresa defina
reglas para esa empresa basadas en aplicaciones (por
número de puerto) y zonas, el IPS aplica la lógica
basándose en firmas suministradas en su mayoría por el
proveedor del IPS. Esas firmas buscan este tipo de
ataques:
DoS
DDoS
Gusanos
Virus
Para cumplir su misión, el IPS necesita descargar y

mantener actualizada su base de datos de firmas. Los
expertos en seguridad trabajan para crear las firmas. A
continuación, el IPS debe descargar la base de datos de
firmas de exploits y seguir descargando actualizaciones
a lo largo del tiempo, como se muestra en la Figura 5-9.
||||||||||||||||||||
||||||||||||||||||||
Figura 5-9 IPS y Base de Datos de Firmas
Por ejemplo, piense en lo que ocurre cuando se crea un

virus informático completamente nuevo. Los productos
de seguridad basados en host, como el software
antivirus, deben instalarse en los ordenadores de la
empresa. Estas herramientas utilizan un modelo similar
al del IPS, manteniendo una base de datos actualizada
de firmas de virus. Las firmas pueden buscar patrones
en la forma en que un virus informático podría
almacenarse dentro de los archivos del ordenador, o
en los archivos enviados al ordenador a través del
correo electrónico o los navegadores web. Pero habrá
cierto desfase temporal entre el día en que se descubre
el virus (lo que se conoce como ataques de día cero) y
el momento en que los investigadores han desarrollado
una firma de virus, modificado su base de datos y dado
tiempo a que todos los hosts actualicen su software
antivirus. Los hosts están en peligro durante este lapso
de tiempo.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
El IPS proporciona un servicio complementario para

prevenir los virus. Los investigadores buscarán formas
de que un IPS pueda reconocer el mismo virus mientras
vuela por la red con nuevas firmas IPS, por ejemplo,
buscando paquetes con un puerto concreto y una cadena
hexadecimal determinada en la carga útil de la
aplicación. Una vez desarrolladas, los dispositivos IPS
de la red deben actualizarse con la nueva base de datos
de firmas, protegiendo así contra ese virus.
Tanto las protecciones basadas en host como las
basadas en IPS desempeñan un papel importante, pero
el hecho de que un IPS proteja secciones de una red
significa que, en ocasiones, el IPS puede reaccionar
más rápidamente ante nuevas amenazas para proteger
hosts.
Cortafuegos de nueva generación de Cisco

Los temas del examen CCNA 200-301 mencionan los
términos firewall y IPS pero precedidos del término
next- generation. Hacia mediados de la década de
2010, Cisco y algunos de sus competidores empezaron
a utilizar el término próxima generación cuando
hablaban de sus productos de seguridad para destacar
algunas de las características más recientes. En
resumen, un cortafuegos de nueva generación (NGFW)
y un IPS de nueva generación (NGIPS) son los
productos actuales de cortafuegos e IPS de Cisco.
Sin embargo, el uso del término próxima generación va

mucho más allá de una simple etiqueta de marketing: el
término hace hincapié en algunos cambios y mejoras
importantes a lo largo de los años. El sector de la
seguridad asiste a ciclos interminables de nuevos
||||||||||||||||||||
||||||||||||||||||||
ataques seguidos de nuevas soluciones, algunas de las

cuales requieren nuevas características o incluso nuevos
productos. Algunos de los cambios que han requerido
nuevas funciones de seguridad son
||||||||||||||||||||
||||||||||||||||||||
la proliferación de dispositivos móviles -dispositivos que

salen de la empresa, se conectan a Internet y vuelven a
ella-, que crean un nuevo nivel de riesgo. Además,
ninguna función o dispositivo de seguridad (cortafuegos,
IPS, antimalware) puede por sí solo detener algunas
amenazas, por lo que las herramientas de nueva
generación deben ser capaces de trabajar mejor juntas
para ofrecer soluciones. En resumen, los productos de
nueva generación tienen funciones realmente útiles que
no se encontraban en sus predecesores.
En cuanto a los productos de Cisco, durante muchos

años la marca denominó a sus cortafuegos Cisco Adaptive
Security Appliance (ASA). Alrededor de 2013, Cisco
adquirió Sourcefire, una empresa de productos de
seguridad. Muchas de las características del firewall de
próxima generación (e IPS) provienen del software
adquirido a través de esa adquisición. A partir de 2019
(cuando se escribió este capítulo), todos los firewalls que
Cisco vende actualmente tienen nombres que evocan
recuerdos de la adquisición de Sourcefire, y la mayor
parte de la línea de productos de firewall se llama
firewalls Cisco Firepower
(www.cisco.com/go/firewalls).
Por supuesto, un NGFW sigue realizando las funciones

tradicionales de un cortafuegos, como el filtrado por
estado mediante la comparación de campos en las
cabeceras IP, TCP y UDP, y el uso de zonas de
seguridad al definir las reglas del cortafuegos. Para dar
una idea de algunas de las nuevas funciones de nueva
generación, consideremos el reto de emparejar paquetes
con puertos:
1. Cada aplicación basada en IP debe utilizar un puerto conocido.
||||||||||||||||||||
||||||||||||||||||||
2. Los atacantes saben que los cortafuegos filtrarán los puertos más
conocidos de las sesiones iniciadas desde la zona exterior a la zona
interior (véase la figura
Technet24
||||||||||||||||||||
||||||||||||||||||||
5-8).
3. Los atacantes utilizan el escaneo de puertos para encontrar cualquier

puerto que el cortafuegos de una empresa permita atravesar en este
momento.
4. Los atacantes intentan utilizar un protocolo de su elección (por
ejemplo, HTTP) pero con el puerto no estándar encontrado a través
del escaneo de puertos como una forma de intentar conectarse a
hosts dentro de la empresa.
La secuencia enumera un resumen de algunos de los

pasos que deben dar los atacantes, pero no enumera
cada una de las tareas. Sin embargo, incluso a esta
profundidad, se puede ver cómo los atacantes pueden
encontrar una manera de enviar paquetes más allá del
cortafuegos corporativo.
¿La solución? Un cortafuegos de nueva generación que

examine los datos de la capa de aplicación para
identificar la aplicación en lugar de basarse en los
números de puerto TCP y UDP utilizados. Cisco realiza
su inspección profunda de paquetes mediante una
función denominada Application Visibility and Control
(AVC). Cisco AVC puede identificar muchas
aplicaciones basándose en los datos enviados (cabeceras
de la capa de aplicación más estructuras de datos de
aplicación más allá de las cabeceras TCP y UDP).
Cuando se utiliza con un NGFW de Cisco, en lugar de
coincidir con los números de puerto, el cortafuegos
coincide con la aplicación, derrotando ataques como el
que acabamos de describir.
La siguiente lista menciona algunas de las

características de un NGFW. Tenga en cuenta que,
aunque NGFW es un término útil, la línea entre un
cortafuegos tradicional y un cortafuegos de nueva
generación puede ser un poco borrosa, ya que los
||||||||||||||||||||
||||||||||||||||||||
términos describen productos que han sufrido cambios

repetidos durante largos periodos de tiempo. Sin
embargo, esta lista resume algunos de los puntos clave:
||||||||||||||||||||
||||||||||||||||||||
Cortafuegos tradicional: Un NGFW realiza funciones de

cortafuegos tradicionales, como filtrado de cortafuegos con estado,
NAT/PAT y terminación de VPN.
Visibilidad y control de aplicaciones (AVC): Esta función

profundiza en los datos de la capa de aplicación para identificar la
aplicación. Por ejemplo, puede identificar la aplicación basándose
en los datos, en lugar de en el número de puerto, para defenderse de
los ataques que utilizan números de puerto aleatorios.
Protección avanzada contra malware: Las plataformas NGFW

ejecutan múltiples servicios de seguridad, no sólo como plataforma
para ejecutar un servicio independiente, sino para una mejor
integración de funciones. Una función antimalware basada en la red
puede ejecutarse en el propio cortafuegos, bloqueando las
transferencias de archivos que instalarían malware y guardando
copias de los archivos para su posterior análisis.
Filtrado de URL: Esta función examina las URL en cada

solicitud web, categoriza las URL, y filtra o limita la tasa de
tráfico basado en reglas. El grupo de seguridad Cisco Talos supervisa
y crea puntuaciones de reputación para cada dominio conocido en
Internet, y el filtrado de URL puede utilizar esas puntuaciones en
su decisión de categorizar, filtrar o limitar la tasa.
NGIPS: Los productos Cisco NGFW también pueden ejecutar su

función NGIPS junto con el cortafuegos.
Tenga en cuenta que para cualquiera de los servicios

que se benefician de estar en la misma ruta que
atraviesan los paquetes, como un cortafuegos, tiene
sentido que con el tiempo esas funciones puedan migrar
para ejecutarse en el mismo producto. Así, cuando el
diseño necesita tanto un cortafuegos como un IPS en la
misma ubicación de la red, estos productos NGFW
pueden ejecutar la función NGIPS como se muestra en
el dispositivo combinado de la Figura 5-10.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 5-10 Cortafuegos de nueva generación con

módulo IPS de nueva generación
IPS de próxima generación de Cisco

Los productos IPS de próxima generación (NGIPS) de
Cisco han seguido un camino similar al de los
productos NGFW de Cisco. Cisco añadió por primera
vez funciones NGIPS principalmente a través de su
adquisición de Sourcefire, y los productos IPS de Cisco
actuales (en 2019) también utilizan el nombre
Firepower. De hecho, como línea de productos, los
productos NGFW y NGIPS de hardware son los
mismos productos, con la capacidad de ejecutar tanto el
NGFW como el NGIPS.
Al igual que el NGFW, el NGIPS añade funciones a un

IPS tradicional. Por ejemplo, uno de los mayores
problemas de un IPS tradicional es el volumen de
eventos de seguridad registrados por el IPS. Por
ejemplo:
||||||||||||||||||||
||||||||||||||||||||
1. Un IPS compara la base de datos de firmas, que enumera todos

los exploits conocidos, con todos los mensajes.
2. Genera eventos, a menudo muchos más de los que el personal de seguridad puede leer.
3. El personal debe filtrar mentalmente los acontecimientos para
encontrar la proverbial aguja en el pajar, lo que sólo es posible
mediante el trabajo duro, una vasta experiencia y la voluntad de
excavar.
Un NGIPS ayuda con este problema de dos maneras. En

primer lugar, un NGIPS examina el contexto recopilando
datos de todos los hosts y de los usuarios de esos hosts.
El NGIPS conocerá el sistema operativo, los niveles de
revisión del software, qué aplicaciones se están
ejecutando, los puertos abiertos, los protocolos de
transporte y los números de puerto en uso, etcétera.
Armado con esos datos, el NGIPS puede tomar
decisiones mucho más inteligentes sobre qué eventos
registrar.
Por ejemplo, consideremos un NGIPS colocado en una

red para proteger una LAN de campus donde se
conectan los usuarios finales, pero no existe ningún
centro de datos en esa parte de la red. Además, resulta
que todos los PC ejecutan Windows, y posiblemente la
misma versión, por política corporativa. La base de
datos de firmas incluye firmas para exploits de hosts
Linux, Mac, versiones de Windows inexistentes en esa
parte de la red y exploits que se aplican a aplicaciones
de servidor que no se ejecutan en esos hosts. Tras
recopilar esos datos, un NGIPS puede sugerir que se
reste importancia a las comprobaciones de exploits que
no se aplican a esos puntos finales, dedicando más
tiempo y atención a los eventos que podrían producirse,
lo que reduce en gran medida el número de eventos
registrados.
||||||||||||||||||||
||||||||||||||||||||
En la siguiente lista se mencionan algunas de las funciones

de Cisco NGIPS:
Technet24
||||||||||||||||||||
||||||||||||||||||||
IPS tradicional: Un NGIPS realiza funciones tradicionales de

IPS, como usar firmas de exploits para comparar flujos de
paquetes, crear un registro de eventos y posiblemente descartar
y/o redirigir paquetes.
Visibilidad y control de aplicaciones (AVC): Al igual que los

NGFW, un NGIPS tiene la capacidad de mirar profundamente en
los datos de la capa de aplicación para identificar la aplicación.
Conciencia contextual: Las plataformas NGFW recopilan datos de los hosts

-OS, versión/nivel de software, parches aplicados, aplicaciones en
ejecución, puertos abiertos, aplicaciones que envían datos
actualmente, etc. Estos datos informan al NGIPS sobre las
vulnerabilidades, a menudo más limitadas, de una parte de la red, de
modo que el NGIPS puede centrarse en las vulnerabilidades reales y
reducir en gran medida el número de eventos registrados.
Filtrado basado en la reputación: El grupo de inteligencia de

seguridad Cisco Talos investiga diariamente las amenazas a la
seguridad, construyendo los datos utilizados por la cartera de
seguridad de Cisco. Parte de esos datos identifican a los malos actores
conocidos, basándose en la dirección IP, dominio, nombre, o incluso
URL específica, con una puntuación de reputación para cada uno. Un
NGIPS de Cisco puede realizar un filtrado basado en la reputación,
teniendo en cuenta las puntuaciones.
Nivel de impacto del evento: El personal de seguridad necesita

evaluar los eventos registrados, por lo que un NGIPS proporciona
una evaluación basada en niveles de impacto, con caracterizaciones
en cuanto al impacto si un evento es realmente algún tipo de ataque.
Si quieres aprender un poco más sobre estos temas por tu

propio interés, permíteme que te remita a un par de
recursos. En primer lugar, echa un vistazo a los artículos
y entradas de blog del Cisco Talos Intelligence Group
(www.talosintelligence.com). La organización Cisco
Talos investiga problemas de seguridad en todo el
mundo y en toda la gama de productos de seguridad.
Además, un libro de Cisco Press contiene información
muy útil sobre los cortafuegos de nueva generación y
||||||||||||||||||||
||||||||||||||||||||
los firewalls.
||||||||||||||||||||
||||||||||||||||||||
IPSs, escrito a un nivel apropiado como siguiente paso.

Si quieres leer más, echa un vistazo a este libro con el
nombre largo: Integrated Security Technologies and
Solutions, Volume I: Cisco Security Solutions for
Advanced Threat Protection with Next Generation
Firewall, Intrusion Prevention, AMP, and Content
Security (o simplemente usa su ISBN, 9781587147067),
con un capítulo cada uno sobre NGFW y NGIPS.
columna.

utilizado
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Laboratorios Blog

comandos

Tema Número
Elemento
Lista Comandos cuyas contraseñas están 89

encriptadas por el servicio de
encriptación de contraseñas
Lista Reglas para cuando IOS utiliza la 91

contraseña establecida con los comandos
enable password versus enable secret
Lista Lógica por la cual IOS puede utilizar el 92

hash secreto de habilitación cuando un
usuario escribe una contraseña en texto
claro para acceder al modo de
habilitación.
Lista Regla para combinaciones del nombre de 94

usuario
comando
Figura 5- Filtrado de clientes típico mediante 98

6 cortafuegos en el borde de Internet
Figura 5- Zonas de seguridad cortafuegos con DMZ 99

8
||||||||||||||||||||
||||||||||||||||||||
Lista Características de los cortafuegos de nueva 101

generación
Lista Características de los IPS de nueva 103

generación

activar secreto
nombre de usuario local
hash MD5
nombre de usuario secreto
cortafuegos
IPS
cortafuegos de nueva generación (NGFW)
IPS de nueva generación (NGIPS)
Visibilidad y control de las aplicaciones
DO LABS
El software Sim Lite es una versión del producto de
aprendizaje simulador completo de Pearson con un
subconjunto de los laboratorios, incluido gratuitamente
con este libro. El Sim Lite con este libro incluye un par
de laboratorios sobre varios temas relacionados con las
contraseñas. Además, consulta las páginas del blog del
autor para ejercicios de configuración (Config Labs) en
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
https://blog.certskills.com/config-labs.
hace el comando.
Tabla 5-6 Capítulo 5 Comandos de configuración
Comando Modo/Propósito/Descripción
línea consola 0 Comando que cambia el contexto al modo

de configuración de consola.
line vty 1st- Comando que cambia el contexto al modo

vty last-vty de configuración vty para el rango de líneas
vty listadas en el comando.
inicio de sesión Modo de configuración de consola y vty.

Indica al IOS que solicite una contraseña.
contraseña pass- Modo de configuración de consola y vty.

valor Enumera la contraseña necesaria si está
configurado el comando login.
login local Modo de configuración de consola y vty.

Indica al IOS que solicite un nombre de
usuario y una contraseña, para
comprobarlos con los comandos de
configuración global de nombre de
usuario configurados localmente.
nombre de usuario Comando global. Define uno de los posibles

[tipo de algoritmo nombres de usuario múltiples y los nombres
de usuario asociados.
||||||||||||||||||||
||||||||||||||||||||
md5 | sha256 contraseñas, almacenadas como un valor

| scrypt] hash (por defecto MD5), con otras
pass-value opciones de hash también.
secreto
nombre de usuario Comando global. Define un nombre de

contraseña usuario y una contraseña, almacenados por
contraseña-valor defecto en texto claro en la configuración.
crypto key Comando global. Crea y almacena (en

generate rsa una ubicación oculta en la memoria
[modulus 512 | flash) las claves requeridas por SSH.
768 | 1024]
entrada de modo de configuración de línea vty. Define si

transporte se permite el acceso Telnet y/o SSH a este
{telnet | ssh | conmutador.
todos | ninguno}
[no] Comando global que cifra todas las

servicio contraseñas en texto claro en la
encriptació configuración en ejecución. La versión no
n- del comando desactiva el cifrado de
contraseña contraseñas cuando se establece la
contraseña.
activar Comando global para crear la contraseña de

contraseña habilitación, almacenada como texto claro
valor de paso en lugar de un valor hash.
enable Comando global para crear la contraseña

[algorithm-type de habilitación, almacenada como un valor
md5 | sha256 | hash en lugar de texto claro, con el hash
scrypt] secret definido por el tipo de algoritmo.
pass-value
no enable secret Comando global para borrar los comandos

no enable enable secret o enable password,
password respectivamente.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
clase de acceso Un comando en modo vty que habilita

número | nombre en comprobaciones ACL entrantes contra
clientes Telnet y SSH que se conectan al
router.
Comando Propósito
show running-config | Lista las líneas vty y subcomandos de

section vty la configuración.
show running-config | Lista la consola y los subcomandos de

section con la configuración.
show running-config | Lista todas las líneas de la

include enable configuración con la palabra enable.
||||||||||||||||||||
||||||||||||||||||||
Capítulo 6. Implementación
de la seguridad de puertos
de conmutación
Implementación de la
seguridad de puertos de
conmutación

5.7 Configurar funciones de seguridad de Capa 2
(DHCP snooping, inspección ARP dinámica y
seguridad de puertos)
En las redes modernas, la seguridad debe implantarse en

profundidad. La arquitectura de seguridad debe utilizar
cortafuegos y sistemas de prevención de intrusiones
(IPS) en lugares estratégicos, y los hosts deben utilizar
herramientas antivirus y antimalware.
Los routers, que ya deben existir en toda la empresa
en el límite entre las redes de área local y las redes de
área extensa, pueden configurarse con listas de
control de acceso IP para filtrar los paquetes
relacionados con distintos rangos de direcciones IP
en esa empresa.
Los conmutadores LAN tienen una oportunidad única

como punto de aplicación de la seguridad, especialmente
||||||||||||||||||||
||||||||||||||||||||
los conmutadores LAN conectados a dispositivos de

punto final. Los atacantes suelen lanzar ataques desde
los puntos finales conectados a un conmutador LAN
empresarial.
El atacante podría obtener acceso físico al endpoint o
infectar primero el dispositivo para luego lanzar un
ataque.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Además, un dispositivo móvil puede infectarse mientras

está fuera de la red de la empresa y conectarse más
tarde a la red de la empresa, lanzándose el ataque en ese
momento.
Los ingenieros deben asumir que los ataques pueden

lanzarse desde dispositivos de usuario final conectados
directamente a los puertos de acceso de los switches
LAN de la empresa, por lo que los switches Cisco
incluyen una serie de herramientas útiles para ayudar a
prevenir varios tipos de ataques. En este capítulo se
analiza una de estas herramientas: la seguridad de
puertos. En el Capítulo 8, "DHCP Snooping e
inspección ARP", se analizan otras dos herramientas de
seguridad de conmutadores que aprovechan la función
de capa de acceso del conmutador, mientras que en el
Capítulo 7, "Implementación de DHCP", se
proporcionan los detalles de fondo necesarios para
comprender las herramientas del Capítulo 8.
Este breve capítulo adopta un enfoque directo de la

función de seguridad de puertos. La primera sección
discute los conceptos, configuración y verificación,
usando el modo operativo primario de seguridad de
puertos: modo shutdown. La segunda sección discute
algunas de las complejidades de los tres modos
operacionales: apagado, verificación y restricción.

tiempo dedicar a este capítulo. Las respuestas de las
letras se encuentran al final de la página que sigue al
cuestionario. Apéndice C,
||||||||||||||||||||
||||||||||||||||||||
que se encuentra tanto al final del libro como en el sitio

web complementario, incluye tanto las respuestas como
las explicaciones. También encontrará las respuestas y
las explicaciones en el software de evaluación PTP.

Conceptos y configuración de la seguridad portuaria 1-3
Modos de violación de la seguridad portuaria 4, 5
1. ¿Cuál de las siguientes opciones es necesaria para

configurar la seguridad de puertos con aprendizaje
permanente?
1. Establecer el número máximo de direcciones MAC permitidas
en la interfaz con el subcomando switchport port-security
maximum interface.
2. Habilitar la seguridad del puerto con el switchport port-security
subcomando de interfaz.
3. Definir las direcciones MAC específicas permitidas utilizando el
subcomando de interfaz switchport port-security mac-address.
4. Todas las demás respuestas enumeran los comandos necesarios.
2. Un switch Cisco Catalyst se conecta a lo que

deberían ser PCs de usuario individuales. Cada
puerto tiene la misma configuración de seguridad
de puerto, configurada como sigue:
interface range gigabitethernet 0/1 - 24

switchport mode access
switchport port-security
switchport port-security mac-address sticky
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
¿Cuál de las siguientes respuestas describe el

resultado de la configuración de seguridad de
puertos creada con estos comandos? (Elija dos
respuestas).
1. Impide que dispositivos desconocidos con direcciones MAC
desconocidas envíen datos a través de los puertos del
conmutador.
2. Si un usuario conecta un conmutador al cable, impide que
varios dispositivos envíen datos a través del puerto.
3. Permitirá que cualquier dispositivo se conecte a cada puerto y
guardará la dirección MAC de ese dispositivo en la configuración
de inicio.
4. Permitirá que cualquier dispositivo se conecte a cada puerto pero
no guardará la dirección MAC de ese dispositivo en la
configuración de inicio.
3. ¿Cuál de los siguientes comandos enumera las

entradas de la tabla de direcciones MAC para las
direcciones MAC configuradas por la seguridad de
puertos? (Elija dos respuestas).
1. show mac address-table dynamic
2. mostrar tabla de direcciones mac
3. show mac address-table static
4. show mac address-table port-security
4. El comando show port-security interface f0/1

muestra un estado de puerto secure-down. ¿Cuál
de las siguientes respuestas debe ser verdadera
sobre esta interfaz en este momento?
1. El comando show interface status muestra el estado de la
interfaz como conectada.
2. El comando show interface status muestra el estado de la
interfaz como err-disabled.
3. El comando show port-security interface podría listar un
modo de shutdown o restrict, pero no protect.
4. El comando show port-security interface podría listar
un valor de contador de violaciones de 10.
||||||||||||||||||||
||||||||||||||||||||
5. El puerto Gi0/1 de un switch se ha habilitado

correctamente con seguridad de puerto. La
configuración establece el
||||||||||||||||||||
||||||||||||||||||||
modo de violación para restringir. Una trama que

viola la política de seguridad del puerto entra en la
interfaz, seguida de una trama que no lo hace.
¿Cuál de las siguientes respuestas describe
correctamente lo que ocurre en este escenario?
1. El conmutador pone la interfaz en estado de error
deshabilitado cuando llega la primera trama.
2. El switch genera mensajes syslog sobre el tráfico infractor para la
primera trama.
3. El switch incrementa el contador de violaciones para GIO/1 en 1.
4. El conmutador descarta tanto la primera como la segunda trama.
1B
2 B, D
3 B, C
4 B
5 B, C
Temas básicos
CONCEPTOS Y CONFIGURACIÓN DE LA
SEGURIDAD DE LOS PUERTOS
Si el ingeniero de redes sabe qué dispositivos deben
cablearse y conectarse a determinadas interfaces de un
conmutador, puede utilizar la seguridad de puertos de
para restringir esa interfaz de modo que sólo puedan
utilizarla los dispositivos previstos.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Esto reduce la exposición a ataques en los que el

atacante conecta un ordenador portátil a algún puerto de
conmutador no utilizado. Cuando ese dispositivo
inadecuado intenta enviar tramas a la interfaz del
conmutador, éste puede tomar diferentes medidas, que
van desde la simple emisión de mensajes informativos
hasta el cierre efectivo de la interfaz.
La seguridad de puertos identifica los dispositivos

basándose en la dirección MAC de origen de las tramas
Ethernet que envían los dispositivos. Por ejemplo, en la
Figura 6-1, PC1 envía una trama, con la dirección MAC
de PC1 como dirección de origen. La interfaz F0/1 de
SW1 puede configurarse con seguridad de puertos, y si
así fuera, SW1 examinaría la dirección MAC de PC1 y
decidiría si PC1 tiene permiso para enviar tramas al
puerto F0/1.
Figura 6-1 Direcciones MAC de origen en las

tramas cuando entran en un conmutador
La seguridad de puertos tampoco tiene restricciones

sobre si la trama proviene de un dispositivo local o fue
reenviada a través de otros switches. Por ejemplo, el
switch SW1 podría utilizar la seguridad de puertos en
||||||||||||||||||||
||||||||||||||||||||
su interfaz G0/1, comprobando la
||||||||||||||||||||
||||||||||||||||||||
dirección MAC de origen de la trama desde PC2,

cuando se reenvía a SW1 desde SW2.
La seguridad de puertos tiene varias opciones flexibles,

pero todas funcionan con los mismos conceptos básicos.
En primer lugar, los conmutadores habilitan la seguridad
de puertos por puerto, con diferentes ajustes disponibles
por puerto. Cada puerto tiene un número máximo de
direcciones MAC permitidas, lo que significa que para
todas las tramas que entran en ese puerto, sólo se puede
utilizar ese número de direcciones MAC de origen
diferentes antes de que la seguridad del puerto piense
que se ha producido una violación. Cuando llega una
trama con una nueva dirección MAC de origen que
sobrepasa el número máximo de direcciones MAC
permitidas, se produce una violación de la seguridad del
puerto. En ese momento, el switch actúa, por defecto,
descartando todo el tráfico entrante futuro en ese puerto.
La siguiente lista resume estas ideas comunes a todas las

variantes de la seguridad portuaria:
Examina las tramas recibidas en la interfaz para determinar si se

ha producido una violación.
Define un número máximo de direcciones MAC de origen únicas

permitidas para todas las tramas que entran en la interfaz.
Mantiene una lista y un contador de todas las direcciones MAC de

origen únicas en la interfaz.
Supervisa las direcciones MAC recién aprendidas, considerando

que esas direcciones MAC causan una violación si la dirección
MAC recién aprendida empuja el número total de entradas de la
tabla MAC para la interfaz más allá del máximo configurado de
direcciones MAC permitidas para ese puerto.
Realiza acciones para descartar tramas de las direcciones MAC

||||||||||||||||||||
||||||||||||||||||||
infractoras, además de otras acciones dependiendo del modo de

infracción configurado.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Esas reglas definen lo básico, pero la seguridad

portuaria permite también otras opciones, incluidas las
siguientes:
Defina un máximo de tres direcciones MAC, definiendo las tres
direcciones MAC específicas.
Defina un máximo de tres direcciones MAC pero permita que esas

direcciones se aprendan dinámicamente, permitiendo que se aprendan
las tres primeras direcciones MAC.
Defina un máximo de tres direcciones MAC, predefiniendo una

dirección MAC específica y permitiendo que otras dos se aprendan
dinámicamente.
Puede que te guste la idea de predefinir las direcciones

MAC para la seguridad de puertos, pero encontrar la
dirección MAC de cada dispositivo puede ser una
molestia. La seguridad de puertos proporciona un
compromiso útil usando una característica llamada
direcciones MAC seguras pegajosas. Con esta función,
la seguridad de puertos aprende las direcciones MAC de
cada puerto para que no tengas que preconfigurar los
valores. También añade las direcciones MAC
aprendidas a la configuración de seguridad de puertos
(en el fichero running-config). Esta característica ayuda
a reducir el gran esfuerzo de averiguar la dirección
MAC de cada dispositivo.
Como puedes ver, la seguridad portuaria tiene muchas

opciones detalladas. Las siguientes secciones te guiarán
a través de estas opciones para unir las ideas.
Configuración de la seguridad de los puertos

La configuración de la seguridad de puertos implica
varios pasos. En primer lugar, la seguridad de puertos
funciona tanto en puertos de acceso como en puertos
||||||||||||||||||||
||||||||||||||||||||
troncales, pero requiere que configure estáticamente el

puerto como troncal o como puerto de acceso , en lugar
de dejar que el conmutador decida dinámicamente si
desea utilizar el trunking. El
||||||||||||||||||||
||||||||||||||||||||
La siguiente lista de comprobación de configuración

detalla cómo habilitar la seguridad de puertos,
establecer el máximo de direcciones MAC permitidas
por puerto y configurar las direcciones MAC reales:
Paso 1. Configure la interfaz Utilice los

subcomandos switchport mode access o
switchport mode trunk interface,
respectivamente, para convertir la interfaz
del switch en una interfaz de acceso estático
o en una interfaz troncal.
Paso 2. Utilice el subcomando switchport port-
security interface para activar la seguridad
de puertos en la interfaz.
Paso 3. (Opcional) (Opcional) Utilice el
subcomando switchport port- security
maximum number interface para anular el
número máximo predeterminado de
direcciones MAC permitidas asociadas a la
interfaz (1).
Paso 4. (Opcional) Utilice el subcomando de
interfaz switchport port- security
violation {protect | restrict | shutdown}
para anular la acción predeterminada que se
llevará a cabo ante una violación de
seguridad (shutdown).
Paso 5. (Opcional) Utilice el subcomando
switchport port- security mac-address
mac-address interface para predefinir las
direcciones MAC de origen permitidas para
||||||||||||||||||||
||||||||||||||||||||
esta interfaz.
Technet24
||||||||||||||||||||
||||||||||||||||||||
interfaz. Utilice el comando varias veces para

definir más de una dirección MAC.
Paso 6. (Opcional) (Opcional) Utilice el
subcomando switchport port- security mac-
address sticky interface para indicar al
switch que "aprenda pegajosamente" las
direcciones MAC aprendidas dinámicamente.
Para demostrar cómo configurar esta variedad de
ajustes, la Figura 6-2 y el Ejemplo 6-1 muestran cuatro
ejemplos de seguridad de puertos. Tres puertos
funcionan como puertos de acceso, mientras que el
puerto F0/4, conectado a otro switch, funciona como
troncal.
Figura 6-2 Ejemplo de configuración de seguridad de puertos
Ejemplo 6-1 Variaciones en la configuración de

seguridad de puertos
||||||||||||||||||||
||||||||||||||||||||
SW1# show running-config

(Líneas omitidas por brevedad)
interface FastEthernet0/1
switchport port-security mac-address 0200.1111.1111
¡!
¡!
¡!
switchport mode trunk
switchport port-security máximo 8
En primer lugar, analiza la configuración de las cuatro

interfaces del ejemplo 6-1, centrándote en los dos
primeros subcomandos de interfaz en cada caso.
Observe que las tres primeras interfaces del ejemplo
utilizan los mismos dos primeros subcomandos de
interfaz, coincidiendo con los dos primeros pasos de
configuración señalados antes de la Figura 6-2. El
comando switchport port- security habilita la
seguridad del puerto, con todos los valores
predeterminados, y el comando switchport mode
access cumple el requisito de configurar el puerto como
puerto de acceso o troncal. El último puerto, F0/4, tiene
una configuración similar, excepto que ha sido
configurado como troncal en lugar de como puerto de
acceso.
A continuación, escanea las cuatro interfaces de nuevo,

y observa que la configuración difiere en cada interfaz
después de esos dos primeros subcomandos de interfaz.
||||||||||||||||||||
||||||||||||||||||||
Cada interfaz simplemente
Technet24
||||||||||||||||||||
||||||||||||||||||||
muestra un ejemplo diferente para la perspectiva.
La primera interfaz, FastEthernet 0/1, añade un

subcomando opcional de seguridad de puerto:
switchport port-security mac-address
0200.1111.1111, que define una dirección MAC de
origen específica. Con la configuración por defecto de
dirección de origen máxima de 1, sólo las tramas con
MAC de origen 0200.1111.1111 serán permitidas en este
puerto. Cuando una trama con una fuente distinta de
0200.1111.1111 entra en F0/1, el switch normalmente
realizaría el aprendizaje de la dirección MAC y querría
añadir la nueva dirección MAC fuente a la tabla de
direcciones MAC. La seguridad del puerto verá esa
acción como el aprendizaje de una dirección MAC de
más en el puerto, tomando la acción de violación por
defecto de deshabilitar la interfaz.
Como segundo ejemplo, FastEthernet 0/2 utiliza la

misma lógica que FastEthernet 0/1, excepto que utiliza
la característica sticky learning. Para el puerto F0/2, la
configuración del comando switchport port-security
mac-address sticky le dice al switch que aprenda
dinámicamente las direcciones MAC de origen y
agregue comandos port-security a la configuración en
ejecución. El ejemplo 6-2 muestra el archivo running-
config que lista la dirección MAC aprendida con sticky
en este caso.
Ejemplo 6-2 Configuración añadida por la función

Port Security Sticky
SW1# show running-config interfaz f0/2
||||||||||||||||||||
||||||||||||||||||||
Construyendo la configuración...
Configuración actual : 188 bytes
¡!
switchport port-security mac-address sticky 0200.2222.2222
La seguridad de puertos no guarda la configuración de

las direcciones "sticky", por lo que debe utilizar el
comando copy running-config startup- config si lo
desea.
Las otras dos interfaces en el Ejemplo 6-1 no predefinen

las direcciones MAC, ni tampoco las aprenden de forma
permanente (sticky-learn). La única diferencia entre la
configuración de seguridad de puertos de estas dos
interfaces es que FastEthernet 0/4 admite ocho
direcciones MAC porque se conecta a otro conmutador y
debe recibir tramas con múltiples direcciones MAC de
origen. La interfaz F0/3 utiliza el máximo
predeterminado de una dirección MAC.
Nota
Los conmutadores también pueden utilizar la

seguridad de puertos en puertos de voz y
EtherChannels. Para los puertos de voz, asegúrese
de configurar la dirección MAC máxima en al
menos dos (una para el teléfono o para un PC
conectado al teléfono). En los EtherChannels, la
configuración de la seguridad de puertos debe
colocarse en la interfaz puerto-canal, en lugar de en
las interfaces físicas individuales del canal.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Verificación de la seguridad de los puertos

El comando show port-security interface proporciona
la mayor información sobre cómo opera la seguridad de
puertos, como se muestra en el Ejemplo 6-3. Este
comando lista los ajustes de configuración para la
seguridad de puertos en una interfaz. Este comando lista
los ajustes de configuración para la seguridad de puertos
en una interfaz; además lista varios hechos importantes
sobre la operación actual de la seguridad de puertos,
incluyendo información sobre cualquier violación de
seguridad. Los dos comandos del ejemplo muestran las
interfaces F0/1 y F0/2, basadas en la configuración del
Ejemplo 6-1.
Ejemplo 6-3 Uso de la seguridad de puertos para

definir las direcciones MAC correctas de
determinadas interfaces
||||||||||||||||||||
||||||||||||||||||||
SW1# show port-security interface fastEthernet 0/1

Seguridad de puertos :
Activado
Estado del puerto : Apagado seguro
Modo de : Apagado
violación : 0
Tiempo de minutos
Envejecimiento
envejecimiento de : Absolute
direcciones
SecureStatic
Tipo de : Desactivado Máximo de
envejecimiento
direcciones MAC : 1
Direcciones MAC totales : 1
Direcciones MAC configuradas
: 1 Direcciones MAC fijas : 0
Última dirección de origen:Vlan :
0013.197b.5004:1 Recuento de violaciones de
seguridad : 1
SW1# show port-security interface fastEthernet 0/2

Seguridad de puertos : Activado
Estado del puerto : Secure-up
Modo Violación : Apagado
Tiempo de envejecimiento : 0 min
Tipo de envejecimiento :Absolute
SecureStatic Address Aging :
Disabled Máximo de direcciones MAC :
1
Total de direcciones MAC : 1
||||||||||||||||||||
||||||||||||||||||||
configuradas :1
Direcciones MAC pegajosas : 1
Última dirección de origen:Vlan
:0200.2222.2222:1
Recuento de violaciones de :0
Los dos comandos del Ejemplo 6-3 confirman que se ha

producido una violación de seguridad en FastEthernet
0/1, pero no se ha producido ninguna violación en
FastEthernet 0/2. El comando show port- security
interface fastethernet 0/1 muestra que la interfaz está
en estado secure- shutdown, lo que significa que la
interfaz se ha desactivado debido a la seguridad del
puerto. En este caso, otro dispositivo conectado al puerto
F0/1, que envía una trama con una dirección MAC de
origen distinta de 0200.1111.1111, está causando una
violación. Sin embargo, el puerto Fa0/2, que utilizó
sticky learning, simplemente aprendió la dirección MAC
utilizada por el Servidor 2.
Seguridad de puertos Direcciones MAC

Para completar este capítulo, tómese un momento para
pensar en la conmutación de Capa 2, junto con todos
esos ejemplos de salida del comando show mac
address-table dynamic EXEC.
Una vez que un puerto del conmutador se ha

configurado con seguridad de puertos, el conmutador
ya no considera las direcciones MAC asociadas con ese
puerto como entradas dinámicas, como se indica con el
comando show mac address-table dynamic EXEC.
Incluso si las direcciones MAC se aprenden
dinámicamente, una vez que la seguridad del puerto ha
sido
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
habilitado, necesita utilizar una de estas opciones para

ver las entradas de la tabla MAC asociadas con los
puertos que utilizan la seguridad de puertos:
show mac address-table secure: Enumera las direcciones MAC
asociadas a los puertos que utilizan seguridad portuaria.
show mac address-table static: Enumera las direcciones MAC

asociadas con puertos que utilizan seguridad de puertos, así como
cualquier otra dirección MAC definida estáticamente.
El Ejemplo 6-4 prueba este punto. Muestra dos

comandos sobre la interfaz F0/2 del ejemplo de
seguridad de puertos mostrado en la Figura 6-2 y en el
Ejemplo 6-1. En ese ejemplo, la seguridad de puerto
se configuró en F0/2 con aprendizaje pegajoso, por lo
que desde un sentido literal, el conmutador aprendió
una dirección MAC de ese puerto (0200.2222.2222). Sin
embargo, el comando show mac address-table
dynamic no lista la dirección y el puerto porque IOS
considera que esa entrada de la tabla MAC es una
entrada estática. El comando show mac address-table
secure sí lista la dirección y el puerto.
Ejemplo 6-4 Uso de la palabra clave secure para

ver las entradas de la tabla MAC cuando se utiliza la
SW1# show mac address-table secure interface F0/2

Tabla de direcciones Mac
Vlan Dirección Tipo Puert

Mac os
1 0200.2222.2222 ESTÁTICO Fa0/2
Total de direcciones Mac para este
criterio: 1
||||||||||||||||||||
||||||||||||||||||||
SW1# show mac address-table dynamic interface f0/2

Tabla de direcciones Mac
Vlan Dirección Tipo Puert

Mac os
SW1#
MODOS DE VIOLACIÓN DE LA SEGURIDAD DE LOS

PUERTOS
La primera mitad del capítulo ha tratado muchos
detalles de la seguridad de puertos, pero en su mayor
parte ha ignorado una característica importante: el
modo de violación de la seguridad de puertos. El modo
de violación define cómo debe reaccionar la seguridad
de puertos cuando se produce una violación.
En primer lugar, para repasar, ¿qué es una violación de

seguridad de puerto? Cualquier trama recibida que
rompa las reglas de seguridad de puerto en una interfaz.
Por ejemplo:
Para una interfaz que permite dos direcciones MAC cualesquiera,
se produce una violación cuando el total de direcciones MAC
preconfiguradas y aprendidas en la interfaz supera el máximo
configurado de dos.
Para una interfaz que predefine todas las direcciones MAC

específicas permitidas en la interfaz, se produce una violación
cuando el conmutador recibe una trama cuya MAC de origen no es
una de esas direcciones configuradas.
Con la seguridad de puertos, cada puerto del switch

puede configurarse para utilizar uno de los tres modos de
violación que definen las acciones a tomar cuando se
produce una violación. Las tres opciones hacen que el
switch descarte la trama infractora (una trama cuya
dirección MAC de origen sobrepase el límite de
||||||||||||||||||||
||||||||||||||||||||
direcciones MAC aprendidas). Sin embargo, los modos

varían en cuántos otros pasos toman. Por ejemplo,
algunos
Technet24
||||||||||||||||||||
||||||||||||||||||||
Los modos incluyen la acción de que el switch genere

mensajes syslog y mensajes SNMP Trap, mientras que
algunos definen la acción de deshabilitar la interfaz. La
Tabla 6-2 lista los tres modos, sus acciones, junto con
las palabras clave que habilitan cada modo en el
subcomando switchport port-security violation
{protect | restrict | shutdown} interface.
Tabla 6-2 Acciones en caso de violación de la

protección portuaria
Opción en el switchport Proteger Restringir Apagar

puerto Violación de seguridad
Comando
Descarta el tráfico infractor Sí Sí Sí
Envía mensajes de registro y No Sí Sí

SNMP
Desactiva la interfaz No No Sí
poniéndola en estado err-
disabled, descartando todo el
tráfico.
Debido a que IOS reacciona de manera tan diferente con

el modo shutdown en comparación con los modos
restrict y protect, las siguientes páginas explican las
diferencias-primero para el modo shutdown, luego para
los otros dos modos.
Modo de apagado de seguridad de puertos
||||||||||||||||||||
||||||||||||||||||||
Cuando se utiliza el modo de violación de apagado (por

defecto) y se produce una violación de seguridad
portuaria en un puerto, la seguridad portuaria detiene
todo el reenvío de tramas en la interfaz, tanto de entrada
como de salida del puerto. En efecto, actúa como si la
seguridad de puertos hubiera apagado el puerto; sin
embargo, no configura literalmente el puerto con el
subcomando shutdown interface. En su lugar, la
seguridad de puertos utiliza la función err- disabled. Los
switches Cisco utilizan el estado err-disabled para una
amplia gama de propósitos, pero cuando se utiliza el
modo de apagado de seguridad de puertos y se produce
una violación, ocurre lo siguiente:
El estado de la interfaz del conmutador (por show interfaces y

show interfaces status) cambia a un estado deshabilitado por
error.
El estado de seguridad del puerto de la interfaz del conmutador

(por show port-security) cambia a un estado seguro-abajo.
El switch deja de enviar y recibir tramas en la interfaz.
Una vez que la seguridad del puerto ha colocado un

puerto en estado deshabilitado por error, por defecto el
puerto permanece en estado deshabilitado por error hasta
que alguien tome medidas. Para recuperarse de un
estado deshabilitado por error, la interfaz debe apagarse
con el comando shutdown y luego habilitarse con el
comando no shutdown. Alternativamente, el
conmutador puede configurarse para recuperarse
automáticamente del estado deshabilitado por error,
cuando es causado por la seguridad del puerto, con estos
comandos:
||||||||||||||||||||
||||||||||||||||||||
errdisable recovery cause psecure-violation: Un comando

global para habilitar la recuperación automática para
interfaces en una err-
Technet24
||||||||||||||||||||
||||||||||||||||||||
estado desactivado causado por la seguridad del puerto
errdisable recovery interval segundos: Un comando global para

establecer el tiempo de espera antes de recuperar la interfaz.
Para echar un vistazo más de cerca al modo shutdown,

empiece por comprobar el estado de configuración del
switch. Puede comprobar la configuración de seguridad
del puerto en cualquier interfaz con el comando show
port-security interface type number, como se ve en el
Ejemplo 6-2, pero el comando show port-security
(como se muestra en el Ejemplo 6-5) muestra una salida
más breve, con una línea por interfaz habilitada.
Ejemplo 6-5 Confirmación del modo de violación de

SW1# show port-security

Secure Port MaxSecureAddr CurrentAddr SecurityViolation Secur
(Count) (Cuenta) (Cuenta)
Fa0/13 1 1 1
Direcciones totales en el sistema (excluyendo una mac por puerto)

: 0
Límite máximo de direcciones en el sistema (excluyendo una mac
por puerto) : 8192
Observe que para estos siguientes ejemplos, un switch

ha configurado la seguridad de puerto en el puerto
Fa0/13 solamente. En este caso, el switch parece estar
configurado para soportar una dirección MAC, ya ha
alcanzado ese total y tiene una acción de violación de
seguridad de "shutdown".
A continuación, el Ejemplo 6-6 muestra los resultados

después de que una violación de seguridad de puerto ya
ha ocurrido en el puerto F0/13. El primer comando
||||||||||||||||||||
||||||||||||||||||||
confirma el estado err-disabled (por el comando show
||||||||||||||||||||
||||||||||||||||||||
interfaces status) y el estado secure-shutdown

(mediante el comando show port-security).
Ejemplo 6-6 Estado de seguridad del puerto en

modo apagado tras una violación

imagen del código
¡! Las siguientes líneas muestran el mensaje de registro generado
cuando la violación Jul 31 18:00:22.810: %PORT_SECURITY-2-
PSECURE_VIOLATION: Seguridad
causada por la dirección MAC d48c.b57d.8200 en el puerto
FastEthernet0/13
¡! El siguiente comando muestra el estado err-disabled, lo que
implica una secur
SW1# show interfaces Fa0/13 status
Puerto Estado VlanDuplex

Nomb Velocidad
err-desactivado auto auto
re Fa0/13 1
¡! La salida del siguiente comando tiene sombreados para varios
de los más i SW1# show port-security interface Fa0/13
Estado del puerto :seguroModo de
violación : Apagado
SecureStatic Address Aging : Disabled
Máximo de direcciones MAC : 1
Direcciones MAC configuradas :
1 Direcciones MAC fijas : 0
Última dirección de origen:Vlan : 0200.3333.3333:2
Recuento de violaciones de seguridad : 1
La salida del comando show port-security interface

lista el estado actual de la seguridad del puerto
(secure- shutdown) así como el modo configurado
(shutdown). La última línea de salida lista el número de
violaciones que causaron que la interfaz fallara a un
estado err-disabled, mientras que la penúltima línea
identifica la dirección MAC y
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
VLAN del dispositivo que causó la violación.
La Figura 6-3 resume estos comportamientos,

suponiendo el mismo escenario mostrado en el ejemplo.
Figura 6-3 Resumen de Acciones: Apagado en

Modo de Violación de Seguridad de Puertos
Tenga en cuenta que el contador de violaciones anota el

número de veces que la interfaz ha pasado al estado err-
disabled (apagado seguro). Por ejemplo, la primera vez
que falla, el contador se incrementa a 1; mientras está
deshabilitada por error, pueden llegar muchas tramas,
pero el contador permanece en 1. Más tarde, después de
que un ingeniero haya recuperado la interfaz del estado
deshabilitado por error con un apagado/no apagado,
otra violación que provoque que la interfaz falle a un
estado deshabilitado por error hará que el contador se
incremente a 2.
Modos de protección y restricción

de la seguridad portuaria
||||||||||||||||||||
||||||||||||||||||||
Los modos restringir y proteger violación tienen un

enfoque muy diferente para asegurar los puertos.
Estos modos siguen descartando el tráfico infractor,
pero la interfaz permanece en un estado conectado
(up/up) y en un estado de seguridad de puerto de
secure-up. Como resultado, el puerto continúa
reenviando el tráfico correcto pero descarta el tráfico
infractor.
Tener un puerto en un estado aparentemente bueno que

también descarta tráfico puede ser un reto a la hora de
solucionar problemas. Básicamente, hay que conocer la
función y luego saber cómo saber cuándo la seguridad
de puertos está descartando algo de tráfico en un puerto
aunque el estado de la interfaz parezca bueno.
Con el modo de protección, la única acción que toma el

conmutador para una trama que viola las reglas de
seguridad del puerto es descartar la trama. El
conmutador no cambia el puerto a un estado
deshabilitado por error, no genera mensajes y ni siquiera
incrementa el contador de violaciones.
El ejemplo 6-7 muestra un ejemplo con el modo protect

después de que se hayan producido varias violaciones.
Observe que el comando show confirma el modo
(protect) como está configurado en la parte superior del
ejemplo, con un estado de seguridad de puerto de
secure-up-un estado que no cambiará en modo protect.
Además, observe que el contador en la parte inferior
muestra 0, a pesar de que se han producido varias
violaciones, porque el modo protect no cuenta las
tramas violadas.
Ejemplo 6-7 Seguridad de puertos usando el modo Protect

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
SW1# show running-config

¡! Líneas omitidas por brevedad
interfaz FastEthernet0/13
switchport port-
security
switchport port-security mac-address 0200.1111.1111
switchport port-security violation protect
SW1# show port-security interface Fa0/13

Modo Violación : Proteger
Última dirección de origen:Vlan :
0000.0000.0000:0 Recuento de violaciones de
seguridad : 0
Nota
Los pequeños detalles de los contadores de

violaciones y la última dirección de origen pueden
ser ligeramente diferentes con algunos modelos de
switch y versiones de IOS más antiguos. Tenga en
cuenta que las pruebas de esta edición se basan en
conmutadores 2960XR que ejecutan IOS 15.2.(6)E2.
Mientras que el modo shutdown desactiva la interfaz, y

el modo protect no hace nada más que descartar el
tráfico infractor, el modo restrict proporciona un
compromiso entre los otros dos modos. Si el Ejemplo 6-
7 hubiera utilizado el modo de violación restrict en lugar
de protect, el estado del puerto sería
||||||||||||||||||||
||||||||||||||||||||
sin embargo, IOS mostraría alguna indicación de la

actividad de seguridad del puerto, como un contador de
violaciones que se incrementa con precisión, así como
mensajes syslog. El ejemplo 6-8 muestra un ejemplo del
contador de violaciones y termina con un ejemplo de
mensaje syslog de seguridad de puerto. En este caso, 97
tramas entrantes hasta ahora violaron las reglas, con la
trama más reciente teniendo una dirección MAC fuente
de 0200.3333.3333 en VLAN 1.
Ejemplo 6-8 Seguridad de puertos mediante

restricción del modo de violación
SW1# show port-security interface fa0/13

Modo de violación : Restringir
Última dirección de origen:Vlan
:0200.3333.3333:1
Recuento de violaciones de : 97
¡!
¡! El siguiente mensaje de registro también apunta a un problema
de seguridad del puerto.
¡!
01:46:58: %PORT_SECURITY-2-PSECURE_VIOLATION: V i o l a c i ó n d e
seguridad
Dirección MAC 0200.3333.3333 en el puerto FastEthernet0/13.
La Figura 6-4 resume los puntos clave sobre el modo

restringir para la seguridad de puertos. En este caso, la
figura vuelve a coincidir con el mismo escenario del
ejemplo, con un total de 97
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
tramas infractoras llegadas hasta el momento, siendo la

más reciente la procedente de la dirección MAC de
origen MAC3.
Figura 6-4 Resumen de Acciones: Modo de

Violación de Seguridad de Puerto Restringir
detalles. En la tabla 6-3 se indican los elementos clave
de repaso y dónde encontrarlos. Para hacer un mejor
seguimiento de su progreso en el estudio, registre
columna.
||||||||||||||||||||
||||||||||||||||||||

utilizado
||||||||||||||||||||
||||||||||||||||||||

DIKTA

comandos

memoria
Revisar las listas de control de Libro, página web

configuración
Laboratorios Sim Lite, blog
Ver el vídeo Página web

Elemento Número
Lista Resumen de los conceptos de 109

protección portuaria
Lista Lista de comprobación de la 110

configuración de la seguridad
portuaria
Ejemplo 6-1 Ejemplos de configuración de la 111

seguridad portuaria
Tabla 6-2 Medidas de protección portuaria y 115

resultados de cada medida
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Lista Acciones del conmutador cuando se 115

produce una violación de la
seguridad del puerto

seguridad portuaria
modo violación
error desactivado (err-disable)
DO LABS
El software Sim Lite es una versión del producto de
aprendizaje simulador completo de Pearson con un
subconjunto de los laboratorios, incluido gratuitamente
con este libro. El Sim Lite con este libro incluye un par
de laboratorios sobre seguridad de puertos. Además,
consulta las páginas del blog del autor para ejercicios de
configuración (Config Labs) en
https://blog.certskills.com/config-labs.
hace el comando.

configuración
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
switchport Comando del modo de configuración de

mode {access | interfaz que indica al switch que sea siempre un
trunk} puerto de acceso, o que sea siempre un puerto
troncal.
switchport Comando del modo de configuración de

port-security interfaz que añade estáticamente una
mac-address dirección MAC específica como dirección
mac-address MAC permitida en la interfaz.
switchport Subcomando de interfaz que indica al switch

port-security que aprenda las direcciones MAC de la interfaz
mac-address y las añada a la configuración de la interfaz
sticky como direcciones MAC seguras.
switchport Subcomando de interfaz que establece el

port-security número máximo de direcciones MAC estáticas
valor máximo seguras que se pueden asignar a una única
interfaz.
switchport Subcomando de interfaz que indica al

port-security conmutador qué hacer si una dirección
violation MAC inadecuada intenta acceder a la red a
{proteger | través de un puerto de conmutador seguro
restringir |
apagar}
errdisable Comando global que habilita la recuperación

recovery cause automática del estado err-disabled para puertos
psecure- que alcanzan ese estado debido a violaciones
violation de seguridad portuaria
errdisable Comando global que establece el retardo, en

intervalo de segundos, antes de que un conmutador
recuperación intente recuperar una interfaz en modo
segundos deshabilitado por error, independientemente
de la razón por la que dicha interfaz se
encuentre en ese estado.
cierre Subcomandos de interfaz que desactivan y

activan administrativamente una interfaz,
respectivamente
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
no apagado
Comando Propósito
show running- Lista la configuración utilizada actualmente

config
show running- Sólo muestra el extracto de la configuración

config | en ejecución de la interfaz listada y sus
número de tipo subcomandos
de interfaz
show mac Lista las entradas aprendidas dinámicamente en

address-table la tabla de direcciones (reenvío) del switch.
dynamic
[número de
tipo de
interfaz].
show mac Enumera las direcciones MAC definidas o

address-table aprendidas en los puertos configurados con
secure seguridad portuaria.
[número de
tipo de
interfaz]
show mac Enumera las direcciones MAC estáticas y las

address-table direcciones MAC aprendidas o definidas con la
static [número seguridad de puertos
de tipo de
interfaz]
mostrar Enumera una línea de salida por interfaz (o

interfaces sólo para la interfaz enumerada si está
[número de tipo incluida), anotando la descripción, el estado
de interfaz] operativo y los ajustes para dúplex y
estado velocidad en cada interfaz.
||||||||||||||||||||
||||||||||||||||||||
show port- Enumera los ajustes de configuración de

security seguridad del puerto de una interfaz y el estado
interface type operativo de la seguridad.
number
show port- Enumera una línea por interfaz que resume la

security configuración de seguridad de los puertos para
cualquier interfaz en la que esté activada.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 7. Implementación
de DHCP Implementación
de DHCP

1.10 Identificar parámetros IP para SO cliente
(Windows, Mac OS, Linux)
4.0 Servicios IP
4.3 Explicar el papel de DHCP y DNS en la red
4.6 Configurar y verificar cliente y relé DHCP
En el mundo de TCP/IP, la palabra host se refiere a

cualquier dispositivo con una dirección IP: tu teléfono,
tu tableta, un PC, un servidor, un router, un
conmutador... cualquier dispositivo que utilice IP para
proporcionar un servicio o que simplemente necesite
una dirección IP para ser gestionado. El término host
incluye también algunos dispositivos menos obvios: la
pantalla de vídeo de publicidad electrónica del centro
comercial, tu contador de energía eléctrica que utiliza la
misma tecnología que los teléfonos móviles para enviar
la información de tu consumo eléctrico para la
facturación, tu coche nuevo.
Independientemente del tipo de host, cualquier host que

utilice IPv4 necesita cuatro configuraciones IPv4 para
||||||||||||||||||||
||||||||||||||||||||
funcionar correctamente:
||||||||||||||||||||
||||||||||||||||||||
Dirección IP
Máscara de
subred
Enrutadores por
defecto
Direcciones IP del servidor DNS
Este capítulo discute estas configuraciones básicas de IP

en hosts. El capítulo comienza discutiendo cómo un host
puede aprender dinámicamente estas cuatro
configuraciones usando el Protocolo de Configuración
Dinámica de Host (DHCP). La segunda mitad de este
capítulo muestra cómo encontrar las configuraciones en
los hosts y los hechos clave a buscar cuando se muestran
las configuraciones.
Sólo una nota sobre el flujo general de los capítulos:

Este capítulo no trata temas de seguridad, aunque está
dentro de la Parte II, "Servicios de seguridad". Ubiqué
este capítulo enfocado en DHCP aquí porque el
Capítulo 8, "DHCP Snooping and ARP Inspection,"
depende en gran medida del conocimiento de DHCP.

||||||||||||||||||||
||||||||||||||||||||

Technet24
||||||||||||||||||||
||||||||||||||||||||
Protocolo de configuración dinámica de host 1-4
Identificación de la configuración IPv4 del host 5, 6
1. Un PC se conecta a una LAN y utiliza DHCP para

alquilar una dirección IP por primera vez. De los
cuatro mensajes DHCP habituales que fluyen entre
el PC y el servidor DHCP, ¿cuáles envía el cliente?
(Elige dos respuestas).
1. Acuse de recibo
2. Descubra
3. Oferta
4. Solicitar
2. ¿Cuál de los siguientes tipos de información forma

parte de la configuración de un servidor DHCP?
1. Rangos de direcciones IP en subredes que el servidor debe arrendar
2. Rangos de direcciones IP a no arrendar por subred
3. Nombres de host del servidor DNS
4. La dirección IP y MAC del router por defecto en cada subred
3. ¿Qué respuestas enumeran un criterio para elegir

qué interfaces de router deben configurarse como
agente de retransmisión DHCP? (Elija dos
respuestas.)
1. Si la subred de la interfaz no incluye un servidor DHCP
2. Si la subred de la interfaz incluye un servidor DHCP
3. Si la subred de la interfaz contiene clientes DHCP
4. Si la interfaz del router ya tiene un comando ip address dhcp
4. Un router se conecta a un proveedor de servicios de Internet
||||||||||||||||||||
||||||||||||||||||||
(ISP) utilizando su interfaz G0/0/0, con el comando

ip address dhcp configurado. ¿Qué hace el router
con la información de la puerta de enlace
predeterminada aprendida por DHCP?
1. El router ignora el valor de la puerta de enlace
predeterminada obtenida del servidor DHCP.
2. El router utiliza la pasarela por defecto igual que un host,
ignorando su tabla de enrutamiento.
3. El router reenvía los paquetes recibidos basándose en su tabla de
enrutamiento, pero utiliza su configuración de puerta de enlace
predeterminada para reenviar los paquetes que genera él mismo.
4. El router añade una ruta por defecto basada en la puerta de
enlace por defecto a su tabla de enrutamiento IP.
5. En el siguiente extracto de un comando en un Mac,

¿cuál de las siguientes partes de la salida representa
información obtenida de un servidor DHCP? (Elija
dos respuestas).
Macprompt$ ifconfig es0

En1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST>
m options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
éter 00:6d:e7:b1:9a:11
inet 172.16.4.2 máscara de red 0xffffff00 broadcast
172.16.4.2
1. 00:6d:e7:b1:9a:11
2. 172.16.4.2
3. 0xffffff00
4. 172.16.4.255
6. ¿Cuál de los siguientes comandos en un SO

Windows debería listar tanto la dirección IP como
los servidores DNS como aprendidos con DHCP?
1. ifconfig
Technet24
||||||||||||||||||||
||||||||||||||||||||
2. ipconfig
3. ifconfig /all
4. ipconfig /all
1 B, D
2 A, B
3 A, C
4 D
5 B, C
6 D
Temas básicos
PROTOCOLO DE CONFIGURACIÓN
DINÁMICA DE HOST
El Protocolo de Configuración Dinámica de Host
(DHCP) proporciona uno de los servicios más utilizados
en una red TCP/IP. La gran mayoría de los hosts en una
red TCP/IP son dispositivos de usuario, y la gran
mayoría de los dispositivos de usuario aprenden su
configuración IPv4 usando DHCP.
El uso de DHCP tiene varias ventajas sobre la otra

opción de configurar manualmente los parámetros IPv4.
La configuración de los ajustes IP del host se realiza en
un servidor DHCP, y cada cliente aprende estos ajustes
utilizando mensajes DHCP. Como resultado, la
configuración IP del host es
||||||||||||||||||||
||||||||||||||||||||
controlada por el personal de TI, en lugar de en la

configuración local en cada host, lo que resulta en
menos errores de usuario. DHCP permite tanto la
asignación permanente de direcciones de host, pero más
comúnmente, DHCP asigna un arrendamiento temporal
de direcciones IP. Con estos arrendamientos, el servidor
DHCP puede recuperar direcciones IP cuando un
dispositivo se retira de la red, haciendo un mejor uso de
las direcciones disponibles.
DHCP también permite la movilidad. Por ejemplo, cada

vez que un usuario se traslada a un nuevo lugar con una
tableta -a una cafetería, a casa de un cliente o de vuelta
a la oficina-, el dispositivo del usuario puede conectarse
a otra LAN inalámbrica, utilizar DHCP para alquilar
una nueva dirección IP en esa LAN y empezar a
trabajar en la nueva red. Sin DHCP, el usuario tendría
que pedir información sobre la red local y configurar
los ajustes manualmente, con lo que más de un usuario
cometería errores.
Aunque DHCP funciona automáticamente para los hosts

de usuario, requiere cierta preparación por parte de la
red, con alguna configuración en los routers. En algunas
redes empresariales, esa configuración del router puede
ser un único comando en muchas de las interfaces LAN
del router (ip helper-address server-ip), que identifica
al servidor DHCP por su dirección IP. En otros casos, el
router actúa como servidor DHCP. Sea como sea, los
routers tienen algún papel que desempeñar.
Esta primera gran sección del capítulo hace un

recorrido por DHCP, incluyendo conceptos y la
configuración del router
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
para que los routers funcionen bien con un servidor

DHCP independiente.
Conceptos DHCP
Siéntate un momento y piensa en el papel de DHCP para
un ordenador host. El host actúa como cliente DHCP.
Como cliente DHCP, el host comienza sin configuraciones
IPv4 - sin dirección IPv4, sin máscara, sin router por
defecto, y sin direcciones IP de servidor DNS. Pero un
cliente DHCP tiene conocimiento del protocolo DHCP,
por lo que el cliente puede utilizar ese protocolo para (a)
descubrir un servidor DHCP y (b) solicitar el alquiler de
una dirección IPv4.
DHCP utiliza los siguientes cuatro mensajes entre el

cliente y el servidor. (También, como una manera de
ayudar a recordar los mensajes, tenga en cuenta que las
primeras letras se deletrean DORA):
Descubrir: Enviado por el cliente DHCP para

encontrar un servidor DHCP dispuesto.
Oferta: Enviado por un servidor DHCP para ofrecer

arrendar a ese cliente una dirección IP específica (e
informar al cliente de sus otros parámetros).
Solicitud: Enviada por el cliente DHCP para solicitar

al servidor el arrendamiento de la dirección IPv4
indicada en el mensaje de Oferta.
Acuse de recibo: Enviado por el servidor DHCP

para asignar la dirección y listar las direcciones IP de
máscara, router por defecto y servidor DNS.
Los clientes DHCP, sin embargo, tienen un problema

un tanto único: aún no tienen una dirección IP, pero
||||||||||||||||||||
||||||||||||||||||||
necesita enviar estos mensajes DHCP dentro de paquetes

IP. Para que esto funcione, los mensajes DHCP utilizan
dos direcciones IPv4 especiales que permiten que un
host que no tiene dirección IP pueda enviar y recibir
mensajes en la subred local:
0.0.0.0: Dirección reservada para su uso como

dirección IPv4 de origen para hosts que aún no
tienen una dirección IP.
255.255.255.255: La dirección IP de difusión

local. Los paquetes enviados a esta dirección de
destino se difunden en el enlace de datos local, pero
los routers no los reenvían.
Para ver cómo funcionan estas direcciones, la Figura 7-1

muestra un ejemplo de las direcciones IP utilizadas entre
un host (A) y un servidor DHCP en la misma LAN. El
host A, un cliente, envía un mensaje Discover, con la
dirección IP de origen 0.0.0.0 porque el host A no tiene
todavía una dirección IP que utilizar.
El host A envía el paquete al destino 255.255.255.255,
que se envía en una trama de difusión LAN, llegando a
todos los hosts de la subred. El cliente espera que haya
un servidor DHCP en la subred local. ¿Por qué? Los
paquetes enviados a 255.255.255.255 sólo van a los
hosts de la subred local; el router R1 no reenviará este
paquete.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 7-1 Detección y oferta DHCP
Nota
La Figura 7-1 muestra un ejemplo de las direcciones

que se pueden utilizar en una petición DHCP. Este
ejemplo muestra detalles asumiendo que el cliente
DHCP elige usar una opción DHCP llamada
bandera de difusión; todos los ejemplos en este
libro asumen que se usa la bandera de difusión.
Ahora mira el mensaje de oferta que devuelve el servidor

DHCP. El servidor establece de nuevo la dirección IP de
destino en 255.255.255.255. ¿Por qué? El host A todavía
no tiene una dirección IP, por lo que el servidor no puede
enviar un paquete directamente al host A. Por lo tanto, el
servidor envía el paquete a la dirección "todos los hosts
locales de la subred" (255.255.255.255). (El paquete
también se encapsula en una trama de difusión Ethernet).
||||||||||||||||||||
||||||||||||||||||||
Ten en cuenta que todos los hosts de la subred reciben

el mensaje de Oferta. Sin embargo, el mensaje Discover
original lista un número llamado ID de cliente, que
incluye la dirección MAC del host, que identifica al
host original (host A en este caso). Como resultado, el
host A sabe que el mensaje de Oferta es para el host A.
El resto de los hosts recibirán el mensaje de Oferta,
pero observa que el mensaje lista el ID de cliente
DHCP de otro dispositivo, por lo que el resto de los
hosts ignoran el mensaje de Oferta.
Soporte de DHCP para subredes remotas con

DHCP Relay
Los ingenieros de redes tienen que tomar una importante
decisión de diseño con DHCP: ¿Poner un servidor
DHCP en cada subred LAN o ubicar un servidor DHCP
en un sitio central? La pregunta es legítima. Los routers
Cisco pueden actuar como servidor DHCP, por lo que
un diseño distribuido podría utilizar el router en cada
sitio como servidor DHCP. Con un servidor DHCP en
cada subred, como se muestra en la Figura 7-1, los
flujos de protocolo permanecen locales a cada LAN.
Sin embargo, un enfoque de servidor DHCP centralizado

también tiene ventajas. De hecho, algunos documentos
de diseño de Cisco sugieren un diseño centralizado como
mejor práctica, en parte porque permite un control y
configuración centralizados de todas las direcciones IPv4
asignadas en toda la empresa.
Con un servidor DHCP centralizado, esos mensajes

DHCP que fluían sólo en la subred local en la Figura 7-
1 de alguna manera tienen que fluir a través de la red IP
a la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
servidor DHCP centralizado y viceversa. Para que esto

funcione, los routers conectados a las subredes LAN
remotas necesitan un subcomando de interfaz: el
comando ip helper-address server-ip.
El subcomando ip helper-address server-ip indica al

router que haga lo siguiente para los mensajes que llegan
en una interfaz, desde un cliente DHCP:
1. Esté atento a los mensajes DHCP entrantes, con dirección IP de

destino 255.255.255.255.
2. Cambia la dirección IP de origen de ese paquete por la

dirección IP de la interfaz de entrada del router.
3. Cambia la dirección IP de destino de ese paquete por la dirección
del servidor DHCP (tal y como está configurada en el comando
ip helper-address).
4. Enruta el paquete al servidor DHCP.
Este comando evita la regla de "no enrutar paquetes

enviados a 255.255.255.255" cambiando la dirección IP
de destino. Una vez que el destino se ha configurado
para que coincida con la dirección IP del servidor
DHCP, la red puede enrutar el paquete al servidor.
Nota
Esta función, por la que un router retransmite

mensajes DHCP cambiando las direcciones IP en la
cabecera del paquete, se denomina DHCP relay.
||||||||||||||||||||
||||||||||||||||||||
La Figura 7-2 muestra un ejemplo del proceso. El Host

A se sitúa a la izquierda, como cliente DHCP. El
servidor DHCP (172.16.2.11) está a la derecha. R1 tiene
un comando ip helper- address 172.16.2.11
configurado, bajo su interfaz G0/0. En el paso 1, el
router R1 nota el paquete DHCP entrante destinado a
255.255.255.255. El paso 2 muestra los resultados de
cambiar tanto la dirección IP de origen como la de
destino, con R1 enrutando el paquete.
Figura 7-2 Efecto de la dirección IP auxiliar
El router utiliza un proceso similar para los mensajes

DHCP de retorno del servidor. Primero, para el
paquete de retorno del servidor DHCP, el servidor
simplemente invierte la dirección IP de origen y
destino del paquete recibido del router (agente de
retransmisión). Por ejemplo, en la Figura 7-2, el mensaje
de Descubrimiento lista la dirección IP de origen
172.16.1.1, así que el servidor envía el mensaje de
Oferta de vuelta a la dirección IP de destino 172.16.1.1.
Cuando un router recibe un mensaje DHCP, dirigido a
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
una de las propias direcciones IP del router, éste se da

cuenta de que el paquete podría formar parte de la
función de retransmisión DHCP.
Cuando esto ocurre, el agente de retransmisión DHCP
(router R1) necesita cambiar la dirección IP de destino,
para que el cliente DHCP real (host A), que todavía no
tiene una dirección IP, pueda recibir y procesar el
paquete.
La Figura 7-3 muestra un ejemplo de cómo funcionan estas

direcciones, cuando R1 recibe el mensaje DHCP Offer
enviado a la dirección 172.16.1.1 del propio R1. R1
cambia el destino del paquete a 255.255.255.255 y lo
reenvía fuera de G0/0, porque el paquete estaba destinado a
la dirección IP 172.16.1.1 de G0/0. El resultado es que
todos los hosts de esa LAN (incluyendo los de G0/0, G0/0 y
G0/0) se conectan a la dirección IP 172.16.1.1 del R1. Como
resultado, todos los hosts en esa LAN (incluyendo el
cliente DHCP A) recibirán el mensaje.
Figura 7-3 Dirección IP de ayuda para el mensaje de

oferta devuelto por el servidor DHCP
Muchas redes empresariales utilizan un servidor DHCP

centralizado, por lo que la configuración normal del
router incluye un comando ip helper-address en cada
interfaz/subinterfaz LAN. Con esa configuración
||||||||||||||||||||
||||||||||||||||||||
estándar, los hosts de usuario de cualquier interfaz LAN

del router siempre pueden llegar al servidor DHCP y
arrendar una dirección IP.
||||||||||||||||||||
||||||||||||||||||||
Información almacenada en el servidor DHCP

Un servidor DHCP puede sonar como una gran pieza de
hardware, situada en una gran habitación cerrada con un
montón de aire acondicionado para mantener el
hardware frío. Sin embargo, como la mayoría de los
servidores, el servidor es en realidad software, que se
ejecuta en algún sistema operativo de servidor. El
servidor DHCP podría ser una pieza de software
descargada gratuitamente e instalada en un viejo PC. Sin
embargo, debido a que el servidor necesita estar
disponible todo el tiempo, para soportar nuevos clientes
DHCP, la mayoría de las empresas instalan el software
en un centro de datos muy estable y de alta
disponibilidad, con características de alta disponibilidad.
Sin embargo, el servicio DHCP sigue siendo creado por
software.
Para estar preparado para responder a los clientes DHCP

y suministrarles una dirección IPv4 y otra información,
el servidor DHCP (software) necesita configuración. Los
servidores DHCP suelen organizar estas configuraciones
IPv4 por subred, ya que la información que el servidor
comunica al cliente suele ser la misma para todos los
hosts de la misma subred, pero ligeramente diferente
para los hosts de subredes diferentes. Por ejemplo, las
reglas de direccionamiento IP nos dicen que todos los
hosts de la misma subred deben usar la misma máscara,
pero los hosts de subredes diferentes tendrían una
configuración de puerta de enlace predeterminada
diferente.
La siguiente lista muestra los tipos de configuraciones

que el servidor DHCP necesita conocer para dar soporte
a los clientes DHCP:
||||||||||||||||||||
||||||||||||||||||||
ID de subred y máscara: El servidor DHCP puede

utilizar esta información para conocer todas las
direcciones de la subred. (El servidor DHCP sabe que
no debe arrendar el ID de subred ni la dirección de
difusión de subred).
Technet24
||||||||||||||||||||
||||||||||||||||||||
Direcciones reservadas (excluidas): El servidor

necesita saber qué direcciones de la subred no debe
arrendar.
Esta lista permite al ingeniero reservar direcciones
para utilizarlas como direcciones IP estáticas. Por
ejemplo, la mayoría de las direcciones IP de routers y
switches, direcciones de servidores y direcciones de
casi cualquier cosa que no sean dispositivos de
usuario utilizan una dirección IP asignada
estáticamente. La mayoría de las veces, los ingenieros
utilizan la misma convención para todas las subredes,
ya sea reservando las direcciones IP más bajas en
todas las subredes o reservando las direcciones IP
más altas en todas las subredes.
Enrutador(es) predeterminado(s): Es la
dirección IP del enrutador de esa subred.
Dirección(es) IP de DNS: Esta es una lista de

direcciones IP de servidores DNS.
La Figura 7-4 muestra el concepto detrás de la

preconfiguración en un servidor DHCP para dos
subredes basadas en LAN, 172.16.1.0/24 y
172.16.2.0/24. El servidor DHCP se encuentra a la
derecha. Para cada subred, el servidor define todos los
elementos de la lista. En este caso, la configuración
reserva las direcciones IP más bajas de la subred para
utilizarlas como direcciones estáticas.
||||||||||||||||||||
||||||||||||||||||||
Figura 7-4 Preconfiguración en un servidor DHCP
La configuración también puede incluir otros

parámetros. Por ejemplo, puede establecer el límite de
tiempo para arrendar una dirección IP. El servidor
alquila una dirección durante un tiempo (normalmente
un número de días), y entonces el cliente puede pedir
renovar el alquiler. Si el cliente no renueva, el servidor
puede reclamar la dirección IP y ponerla de nuevo en el
grupo de direcciones IP disponibles. La configuración
del servidor establece el tiempo máximo de alquiler.
DHCP utiliza tres modos de asignación, basados en

pequeñas diferencias en la configuración en el servidor
DHCP. La asignación dinámica se refiere a los
mecanismos y configuración DHCP descritos a lo largo
de este capítulo.
Otro método, la asignación automática, establece el
tiempo de arrendamiento DHCP en infinito. Como
resultado, una vez que el servidor elige una dirección del
pool y asigna la dirección IP a un cliente, la dirección IP
permanece con ese mismo cliente.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
indefinidamente. Un tercer modo, la asignación

estática, preconfigura la dirección IP específica para un
cliente basándose en la dirección MAC del cliente. Ese
cliente específico es el único que utiliza la dirección IP.
(Tenga en cuenta que este capítulo sólo muestra
ejemplos y configuración para la asignación dinámica).
Además, el servidor DHCP puede configurarse para

proporcionar otros parámetros de configuración útiles.
Por ejemplo, un servidor puede proporcionar la dirección
IP de un servidor TFTP (Trivial File Transfer Protocol).
Los servidores TFTP proporcionan un medio básico para
almacenar archivos que luego pueden ser transferidos a
un host cliente. Resulta que los teléfonos IP de Cisco
dependen de TFTP para recuperar varios archivos de
configuración cuando el teléfono se inicializa. DHCP
juega un papel clave proporcionando la dirección IP del
servidor TFTP que los teléfonos deben utilizar.
Configuración de funciones DHCP

en routers y switches
Los routers y switches Cisco soportan una gran
variedad de funciones. Los routers pueden ser
configurados para actuar como un servidor DHCP con
sólo unos pocos comandos directos, una característica
útil en el laboratorio y en algunos casos limitados. Más
comúnmente, la empresa utiliza un servidor DHCP
centralizado (que no se ejecuta en un router), pero con
la función de retransmisión DHCP del router en la
mayoría de cada interfaz del router. Por último, los
routers y switches Cisco también pueden actuar como
clientes DHCP, aprendiendo sus direcciones IP de un
servidor DHCP.
||||||||||||||||||||
||||||||||||||||||||
Esta sección discute los temas de configuración DHCP

mencionados para los temas actuales del examen. Estos
incluyen la función de retransmisión DHCP del router y
la configuración para habilitar los servicios de cliente
DHCP tanto en switches como en routers.
Nota
El anteproyecto del examen CCNA 200-301 no

menciona la función de servidor DHCP, pero a
mucha gente le gusta utilizar el servidor DHCP IOS
en el laboratorio para hacer pruebas con DHCP. Si le
interesa saber cómo configurar un servidor DHCP en
un router, consulte el Apéndice D, "Temas de
ediciones anteriores".
Configuración del DHCP Relay

La configuración del DHCP relay requiere una decisión
simple y un único comando de configuración sencillo.
En primer lugar, debe identificar las interfaces que
necesitan la función.
La función de retransmisión DHCP debe configurarse
para cualquier interfaz de router que se conecte a una
subred donde
Existen clientes DHCP en la subred
No existen servidores DHCP en la subred
Una vez identificadas dichas interfaces, la

configuración requiere la interfaz ip helper-address
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
en cada una de esas interfaces. Por ejemplo, con la

Figura 7-3 anterior, la interfaz G0/0 de R1 necesita ser
configurada con el subcomando de interfaz ip helper-
address 172.16.2.11. Una vez habilitado en una interfaz,
el agente retransmisor DHCP del IOS realiza cambios en
las direcciones de los mensajes DHCP entrantes como se
describió anteriormente en el capítulo. Sin el agente de
retransmisión DHCP, la solicitud DHCP nunca llega al
servidor.
Para verificar el agente de retransmisión, puede

utilizar el comando show running-config y buscar
el comando de configuración única o utilizar el
comando show ip interface g0/0 como se muestra
en el Ejemplo 7-1. La línea resaltada confirma el
ajuste configurado. Tenga en cuenta que si no hubiera
comandos ip helper-address configurados en la
interfaz, el texto diría en su lugar "Helper address is
not set".
Ejemplo 7-1 Listado de la configuración actual de la

dirección del ayudante con show ip interface
R1# show ip interface g0/0

GigabitEthernet0/0 está activada, el
protocolo de línea está activado La
dirección de Internet es 172.16.1.1/24 La
dirección de difusión es 255.255.255.255 La
dirección está determinada por la memoria
no volátil La MTU es 1500 bytes
La dirección del ayudante es 172.16.2.11
¡! Líneas omitidas por brevedad (unas 20 lineSc
Configuración de un switch como cliente DHCP
||||||||||||||||||||
||||||||||||||||||||
Un conmutador puede actuar como cliente DHCP para

arrendar su dirección IP. En la mayoría de los casos,
querrá utilizar en su lugar una dirección IP estática para
que el personal pueda identificar más fácilmente la
dirección del switch para la gestión remota. Sin
embargo, como ejemplo de cómo puede funcionar un
cliente DHCP, el siguiente tema muestra cómo
configurar y verificar las operaciones del cliente DHCP
en un switch.
Nota
El capítulo 6, "Configuring Basic Switch

Management," en CCNA 200-301 Official Cert
Guide, Volume 1, también muestra este mismo
ejemplo de cómo configurar un switch para que sea
un cliente DHCP. Este capítulo repite el ejemplo
aquí para que pueda ver todos los detalles de
configuración DHCP relacionados en un solo lugar
en este volumen.
Para configurar un conmutador para que utilice DHCP

para arrendar una dirección, configure la dirección IP
de un conmutador de manera normal, pero con el
subcomando de interfaz ip address dhcp. El Ejemplo
7-2 muestra un ejemplo.
Ejemplo 7-2 Configuración de la

dirección IP dinámica del switch con
DHCP
||||||||||||||||||||
||||||||||||||||||||
Emma# configurar terminal

con CNTL/Z. Emma(config)# interfaz vlan 1
Emma(config-if)# ip address dhcp
Emma(config-if)# no shutdown
Technet24
||||||||||||||||||||
||||||||||||||||||||
Emma(config-if)# ^Z
Emma
00:38:20: %LINK-3-UPDOWN: Interfaz Vlan1, cambio de estado a up
00:38:21: %LINEPROTO-5-UPDOWN: Protocolo de línea en interfaz
Vlan1,
Para verificar que DHCP funcionó, comience con la

forma tradicional de verificar las direcciones IP en las
interfaces VLAN del switch: el comando show
interfaces vlan x como se demuestra en el Ejemplo 7-3.
Primero, compruebe el estado de la interfaz, porque el
switch no intenta DHCP hasta que la interfaz VLAN
alcanza un estado up/up. En particular, si se olvida de
emitir el comando no shutdown, la interfaz VLAN 1
permanecerá en estado shutdown y aparecerá como
"administratively down" en la salida del comando show.
Ejemplo 7-3 Verificación de la dirección IP obtenida

por DHCP en un conmutador
Emma# show interfaces vlan 1

Vlan1 está activa, protocolo de línea activo
El hardware es EtherSVI, la dirección es 0019.e86a.6fc0 (bia
0019.e86a.
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
fiabilidad 255/255, txload 1/255, rxload 1/255
La segunda mitad del Ejemplo 7-3 muestra la salida del

comando show interfaces vlan x, que lista la dirección
IP de la interfaz en la tercera línea. Si configura
estáticamente la dirección IP, la dirección IP siempre
aparecerá en la lista; sin embargo, cuando se usa DHCP,
esta línea sólo existe si
||||||||||||||||||||
||||||||||||||||||||
DHCP tuvo éxito. También, note que cuando está

presente, la salida no indica si la dirección fue
configurada estáticamente o aprendida con DHCP. La
salida lista 192.168.1.101 como la dirección, pero sin
información para identificar si la dirección IP es una
dirección IP estática o aprendida con DHCP.
Para ver más detalles específicos de DHCP, utilice el

comando show dhcp lease para ver la dirección IP
arrendada (temporalmente) y otros parámetros. (Tenga
en cuenta que el conmutador no almacena la
configuración IP aprendida DHCP en el archivo running-
config). El Ejemplo 7-4 muestra un ejemplo de salida.
Observe también que el conmutador aprende su
configuración de pasarela por defecto utilizando también
DHCP.
Ejemplo 7-4 Verificación de la información obtenida

por DHCP en un conmutador
Emma# show dhcp lease

Temp IP addr: 192.168.1. 101for peer on Interface:
Vlan1 Temp sub net mask: 255.255.255.0
Servidor DHCP Lease: 192.168.1.1, estado: 3 Bound
DHCP transaction id: 1966
Arrendamiento: 86400 segs, Renovación: 43200 segs, Reenganche:
75600 segs Temp default-gateway addr: 192.168.1.1
El siguiente temporizador se dispara después de: 11:59:45
Cuenta de reintentos: 0 Client-ID:cisco-
0019.e86a.6fc0-Vl1 Hostname: Emma
Emma# show ip default-gateway

192.168.1.1
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Configuración de un router como cliente DHCP

Al igual que con los switches, puedes configurar las
interfaces de los routers para arrendar una dirección IP
usando DHCP en lugar de usar una dirección IP estática,
aunque esos casos serán raros. En la mayoría de los
casos tiene más sentido configurar estáticamente las
direcciones IP de la interfaz del router con la dirección
listada en el subcomando de interfaz ip address mask.
Sin embargo, configurar un router para arrendar una
dirección usando DHCP tiene sentido en algunos casos
con un router conectado a Internet; de hecho, la mayoría
de los routers domésticos hacen exactamente eso.
Un router con un enlace a Internet puede aprender su

dirección IP y máscara con DHCP y también aprender
la dirección del router ISP vecino como pasarela por
defecto. La Figura 7-5 muestra un ejemplo, con tres
routers a la izquierda en un emplazamiento empresarial.
El router R1 utiliza DHCP para aprender su dirección
IP (192.0.2.2) del router ISP a través de una conexión a
Internet.
Figura 7-5 Router de Empresa Construyendo y

Anunciando Rutas por Defecto con Cliente DHCP
||||||||||||||||||||
||||||||||||||||||||
El proceso DHCP suministra una dirección IP de

pasarela por defecto al router R1, pero los routers
normalmente no utilizan una configuración de pasarela
por defecto; sólo los hosts utilizan una configuración de
pasarela por defecto. Sin embargo, el router aprovecha
esa información convirtiendo esa dirección IP de
pasarela por defecto en la base de una ruta por defecto.
Por ejemplo, en la Figura 7-5, el router R1 añade
dinámicamente una ruta por defecto a su tabla de
enrutamiento con la dirección IP de la pasarela por
defecto del mensaje DHCP
-que es la dirección IP del router del ISP- como
dirección de siguiente salto. En ese momento, R1 tiene
una buena ruta para reenviar paquetes a Internet.
Además, el router R1 puede distribuir esa ruta por

defecto al resto de los routers utilizando un protocolo de
enrutamiento interior como OSPF. Consulte la sección
titulada "OSPF Default Routes" en el Capítulo 20 de la
CCNA 200-301 Official Cert Guide, Volumen 1, para
obtener más información.
El Ejemplo 7-5 muestra la configuración en el router R1

para que coincida con la Figura 7-5. Note que comienza
con R1 configurando su interfaz G0/1 para usar DHCP
para aprender la dirección IP a usar en la interfaz,
usando el comando ip address dhcp.
Ejemplo 7-5 Aprendizaje de una dirección y una

ruta estática por defecto con DHCP
||||||||||||||||||||
||||||||||||||||||||

R1(config)# interface
gigabitethernet0/1 R1(config-if)# ip
address dhcp R1(config-if)# end
R1#
Technet24
||||||||||||||||||||
||||||||||||||||||||
R1# show ip route static

¡! Leyenda omitida
La pasarela de último recurso es 192.0.2.1 a la red
0.0.0.0
S* 0.0.0.0/0 [254/0] vía 192.0.2.1
El final del ejemplo muestra la ruta por defecto añadida

a la tabla de enrutamiento de R1 como resultado del
aprendizaje de una dirección de puerta de enlace por
defecto de 192.0.2.1 desde DHCP. Extrañamente, IOS
muestra esta ruta como una ruta estática (destino
0.0.0.0/0), aunque la ruta es aprendida dinámicamente
basada en el gateway por defecto aprendido de DHCP.
Para reconocer esta ruta como una ruta por defecto
aprendida de DHCP, fíjese en el valor de distancia
administrativa de 254. IOS utiliza una distancia
administrativa por defecto de 254. IOS utiliza una
distancia administrativa predeterminada de 1 para las
rutas estáticas configuradas con el comando de
configuración ip route, pero un valor predeterminado de
254 para las rutas predeterminadas agregadas debido a
DHCP.
IDENTIFICACIÓN DE LA CONFIGURACIÓN IPV4 DEL HOST

Tanto si se aprende usando DHCP como si no, cada host
que usa IP versión 4 necesita tener algunas
configuraciones para funcionar correctamente. Esta
segunda gran división del capítulo examina esas
configuraciones y muestra ejemplos de las mismas en
Windows, Linux y macOS.
Configuración de host para IPv4

Para funcionar correctamente, un host IPv4 necesita
||||||||||||||||||||
||||||||||||||||||||
conocer estos valores:
||||||||||||||||||||
||||||||||||||||||||
Direcciones IP del servidor DNS
Dirección IP de la puerta de enlace
predeterminada (enrutador) Dirección IP
propia del dispositivo
Máscara de subred propia del dispositivo
Para repasar lo básico, el host debe conocer la dirección

IP de uno o más servidores DNS para enviar las
peticiones de resolución de nombres de los servidores.
Para las empresas, los servidores pueden residir en la
empresa, como se muestra en la Figura 7-6. El host de la
izquierda (a veces llamado endpoint) normalmente
conoce las direcciones de al menos dos servidores DNS
por redundancia. Si el primer DNS no responde, el
endpoint puede intentar la resolución de nombres con el
siguiente servidor DNS.
Figura 7-6 El host A necesita conocer la dirección

IP de los servidores DNS
Cada endpoint necesita conocer la dirección IP de un

router que resida en la misma subred. El endpoint
utiliza ese router como su router por defecto o pasarela
por defecto, como se muestra a continuación
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
en la Figura 7-7. Desde una perspectiva lógica de host, el

host puede entonces reenviar paquetes destinados a
direcciones fuera de la subred al router por defecto, con
ese router reenviando entonces el paquete basado en su
tabla de enrutamiento.
Figura 7-7 La configuración del router por

defecto del host debe ser igual a la dirección de
la interfaz del router
Por supuesto, cada dispositivo necesita su propia

dirección IP y máscara de subred. Igualmente importante
es que el host y el router por defecto se pongan de
acuerdo sobre las direcciones dentro de la subred. El host
utilizará la dirección y la máscara para hacer los cálculos
y determinar qué direcciones están en la misma subred y
cuáles están en otras subredes. Para que el enrutamiento
funcione correctamente, la dirección y la máscara de la
interfaz del enrutador por defecto deben dar como
resultado la misma definición de la subred con las
mismas direcciones, como se muestra en la Figura 7-8.
||||||||||||||||||||
||||||||||||||||||||
Figura 7-8 Necesidad de un acuerdo de

subred entre el host y el router por defecto
El resto de esta sección muestra ejemplos de la

visualización de estos ajustes en la interfaz gráfica de
usuario (GUI) y la interfaz de línea de comandos (CLI)
de tres sistemas operativos host diferentes.
Configuración de la IP del host en Windows

La mayoría de los sistemas operativos del mundo, sin
duda los más comunes con los que la gente trabaja a
diario, tienen una ventana de configuración bastante fácil
de alcanzar que enumera la mayoría, si no todos, los
ajustes IPv4 en un solo lugar. Por ejemplo, la Figura 7-9
muestra la pantalla de configuración de red de un host
Windows 10 desde el área de red del Panel de control de
Windows.
Este ejemplo concreto muestra las cuatro grandes
configuraciones: dirección, máscara, router y DNS.
Sin embargo, más allá de la interfaz gráfica de usuario,

la mayoría de los sistemas operativos tienen una
variedad de comandos de red disponibles desde una
línea de comandos. En todas las versiones de Windows,
los comandos ipconfig e ipconfig
||||||||||||||||||||
||||||||||||||||||||
Los comandos /all proporcionan la ayuda más directa, como se muestra en
Technet24
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 7-6. Como puede ver, ambos listan la

dirección, máscara y puerta de enlace predeterminada,
con el comando ipconfig /all listando también la
configuración del servidor DNS .
Figura 7-9 Dirección IP, máscara y configuración

predeterminada del router en Windows
Ejemplo 7-6 ipconfig e ipconfig/all (Windows)
||||||||||||||||||||
||||||||||||||||||||
C:\DOCUME1\OWNER> ipconfig
Configuración IP Windows
Adaptador Ethernet Ethernet3:
Sufijo DNS específico de la conexión .

:
Dirección IPv4. . . . . . . . . . . : 192.168.1.172
Máscara de subred: 255.255.255.0
Puerta de enlace predeterminada..: 192.168.1.1
C:\DOCUME1\OWNER> ipconfig /all

Adaptador Ethernet Ethernet 3:
Sufijo DNS específico de la conexión . :

Descripción : ASIX AX88179 USB 3.0 a Gi
Dirección física. . . . . . . : 00-05-1B-A3-5D-D0
DHCP Activado . . . . . . . . . : Sí
Autoconfiguración Activada . . . : Sí
Dirección IPv4. . . . . . . . . : 192.168.1.172(Preferida)
Máscara de subred : 255.255.255.0
Arrendamiento Obtenido . . . . . . . . : Viernes, 2 de agosto
de 2019 12: Expiración del arrendamiento . . . . . . . . :
Sábado, 3 de agosto de 2019 1
Puerta de enlace predeterminada : 192.168.1.1
Servidor DHCP : 192.168.1.1
Servidores DNS : 208.67.222.222
208.67.220.220
NetBIOS sobre Tcpip. . . . . . : Activado
Otro comando común en la mayoría de los sistemas

operativos de host de usuario es el comando netstat -
rn. Este comando muestra la tabla de enrutamiento IP
del host. De interés, la parte superior de la tabla lista
una ruta basada en la puerta de enlace predeterminada,
con la subred de destino y la máscara listadas como
0.0.0.0 y 0.0.0.0. La parte superior de la salida también
lista varias otras rutas relacionadas con tener una
interfaz de trabajo, como una ruta a la subred
conectada a la interfaz. El Ejemplo 7-7 muestra un
||||||||||||||||||||
||||||||||||||||||||
extracto de la salida
Technet24
||||||||||||||||||||
||||||||||||||||||||
netstat -rn desde el mismo host Windows, con la ruta

por defecto y la ruta a la subred local (192.168.1.0) en
la lista. Tenga en cuenta que una puerta de enlace de
"on-link" significa que el PC piensa que el destino está
en la subred local (enlace).
Ejemplo 7-7 Comando netstat -rn (Windows)

imagen del código
C:³\DOCUME1\OWNER> netstat -rn
Tabla de rutas IPv4

=================================================================
Rutas activas:
Red de destino Máscara de red Pasarela Interfa
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.
127.0.0.0 255.0.0.0 En enlace 127.0.
127.0.0.1 255.255.255.255 En enlace 127.0.
127.255.255.255 255.255.255.255 En enlace 127.0.
169.254.0.0 255.255.0.0 En enlace 169.254.244.
169.254.244.178 255.255.255.255 En enlace 169.254.244.
169.254.255.255 255.255.255.255 En enlace 169.254.244.
192.168.1.0 255.255.255.0 En enlace 192.168.1.
192.168.1.172 255.255.255.255 On-link 192.168.1.
192.168.1.255 255.255.255.255 On-link 192.168.1.
¡! Líneas omitidas en aras de la
brevedad
Configuración de la IP del host en macOS

Aunque los detalles varían, al igual que Windows,
macOS tiene tanto una interfaz gráfica para ver la
configuración de red como una variedad de comandos de
red. Esta sección muestra ejemplos de cada una de ellas,
empezando por la Figura 7-10. Muestra la configuración
de red en macOS para una interfaz Ethernet, con la
dirección, la máscara, el router por defecto y las
direcciones del servidor DNS. Observa también que la
configuración indica que la interfaz
||||||||||||||||||||
||||||||||||||||||||
está utilizando DHCP.

por defecto del router en macOS
Tanto macOS como Linux soportan el comando ifconfig

para listar información similar al comando ipconfig /all
de Windows. (Tenga en cuenta que ifconfig no tiene una
opción /all.) Cabe destacar que el comando ifconfig no
muestra la puerta de enlace predeterminada o los
servidores DNS, por lo que el Ejemplo 7-8 incluye otros
dos comandos de macOS que proporcionan esos
detalles.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 7-8 ifconfig, networksetup -getinfo y

networksetup -getdnsservers (macOS)

imagen del código
Wendell-Odoms-iMac:~ wendellodom$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
éter 0c:4d:e9:a9:9c:41
inet 192.168.1.102 máscara de red 0xffffff00 broadcast
192.168.1
¡! Detalles de IPv6 omitidos por brevedad
medio: autoselect (1000baseT <full-duplex,flow-control,en
ethernet>)
estado: activo
Wendell-Odoms-iMac:~ wendellodom$ networksetup -getinfo Ethernet

Configuración DHCP
Dirección IP: 192.168.1.102
Máscara de subred: 255.255.255.0
Enrutador: 192.168.1.1
ID de cliente:
IPv6: Automático
Dirección IPv6: ninguna
Enrutador IPv6: ninguno
Dirección Ethernet: 0c:4d:e9:a9:9c:41
Wendell-Odoms-iMac:~ wendellodom$ networksetup -getdnsservers Eth

8.8.8.4
8.8.8.8
Al igual que Windows, macOS añade una ruta

predeterminada a su tabla de enrutamiento de host
basada en la puerta de enlace predeterminada, así como
una ruta a la subred local calculada a partir de la
dirección IP y la máscara aprendidas con DHCP. Y al
igual que Windows, macOS utiliza el comando netstat -
rn para listar esas rutas, pero con varias diferencias en la
salida. En el ejemplo de macOS mostrado en el Ejemplo
7-9, el comando
||||||||||||||||||||
||||||||||||||||||||
representa la ruta por defecto utilizando la palabra

por defecto en lugar de los números emparejados 0.0.0.0 y
0.0.0.0 para la subred y la máscara de destino.
Ejemplo 7-9 Comando netstat -rn (macOS)

imagen del código
C:³\DOCUME1\OWNER> netstat -
rn
Tablas de encaminamiento
Internet:
Destino Pasarel Bande Refe Uti
por defecto a192.168.1.1 ras renc lic
127 127.0.0.1 UGSc ias e
127.0.0.1 127.0.0.1 UCS 92 0
169.254 enlace#5 UH 0 0
169.254.210.104 0:5:1b:a3:5d:d0 UCS 4 1950
192.168.1 enlace UHLSW 2 0
192.168.1.1/32 #5 UCS 0 0
192.168.1.1 enlace
60:e3:27:fb:70:97 UCS 9 0
192.168.1.102/32 #5
enlace#5 UHLWIir 1 0
UCS 12 2502
! líneas omitidas por
brevedad 0 0
Configuración de la IP del host en Linux

En Linux, las ventanas gráficas para mostrar la
configuración de red difieren por muchas razones. En
primer lugar, el mundo Linux incluye un gran número de
versiones o distribuciones Linux diferentes. Además,
Linux separa el sistema operativo del escritorio (la
interfaz gráfica) de modo que un usuario de una
distribución de Linux puede elegir entre diferentes
interfaces de escritorio. Como resultado, verás diferentes
pantallas GUI para mostrar la configuración de red de
Linux.
A modo de perspectiva, esta sección muestra algunos

ejemplos del escritorio MATE incluido en Ubuntu
MATE Linux
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
distribución (www.ubuntu-mate.org). En primer lugar, la

imagen de la Figura 7-11 muestra los detalles de un
adaptador LAN inalámbrico e incluye la dirección IPv4,
la máscara, el enrutador predeterminado y la dirección IP
DNS primaria.

por defecto del router en Linux
Desde la línea de comandos, los hosts Linux suelen

soportar un amplio conjunto de comandos. Sin embargo,
un antiguo conjunto de comandos, referenciados
conjuntamente como net-tools, ha quedado obsoleto en
Linux, hasta el punto de que algunos Linux
||||||||||||||||||||
||||||||||||||||||||
no incluyen net-tools. (La biblioteca net-tools incluye

ifconfig y netstat -rn. Para reemplazar esas
herramientas, Linux utiliza la biblioteca iproute, que
incluye un conjunto de comandos y funciones de
reemplazo, muchos realizados con el comando ip y
algunos parámetros.
Nota
Consulte este enlace para una comparación más
amplia de los comandos:
https://access.redhat.com/sites/default/files/attachments/rh_ip
El Ejemplo 7-10 muestra un ejemplo del comando

ifconfig para la misma interfaz detallada en la Figura 7-
11. Observe que lista las direcciones Ethernet MAC e
IPv4, junto con la máscara de subred, similar a la versión
macOS del comando. Sin embargo, en Linux, también
muestra algunos contadores de interfaz.
Ejemplo 7-10 Comandos ifconfig e ip address

(Linux)
chris@LL ~ $ ifconfig wlan0

wlan0 Enlace encap:Ethernet HWaddr 30:3a:64:0d:73:43
inet addr:192.168.1.223 Bcast:192.168.1.255 Mask:255.
inet6 addr: fe80::e5b8:f355:636a:b2a4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Métrica:1
RX paquetes:2041153 errores:0 abandonados:0
desbordamientos:0 trama: TX paquetes:712814 errores:0
abandonados:0 desbordamientos:0 portadora
Technet24
||||||||||||||||||||
||||||||||||||||||||
colisiones:0 txqueuelen:1000
RX bytes:2677874115 (2,6 GB) TX bytes:134076542 (134,0
chris@LL ~ $ dirección ip
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq sta
link/ether 30:3a:64:0d:73:43 brd ff:ff:ff:ff:ff:ff:ff:ff
inet 192.168.1.223/24 brd 192.168.1.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::e5b8:f355:636a:b2a4/64 scope link
valid_lft forever preferred_lft forever
La parte inferior del ejemplo muestra el comando del

paquete iproute que sustituye a ifconfig, es decir, la
dirección ip. Observe que muestra la misma
información básica de direccionamiento, sólo que con la
máscara de subred mostrada en notación de prefijo en
lugar de decimal con puntos.
Linux también ha soportado durante mucho tiempo el

comando netstat -rn, como parte del paquete net-tools,
con un ejemplo mostrado en el Ejemplo 7-11. La salida
lista la ruta por defecto, pero con un estilo que muestra el
destino como 0.0.0.0. La salida lista una ruta por defecto,
pero con un estilo que muestra el destino como 0.0.0.0.
Como es usual, la ruta por defecto apunta a la pasarela
por defecto aprendida con DHCP: 192.168.1.1. También
lista una ruta a la red local. También muestra una ruta a
la subred local (192.168.1.0 como se resalta en la parte
inferior de la salida).
Ejemplo 7-11 Comandos netstat -rn e ip route

(Linux)
chris@LL ~ $ netstat -rn

Tabla de enrutamiento IP del núcleo
Destino Pasarela Genmask Bander MSS Windo
as
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0
||||||||||||||||||||
||||||||||||||||||||
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0
||||||||||||||||||||
||||||||||||||||||||
chris@LL ~ $ ip route
default via 192.168.1.1 dev wlan0 proto static metric 600
169.254.0.0/16 dev wlan0 scope link metric 1000
192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1
chris@LL ~ $
La parte inferior del ejemplo muestra el comando

destinado a sustituir a netstat -rn: ip route. Observe
que también muestra una ruta por defecto que hace
referencia al enrutador por defecto, junto con una ruta
para la subred local.
detalles. En la Tabla 7-2 se indican los elementos de
repaso más importantes y dónde encontrarlos. Para
hacer un mejor seguimiento de su progreso en el
estudio, registre cuándo completó estas actividades en
la segunda columna.

utilizado
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||

comandos

Tema Número
Elemento
Lista Definiciones de direcciones IPv4 especiales 125

0.0.0.0 y 255.255.255.255
Lista Cuatro pasos lógicos creados por el 127

comando ip helper- address
Figura 7- Qué cambia el comando ip helper- 127

2 address en un mensaje DHCP Discover
Lista Los dos hechos que deben ser ciertos 130

sobre una subred para que un router
necesite ser un agente de retransmisión
DHCP para esa subred
Ejemplo Comandos de switch que confirman los 131

7-4 detalles de las operaciones del cliente
DHCP basadas en el subcomando ip
address dhcp interface
Lista La configuración IPv4 esperada en un 133

host de usuario final
Ejemplo Salida de un ipconfig /all de Windows 135

7-6 comando
||||||||||||||||||||
||||||||||||||||||||
Ejemplo Salida de un comando ifconfig de 137

7-8 macOS más dos comandos
networksetup

Cliente DHCP
Servidor DHCP
Agente de retransmisión DHCP
pasarela por defecto
Servidor DNS
Las tablas 7-4, 7-5 y 7-6 enumeran los comandos de
hace el comando.

configuración
ip helper- Un subcomando de interfaz que indica al router que

address se fije en las difusiones de subred local (a
Dirección 255.255.255.255) que utilizan UDP, y cambie la
IP dirección IP de origen y destino, permitiendo que los
servidores DHCP se sitúen en una subred remota.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
dirección Subcomando de interfaz que indica al router o

ip dhcp switch que utilice DHCP para intentar arrendar una
dirección DHCP desde un servidor DHCP.
show arp, Comando que lista la tabla ARP IPv4 del router
show ip
arp
show Comando de switch que lista información sobre

dhcp direcciones arrendadas debido a la configuración del
lease comando ip address dhcp
show ip Comando del conmutador que enumera la

default- configuración de la puerta de enlace predeterminada
gateway del conmutador, independientemente de si se ha
obtenido mediante DHCP o se ha configurado
estáticamente.

genéricos de red de host
ipconfig /all (Windows) Enumera la dirección IP, la máscara, la

puerta de enlace y los servidores DNS.
ifconfig (Mac, Linux) Lista la dirección IP y la máscara de

una interfaz
networksetup (Mac) Enumera la configuración IP, incluido el

-getinfo enrutador predeterminado.
interfaz
||||||||||||||||||||
||||||||||||||||||||
networksetup (Mac) Lista los servidores DNS utilizados

-
getdnsservers
interfaz
netstat -rn (Windows, Mac, Linux) Lista la tabla de

enrutamiento del host, incluyendo una ruta por
defecto que utiliza la puerta de enlace por
defecto aprendida de DHCP.
arp -a (Windows, Mac, Linux) Lista la tabla ARP del

host
dirección ip (Linux) Enumera la información sobre

direcciones IP y máscaras de las interfaces; es
el sustituto de ifconfig en Linux.
ruta ip (Linux) Enumera las rutas, incluida la ruta por

defecto y una ruta a la subred local; el sustituto
de Linux para netstat -rn
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 8. DHCP Snooping

e inspección ARP

5.7 Configurar funciones de seguridad de Capa 2
(DHCP snooping, inspección ARP dinámica y
seguridad de puertos)
Para comprender los tipos de riesgos que existen en las

redes modernas, primero hay que entender las reglas.
Luego hay que pensar en cómo un atacante podría
aprovecharse de esas reglas de diferentes maneras.
Algunos ataques podrían causar daños como parte de un
ataque de denegación de servicio (DoS), mientras que un
ataque de reconocimiento podría recopilar más datos
para preparar algún otro ataque. Para cada protocolo y
función que aprendes en redes, hay posibles métodos
para aprovecharse de esas características para dar ventaja
a un atacante.
Este capítulo discute dos características del switch que

ayudan a prevenir algunos tipos de ataques que pueden
resultar en que el atacante obtenga copias de paquetes
enviados a/desde un host legítimo. Una de estas
funciones, DHCP Snooping, detecta los mensajes
DHCP que quedan fuera del uso normal.
||||||||||||||||||||
||||||||||||||||||||
de DHCP -mensajes que pueden ser parte de un ataque-

y descarta esos mensajes. También vigila los mensajes
DHCP que fluyen a través de un conmutador LAN,
construyendo una tabla que enumera los detalles de los
flujos DHCP legítimos, para que otras funciones del
conmutador puedan saber qué arrendamientos DHCP
legítimos existen para los dispositivos conectados al
conmutador.
La segunda de estas funciones, la inspección dinámica

de ARP (DAI), también ayuda a evitar que los paquetes
se redirijan a un host atacante. Algunos ataques ARP
intentan convencer a los hosts para que envíen paquetes
al dispositivo del atacante en lugar de al verdadero
destino. El switch vigila los mensajes ARP a medida que
fluyen a través del switch. El conmutador comprueba los
mensajes ARP entrantes, cotejándolos con el
funcionamiento normal de ARP, así como cotejando los
detalles con otras fuentes de datos, incluida la tabla de
vinculación de DHCP Snooping. Cuando el mensaje
ARP no coincide con la información conocida sobre las
direcciones legítimas en la red, el conmutador filtra el
mensaje ARP.
Este capítulo examina los conceptos y la configuración

de DHCP Snooping en la primera sección principal y
DAI en la segunda.

||||||||||||||||||||
||||||||||||||||||||
como en la página
Technet24
||||||||||||||||||||
||||||||||||||||||||
incluye tanto las respuestas como las explicaciones.

También puede encontrar las respuestas y las
explicaciones en el software de evaluación PTP.

Snooping DHCP 1-4
Inspección ARP dinámica 5-7
1. Un ingeniero oye hablar de DHCP Snooping y

decide implementarlo. ¿Cuáles de los siguientes
son los dispositivos en los que se podría
implementar DHCP Snooping? (Elija dos
respuestas).
1. Conmutadores de capa 2
2. Enrutadores
3. Conmutadores multicapa
4. Host de usuario final
2. El switch de capa 2 SW2 conecta un switch de

capa 2 (SW1), un router (R1), un servidor DHCP
(S1) y tres PCs (PC1, PC2 y PC3). Todos los PCs son
clientes DHCP. ¿Cuáles de las siguientes son las
configuraciones más probables del estado de
confianza de DHCP Snooping en SW2 para los
puertos conectados a los dispositivos listados?
1. El puerto conectado al router no es de confianza.
2. El puerto conectado al switch SW1 es de confianza.
3. El puerto conectado a PC1 no es de confianza.
||||||||||||||||||||
||||||||||||||||||||
4. El puerto conectado a PC3 es de confianza.
3. El switch SW1 necesita ser configurado para

utilizar DHCP Snooping en la VLAN 5 y sólo en
la VLAN 5. ¿Qué comandos deben incluirse,
asumiendo que al menos un puerto del switch en la
VLAN 5 debe ser un puerto no confiable? (Elija
dos respuestas).
1. no ip dhcp snooping trust
2. ip dhcp snooping untrust
3. ip dhcp snooping
4. ip dhcp snooping vlan 5
4. En un conmutador multicapa, un conmutador

necesita ser configurado para realizar DHCP
Snooping en algunos puertos de Capa 2 en la VLAN
3. Qué comando puede o no ser necesario
dependiendo de si el switch también actúa como
agente de retransmisión DHCP?
1. no ip dhcp snooping information option
2. ip dhcp snooping limit rate 5
3. errdisable recovery cause dhcp-rate-limit
4. ip dhcp snooping vlan 3
5. El switch SW1 ha sido configurado para utilizar la

Inspección ARP Dinámica con DHCP Snooping en la
VLAN 5. Una petición ARP llega al puerto G0/1.
¿Qué respuesta describe dos elementos que DAI
siempre compara independientemente de la
configuración?
1. La dirección de hardware de origen ARP del mensaje y la
dirección MAC de origen de la cabecera Ethernet del mensaje.
2. La dirección de hardware de origen ARP del mensaje y la
tabla de vinculación de DHCP Snooping.
3. La dirección IP de destino ARP del mensaje y la tabla de
vinculación DHCP Snooping.
4. La dirección IP de destino ARP del mensaje y la tabla ARP del switch.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
6. El switch SW1 necesita ser configurado para utilizar

Inspección ARP Dinámica junto con DHCP Snooping en
la VLAN 6 y sólo en la VLAN 6. ¿Qué comandos
deben incluirse, asumiendo que al menos un puerto
del switch en la VLAN 6 debe ser un puerto de
confianza? (Elija dos respuestas).
1. no ip arp inspection untrust
2. ip arp inspection trust
3. inspección ip arp
4. ip arp inspection vlan 6
7. Un switch de Capa 2 necesita ser configurado para

usar Inspección Dinámica ARP junto con DHCP
Snooping. ¿Qué comando haría que DAI
monitoreara las tasas de mensajes ARP en una
interfaz a una tasa promedio de 4 mensajes ARP
recibidos por segundo? (Elija dos respuestas).
1. ip arp inspection limit rate 4 burst interval 2
4. ip arp inspection limit rate 4
1 A, C
2 B, C
3 C, D
4 A
5B
6 B, D
7 C, D
||||||||||||||||||||
||||||||||||||||||||
Temas básicos
SNOOPING DHCP
Los servidores DHCP juegan un papel vital en la
mayoría de las redes hoy en día, con casi todos los
puntos finales de usuario utilizando DHCP para aprender
su dirección IP, máscara, pasarela por defecto y
direcciones IP de servidor DNS. El Capítulo 7,
"Implementación de DHCP", muestra cómo debería
funcionar DHCP en circunstancias normales. Esta
sección examina ahora cómo los atacantes pueden
utilizar DHCP para sus propios fines y cómo dos
herramientas específicas - DHCP Snooping y la
Inspección dinámica de ARP (DAI) - ayudan a derrotar
esos ataques.
Esta sección comienza con un examen de la necesidad

de los conceptos de DHCP Snooping incluyendo los
tipos de ataques que puede tratar de prevenir, seguido
de detalles de cómo configurar DHCP Snooping.
Conceptos de DHCP Snooping

DHCP Snooping en un switch actúa como un cortafuegos
o una ACL en muchos sentidos. Analiza los mensajes
entrantes en el subconjunto especificado de puertos en
una VLAN. DHCP Snooping nunca filtra mensajes que
no sean DHCP, pero puede optar por filtrar mensajes
DHCP, aplicando la lógica para tomar una decisión:
permitir el mensaje DHCP entrante o descartar el
mensaje.
Mientras que el propio DHCP proporciona un servicio

de Capa 3, DHCP Snooping funciona en conmutadores
||||||||||||||||||||
||||||||||||||||||||
LAN y es comúnmente
Technet24
||||||||||||||||||||
||||||||||||||||||||
utilizado en switches LAN de Capa 2 y habilitado en

puertos de Capa 2. La razón para colocar DHCP
Snooping en el switch es que la función debe realizarse
entre un dispositivo de usuario final típico -el tipo de
dispositivo que actúa como cliente DHCP- y servidores
DHCP o agentes de retransmisión DHCP.
La Figura 8-1 muestra una red de ejemplo que

proporciona un buen telón de fondo para discutir DHCP
Snooping. Primero, todos los dispositivos se conectan
al switch SW2 de Capa 2, con todos los puertos como
switchports de Capa 2, todos en la misma VLAN. Los
clientes DHCP típicos se sitúan a la derecha de la
figura. La izquierda muestra otros dispositivos que
podrían ser la ruta a través de la cual alcanzar un
servidor DHCP.
Figura 8-1 Conceptos Básicos de DHCP Snooping:

Los puertos cliente no son de confianza
DHCP Snooping funciona primero en todos los puertos

de una VLAN, pero cada puerto es de confianza o no de
DHCP Snooping. Para entender por qué, considere este
resumen de las reglas generales utilizadas por DHCP
||||||||||||||||||||
||||||||||||||||||||
Snooping. Tenga en cuenta que
||||||||||||||||||||
||||||||||||||||||||
diferencian entre los mensajes enviados normalmente

por los servidores (como DHCPOFFER y DHCPACK) y los
enviados normalmente por los clientes DHCP:
Los mensajes DHCP recibidos en un puerto no confiable, para
mensajes normalmente enviados por un servidor, serán siempre
descartados.
Los mensajes DHCP recibidos en un puerto no fiable, como los que

normalmente envía un cliente DHCP, pueden ser filtrados si parecen
formar parte de un ataque.
Los mensajes DHCP recibidos en un puerto de confianza serán

reenviados; los puertos de confianza no filtran (descartan) ningún
mensaje DHCP.
Un ejemplo de ataque: Un servidor DHCP falso

Para darle algo de perspectiva, la Figura 8-2 muestra el
PC de un usuario legítimo en el extremo derecho y el
servidor DHCP legítimo en el extremo izquierdo. Sin
embargo, un atacante ha conectado su portátil a la LAN
y ha comenzado su ataque DHCP actuando como un
servidor DHCP. Siguiendo los pasos de la figura,
supongamos que el PC1 está intentando alquilar una
dirección IP mientras el atacante está realizando su
ataque:
1. PC1 envía una difusión LAN con el primer mensaje DHCP
de PC1 (DHCPDISCOVER).
2. El PC del atacante, actuando como un servidor DHCP falso,

responde al DHCPDISCOVER con un DHCPOFFER.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 8-2 El Ataque DHCP Suministra una Buena

Dirección IP pero una Puerta de Enlace
Predeterminada Equivocada
En este ejemplo, el servidor DHCP creado y utilizado

por el atacante realmente alquila una dirección IP útil a
PC1, en la subred correcta, con la máscara correcta. ¿Por
qué? El atacante quiere que PC1 funcione, pero con un
giro. Fíjate en la puerta de enlace predeterminada
asignada a PC1: 10.1.1.2, que es la dirección de PC del
atacante, en lugar de 10.1.1.1, que es la dirección del
router R1. Ahora PC1 piensa que tiene todo lo que
necesita para conectarse a la red, y lo tiene, pero ahora
todos los paquetes enviados por PC1 a lo que piensa que
es su enrutador por defecto fluyen primero a través del
PC del atacante, creando un ataque man-in- the-middle,
como se muestra en la Figura 8-3.
||||||||||||||||||||
||||||||||||||||||||
Figura 8-3 Resultado desafortunado: El ataque

DHCP conduce al Man-in-the-Middle
Tenga en cuenta que el DHCP legítimo también

devuelve un mensaje DHCPOFFER al host PC1, pero
la mayoría de los hosts utilizan el primer DHCPOFFER
recibido, y el atacante probablemente será el primero en
este escenario.
Los dos pasos de la figura muestran el flujo de datos

una vez finalizado el DHCP. Para cualquier tráfico
destinado a salir de la subred, PC1 envía sus paquetes a
su puerta de enlace predeterminada, 10.1.1.2, que
resulta ser el atacante. El atacante reenvía los paquetes
a R1. El usuario de PC1 puede conectarse a todas y
cada una de las aplicaciones como de costumbre, pero
ahora el atacante puede guardar una copia de todo lo
enviado por PC1.
Lógica de DHCP Snooping

El ejemplo anterior muestra sólo un ataque en el que el
atacante actúa como un servidor DHCP (servidor
DHCP espurio). DHCP Snooping derrota este tipo de
ataques haciendo que la mayoría de los puertos no sean
de confianza, lo que por definición filtraría los mensajes
||||||||||||||||||||
||||||||||||||||||||
del servidor DHCP que llegan a los puertos no de

confianza.
Technet24
||||||||||||||||||||
||||||||||||||||||||
puertos. Por ejemplo, en las Figuras 8-2 y 8-3, hacer

que el puerto conectado al atacante sea un puerto
DHCP Snooping no confiable derrota el ataque.
Para apreciar el amplio conjunto de reglas y lógica de

DHCP Snooping, ayuda tener una referencia práctica de
algunos de los mensajes y procesos DHCP más
comunes. Para un rápido repaso, el flujo normal de
mensajes incluye esta secuencia: DISCOVER, OFFER,
REQUEST, ACK
(DORA). En concreto:
Los clientes envían DISCOVER y
REQUEST. Los servidores envían
OFERTA y ACK.
Además, los clientes DHCP también utilizan el comando DHCP RELEASE

y mensajes DHCP DECLINE. Cuando un cliente tiene
un contrato de arrendamiento de trabajo para una
dirección, pero ya no quiere usar la dirección, el cliente
DHCP puede decirle al servidor DHCP que ya no
necesita la dirección, liberándola de nuevo al servidor
DHCP, con el mensaje DHCP RELEASE.
Del mismo modo, un cliente puede enviar un mensaje
DHCP DECLINE para rechazar el uso de una dirección
IP durante el flujo normal de mensajes DORA.
Pasemos ahora a la lógica para puertos DHCP Snooping

no confiables. La Figura 8-4 resume las ideas, con dos
puertos de switch. A la izquierda, el puerto del switch se
conecta a un servidor DHCP, por lo que debería ser de
confianza; de lo contrario DHCP no funcionaría, porque
el switch filtraría todos los mensajes DHCP enviados
por el servidor DHCP. A la derecha, PC1 se conecta a
un puerto no fiable con un cliente DHCP.
||||||||||||||||||||
||||||||||||||||||||
Figura 8-4 Resumen de reglas para DHCP Snooping
La siguiente lista resume las reglas de DHCP Snooping:
1. Examina todos los mensajes DHCP entrantes.
2. Si normalmente lo envían los servidores, descarte el mensaje.

3. Si normalmente lo envían los clientes, fíltrelo del siguiente modo:
1. Para los mensajes DISCOVER y REQUEST, compruebe la

coherencia de la dirección MAC entre la trama Ethernet y el
mensaje DHCP.
2. Para los mensajes RELEASE o DECLINE, compruebe la interfaz
entrante más la dirección IP frente a la tabla de vinculación de
DHCP Snooping.
4. Para los mensajes no filtrados que dan lugar a un arrendamiento

DHCP, cree una nueva entrada en la tabla de vinculación de
DHCP Snooping.
Las páginas siguientes completan la discusión de

conceptos explicando un poco más los pasos 3 y 4 de la
lista.
Filtrado de mensajes DISCOVER en función de la

dirección MAC
DHCP Snooping realiza una comprobación directa de la
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
mensajes más comunes enviados por el cliente:

DISCOVER y REQUEST. En primer lugar, ten en
cuenta que los mensajes DHCP definen el campo
chaddr (dirección de hardware del cliente) para
identificar al cliente. Los hosts en LAN incluyen la
dirección MAC del dispositivo como parte de chaddr.
Como es habitual, los hosts Ethernet encapsulan los
mensajes DHCP dentro de tramas Ethernet, y esas
tramas, por supuesto, incluyen una dirección MAC de
origen - una dirección que debería ser la misma
dirección MAC utilizada en el campo chaddr de DHCP.
DHCP Snooping hace una simple comprobación para
asegurarse de que esos valores coinciden.
La Figura 8-5 muestra cómo un atacante podría intentar

sobrecargar el servidor DHCP y arrendar todas las
direcciones de la subred. El PC del atacante utiliza la
pseudo dirección MAC A, por lo que los tres mensajes
DISCOVER de la figura muestran una dirección
Ethernet de origen "A". Sin embargo, cada mensaje (en
los datos DHCP) identifica una dirección MAC
diferente en el valor chaddr (mostrado como MAC1,
MAC2, y MAC3 en la figura para abreviar), así que
desde una perspectiva DHCP, cada mensaje parece ser
una petición DHCP diferente. El atacante puede intentar
arrendar cada dirección IP en la subred para que ningún
otro host pueda obtener un arrendamiento.
||||||||||||||||||||
||||||||||||||||||||
Figura 8-5 DHCP Snooping comprueba chaddr y

Ethernet Source MAC
La característica principal de DHCP Snooping derrota

este tipo de ataque en puertos no confiables.
Comprueba la dirección MAC de origen de la cabecera
Ethernet y la compara con la dirección MAC de la
cabecera DHCP, y si los valores no coinciden, DHCP
Snooping descarta el mensaje.
Filtrado de mensajes que liberan direcciones IP

Antes de ver la siguiente parte de la lógica, necesitas
entender primero la tabla de vinculación de DHCP
Snooping.
DHCP Snooping construye la tabla de vinculación

DHCP Snooping para todos los flujos DHCP que ve y
que permite completar. Es decir, para cualquier flujo
DHCP legítimo en funcionamiento, mantiene una lista de
algunos de los datos importantes. Entonces DHCP
Snooping, y otras características como la Inspección
ARP Dinámica, pueden usar la tabla para tomar
decisiones.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Como ejemplo, considere la Figura 8-6, que repite la

misma topología que la Figura 8-4, ahora con una
entrada en su tabla de enlace DHCP Snooping.
Figura 8-6 Cliente DHC P legítimo con entrada

DHCP Binding creada por DHCP Snooping
En esta red simple, el cliente DHCP de la derecha

arrienda la dirección IP 172.16.2.101 del servidor
DHCP de la izquierda. La función DHCP Snooping del
switch combina la información de los mensajes DHCP
con la información sobre el puerto (interfaz G1/0/3,
asignada a la VLAN 11 por el switch) y la coloca en la
tabla de enlace DHCP Snooping.
A continuación, DHCP Snooping aplica una lógica de

filtrado adicional que utiliza la tabla de vinculación de
DHCP Snooping: comprueba los mensajes enviados por
el cliente, como RELEASE y DECLINE, que harían
que el servidor DHCP pudiera liberar una dirección. Por
ejemplo, un usuario legítimo podría arrendar
||||||||||||||||||||
||||||||||||||||||||
172.16.2.101, y en algún momento liberar la dirección de

nuevo al servidor; sin embargo, antes de que el cliente
haya terminado con su arrendamiento, un atacante podría
enviar un mensaje DHCP RELEASE para liberar esa
dirección de nuevo en el pool. El atacante podría
entonces intentar inmediatamente arrendar esa dirección,
esperando que el servidor DHCP asigne esa misma
dirección 172.16.2.101 al atacante.
La Figura 8-7 muestra un ejemplo. PC1 ya tiene una

dirección DHCP (172.16.2.101), con SW2 listando una
entrada en la tabla DHCP Snooping binding. La figura
muestra la acción por la cual el atacante del puerto
G1/0/5 intenta liberar la dirección de PC1. DHCP
Snooping compara el mensaje entrante, la interfaz
entrante y la entrada de la tabla coincidente:
1. El mensaje entrante es un mensaje DHCP RELEASE en el puerto
G1/0/5 con la dirección 172.16.2.101.
2. La tabla de vinculación de DHCP Snooping enumera 172.16.2.101
como arrendada originalmente a través de mensajes que llegan al puerto
G1/0/3.
3. DHCP Snooping descarta el mensaje DHCP RELEASE.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 8-7 DHCP Snooping derrota una liberación

DHCP de otro puerto
Configuración de DHCP Snooping

DHCP Snooping requiere varios pasos de configuración
para que funcione. En primer lugar, es necesario utilizar
un par de comandos globales asociados: uno para activar
DHCP Snooping y otro para listar las VLAN en las que
utilizar DHCP Snooping. Ambos deben incluirse para
que DHCP Snooping funcione.
En segundo lugar, aunque no es literalmente necesario,

a menudo necesitará configurar algunos puertos como
puertos de confianza. La mayoría de los switches que
utilizan DHCP Snooping para una VLAN tienen
algunos puertos de confianza y otros no, y con un valor
por defecto de no confianza, es necesario configurar los
puertos de confianza.
Esta sección comienza con un ejemplo que muestra

cómo configurar un switch típico de Capa 2 para
utilizar DHCP Snooping, con los comandos requeridos
que se acaban de describir, y con otros comandos
opcionales.
Configuración de DHCP Snooping en un Switch de Capa 2

Todos los ejemplos siguientes se basan en la topología
ilustrada en la Figura 8-8, con el switch SW2 de Capa 2
como switch en el que habilitar DHCP Snooping. El
servidor DHCP se encuentra al otro lado de la WAN, a la
izquierda de la figura. Como resultado, el puerto de SW2
conectado al router R2 (un agente de retransmisión
DHCP) necesita ser de confianza. A la derecha, dos PC
de muestra pueden utilizar la configuración
||||||||||||||||||||
||||||||||||||||||||
predeterminada no fiable.
||||||||||||||||||||
||||||||||||||||||||
Figura 8-8 Ejemplo de red utilizada en los

ejemplos de configuración de DHCP Snooping
El switch SW2 coloca todos los puertos de la figura en la

VLAN 11, por lo que para habilitar DHCP Snooping en la
VLAN 11, SW2 requiere dos comandos, como se
muestra cerca de la parte superior del Ejemplo 8-1: ip
dhcp snooping e ip dhcp snooping vlan 11.
A continuación, para cambiar la lógica del puerto
G1/0/2 (conectado al router) para que sea de
confianza, la configuración incluye el subcomando ip
dhcp snooping trust interface.
Ejemplo 8-1 Configuración de DHCP Snooping que

coincide con la Figura 8-8
ip dhcp snooping
ip dhcp snooping vlan 11
no ip dhcp snooping information option
¡!
interface
GigabitEthernet1/0/2 ip dhcp
snooping trust
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Tenga en cuenta que el comando no ip dhcp snooping

information option del Ejemplo 8-1 se explicará en un
contexto mejor justo después del Ejemplo 8-2, pero se
enumera en el Ejemplo 8-1 para que el ejemplo sea
completo.
Con esta configuración, el switch sigue los pasos lógicos

detallados en la sección anterior titulada "Lógica de
DHCP Snooping." Para ver algún soporte para esa
afirmación, mire el Ejemplo 8-2, que muestra la salida
del comando show ip dhcp snooping en el switch SW2.
Ejemplo 8-2 SW2 Estado de DHCP Snooping

imagen del código
SW2# show ip dhcp snooping
Switch DHCP snooping está
activado Switch DHCP gleaning
está desactivado
DHCP snooping está configurado en las siguientes
VLAN: 11
DHCP snooping está operativo en las siguientes
VLAN: 11
Smartlog está configurado en las siguientes VLAN:
ninguno
Smartlog está operativo en las siguientes VLAN:
ninguno
DHCP snooping está configurado en las siguientes interfaces L3:
La inserción de la opción 82 está desactivada

circuit-id formato por defecto: vlan-
mod-port remote-id: bcc4.938b.a180
(MAC)
La opción 82 en un puerto no fiable no está
permitida La verificación del campo hwaddr
está activada La verificación del campo
giaddr está activada
DHCP snooping trust/rate está configurado en la siguiente
interfaz
Interfaz TrustedAllow opciónRate

límite
GigabitEthernet1/0/2 sí sí ilimitado
Circuit-ids personalizados:
||||||||||||||||||||
||||||||||||||||||||
Las líneas resaltadas en el ejemplo señalan algunos de

los ajustes de configuración clave. Empezando por
arriba, las dos primeras confirman la configuración de
los comandos ip dhcp snooping e ip dhcp snooping
vlan 11, respectivamente. Además, las líneas resaltadas
en la parte inferior de la salida muestran una sección que
lista los puertos de confianza-en este caso, sólo el puerto
G1/0/2.
Además, es posible que haya notado la línea resaltada

en el medio que dice Insertion of option 82 is
disabled. Esa línea confirma la adición del comando no
ip dhcp information option a la configuración del
Ejemplo 8-1. Para entender por qué el ejemplo incluye
este comando, considere estos hechos acerca de los
agentes de retransmisión DHCP:
Los agentes de retransmisión DHCP añaden nuevos campos a las
solicitudes DHCP, definidos como campos de cabecera DHCP de la
opción 82 (en RFC 3046).
DHCP Snooping utiliza una configuración predeterminada que

funciona bien si el switch actúa como switch de capa 3 y como
agente de retransmisión DHCP, lo que significa que el switch debe
insertar los campos de la opción 82 de DHCP en los mensajes DHCP.
En efecto, el switch utiliza por defecto la opción ip dhcp snooping
information.
Cuando el conmutador no actúa también como agente de

retransmisión DHCP, la configuración predeterminada impide que
DHCP funcione para los usuarios finales. El conmutador establece
campos en los mensajes DHCP como si fuera un agente de
retransmisión DHCP, pero los cambios en esos mensajes hacen que la
mayoría de los servidores DHCP (y la mayoría de los agentes de
retransmisión DHCP) ignoren los mensajes DHCP recibidos.
Conclusión: Para que DHCP Snooping funcione en un

conmutador que no sea también un agente de retransmisión
DHCP, desactive la función de opción 82 mediante el comando
no ip dhcp snooping information option global.
||||||||||||||||||||
||||||||||||||||||||
Con esto concluye la configuración de DHCP Snooping

que es necesaria y que necesitará realizar con mayor
frecuencia.
Technet24
||||||||||||||||||||
||||||||||||||||||||
la función. El resto de esta sección discute algunas

características opcionales de DHCP Snooping.
Limitación de la tasa de mensajes DHCP

Sabiendo que DHCP Snooping impide sus ataques,
¿qué podrían hacer los atacantes en respuesta? Idear
nuevos ataques, incluyendo atacar al propio DHCP
Snooping.
Una forma de atacar DHCP Snooping se aprovecha del

hecho de que utiliza la CPU de propósito general de un
switch. Sabiendo esto, los atacantes pueden idear ataques
para generar grandes volúmenes de mensajes DHCP en
un intento de sobrecargar la función DHCP Snooping y
la propia CPU del switch. El objetivo puede ser un
simple ataque de denegación de servicio o una
combinación de ataques que puedan causar que DHCP
Snooping falle al examinar cada mensaje, permitiendo
que otros ataques DHCP funcionen entonces.
Para ayudar a prevenir este tipo de ataque, DHCP

Snooping incluye una función opcional que rastrea el
número de mensajes DHCP entrantes. Si el número de
mensajes DHCP entrantes excede ese límite en un
periodo de un segundo, DHCP Snooping trata el evento
como un ataque y mueve el puerto a un estado de error
deshabilitado. Además, la función puede activarse tanto
en interfaces fiables como no fiables.
Aunque limitar la velocidad de los mensajes DHCP

puede ayudar, colocar el puerto en un estado de error
deshabilitado puede crear problemas.
Como recordatorio, una vez en el estado err-disabled, el
switch no enviará ni recibirá tramas para la interfaz.
||||||||||||||||||||
||||||||||||||||||||
Sin embargo, el estado "err-disabled" podría ser un problema demasiado

grave.
||||||||||||||||||||
||||||||||||||||||||
porque la acción de recuperación predeterminada para un

estado de error inhabilitado requiere la configuración de
un subcomando shutdown y luego un subcomando no
shutdown en la interfaz.
Para ayudar a lograr un mejor equilibrio, puede habilitar

la limitación de velocidad de DHCP Snooping y luego
también configurar el conmutador para que se recupere
automáticamente del estado err-disabled del puerto, sin
necesidad de un comando shutdown y luego no
shutdown.
El Ejemplo 8-3 muestra cómo habilitar los límites de

tasa de DHCP Snooping y la recuperación de errores
deshabilitados. Primero, mire la mitad inferior de la
configuración, a las interfaces, para ver la
configuración directa de los límites por interfaz usando
los subcomandos ip dhcp snooping rate limit
number interface. La parte superior de la
configuración utiliza dos comandos globales para
decirle a IOS que se recupere de un estado de error
deshabilitado si es causado por DHCP Snooping, y que
utilice un número no predeterminado de segundos
para esperar antes de recuperar la interfaz. Tenga en
cuenta que la configuración en el Ejemplo 8-3
dependería de la configuración central para DHCP
Snooping como se muestra en el Ejemplo 8-1.
Ejemplo 8-3 Configuración de límites de velocidad de

mensajes DHCP Snooping
||||||||||||||||||||
||||||||||||||||||||
errdisable recovery cause dhcp-rate-limit

errdisable recovery interval 30
¡!
interface GigabitEthernet1/0/2
ip dhcp snooping limit rate 10
¡!
interfaz GigabitEthernet1/0/3
Technet24
||||||||||||||||||||
||||||||||||||||||||
Una repetición del comando show ip dhcp snooping

ahora muestra los límites de velocidad cerca del final de
la salida, como se observa en el Ejemplo 8-4.
Ejemplo 8-4 Confirmación de los límites de velocidad de DHCP Snooping
SW2# show ip dhcp snooping

Interfaz TrustedAllow Límite

d e tarifa
opción GigabitEthernet1/0/2 sí sí 10
Circuitos personalizados:
GigabitEthernet1/0/3 no no 2
Circuitos personalizados:
Resumen de la configuración de DHCP Snooping

resume los comandos incluidos en esta sección sobre
cómo configurar DHCP Snooping.
Paso 1. Configure este par de comandos (ambos

obligatorios):
A. Utilice el comando ip dhcp snooping
global para habilitar DHCP Snooping en el
||||||||||||||||||||
||||||||||||||||||||
interruptor.
B. Utilice el comando global ip dhcp
snooping vlan vlan-list para identificar
las VLAN en las que utilizar DHCP
Snooping.
Paso 2. (Opcional): Utilice el comando no ip dhcp
snooping information option global en los
conmutadores de Capa 2 para desactivar la
inserción de datos DHCP Opción 82 en los
mensajes DHCP, específicamente en los
conmutadores que no actúan como agente de
retransmisión DHCP.
Paso 3. Configure el subcomando ip dhcp
snooping trust interface para anular la
configuración predeterminada de no fiable.
Paso 4. (Opcional): Configure los límites de
velocidad de DHCP Snooping y la
recuperación de errores desactivados:
Paso A. (Opcional): Configure el
subcomando de interfaz ip dhcp
snooping limit rate number para
establecer un límite de mensajes
DHCP por segundo.
Paso B. (Opcional): Configure el
subcomando de interfaz no ip dhcp
snooping limit rate number para
eliminar un límite existente y
restablecer la interfaz para que utilice
el valor predeterminado de sin límite
de velocidad.
||||||||||||||||||||
Paso C. (Opcional): Configure el comando
||||||||||||||||||||
global errdisable recovery cause

dhcp- rate-limit para habilitar
Technet24
||||||||||||||||||||
||||||||||||||||||||
la función de recuperación automática

del modo deshabilitado por error,
suponiendo que el conmutador colocó
el puerto en estado deshabilitado por
error debido a que se superaron los
límites de velocidad de DHCP
Snooping.
Paso D. (Opcional): Configure los
comandos globales errdisable
recovery interval seconds para
establecer el tiempo que se debe
esperar antes de recuperarse de un
estado deshabilitado por error de la
interfaz (independientemente de la
causa del estado deshabilitado por
error).
INSPECCIÓN ARP DINÁMICA

La función de inspección dinámica de ARP (DAI) de un
conmutador examina los mensajes ARP entrantes en
puertos no confiables para filtrar aquellos que cree que
forman parte de un ataque. La función principal de DAI
compara los mensajes ARP entrantes con dos fuentes de
datos: la tabla de enlace DHCP Snooping y cualquier
ACL ARP configurada. Si el mensaje ARP entrante no
coincide con las tablas del switch, éste descarta el
mensaje ARP.
Esta sección sigue la misma secuencia que la sección de

DHCP Snooping, primero examinando los conceptos
detrás de DAI y ataques ARP, y luego mostrando como
configurar DAI con características requeridas y
opcionales.
||||||||||||||||||||
||||||||||||||||||||
Conceptos DAI
Para comprender los ataques que puede prevenir la DAI, es necesario
||||||||||||||||||||
||||||||||||||||||||
estar preparado para comparar operaciones ARP

normales con el uso anormal de ARP utilizado en
algunos tipos de ataques. Esta sección usa el mismo
flujo, primero revisando algunos detalles importantes de
ARP, y luego mostrando cómo un atacante puede
simplemente enviar una respuesta ARP -llamada ARP
gratuito- provocando que los hosts añadan entradas ARP
incorrectas a sus tablas ARP.
Revisión de ARP IP normal

Si todo lo que le interesa es cómo funciona ARP
normalmente, sin preocuparse por los ataques, puede
pensar en ARP a la profundidad mostrada en la Figura 8-
9. La figura muestra una secuencia típica. El host PC1
necesita enviar un paquete IP a su router por defecto
(R2), así que PC1 envía primero un mensaje de petición
ARP en un intento de aprender la dirección MAC
asociada con la dirección 172.16.2.2 de R2. El router R2
envía de vuelta una respuesta ARP, listando la dirección
MAC de R2 (nótese que la figura muestra pseudo
direcciones MAC para ahorrar espacio).
Figura 8-9 Tablas ARP legítimas después del DHCP de PC1

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
y ARP con el Router R2
Las tablas ARP de la parte inferior de la figura revelan

un hecho importante: ambos hosts aprenden la
dirección MAC del otro host con este flujo de dos
mensajes. No sólo PC1 aprende la dirección MAC de
R2 basándose en la respuesta ARP (mensaje 2), sino
que el router R2 aprende la dirección IP y MAC de PC1
gracias a la petición ARP (mensaje 1). Para ver por qué,
eche un vistazo a la vista más detallada de esos
mensajes como se muestra en la Figura 8-10.
Figura 8-10 Vista detallada de la solicitud y respuesta

ARP
||||||||||||||||||||
||||||||||||||||||||
Los mensajes ARP definen campos de dirección IP y de

hardware (MAC) de origen, así como campos de
dirección IP y de hardware de destino. El origen debe
listar la dirección IP y MAC del dispositivo emisor, sin
importar si el mensaje es una respuesta ARP o una
petición ARP. Por ejemplo, el mensaje 1 de la figura,
enviado por PC1, enumera las direcciones IP y MAC de
PC1 en los campos de origen, por lo que el router R2
podría conocer esa información. PC2 también conoce la
dirección MAC de R2 por los campos de dirección de
origen en la respuesta ARP.
ARP gratuito como vector de ataque

Normalmente, un host utiliza ARP cuando conoce la
dirección IP de otro host y quiere conocer la dirección
MAC de ese host. Sin embargo, por razones legítimas,
un host también puede querer informar a todos los hosts
de la subred sobre su dirección MAC. Esto puede ser útil
cuando un host cambia su dirección MAC, por ejemplo.
Por lo tanto, ARP soporta la idea de un mensaje ARP
gratuito con estas características:
Es una respuesta ARP.
Se envía sin haber recibido antes una petición ARP.
Se envía a una dirección de difusión de destino Ethernet para que

todos los hosts de la subred reciban el mensaje.
Por ejemplo, si la dirección MAC de un host es MAC

A, y cambia a MAC B, para provocar que todos los
demás hosts actualicen sus tablas ARP, el host podría
enviar un ARP gratuito que enumere una MAC de
origen de MAC B.
||||||||||||||||||||
||||||||||||||||||||
Los atacantes pueden aprovecharse de los ARPs gratuitos porque
Technet24
||||||||||||||||||||
||||||||||||||||||||
permiten al host emisor hacer que otros hosts cambien

sus tablas ARP. La Figura 8-11 muestra un ejemplo
iniciado por el PC A (un atacante) con un ARP gratuito.
Sin embargo, este ARP lista la dirección IP de PC1 pero
la dirección MAC de un dispositivo diferente (PC A) en
el paso 1, causando que el router actualice su tabla ARP
(paso 2).
Figura 8-11 Uso Nefasto de Respuesta ARP Causa

Datos ARP Incorrectos en R2
En este punto, cuando R2 reenvíe paquetes IP a la

dirección IP de PC1 (172.16.2.101), R2 los encapsulará
en una trama Ethernet con PC A como destino en lugar
de con la dirección MAC de PC1. Al principio, esto
podría parecer que detiene el funcionamiento de PC1,
pero en cambio podría ser parte de un ataque man- in-
the-middle para que PC A pueda copiar cada mensaje.
La Figura 8-12 muestra la idea de lo que ocurre en este
punto:
1. PC1 envía mensajes a algún servidor situado a la izquierda del router R2.
||||||||||||||||||||
||||||||||||||||||||
2. El servidor responde a la dirección IP de PC1, pero R2 reenvía ese

paquete a la dirección MAC de PC A, en lugar de a PC1.
3. El PC A copia el paquete para su posterior procesamiento.

4. PC A reenvía el paquete dentro de una nueva trama a PC1 para que
PC1 siga funcionando.
Figura 8-12 Ataque Man-in-the-Middle resultante

de un ARP gratuito
Lógica de inspección ARP dinámica

DAI tiene una variedad de características que pueden
prevenir este tipo de ataques ARP. Para entender cómo,
considere la secuencia de un host cliente típico con
respecto tanto a DHCP como a ARP. Cuando un host no
tiene una dirección IP todavía-es decir, antes de que el
proceso DHCP se complete
-no necesita utilizar ARP. Una vez que el host alquila
una dirección IP y aprende su máscara de subred,
necesita ARP para aprender las direcciones MAC de
otros hosts o el router por defecto en la subred, por lo
que envía algunos mensajes ARP. En resumen, DHCP
ocurre primero, luego ARP.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
DAI adopta un enfoque para interfaces no fiables que

confirma la corrección de un ARP basándose en los
datos de DHCP Snooping sobre los mensajes DHCP
anteriores. Los mensajes DHCP normales correctos
enumeran la dirección IP arrendada a un host, así como
la dirección MAC de ese host. La función DHCP
Snooping también registra esos datos en la tabla de
vinculación DHCP Snooping del switch.
Para cualquier puerto DAI no confiable, DAI compara

los campos de IP de origen y dirección MAC de origen
del mensaje ARP con la tabla de vinculación DHCP
Snooping. Si se encuentra en la tabla, DAI permite el
paso del ARP, pero si no, DAI descarta el ARP. Por
ejemplo, la Figura 8-13 muestra el paso 1 en el que el
atacante en el PC A intenta el ARP gratuito mostrado
anteriormente en la Figura 8-11. En el paso 2, DAI
realiza una llamada a la dirección MAC de origen. En el
paso 2, DAI hace una comparación con la tabla de
enlaces DHCP Snooping, no encontrando una
coincidencia con la MAC A junto con la dirección IP
172.16.2.101, por lo que DAI descartaría el mensaje.
||||||||||||||||||||
||||||||||||||||||||
Figura 8-13 Filtrado DAI ARP basado en la tabla de

enlace DHCP Snooping
DAI trabaja con la idea de puertos confiables y no

confiables con las mismas reglas generales que DHCP
Snooping. Los puertos de acceso conectados a
dispositivos de usuario final no suelen ser de confianza
ni para DHCP Snooping ni para DAI. Los puertos
conectados a otros switches, routers, el servidor DHCP-
cualquier cosa que no sean enlaces a dispositivos de
usuario final-deberían ser de confianza para DAI.
Tenga en cuenta que aunque DAI puede utilizar la tabla

DHCP Snooping como se muestra aquí, también puede
utilizar datos similares configurados estáticamente que
enumera pares correctos de direcciones IP y MAC a
través de una herramienta llamada ACLs ARP. Usar
ACLs ARP con DAI es útil para puertos conectados a
dispositivos que usan direcciones IP estáticas en lugar de
DHCP. Tenga en cuenta que DAI busca tanto los datos
de enlace DCHP Snooping como los datos de enlace
||||||||||||||||||||
||||||||||||||||||||
DCHP Snooping.
Technet24
||||||||||||||||||||
||||||||||||||||||||
ACL ARP.
Más allá de esa característica principal, tenga en cuenta

que DAI puede realizar opcionalmente otras
comprobaciones también. Por ejemplo, la cabecera
Ethernet que encapsula el ARP debe tener direcciones
que coincidan con el origen ARP y direcciones MAC de
destino.
La Figura 8-14 muestra un ejemplo de la comparación
de la dirección MAC de origen Ethernet y el campo de
hardware de origen del mensaje ARP.
Figura 8-14 Comprobaciones de filtrado DAI para

direcciones MAC de origen
Se puede habilitar DAI para que realice las

comparaciones que se muestran en la figura,
descartando estos mensajes:
Mensajes con una dirección MAC de origen de cabecera Ethernet
que no es igual a la dirección de hardware (MAC) de origen ARP.
Mensajes de respuesta ARP con una dirección MAC de destino en

la cabecera Ethernet que no es igual a la dirección de hardware
(MAC) de destino ARP.
Mensajes con direcciones IP inesperadas en los dos campos de

dirección IP ARP
Por último, al igual que DHCP Snooping, DAI realiza su

||||||||||||||||||||
||||||||||||||||||||
trabajo en la CPU del conmutador en lugar de en el

ASIC del conmutador, lo que significa que
||||||||||||||||||||
||||||||||||||||||||
La propia DAI puede ser más susceptible a ataques DoS.

El atacante podría generar un gran número de mensajes
ARP, aumentando el uso de la CPU en el switch. DAI
puede evitar estos problemas limitando el número de
mensajes ARP en un puerto a lo largo del tiempo.
Configuración de Inspección ARP

Dinámica
La configuración de DAI requiere sólo unos pocos
comandos, con la habitual mayor variedad de ajustes de
configuración opcionales.
Esta sección examina la configuración DAI, primero
con la mayoría de los ajustes por defecto y con
confianza en DHCP Snooping. A continuación se
muestran algunas de las características opcionales,
como los límites de velocidad, la recuperación
automática del estado de error deshabilitado, y cómo
habilitar comprobaciones adicionales de los mensajes
ARP entrantes.
Configuración de la inspección ARP en un conmutador de capa 2

Antes de configurar DAI, debe pensar en la función y
tomar algunas decisiones basadas en sus objetivos,
topología y funciones de los dispositivos. Las
decisiones incluyen lo siguiente:
Elija si desea confiar en DHCP Snooping, ARP ACLs, o ambos.
Si utiliza DHCP Snooping, configúrelo y haga que los puertos

correctos sean de confianza para DHCP Snooping.
Elija la(s) VLAN(s) en la(s) que desea habilitar DAI.
Haga que DAI sea de confianza (en lugar de la configuración

predeterminada de no confianza) en puertos seleccionados de esas
VLAN, normalmente para los mismos puertos en los que confió para
DHCP Snooping.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Todos los ejemplos de configuración de esta sección

utilizan la misma red de muestra utilizada en los temas
de configuración de DHCP Snooping, repetida aquí
como Figura 8-15. Al igual que con DHCP Snooping, el
switch SW2 de la derecha debe configurarse para
confiar en el puerto conectado al router (G1/0/2), pero
no confiar en los dos puertos conectados a los PCs .
Figura 8-15 Ejemplo de red utilizada en

los ejemplos de configuración de
inspección ARP
El Ejemplo 8-5 muestra la configuración requerida para

habilitar DAI en el switch SW2 en la Figura 8-15-una
configuración que sigue una progresión similar
comparada con DHCP Snooping. Todos los puertos en
la figura se conectan a la VLAN 11, por lo que para
habilitar DAI en la VLAN 11, sólo tiene que añadir el
comando global ip arp inspection vlan 11. Luego, para
cambiar la lógica en el puerto G1/0/2 (conectado al
router) para que sea confiable por DAI, agregue el
subcomando ip arp inspection trust interface.
Ejemplo 8-5 Configuración de inspección ARP IP

para que coincida con la Figura 8-15
||||||||||||||||||||
||||||||||||||||||||
ip arp inspection vlan 11

¡!
interface
GigabitEthernet1/0/2 ip arp
inspection trust
El Ejemplo 8-5 configura DAI, pero omite tanto DHCP

Snooping como las ACL ARP. (Si se configurara un
conmutador sólo con los comandos mostrados en el
Ejemplo 8-5, el conmutador filtraría todos los ARP que
entraran en todos los puertos no confiables de la VLAN
11). El Ejemplo 8-6 muestra una configuración DAI
completa y en funcionamiento que añade la configuración
DHCP Snooping para que coincida con la configuración
DAI del Ejemplo 8-5. Observe que el Ejemplo 8-6
combina la configuración anterior de DHCP Snooping
del Ejemplo 8-1 para esta misma topología con la
configuración DAI que se acaba de mostrar en el
Ejemplo 8-5, con resaltados para las líneas de
configuración específicas DAI.
Ejemplo 8-6 Configuración de IP DHCP Snooping

añadida para soportar DAI
ip arp inspection vlan 11

ip dhcp snooping
ip dhcp snooping vlan 11
no ip dhcp snooping information option
¡!
ip dhcp snooping trust
ip arp inspection trust
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Recuerde, DHCP ocurre primero con los clientes DHCP,

y luego ellos envían mensajes ARP. Con la
configuración del Ejemplo 8-6, el switch construye su
tabla de vinculación DHCP Snooping analizando los
mensajes DHCP entrantes.
A continuación, cualquier mensaje ARP entrante en
puertos DAI no confiables debe tener información
coincidente en esa tabla de vinculación.
El Ejemplo 8-7 confirma los hechos clave sobre la

operación correcta de DAI en esta red de ejemplo
basada en la configuración del Ejemplo 8-6. El
comando show ip arp inspection muestra ambos
ajustes de configuración junto con variables de estado y
contadores. Por ejemplo, las líneas resaltadas muestran
el total de mensajes ARP recibidos en puertos no
confiables en esa VLAN y el número de mensajes ARP
descartados (actualmente 0).
Ejemplo 8-7 SW2 Estado de Inspección ARP IP

imagen del código
SW2# show ip arp inspection
Validación Mac de origen :

Desactivado Validación Mac de destino
: Desactivado Validación de dirección
IP : Desactivado
Estátic
a
Vlan Configuración OperaciónACL Match
11 Activado Activo
Vlan Registro ACL Registro Desconexión de
11 Denegar DHCP Denegar la sonda
Vlan Reenviado Se ha caído DHCP DropsACL

Drops
||||||||||||||||||||
||||||||||||||||||||
11 59 0 0 0
Vlan DHCP Permisos ACL Permisos Permisos de Fuente MAC F

sondeo
11 7 0 49
Vlan Desti Fallos MAC Fallos en la Prot

no validación de IP inválido
Vlan Desti Fallos MAC Fallos en la Prot

no validación de IP inválido
11 0 0
SW2# show ip dhcp snooping binding
DirecciónMac IpAddressLease (sec) Tipo VLAN
02:00:11:11:11:11 172.16.2.101 86110 dhcp-snooping 11

02:00:22:22:22:22 172.16.2.102 86399 dhcp-snooping 11
Número total de fijaciones: 2
El final del Ejemplo 8-7 muestra un ejemplo del

comando show ip dhcp snooping binding en el switch
SW2. Observe que las dos primeras columnas listan una
dirección MAC e IP como aprendidas de los mensajes
DHCP. Luego, imagine que llega un mensaje ARP
desde PC1, un mensaje que debería listar la dirección
MAC 0200.1111.1111 de PC1 y 172.16.2.101 como la
dirección MAC e IP de origen, respectivamente. Según
esta salida, el switch encontraría esos datos
coincidentes y permitiría el mensaje ARP.
El Ejemplo 8-8 muestra algunos detalles de lo que

ocurre cuando el switch SW2 recibe un mensaje ARP
inválido en el puerto G1/0/4 de la Figura 8-15. En este
caso, para crear el mensaje ARP inválido, PC2 en la
figura fue configurado con una dirección IP estática de
172.16.2.101 (que es la dirección IP arrendada DHCP de
PC1). Los puntos destacados en el mensaje de registro
en la parte superior del ejemplo muestran la MAC de
origen reclamada de PC2
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
y las direcciones IP de origen en el mensaje ARP. Si

vuelve a la parte inferior del Ejemplo 8-7, puede ver que
este par MAC/IP de origen no existe en la tabla de
enlace DHCP Snooping, por lo que DAI rechaza el
mensaje ARP.
Ejemplo 8-8 Resultados de muestra de un ataque ARP

imagen del código
Jul 25 14:28:20.763: %SW_DAI-4-DHCP_SNOOPING_DENY: 1 ARP inválido
vlan
11.([0200.2222.2222/172.16.2.101/0000.0000.0000/172.16.2.1/0 25
2019])
SW2# show ip arp inspection statistics
Vlan Forwarded Dropped DHCP Drops ACL Drops

11 59 17 17 0
Permisos ACL Permisos Sonda

VlanDHCP PermisosFuen
11 7 te MAC F 0 49
VlanDest MAC FailuresIP Validation

FailuresInvalid Prot
11 0 0
Las estadísticas del comando show ip arp inspection

también confirman que el switch ha descartado algunos
mensajes ARP. Las líneas resaltadas en el centro de la
tabla muestran un total de 17 mensajes ARP descartados
en la VLAN 11. Esa misma línea resaltada confirma que
los 17 mensajes se perdieron debido a la tabla de enlace
DHCP Snooping ("DHCP Drops"), con cero mensajes
perdidos debido a una ACL ARP ("ACL Drops").
Limitación de la frecuencia de los mensajes DAI
||||||||||||||||||||
||||||||||||||||||||
Al igual que DHCP Snooping, DAI también puede ser el

foco de un ataque DoS con el atacante generando un
gran número de mensajes ARP. Al igual que DHCP
Snooping, DAI soporta la configuración de límites de
velocidad para ayudar a prevenir esos ataques, con una
reacción para colocar el puerto en un estado de error
deshabilitado, y con la capacidad de configurar la
recuperación automática de ese estado de error
deshabilitado.
Los límites de velocidad de DHCP Snooping y DAI

tienen algunas pequeñas diferencias en su
funcionamiento, valores por defecto y configuración,
como se indica a continuación:
DAI utiliza por defecto límites de velocidad para todas las
interfaces (confiables y no confiables), y DHCP Snooping no
utiliza límites de velocidad por defecto.
DAI permite la configuración de un intervalo de ráfaga (un

número de segundos), de modo que el límite de velocidad puede
tener una lógica del tipo "x mensajes ARP en y segundos" (DHCP
Snooping no define una configuración de ráfaga).
Es útil ver la configuración del límite de velocidad de

DAI y DHCP Snooping juntas para hacer
comparaciones, así que el Ejemplo 8-9 muestra ambas.
El ejemplo repite exactamente los mismos comandos
DHCP Snooping del anterior Ejemplo 8-3 pero añade la
configuración DAI (resaltada). La configuración en el
Ejemplo 8-7 puede ser añadida a la configuración
mostrada en el Ejemplo 8-6 para una configuración
completa de DHCP Snooping y DAI.
Ejemplo 8-9 Configuración de límites de velocidad

de mensajes de inspección ARP
||||||||||||||||||||
||||||||||||||||||||
errdisable recovery cause dhcp-rate-limit

errdisable recovery cause arp-inspection
Technet24
||||||||||||||||||||
||||||||||||||||||||
intervalo de recuperación errdisable 30

¡!
ip arp inspection limit rate 8
¡!
interface
GigabitEthernet1/0/3 ip dhcp
snooping limit rate 2
ip arp inspection limit rate 8 burst interval 4
El Ejemplo 8-10 muestra la salida que confirma los

ajustes de configuración. Por ejemplo, el Ejemplo 8-9
configura el puerto G1/0/2 con una tasa de 8 mensajes
para cada ráfaga (por defecto) de 1 segundo; la salida
en el Ejemplo 8-10 para la interfaz G1/0/2 también
lista una tasa de 8 y un intervalo de ráfaga de 1. De
manera similar, el Ejemplo 8-9 configura el puerto
G1/0/3 con una tasa de 8 sobre una ráfaga de 4
segundos, con el Ejemplo 8-10 confirmando esos
mismos valores para el puerto
G1/0/3. Observe que las otras dos interfaces del ejemplo
8-10 muestran la configuración predeterminada de una
velocidad de 15 mensajes en una ráfaga de un segundo.
Ejemplo 8-10 Confirmación de límites de tasa de inspección ARP
Haga clic aquí para de imagen

ver co
interfaces de inspección
SW2# show ip arp Estado de confianza Velocidad
Interfaz (pps)Intervalo de ráfagas
Gi1/0/1 Sin 15 1
confianza
Gi1/0/2 De 8 1
confianza
Gi1/0/3 Sin 8 4
confianza
Gi1/0/4 Sin 15 1
¡! Líneas confianza
omitidas por
brevedad
||||||||||||||||||||
||||||||||||||||||||
Configuración de comprobaciones opcionales de mensajes DAI
||||||||||||||||||||
||||||||||||||||||||
Como se mencionó en la sección titulada "Lógica de

Inspección ARP Dinámica", DAI siempre comprueba los
campos de dirección MAC y IP de origen del mensaje
ARP contra alguna tabla en el switch, pero también
puede realizar otras comprobaciones. Estas
comprobaciones requieren más CPU, pero también
ayudan a prevenir otros tipos de ataques.
El Ejemplo 8-11 muestra cómo configurar esas tres

comprobaciones adicionales. Tenga en cuenta que
puede configurar una, dos o las tres opciones:
simplemente configure el comando ip arp inspection
validate nuevamente con todas las opciones que desee
en un comando, y este reemplaza el comando de
configuración global anterior. El ejemplo muestra las
tres opciones, con la opción src-mac (mac de origen)
configurada.
Ejemplo 8-11 Confirmación de los límites de tasa de inspección ARP

imagen del código
SW2# configurar terminal
Termine con CNTL/Z.
SW2(config)# ip arp inspection validate ?

dst-mac Validar dirección MAC de destino
ipValidar direcciones IP
src-mac Validar dirección MAC de origen
SW2(config)# ip arp inspection validate src-mac

SW2(config)# ^Z
SW2#
SW2# show ip arp inspection
Validación Mac en :
Validación Mac de destino : Activado
origen
Desactivado
Validación de dirección IP :
Desactivado
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Resumen de Configuración de Inspección ARP IP

resume los comandos incluidos en esta sección sobre
cómo configurar la Inspección dinámica IP ARP:
Paso 1. Utilice el comando global ip arp

inspection vlan vlan-list. Utilice el comando
global ip arp inspection vlan vlan-list para
habilitar la inspección dinámica de ARP
(DAI) en el conmutador para las VLAN
especificadas.
Paso 2. Aparte de la configuración DAI, configure
también DHCP Snooping y/o ARP ACLs para su
uso por DAI.
Paso 3. Configure el subcomando Configure el
subcomando ip arp inspection trust
interface para anular la configuración
predeterminada de no fiable.
Paso 4. (Opcional): Configure los límites de
velocidad DAI y la recuperación de
errores deshabilitados:
Paso A. (Opcional): Configure el
subcomando de interfaz ip arp
inspection limit rate number [burst
interval seconds] para establecer un
límite de mensajes ARP por segundo,
o mensajes ARP por cada intervalo
configurado.
||||||||||||||||||||
||||||||||||||||||||
Paso B. (Opcional): Configure la interfaz

ip arp inspection limit rate none.
||||||||||||||||||||
||||||||||||||||||||
para desactivar los límites de velocidad.

Paso C. (Opcional): Configure el comando
global errdisable recovery cause
arp- inspection para habilitar la
función de recuperación automática
desde el modo deshabilitado por error,
suponiendo que el conmutador colocó
el puerto en estado deshabilitado por
error debido a que se excedieron los
límites de velocidad de DAI.
Paso D. (Opcional): Configure los
comandos globales errdisable
recovery interval seconds para
establecer el tiempo que se debe
esperar antes de recuperarse de un
estado deshabilitado por error de la
interfaz (independientemente de la
causa del estado deshabilitado por
error).
Paso 5. (Opcional): Configure el comando global
ip arp inspection validate {[dst-mac]
[src-mac] [ip]} para agregar pasos de
validación de DAI.
||||||||||||||||||||
||||||||||||||||||||

detalles. En la Tabla 8-2 se describen los
Technet24
||||||||||||||||||||
||||||||||||||||||||
elementos de repaso y dónde puede encontrarlos. Para

hacer un mejor seguimiento de su progreso en el
estudio, anote cuándo completó estas actividades en la
segunda columna.

utilizado

DIKTA
Revisar las listas de control de Libro, página web

configuración


Tema Número
Elemento
Figura 8- Acciones de filtrado DHCP en puertos 149

4 fiables y no fiables
Lista Lógica de DHCP Snooping 149
Figura 8- Concepto de tabla de vinculación de DHCP 151

6 Snooping
Ejemplo Configuración de DHCP Snooping 152
||||||||||||||||||||
||||||||||||||||||||
8-1
Lista Lista de comprobación de la configuración 155

de DHCP Snooping
Figura 8- Detalle dentro de los mensajes ARP con 157

10 origen y destino
Lista Detalles ARP gratuitos 157
Figura 8- Lógica central de inspección dinámica de 159

13 ARP
Ejemplo Configuración de Inspección ARP 161

8-6 Dinámica con configuración asociada de
DHCP Snooping
Lista Lista de comprobación de inspección ARP 165

dinámica

Snooping DHCP
puerto de confianza
puerto no fiable
Tabla de vinculación de DHCP Snooping
Inspección ARP dinámica
(ARP) dirección IP de origen
(ARP) dirección de hardware de origen
Technet24
||||||||||||||||||||
||||||||||||||||||||
Respuesta ARP
ARP gratuito
hace el comando.

configuración
ip dhcp Comando global que habilita DHCP Snooping si

snooping se combina con su habilitación en una o más
VLANs.
ip dhcp Comando global que enumera las VLAN en

snooping las que habilitar DHCP Snooping, suponiendo
vlan vlan-list que el comando ip dhcp snooping también
esté configurado.
opción [no] Comando que habilita (o deshabilita sin opción)

ip dhcp la función de inserción de parámetros DHCP
snooping opción 82 por parte del switch cuando también se
information utiliza DHCP Snooping.
[no] ip dhcp Subcomando de interfaz que establece el estado

snooping de confianza de DHCP Snooping para una
trust interfaz (por defecto no, o no fiable).
ip dhcp Subcomando de interfaz que establece un límite a

la
||||||||||||||||||||
||||||||||||||||||||
snooping Número de mensajes DHCP entrantes procesados en

limit rate una interfaz, por segundo, antes de que DHCP
number Snooping descarte todos los demás mensajes
DHCP entrantes en ese mismo segundo.
err-disable Comando global que permite al conmutador

recovery recuperar automáticamente una interfaz
cause dhcp- deshabilitada por error si se establece en ese
rate-limit estado debido a la superación de un ajuste de
límite de velocidad DHCP.
err-disable Comando global que establece el número de

intervalo segundos que IOS espera antes de recuperar las
de interfaces deshabilitadas por error que, según
recuperaci varios ajustes de configuración, deberían
ón recuperarse automáticamente.
segundos
err- Comando global que permite al switch recuperar

desactivar automáticamente una interfaz deshabilitada por
recuperaci error si se establece en ese estado debido a una
ón causa violación de inspección ARP.
arp-
inspección
Comando Propósito
show ip Enumera una gran variedad de ajustes de

dhcp configuración de DHCP Snooping
snooping
mostrar Enumera los contadores relativos al

estadísticas comportamiento de DHCP Snooping en el switch
ip dhcp
snooping
show ip Muestra el contenido de la tabla de vinculación

dhcp DHCP Snooping creada dinámicamente.
snooping
binding
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
show ip arp Enumera tanto los parámetros de configuración de

inspection la Inspección dinámica de ARP (DAI) como los
contadores de mensajes ARP procesados y filtrados.
show ip arp Lista el subconjunto de la inspección show ip arp

inspection salida de comando que incluye contadores
statistics
||||||||||||||||||||
||||||||||||||||||||
Parte II. Consulte

Lleve un registro del progreso de su revisión de piezas
con la lista de comprobación que se muestra en la Tabla
P2-1. Los detalles de cada tarea siguen a la tabla.
Cuadro P2-1 Lista de comprobación de la revisión de la Parte II
Actividad 1ª Fecha 2ª Fecha

Realizada Finalizada
Repita todas las

preguntas DIKTA
Responder a las
preguntas de repaso
Repasar los temas clave
Laboratorios Do
Videos de revisión
REPETIR TODAS LAS PREGUNTAS DIKTA

Para esta tarea, utilice el software PTP para
responder de nuevo a las preguntas "¿Sé esto ya?" de
los capítulos de esta parte del libro.
RESPONDER A LAS PREGUNTAS DE REPASO
Technet24
||||||||||||||||||||
||||||||||||||||||||
Para esta tarea, utilice el PTP para responder a las

preguntas de repaso de esta parte del libro.
REPASAR LOS TEMAS CLAVE

Repase todos los temas clave de todos los capítulos de
esta parte, ya sea hojeando los capítulos o utilizando la
aplicación Temas clave del sitio web complementario.
UTILIZAR ELEMENTOS DE REPASO

INTERACTIVOS POR CAPÍTULO
A través del sitio web complementario, navegue por los
elementos de repaso interactivos, como las tablas de
memoria y las fichas de términos clave, para repasar el
contenido de cada capítulo.
LABS
Dependiendo de la herramienta de laboratorio que
elijas, aquí tienes algunas sugerencias sobre qué hacer
en el laboratorio:
Simulador de red Pearson: Si utiliza el simulador

Pearson CCNA completo, céntrese más en los
laboratorios de escenarios de configuración y
escenarios de solución de problemas asociados a los
temas de esta parte del libro. Estos tipos de
laboratorios incluyen un conjunto más amplio de
temas y funcionan bien como actividades de repaso de
la parte. (Consulte la Introducción para obtener más
detalles sobre cómo encontrar los laboratorios
relacionados con los temas de esta parte del libro).
Blog Config Labs: El blog del autor

(https://blog.certskills.com) incluye una serie de
laboratorios centrados en la configuración que
puedes hacer en papel,
||||||||||||||||||||
||||||||||||||||||||
cada uno en 10-15 minutos. Revise y realice los

laboratorios de esta parte del libro utilizando los
menús para navegar hasta el contenido de cada
capítulo y, a continuación, busque todos los
laboratorios de configuración relacionados con ese
capítulo. (Puedes ver instrucciones más detalladas
en https://blog.certskills.com/config-labs.)
Otros: Si utiliza otras herramientas de laboratorio,

aquí tiene algunas sugerencias: asegúrese de
experimentar con la variedad de temas de
configuración de esta parte, incluidas las contraseñas
de routers y switches, la seguridad de puertos de
switches, la inspección ARP dinámica y DHCP
Snooping.
VER VÍDEOS
Dos capítulos de esta parte mencionan vídeos incluidos
como material extra relacionado con esos capítulos. Echa
un vistazo a la referencia en el Capítulo 4 a un vídeo
sobre el uso del protocolo RADIUS, así como la
referencia del Capítulo 6 a un vídeo sobre la solución de
problemas de seguridad de puertos de conmutación.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Parte III: Servicios IP
Capítulo 9: Protocolos de gestión de dispositivos
Capítulo 10: Traducción de direcciones de red
Capítulo 11: Calidad de servicio (QoS)
Capítulo 12: Servicios IP varios
Revisión de la Parte III
La Parte III se centra en una serie de temas que pueden

encontrarse en casi todas las redes. Ninguno es necesario
para que una red funcione, pero muchos son servicios
útiles. La mayoría utilizan IP o soportan la red IP de
alguna manera, por lo que la Parte III agrupa los temas
como Servicios IP.
La Parte III comienza y termina con capítulos que

examinan una serie de temas más pequeños. En primer
lugar, el capítulo 9 examina varios servicios IP para los
que el examen CCNA requiere que desarrolle
habilidades de configuración y verificación. Estos
servicios incluyen logging y syslog, el Network Time
Protocol (NTP), así como dos servicios relacionados:
CDP y LLDP.
El capítulo 12, al final de la Parte III, se cierra con otra
||||||||||||||||||||
||||||||||||||||||||
serie de temas más pequeños-aunque los temas del

examen CCNA 200-301 sólo requieren conocimientos
conceptuales, no habilidades de configuración para estos
temas. Este capítulo incluye los protocolos de
redundancia de primer salto (FHRP), el protocolo simple
de administración de red (SNMP) y dos protocolos
relacionados: TFTP y FTP.
Los dos capítulos centrales de la Parte III también se

centran en los servicios basados en IP, comenzando con
el examen del Capítulo 10 sobre la Traducción de
Direcciones de Red (NAT). Casi todas las redes utilizan
NAT con IPv4, aunque en muchos casos, el cortafuegos
implementa NAT. Este capítulo muestra cómo
configurar y verificar NAT en un router Cisco.
A primera vista, el capítulo 11 puede parecer un capítulo

extenso sobre un solo tema, la calidad del servicio, y de
hecho se centra en la calidad del servicio; sin embargo,
la calidad del servicio incluye, por naturaleza, una
amplia variedad de herramientas individuales de
calidad del servicio. Este capítulo lo guía a través de los
conceptos básicos de las principales características de
QoS.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 9. Protocolos de
gestión de dispositivos
Protocolos de gestión de
dispositivos
2.0 Acceso a la red

2.3 Configurar y verificar protocolos de
descubrimiento de Capa 2 (Cisco Discovery
Protocol y LLDP)
4.0 Servicios IP
4.2 Configurar y verificar el funcionamiento de
NTP en modo cliente y servidor
4.5 Describir el uso de las características de syslog,
incluyendo facilidades y niveles
Este capítulo comienza la Parte III con una discusión de

los conceptos, configuración y verificación de tres
funciones que se encuentran en los routers y switches
Cisco. Estas funciones se centran más en la gestión de
los propios dispositivos de red que en la gestión de la
red que crean los dispositivos.
La primera sección importante de este capítulo se

centra en los mensajes de registro y syslog. La mayoría
de los dispositivos informáticos tienen la necesidad de
||||||||||||||||||||
||||||||||||||||||||
notificar al administrador de cualquier problema

significativo; en general, en todo el mundo de la
informática, los mensajes de
||||||||||||||||||||
||||||||||||||||||||
de este tipo se denominan mensajes de registro. Los

dispositivos Cisco también generan mensajes de registro.
En la primera sección se muestra cómo un dispositivo
Cisco gestiona esos mensajes y cómo se pueden
configurar los routers y switches para que los ignoren o
los guarden de distintas formas.
A continuación, las distintas funciones de los routers y

switches se benefician de la sincronización de sus relojes
horarios. Como la mayoría de los dispositivos
informáticos, los routers y switches tienen una función
de reloj interno para mantener la hora. El Protocolo de
Tiempo de Red (NTP) proporciona un medio para que
los dispositivos sincronicen su tiempo, como se discute
en la segunda sección.
La última sección principal se centra en dos protocolos

que realizan el mismo tipo de trabajo: Cisco Discovery
Protocol (CDP) y Link Layer Discovery Protocol (LLDP).
Ambos proporcionan un medio para que los dispositivos
de red aprendan sobre los dispositivos vecinos, sin
requerir que IPv4 o IPv6 estén funcionando en ese
momento.

||||||||||||||||||||
||||||||||||||||||||
Tabla 9-1 "¿Ya lo sé?" Fundación
Technet24
||||||||||||||||||||
||||||||||||||||||||
Temas Asignación de secciones a preguntas
Registro de mensajes del sistema (Syslog) 1-2
Protocolo de tiempo de red (NTP) 3-4
Análisis de la topología mediante CDP y LLDP 5-6
1. ¿Qué nivel de registro en la consola es el

predeterminado para un dispositivo Cisco?
1. Información
2. Errores
3. Advertencias
4. Depuración
2. ¿Qué comando limita los mensajes enviados a un

servidor syslog a los niveles 4 a 0?
1. trampa de registro 0-4
2. trampa de registro 0,1,2,3,4
3. trampa de registro 4
4. trampa de registro a 4
3. ¿Cuál de las siguientes afirmaciones es correcta

sobre la función de cliente NTP en un router
Cisco?
1. El cliente sincroniza su reloj con la hora del día basándose en el
servidor NTP.
2. Cuenta los ciclos de la CPU del router local para mantener la
hora con mayor precisión.
3. El cliente sincroniza su velocidad de reloj de línea serie basándose
en el servidor NTP.
4. El cliente debe estar conectado a la misma subred que un servidor NTP.
4. La única configuración NTP en el router R1 es la ntp
||||||||||||||||||||
||||||||||||||||||||
servidor 10.1.1.1. ¿Qué respuestas describen cómo

funciona NTP en el router?
1. Sólo como servidor NTP
2. Sólo como cliente NTP
3. Como servidor NTP sólo después de que el cliente NTP se
sincronice con el servidor NTP 10.1.1.1
4. Como servidor NTP independientemente de si el
cliente NTP se sincroniza con el servidor NTP 10.1.1.1
5. Imagina que un switch se conecta a través de un

cable Ethernet a un router, y el nombre de host del
router es Hannah. ¿Cuál de los siguientes comandos
podría darle información sobre la versión IOS en
Hannah sin establecer una conexión Telnet a
Hannah? (Elija dos respuestas.)
1. mostrar vecinos Hannah
2. mostrar cdp
3. show cdp neighbors
4. show cdp neighbors Hannah
5. mostrar entrada cdp Hannah
6. show cdp neighbors detail
6. Un switch está cableado a un router cuyo nombre de

host es Hannah. ¿Cuál de los siguientes comandos
LLDP podría identificar el modelo de hardware de
Hannah? (Elija dos respuestas).
1. mostrar vecinos
2. mostrar vecinos Hannah
3. mostrar lldp
4. mostrar interfaz lldp
5. mostrar vecinos lldp
6. mostrar entrada lldp Hannah
Technet24
||||||||||||||||||||
||||||||||||||||||||
1D
2C
3A
4 C
5 E, F
6 E, F
Temas básicos
REGISTRO DE MENSAJES DEL SISTEMA (SYSLOG)
Es sorprendente lo útiles que los dispositivos Cisco
intentan ser para sus administradores. Cuando ocurren
eventos importantes (e incluso no tan importantes),
estos dispositivos Cisco intentan notificar a los
administradores con mensajes detallados del sistema.
Como aprenderás en esta sección, estos mensajes
varían desde los muy mundanos a los que son
increíblemente importantes.
Afortunadamente, los administradores disponen de una
gran variedad de opciones para almacenar estos
mensajes y ser alertados de aquellos que podrían tener
un mayor impacto en la infraestructura de la red.
Cuando ocurre un evento que el SO del dispositivo

considera interesante, ¿cómo nos lo notifica a los
humanos? Cisco IOS puede enviar los mensajes a
cualquier persona que haya iniciado sesión en el
dispositivo. También puede almacenar el mensaje para
que un usuario pueda verlo más tarde. Las siguientes
páginas
||||||||||||||||||||
||||||||||||||||||||
examinar ambos temas.
Nota
Los temas del examen CCNA 200-301 enumeran un

tema de examen sobre registro y syslog: "Describir el
uso de las funciones de syslog, incluidas las
instalaciones y los niveles". Este tema de examen no
requiere que comprenda la configuración
relacionada. Sin embargo, la configuración revela
muchos de los conceptos básicos, por lo que esta
sección incluye los detalles de configuración como
medio para ayudarle a comprender cómo funcionan
el registro y syslog.
Envío de mensajes en tiempo real a

los usuarios actuales
El IOS de Cisco que se ejecuta en un dispositivo al
menos intenta permitir que los usuarios actuales vean los
mensajes de registro cuando se producen. Puede que no
todos los routers o switches tengan usuarios conectados,
pero si algún usuario está conectado, el router o switch
se beneficia al hacer que el ingeniero de red esté al tanto
de cualquier problema.
Por defecto, IOS muestra mensajes de log a los usuarios

de consola para todos los niveles de severidad de los
mensajes. Eso ocurre por defecto debido al comando de
configuración global logging console. De hecho, si usted
ha estado utilizando un puerto de consola a lo largo de su
tiempo de lectura de este libro, es probable que ya haya
notado muchos mensajes syslog, como los mensajes
||||||||||||||||||||
||||||||||||||||||||
acerca de las interfaces que suben o bajan.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Para otros usuarios (es decir, usuarios de Telnet y SSH),

el dispositivo requiere un proceso de dos pasos antes de
que el usuario vea los mensajes. En primer lugar, IOS
tiene otro ajuste de configuración global -logging
monitor- que le dice a IOS que habilite el envío de
mensajes de registro a todos los usuarios registrados. Sin
embargo, esta configuración por defecto no es suficiente
para que el usuario vea los mensajes de registro. El
usuario también debe emitir el comando terminal
monitor EXEC durante la sesión de inicio de sesión,
que indica a IOS que esta sesión de terminal desea
recibir mensajes de registro.
La Figura 9-1 resume estos puntos clave sobre cómo el

IOS de un router o switch Cisco procesa los mensajes de
registro para los usuarios actualmente conectados. En la
figura, el usuario A se sienta en la consola y siempre
recibe mensajes de registro. A la derecha, el hecho de
que el usuario B vea los mensajes (porque el usuario B
emitió el comando monitor de terminal después de
iniciar sesión), y el usuario C no, muestra que cada
usuario puede controlar si recibe o no mensajes de
registro.
||||||||||||||||||||
||||||||||||||||||||
Figura 9-1 Procesamiento de IOS para Mensajes de

Registro a Usuarios Actuales
Almacenamiento de mensajes de
registro para su posterior revisión
Con el registro en la consola y en los terminales, ocurre
un evento, IOS envía los mensajes a las sesiones de
consola y terminal, y luego IOS puede descartar el
mensaje. Sin embargo, es evidente que sería útil
mantener una copia de los mensajes de registro para su
posterior revisión, por lo que IOS proporciona dos
medios principales para mantener una copia.
IOS puede almacenar copias de los mensajes de registro

en RAM en virtud del comando de configuración global
logging buffered. Entonces cualquier usuario puede
volver más tarde y ver los antiguos mensajes de registro
utilizando el comando show logging EXEC.
Como segunda opción -una opción utilizada

frecuentemente en redes de producción- todos los
dispositivos almacenan sus mensajes de registro de
forma centralizada en un servidor syslog. RFC 5424
define el protocolo syslog, que proporciona los medios
por los que un dispositivo como un conmutador o un
enrutador puede utilizar un protocolo UDP para enviar
mensajes a un servidor syslog para su almacenamiento.
Todos los dispositivos pueden enviar sus mensajes de
registro al servidor. Más tarde, un usuario puede
conectarse al servidor (normalmente con una interfaz
gráfica de usuario) y examinar los mensajes de registro
de varios dispositivos. Para configurar un router o switch
para que envíe mensajes de registro a un servidor syslog,
||||||||||||||||||||
||||||||||||||||||||
añada el host de registro

{address | hostname }, haciendo referencia al comando global
Technet24
||||||||||||||||||||
||||||||||||||||||||
Dirección IP o nombre de host del servidor syslog.
La Figura 9-2 muestra las ideas que hay detrás del

registro en buffer y del registro syslog.
Figura 9-2 IOS Almacenamiento de mensajes de

registro para su visualización posterior: Buffered y
Syslog Server
Formato del mensaje de registro

IOS define el formato de los mensajes de registro. El
mensaje comienza con algunos campos de datos sobre el
mensaje, seguidos de un texto más fácil de leer por los
humanos. Por ejemplo, echa un vistazo a este mensaje de
muestra:
*Dec 18 17:10:15.079: %LINEPROTO-5-UPDOWN: Protocolo de línea en

Interfa
Observe que por defecto en este dispositivo en particular, vemos
||||||||||||||||||||
||||||||||||||||||||
lo siguiente:
Una marca de tiempo: *Dic 18 17:10:15.079

La instalación en el router que generó el
mensaje: %LINEPROTO
Nivel de gravedad: 5
Un mnemónico para el mensaje: UPDOWN
La descripción del mensaje: Protocolo de línea
en la interfaz FastEthernet0/0, cambio de estado a
caído.
IOS dicta la mayor parte del contenido de los mensajes,
pero al menos puedes activar y desactivar el uso de la
marca de tiempo (que se incluye por defecto) y un
número de secuencia de mensaje de registro (que no
está activado por defecto). El Ejemplo 9-1 invierte esos
valores por defecto desactivando las marcas de tiempo
y activando los números de secuencia.
Ejemplo 9-1 Desactivación de las marcas de tiempo

y activación de los números de secuencia en los
mensajes de registro
R1(config)# no service timestamps

R1(config)# service sequence-numbers
R1(config)# end
R1#
000011: %SYS-5-CONFIG_I: Configurado desde consola por consola
Para ver el cambio de formato, observe el mensaje de

registro al final del ejemplo. Como es habitual, al salir
del modo de configuración, el dispositivo emite otro
mensaje de registro. Comparando este mensaje con el
||||||||||||||||||||
||||||||||||||||||||
anterior
Technet24
||||||||||||||||||||
||||||||||||||||||||
puede ver que ahora ya no indica la hora del día, pero sí

un número de secuencia.
Niveles de gravedad de los mensajes de registro

Los mensajes de registro pueden simplemente
informarte de algún evento mundano, o pueden
informarte de algún evento crítico. Para ayudarte a
entender la importancia de cada mensaje, IOS asigna a
cada mensaje un nivel de gravedad (como se indica en
los mismos mensajes en la página anterior más o
menos). La Figura 9-3 muestra los niveles de severidad:
cuanto más bajo es el número, más severo es el evento
que causó el mensaje. (Observe que los valores de la
izquierda y del centro se utilizan en los comandos IOS).
Figura 9-3 Niveles de Gravedad de Mensajes

Syslog por Palabra Clave y Numeral
La Figura 9-3 divide los ocho niveles de gravedad en

cuatro secciones para que el significado tenga un poco
más de sentido.
||||||||||||||||||||
||||||||||||||||||||
Los dos niveles superiores de la figura son los más

graves. Los mensajes de este nivel significan que existe
un problema grave e inmediato. Los tres niveles
siguientes, denominados Crítico, Error y Advertencia,
también informan sobre eventos que afectan al
dispositivo, pero no son tan inmediatos ni graves. Por
ejemplo, un mensaje de registro común sobre una
interfaz que falla a un estado físicamente caído se
muestra como un mensaje de nivel de gravedad 3.
Continuando hacia abajo en la figura, IOS utiliza los

siguientes dos niveles (5 y 6) para mensajes que son
más para notificar al usuario que para identificar
errores. Finalmente, el último nivel de la figura se
utiliza para mensajes solicitados por el comando debug,
como se muestra en un ejemplo más adelante en este
capítulo.
La Tabla 9-2 resume los comandos de configuración

utilizados para habilitar el registro y establecer el nivel
de gravedad para cada tipo. Cuando se establece el nivel
de gravedad, IOS enviará mensajes de ese nivel de
gravedad y otros más graves (números de gravedad más
bajos) al servicio identificado en el comando. Por
ejemplo, el comando logging console 4 hace que IOS
envíe mensajes de nivel de gravedad 0-4 a la consola.
Además, tenga en cuenta que el comando para
desactivar cada servicio es la versión no del comando,
con no delante del comando (no logging console, no
logging monitor, etc.).
Tabla 9-2 Cómo configurar los niveles de mensajes de

registro para cada servicio de registro
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
ServicioPara activar el registroPara establecer niveles

de mensajes
Consola consola de registro nombre-nivel de la consola de

registro
| Número de nivel
Monitor monitor de registro logging monitor level-name

| Número de nivel
Buffered registro en búfer logging buffered level-

name | level-number
Syslog host de registro logging trap level-name |

dirección | nombre de número de nivel
host
Configuración y verificación del

registro del sistema
Con la información de la Tabla 9-2, configurar syslog en
un router o switch Cisco IOS debería ser relativamente
sencillo. El Ejemplo 9-2 muestra un ejemplo, basado en
la Figura 9-4. La figura muestra un servidor syslog en la
dirección IP 172.16.3.9. Ambos switches y ambos
routers utilizarán la misma configuración mostrada en el
Ejemplo 9-2, aunque el ejemplo muestra el proceso de
configuración en un único dispositivo, el router R1.
||||||||||||||||||||
||||||||||||||||||||
Figura 9-4 Red de muestra utilizada en los ejemplos

de registro
Ejemplo 9-2 Configuración de Syslog en R1
logging console 7
logging monitor debug
logging buffered 4
logging host 172.16.3.9
logging trap warning
En primer lugar, observe que el ejemplo configura el

mismo nivel de mensaje en la consola y para la
monitorización del terminal (nivel 7, o debug), y el
mismo nivel tanto para el buffer como para el registro en
el servidor syslog (nivel 4, o warning). Los niveles
pueden configurarse utilizando el nivel de gravedad
numérico o el nombre, como se ha mostrado
anteriormente en la Figura 9-3.
El comando show logging confirma esos mismos ajustes

de configuración y también lista los mensajes de registro
según la configuración del búfer de registro. El Ejemplo
9-3 muestra un ejemplo, con los ajustes de configuración
para que coincida con
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 9-2 resaltado en gris.
Ejemplo 9-3 Visualización de los parámetros de

registro configurados según el ejemplo anterior
R1# show logging
Registro Syslog: activado (0 mensajes descartados, 3 mensajes
limitados) No Discriminador de mensajes activo.
No Discriminador de mensajes inactivos.
Registro en consola: nivel de depuración, 45 mensajes

registrados, filtrado xml dis desactivado
Monitor de registro: nivel de depuración, 0 mensajes
registrados, filtrado xml disa desactivado
Registro en búfer: nivel de advertencias, 0 mensajes
registrados, filtrado xml desactivado
Registro de excepciones: tamaño (8192 bytes)
Mensajes de registro de recuento y marca de
tiempo: desactivado Registro persistente:
desactivado
No hay módulos de filtro activos.
Trap logging: nivel warnings, 0 líneas de mensaje

registradas Logging to 172.16.3.9 (udp port 514,
audit disabled,
enlace),
0 líneas de mensaje registradas,
0 líneas de mensajes de velocidad limitada,
0 líneas de mensaje perdidas por MD,
xml desactivado, número de secuencia
desactivado filtrado desactivado
Origen-Interfaz de registro: VRF
Nombre: Memoria intermedia de registro (8192
bytes):
||||||||||||||||||||
||||||||||||||||||||
Ya te habrás dado cuenta de que conocer los nombres

de los ocho niveles de mensajes de registro puede ser
útil si quieres entender la salida de los comandos. La
mayoría de los comandos show listan los niveles de
mensajes de registro por nombre, no por número. Como
puede ver en los resaltes grises de este ejemplo, dos
niveles muestran "debug" y dos muestran "warning",
aunque algunos de los comandos de configuración se
refieren a esos niveles por su número.
Además, no se puede saber esto por la salida, pero en el

Ejemplo 9-3, el router R1 no tiene mensajes de registro
almacenados en buffer. (Observe el valor 0 del contador
para los mensajes de registro almacenados en el búfer.)
Si se hubiera almacenado algún mensaje de registro en
el búfer, los mensajes de registro reales se listarían al
final del comando. En este caso, acababa de arrancar el
router, y ningún mensaje había sido almacenado
todavía. (También podría borrar los mensajes antiguos
del registro con el comando clear logging EXEC).
El siguiente ejemplo muestra la diferencia entre los

niveles de severidad actuales. Este ejemplo muestra al
usuario deshabilitando la interfaz G0/1 en R1 con el
comando shutdown y luego volviéndola a habilitar con
el comando no shutdown. Si observa detenidamente los
mensajes resaltados, verá varios mensajes de severidad 5
y uno de severidad 3. El comando de configuración
global logging buffered 4 en R1 (ver Ejemplo 9-2)
significa que R1 no almacenará en buffer los mensajes
de registro de nivel de severidad 5, pero almacenará en
buffer el mensaje de nivel de severidad 3. El Ejemplo 9-
4 termina mostrando ese mensaje de registro al final de
la página
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
salida del comando show logging.
Ejemplo 9-4 Ver Mensajes de Severidad 3 y 5 en la

Consola, y Severidad 3 Sólo en el Buffer

con CNTL/Z. R1(config)# interfaz g0/1
R1(config-if)# apagado
R1(config-if)#
*Oct 21 20:07:07.244: %LINK-5-CHANGED: Interfaz GigabitEthernet0
*Oct 21 20:07:08.244: %LINEPROTO-5-UPDOWN: Protocolo de línea en
Inter R1(config-if)# no shutdown
R1(config-if)#
*Oct 21 20:07:24.312: %LINK-3-UPDOWN: Interfaz GigabitEthernet0/
Inter R1(config-if)# ^Z
R1#
*Oct 21 20:07:36.546: %SYS-5-CONFIG_I: Configurado desde consola
por R1# show logging

¡! Saltando unas 20 líneas, las mismas líneas del Ejemplo 9-3,
hasta t Log Buffer (8192 bytes):
*Oct 21 20:07:24.312: %LINK-3-UPDOWN: Interfaz GigabitEthernet0/
El comando debug y los mensajes

de registro
De los ocho niveles de gravedad de los mensajes de
registro, uno de ellos, el nivel de depuración (7), tiene
una finalidad especial: para los mensajes generados
||||||||||||||||||||
||||||||||||||||||||
como resultado de un usuario conectado al router o

switch que emite un comando de depuración.
El comando debug EXEC proporciona al ingeniero de

red una forma de pedir a IOS que monitorice ciertos
eventos internos, con ese proceso de monitorización
continuando en el tiempo, de forma que IOS pueda
emitir mensajes de registro cuando esos eventos ocurran.
El ingeniero puede iniciar sesión, emitir el comando de
depuración, y pasar a otro trabajo. El usuario puede
incluso desconectarse del dispositivo, y la depuración
permanece activada. IOS sigue supervisando la solicitud
en ese comando de depuración y genera mensajes de
registro sobre cualquier evento relacionado. La
depuración permanece activa hasta que algún usuario
emite el comando no debug con los mismos parámetros,
desactivando la depuración.
Nota
Mientras que el comando debug es sólo un

comando, tiene un gran número de opciones, al igual
que el comando show puede ser un comando, pero
también tiene muchas, muchas opciones.
La mejor manera de ver cómo funciona el comando de

depuración, y cómo utiliza los mensajes de registro, es
ver un ejemplo.
El Ejemplo 9-5 muestra un ejemplo de depuración de
mensajes Hello OSPF para el router R1 en la Figura 9-
4. El router (R1) habilita OSPF en dos interfaces y ha
establecido una relación de vecino OSPF con el router
||||||||||||||||||||
||||||||||||||||||||
R2 (RID
Technet24
||||||||||||||||||||
||||||||||||||||||||
2.2.2.2). La salida de depuración muestra un mensaje

de registro para el Hello enviado en cada una de las
cuatro interfaces habilitadas para OSPF, así como
mensajes de registro para los mensajes Hello recibidos
de cada uno de los tres vecinos OSPF.
Ejemplo 9-5 Uso de debug ip ospf hello desde la

consola de R1
R1# debug ip ospf hello

La depuración de OSPF
hello está activada R1#
*Ago 10 13:38:19.863: OSPF-1 HELLO Gi0/1: Enviar hola a 224.0.0.5
*Aug 10 13:38:21.199: OSPF-1 HELLO Gi0/2: Rcv hello from 2.2.2.2
*Ago 10 13:38:22.843: OSPF-1 HELLO Gi0/2: Send hello to 224.0.0.5
R1#
El usuario de consola ve los mensajes de registro

creados en nombre de ese comando de depuración
después de que el comando de depuración se completa.
Según la configuración anterior en el Ejemplo 9-2, el
comando logging console 7 de R1 nos dice que el
usuario de consola recibirá los niveles de severidad 0-7,
lo que incluye los mensajes de depuración de nivel 7.
Note que con la configuración actual, estos mensajes de
depuración no estarían en el buffer local de mensajes de
log (debido al nivel en el comando logging buffered
warning), ni serían enviados al servidor syslog (debido
al nivel en el comando logging trap 4).
Observe que el usuario de consola ve automáticamente

los mensajes de registro como se muestra en el Ejemplo
9-4. Sin embargo, como se indica en el texto que
describe la Figura 9-1, un usuario que se conecta a
||||||||||||||||||||
||||||||||||||||||||
R1 necesitaría también emitir el comando terminal

monitor para ver esos mensajes de depuración. Por
ejemplo, cualquiera que haya iniciado sesión con SSH
en el momento en que se recopiló la salida del Ejemplo
9-4 no habría visto la salida, incluso con el comando
logging monitor debug configurado en el router R1,
sin emitir primero un comando terminal monitor.
Tenga en cuenta que todas las opciones de depuración

habilitadas utilizan la CPU del router, lo que puede
causar problemas al router. Puede supervisar el uso de
CPU con el comando show process cpu, pero debe tener
cuidado al utilizar comandos de depuración con
precaución en dispositivos de producción. Además,
tenga en cuenta que cuantos más usuarios CLI reciban
mensajes de depuración, más CPU se consume. Por lo
tanto, algunas instalaciones eligen no incluir mensajes de
registro de nivel de depuración para el registro de
consola y terminal, requiriendo que los usuarios miren el
buffer de registro o syslog para esos mensajes, sólo para
reducir la carga de CPU del router.
PROTOCOLO DE TIEMPO DE RED (NTP)

Cada dispositivo de red tiene algún concepto de fecha y
hora del día. Por ejemplo, los mensajes de registro
discutidos en la primera sección principal de este
capítulo tenían una marca de tiempo con la fecha y la
hora del día. Ahora imagina mirar todos los mensajes de
registro de todos los routers y switches almacenados en
un servidor syslog. Todos esos mensajes tienen una
fecha y una marca de tiempo, pero ¿cómo te aseguras de
que las marcas de tiempo son consistentes? ¿Cómo te
aseguras de que todos los dispositivos sincronizan sus
||||||||||||||||||||
||||||||||||||||||||
relojes con la hora del día de forma que
Technet24
||||||||||||||||||||
||||||||||||||||||||
para poder entender todos los mensajes de registro del

servidor syslog? ¿Cómo podría entender los mensajes
de un evento que afectó a dispositivos en tres zonas
horarias diferentes?
Por ejemplo, considere los mensajes en dos routers, R1 y

R2, como se muestra en el Ejemplo 9-6. Los routers R1
y R2 no sincronizan sus relojes. Los routers R1 y R2 no
sincronizan sus relojes. Sigue ocurriendo un problema en
el enlace serie entre los dos routers. Un ingeniero de red
mira todos los mensajes de registro almacenados en el
servidor syslog. Sin embargo, cuando el ingeniero ve
algunos mensajes del R1, a las 13:38:39 (alrededor de la
1:40 p.m.), no piensa en buscar los mensajes del R2 que
tienen una marca de tiempo de alrededor de las 9:45
a.m..
Ejemplo 9-6 Mensajes de registro de los routers R1

y R2, comparados

imagen del código
*Oct 19 13:38:37.568: %OSPF-5-ADJCHG: Proceso 1, Nbr 2.2.2.2 en S

Inter

imagen del código
¡! Estos mensajes ocurrieron en el router R2
Oct 19 09:44:09.027: %LINK-3-UPDOWN: Interface Serial0/0/1, chang
Oct 19 09:44:09.027: %OSPF-5-ADJCHG: Process 1, Nbr 1.1.1.1 on Se
En realidad, los mensajes en ambas partes del

Ejemplo 9-6 ocurrieron con 0.5 segundos de
diferencia porque emití un comando de apagado en
uno de los routers.
||||||||||||||||||||
||||||||||||||||||||
Sin embargo, los relojes horarios de los dos routers no

estaban sincronizados, lo que hace que los mensajes de
los dos routers parezcan no estar relacionados. Con
relojes sincronizados, los dos routers habrían indicado
marcas de tiempo prácticamente idénticas de casi la
misma hora exacta en que se produjeron estos
mensajes, lo que facilitaría mucho la lectura y
correlación de los mensajes.
Routers, switches, otros dispositivos de red y

prácticamente todos los dispositivos conocidos en el
mundo de la informática tienen un reloj con la hora del
día. Por varias razones, tiene sentido sincronizar esos
relojes para que todos los dispositivos tengan la misma
hora del día, aparte de las diferencias de zona horaria.
El Protocolo de Tiempo de Red (NTP) proporciona los
medios para hacerlo.
NTP proporciona a cualquier dispositivo una forma de

sincronizar sus relojes horarios. NTP proporciona
mensajes de protocolo que los dispositivos utilizan para
conocer la marca de tiempo de otros dispositivos. Los
dispositivos se envían mutuamente marcas de tiempo
con mensajes NTP, intercambiando mensajes
continuamente, y un dispositivo cambia su reloj para que
coincida con el otro, sincronizando finalmente los
relojes. Como resultado, las acciones que se benefician
de la sincronización, como las marcas de tiempo en los
mensajes de registro, funcionan mucho mejor.
Esta sección trabaja a través de una progresión de temas

que conduce a los tipos más comunes de
configuraciones NTP que se ven en las redes reales. La
sección comienza con ajustes básicos, como la zona
||||||||||||||||||||
||||||||||||||||||||
horaria y la hora inicial configurada en un router o

switch, seguido de la configuración básica de NTP.
Technet24
||||||||||||||||||||
||||||||||||||||||||
A continuación, el texto examina algunos aspectos

internos de NTP relativos a cómo NTP define las fuentes
de datos de tiempo (relojes de referencia) y la calidad de
cada fuente de tiempo (estrato). La sección termina con
más configuración que explica configuraciones típicas de
empresa, con múltiples ntp comandos para la
redundancia y el uso de interfaces loopback para alta
disponibilidad.
Ajustar la hora y la zona horaria

El trabajo de NTP es sincronizar relojes, pero NTP
funciona mejor si ajustas el reloj del dispositivo a una
hora razonablemente cercana antes de habilitar la
función de cliente NTP con el comando ntp server. Por
ejemplo, mi reloj de pulsera marca las 8:52 p.m. en este
momento. Antes de iniciar NTP en un nuevo router o
switch para que se sincronice con otro dispositivo,
debería poner la hora a las 8:52 p.m., poner la fecha y la
zona horaria correctas, e incluso decirle al dispositivo
que se ajuste al horario de verano-y luego activar NTP.
Ajustar la hora correctamente le da a NTP un buen
comienzo hacia la sincronización.
El Ejemplo 9-7 muestra cómo configurar la fecha, la

hora, la zona horaria y el horario de verano.
Curiosamente, utiliza dos comandos de configuración
(para la zona horaria y el horario de verano) y un
comando EXEC para establecer la fecha y la hora en el
router.
Ejemplo 9-7 Ajuste de la fecha/hora con el reloj

ajustado, más zona horaria/DST
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||

con CNTL/Z. R1(config)# reloj zona horaria EST -5
R1(config)# clock summer-time EDT recurring
R1(config)# ^Z
R1#
R1# clock set 20:52:49 21 de octubre de 2015
*Oct 21 20:52:49.000: %SYS-6-CLOCKUPDATE: El reloj del sistema ha
sido u R1# show clock
20:52:55.051 EDT mié oct 21 2015
Concéntrese primero en los dos comandos de

configuración. Debe configurar los dos primeros
comandos antes de configurar la hora del día con el
comando clock set EXEC porque los dos comandos de
configuración afectan a la hora que se configura. En el
primer comando, la parte de la zona horaria del reloj
define el comando y una palabra clave. El siguiente
parámetro, "EST" en este caso, es cualquier valor que
elijas, pero elige el nombre de la zona horaria del
dispositivo. Este valor se muestra en los comandos
show, así que aunque tú inventes el valor, éste tiene que
ser significativo para todos. Yo elegí EST, el acrónimo
de US Eastern Standard Time. El parámetro "-5"
significa que este dispositivo está 5 horas por detrás de
la Hora Universal Coordinada (UTC).
La parte del horario de verano del segundo comando

define lo que hay que hacer, siendo de nuevo "EDT" un
campo en el que se podría haber utilizado cualquier
valor. Sin embargo, debe utilizar un valor significativo.
Este es el valor que se muestra con la hora en los
comandos show cuando el horario de verano está en
vigor, así que elegí EDT porque es el acrónimo de
horario de verano en esa misma zona horaria EST.
Por último, la palabra clave recurring indica al enrutador que debe lanzar
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
avanzar una hora y retroceder una hora automáticamente

a lo largo de los años.
A continuación, el comando clock set EXEC establece

la hora, el día del mes, el mes y el año. Sin embargo,
tenga en cuenta que IOS interpreta la hora tal como se
escribe en el comando en el contexto de la zona horaria
y el horario de verano. En el ejemplo, el comando clock
set indica una hora de 20:52:49 (el comando utiliza una
sintaxis horaria con un formato de 24 horas, no con un
formato de 12 horas más a.m./p.m.). Como resultado de
esa hora más los dos comandos de configuración
anteriores, el comando show clock (emitido segundos
después) lista esa hora, pero también anota la hora como
EDT, en lugar de hora UTC.
Configuración básica de NTP

Con NTP, los servidores suministran información sobre
la hora del día a los clientes, y éstos reaccionan
ajustando sus relojes para que coincidan. El proceso
requiere pequeños ajustes repetidos a lo largo del tiempo
para mantener esa sincronización. La configuración en sí
puede ser simple, o puede ser extensa una vez que
añades la configuración de seguridad y la redundancia.
Cisco proporciona dos comandos de configuración ntp

que dictan cómo funciona NTP en un router o switch,
como sigue:
ntp maestro {nivel de estrato}: Modo servidor NTP: el dispositivo

actúa sólo como servidor NTP y no como cliente NTP. El
dispositivo obtiene su hora
||||||||||||||||||||
||||||||||||||||||||
información del reloj interno del dispositivo.
ntp server {address | hostname} : modo cliente/servidor NTP: el

dispositivo actúa como cliente y como servidor. En primer lugar,
actúa como cliente NTP, para sincronizar la hora con un servidor.
Una vez sincronizado, el dispositivo puede actuar como servidor
NTP para proporcionar la hora a otros clientes NTP.
Para un ejemplo que muestra la sintaxis básica de

configuración y los comandos show, considera la
Figura 9-5. Con esta sencilla configuración:
R3 actúa sólo como servidor NTP.
R2 actúa en modo cliente/servidor, primero como cliente NTP para

sincronizar la hora con el servidor NTP R3 y luego como servidor
para suministrar la hora al cliente NTP R1.
R1 actúa en modo cliente/servidor, primero como cliente NTP para

sincronizar la hora con el servidor NTP R2. (R1 estará dispuesto a
actuar como servidor, pero resulta que ningún dispositivo hace
referencia a R1 como servidor NTP en este ejemplo).
Figura 9-5 R1 como cliente NTP, R2 como

cliente/servidor, R3 como servidor
Como puedes ver, NTP requiere poca configuración para

hacerlo funcionar con un único comando de
configuración en cada dispositivo. El ejemplo 9-8 recoge
la configuración de los dispositivos mostrados en la
figura para facilitar su consulta.
Ejemplo 9-8 Configuración Cliente/Servidor NTP

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
¡! Configuración en R1:
servidor ntp 172.16.2.2
maestro ntp 2
El Ejemplo 9-9 lista la salida del comando show ntp

status en R1, con la primera línea de salida incluyendo
algunos ítems de estado importantes. Primero, muestra
un estado de sincronizado, que confirma que el cliente
NTP ha completado el proceso de cambiar su hora para
que coincida con la hora del servidor. Cualquier router
que actúe como cliente NTP mostrará "no sincronizado"
en esa primera línea hasta que el proceso de
sincronización NTP se complete con al menos un
servidor. También confirma la dirección IP del servidor -
el reloj de referencia de este dispositivo- con la dirección
IP configurada en el Ejemplo 9-8 (172.16.2.2).
Ejemplo 9-9 Verificación del Estado del Cliente NTP en R1
||||||||||||||||||||
||||||||||||||||||||
R1# show ntp status
Reloj sincronizado, estrato 4, referencia 172.16.2.2 frecuencia
nominal 250.0000 Hz, frecuencia real 250.0000 Hz, precisión ntp
uptime 1553800 (1/100 de segundo), resolución 4000 hora de
referencia DA5E7147.56CADEA7 (19:54:31.339 EST Thu Feb 4 2
desfase 0.0986 mseg, retardo raíz 2.46 mseg
la dispersión de la raíz es de 22,19 mseg, la dispersión de los
pares es de 5,33 mseg el estado del filtro de bucle es 'CTRL'
(Bucle Normal Controlado), la deriva es de 0,0 el intervalo de
sondeo del sistema es de 64, la última actualización fue hace 530
segundos.
A continuación, mire la salida del comando show ntp

associations tanto del R1 como del R2, como se
muestra en el Ejemplo 9-10. Este comando enumera
todos los servidores NTP que el dispositivo local puede
intentar utilizar, con información de estado sobre la
asociación entre el dispositivo local (cliente) y los
distintos servidores NTP. Comenzando con R1, observe
que tiene una asociación (es decir, relación con un
servidor NTP), basada en el comando de configuración
one ntp server 172.16.2.2 en R1. El * significa que R1
ha contactado con éxito con el servidor. Verás datos
similares en la misma salida de comando tomada del
router R2.
Ejemplo 9-10 Verificación del estado del cliente NTP

en R1 y R2
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
R1# show ntp associations
¡! Esta salida es tomada del router R1, actuando en mo

cliente/servidor
dirección reloj ref st cuando el sondeo alcanza el offset
de retardo d
*~172.16.2.2 172.16.3.3 3 50 64 377 1.223 0.090 4
* sys.peer, # seleccionado, + candidato, - outlyer, x

falseticker, ~

imagen del código
¡! Esta salida está tomada del router R2, actuando en mo

cliente/servidor
direcci ref clockst cuando poll alcance delay
ón offset d
*~172.16.3.3 127.127.1.1 2 49 64 377 1.220 -7.758 3
* sys.peer, # seleccionado, + candidato, - outlyer, x

falseticker, ~
Reloj de referencia NTP y estrato

Los servidores NTP deben aprender la hora de algún
dispositivo. Para los dispositivos que actúan en modo
cliente/servidor NTP, el dispositivo utiliza la función de
cliente NTP para aprender la hora. Sin embargo, los
dispositivos que actúan únicamente como servidor NTP
obtienen la hora del hardware interno del dispositivo o
de algún reloj externo que utilice mecanismos distintos a
NTP.
Por ejemplo, cuando se configura con el comando ntp

master, un router/switch Cisco utiliza el hardware
interno de su dispositivo para determinar la hora. Todos
los ordenadores, incluidos los dispositivos de red,
necesitan algún medio para mantener la hora por una
miríada de razones, por lo que incluyen tanto
||||||||||||||||||||
||||||||||||||||||||
componentes de hardware y procesos de software para

mantener la hora incluso durante periodos en los que el
dispositivo pierde energía.
Además, los servidores y clientes NTP utilizan un

número para mostrar la precisión percibida de sus datos
de reloj de referencia en función del nivel de estrato.
Cuanto más bajo es el nivel de estrato, más preciso se
considera el reloj de referencia. Un servidor NTP que
utiliza su hardware interno o reloj de referencia externo
establece su propio nivel de estrato. A continuación, un
cliente NTP añade 1 al nivel de estrato que aprende de su
servidor NTP, de modo que el nivel de estrato aumenta
cuantos más saltos se alejan de la fuente de reloj
original.
Por ejemplo, en la Figura 9-5, se puede ver el servidor

primario NTP (R3) con un estrato de 2. R2, que hace
referencia a R3, añade 1 para tener un estrato de 3. R1
utiliza R2 como su servidor NTP, por lo que R1 añade 1
para tener un estrato de 4.
Estos niveles de estrato crecientes permiten a los
dispositivos hacer referencia a varios servidores NTP y
utilizar la información horaria del mejor servidor NTP,
siendo el mejor el servidor con el nivel de estrato más
bajo.
Los routers y switches usan el nivel de estrato por

defecto de 8 para su reloj de referencia interno basado
en la configuración por defecto de 8 para el nivel de
estrato en el comando ntp master [stratum-level]. El
comando le permite establecer un valor de 1 a 15; en el
Ejemplo 9-8, el comando ntp master 2 establece el
nivel de estrato del router R3 en 2.
||||||||||||||||||||
||||||||||||||||||||
Nota
Technet24
||||||||||||||||||||
||||||||||||||||||||
NTP considera que 15 es el nivel de estrato útil más

alto, por lo que cualquier dispositivo que calcule su
estrato como 16 considera los datos de tiempo
inutilizables y no confía en la hora. Por lo tanto, evite
establecer valores de estrato más altos en el comando
ntp master.
Para ver la evidencia, refiérase de nuevo al Ejemplo 9-
10, que muestra dos comandos basados en la misma
configuración del Ejemplo 9-8 y la Figura 9-5. La
salida resalta detalles sobre los relojes de referencia y
los niveles de estrato, como sigue:
R1: Según el comando ntp server 172.16.2.2

configurado, el comando show muestra la misma
dirección (que es la dirección del router R2). Los
campos ref clock (reloj de referencia) y st (estrato)
representan el reloj de referencia de R2 como
172.16.3.3-en otras palabras, el servidor NTP de R2,
que es R3 en este caso. El valor 3 del campo st
muestra el estrato de R2.
R2: Según el comando ntp server 172.16.3.3

configurado, el comando show lista 172,16,3,3, que es
una dirección en el router R3. La salida indica que el
reloj de referencia de R3 es 127.127.1.1-, lo que indica
que el servidor (R3) obtiene su reloj internamente. Lista
el valor st (stratum) de R3 como 2 - consistente con el
comando ntp master 2 configurado en R3 (según el
Ejemplo 9-8).
En el propio servidor primario NTP (R3 en este caso), la

salida tiene más marcadores que indican el uso del reloj
interno. El ejemplo 9-11 muestra la salida de R3, con
||||||||||||||||||||
||||||||||||||||||||
un reloj de referencia de la dirección loopback

127.127.1.1, usado para referirse al hecho de que este
router obtiene sus datos de reloj internamente. También,
en la salida del comando show ntp associations en la
parte inferior, note esa misma dirección, junto con un
valor de reloj de referencia de ".LOCL". En efecto, R3,
por el comando de configuración ntp master, tiene una
asociación con su reloj interno.
Ejemplo 9-11 Examen del servidor NTP, reloj de

referencia y datos de estrato

imagen del código
R3# show ntp status
Reloj sincronizado, estrato 2, referencia 127.127.1.1,
frecuencia nominal 250,0000 Hz, frecuencia real 250,0000 Hz,
precisión ntp uptime 595300 (1/100 de segundo), resolución 4000,
hora de referencia E0F9174C.87277EBB (16:13:32.527 daylight Sat
Au desfase 0,0000 mseg, retardo raíz 0,00 mseg.
la dispersión raíz es de 0,33 mseg, la dispersión par es de 0,23
mseg el estado del filtro de bucle es "CTRL" (bucle controlado
normal), la deriva es de 0,0
el intervalo de sondeo del sistema es 16, la última actualización
fue hace 8 segundos.
addressre st cuan retardo de
f clock 1 do alcance
16 de 0.000
377 sondeo
*~127.127.1.1 .LOCL.
* sys.peer, # seleccionado, + candidato,15
- outlyer, x
falseticker, ~
Configuración NTP redundante

En lugar de utilizar un dispositivo de red como reloj de
referencia para la empresa, puede hacer referencia a
mejores fuentes de tiempo en Internet o adquirir un
servidor NTP específico que disponga de un mejor
hardware de sincronización. Por ejemplo, una empresa
podría utilizar NTP para hacer referencia a NTP
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
servidores que utilizan un reloj atómico como fuente de

referencia, como los servidores primarios NTP de la
Figura 9-6, que casualmente están gestionados por el
Instituto Nacional de Estándares y Tecnología de EEUU
(NIST) (ver tf.nist.gov).
Figura 9-6 Niveles de estrato cuando se utiliza un

servidor NTP de estrato 1 basado en Internet
Nota
Mientras que los términos comunes modo servidor

NTP y NTP
||||||||||||||||||||
||||||||||||||||||||
modo cliente/servidor son útiles, las RFC de NTP

(1305 y 5905) también utilizan otros dos términos
específicos para ideas similares: Servidor primario
NTP y servidor secundario NTP. Un servidor
primario NTP actúa sólo como servidor, con un reloj
de referencia externo al dispositivo, y tiene un nivel
de estrato de 1, como los dos servidores primarios
NTP que se muestran en la Figura 9-6. Los
servidores secundarios NTP son servidores que
utilizan el modo cliente/servidor como se describe a
lo largo de esta sección, dependiendo de la
sincronización con algún otro servidor NTP.
Para un buen diseño, la configuración NTP de la
empresa debería referirse al menos a dos servidores NTP
externos para redundancia. Además, sólo unos pocos
dispositivos de la empresa deben hacer referencia a los
servidores NTP externos y luego actuar como cliente y
servidor NTP. La mayoría de los dispositivos de la
empresa, como los mostrados en la parte inferior de la
figura, actuarían como clientes NTP. El ejemplo 9-12
muestra la configuración en los routers R1 y R2 de la
figura para llevar a cabo este diseño.
Ejemplo 9-12 Configuración NTP en R1, R2 según

Figura 9-6
servidor ntp time-a-b-

nist.gov servidor ntp time-a-
g.nist.gov
Además de hacer referencia a los primarios NTP redundantes
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
algunos enrutadores en la empresa necesitan estar listos

para suministrar datos de reloj si esos servidores
primarios NTP se vuelven inalcanzables. Existe un
riesgo con la configuración del Ejemplo 9-12 porque si
los routers R1 y R2 dejan de recibir mensajes NTP de
los servidores NTP de Internet, perderán su único reloj
de referencia. Después de perder su reloj de referencia,
R1 y R2 ya no podrían ser servidores NTP útiles para el
resto de la empresa.
Para superar este posible problema, los routers también

pueden configurarse con el comando ntp master, lo
que da lugar a esta lógica:
1. Establecer una asociación con los servidores NTP según el servidor ntp
mando.
2. Establezca una asociación con su reloj interno utilizando el

comando ntp master stratum.
3. Establecer el nivel de estrato del reloj interno (por el maestro ntp
{nivel de estrato}) a un nivel de estrato superior (peor) que el de
los servidores NTP basados en Internet.
4. Sincronizar con la mejor fuente de tiempo conocida (la más baja),

que en este caso será uno de los servidores NTP de Internet.
La lógica tiene algunos pasos, pero la configuración en

sí es simple, como se muestra en el Ejemplo 9-13.
Comparado con el Ejemplo 9-12, sólo hay que añadir el
comando ntp master. Los servidores NTP utilizados en
este ejemplo tienen un nivel de estrato de 1, por lo que el
uso del comando ntp master 7, con un estrato mucho
más alto, hará que los routers R1 y R2 utilicen uno de
los servidores NIST NTP cuando esté disponible y
utilicen la fuente de reloj interna sólo cuando la
conectividad con el NIST
||||||||||||||||||||
||||||||||||||||||||
servidores se pierde.
Ejemplo 9-13 Configuración NTP en R1 y R2 para

proteger contra fallos de Internet
servidor ntp tiempo-a-b-
nist.gov servidor ntp
tiempo-a-g.nist.gov maestro
ntp 7
NTP usando una interfaz Loopback

para una mejor disponibilidad
Por defecto, un servidor NTP aceptará mensajes NTP
que lleguen a cualquiera de sus direcciones IPv4. Sin
embargo, los clientes hacen referencia a una dirección
IP específica del servidor NTP. Esto crea un problema
de disponibilidad.
Por ejemplo, considera la topología de la Figura 9-7, con

el router R4 a la derecha actuando como servidor NTP y
los otros routers actuando como clientes. R4 tiene tres
direcciones IP que los clientes podrían poner en sus
comandos de dirección de servidor ntp. Ahora
consideremos qué ocurre cuando falla una interfaz en
R4, pero sólo una. No importa cual de las tres interfaces
falle, esa dirección IP en esa interfaz no puede ser usada
para enviar y recibir paquetes. En ese caso, para
cualquier cliente NTP que se haya referido a esa
dirección IP específica
Probablemente todavía habría una ruta para llegar a la propia R4.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
El cliente NTP no podría enviar paquetes a la dirección configurada

porque esa interfaz está caída.
Figura 9-7 Problema de disponibilidad al hacer

referencia a la dirección IP de la interfaz física de un
servidor NTP
Lo que se necesita es una forma de enviar un paquete a

R4, una forma que no esté ligada al estado de ninguna
interfaz. Es decir, mientras haya algún camino para
enviar paquetes al propio R4, permitir que NTP siga
funcionando. El objetivo es evitar el caso en el que el
fallo de una única interfaz en el router R4 también
provoque el fallo de NTP.
Cisco utiliza la interfaz loopback del router para

satisfacer esa necesidad exacta. Las interfaces loopback
son interfaces virtuales internas de Cisco IOS, creadas
mediante el comando interface loopback number,
donde el número es un entero. Una vez configurada, esa
interfaz loopback existe dentro de ese router y no está
ligada a ninguna interfaz física. A una interfaz loopback
se le puede asignar una dirección IP, los protocolos de
enrutamiento pueden anunciar sobre la subred, y se
puede hacer ping/traceroute a esa dirección. Actúa
como otras interfaces físicas en muchos aspectos, pero
una vez configurada, permanece en estado up/up
mientras
||||||||||||||||||||
||||||||||||||||||||
El router permanece activo.
No se emite un comando shutdown en esa interfaz loopback.
Nota
Esta discusión no trata sobre la dirección especial

IPv4 de loopback 127.0.0.1. La interfaz loopback
de la que se habla en esta sección es un concepto
totalmente diferente.
El Ejemplo 9-14 muestra el pequeño cambio de

configuración que añade la interfaz loopback a la
configuración NTP, que se basa en la Figura 9-5. En
este caso, la configuración del Ejemplo 9-14 cambia
ligeramente la configuración mostrada anteriormente en
el Ejemplo 9-8. R1 sigue actuando como cliente. R1,
que sigue actuando como cliente, ahora apunta a la
nueva dirección IP de la interfaz loopback de R2,
172.16.9.9. R2 ahora tiene configuración para una
nueva interfaz loopback (loopback 0). R2 también tiene
un comando que le dice que use la dirección IP de esa
interfaz loopback 0 como dirección de origen cuando
envíe paquetes NTP.
Ejemplo 9-14 Configuración de cliente/servidor NTP

en R1 y R2 usando una interfaz Loopback
||||||||||||||||||||
||||||||||||||||||||
¡! Configuración en R1, un cliente
Technet24
||||||||||||||||||||
||||||||||||||||||||

imagen del código
¡! Configuración en R2 para su función de servidor
interfaz loopback 0
dirección ip 172.16.9.9 255.255.255.0
¡!
maestro ntp 4
ntp fuente loopback 0
¡! Verificación en el router
R2 R2# show interfaces
loopback 0
Loopback0 está activo, protocolo de línea activo
El hardware es Loopback
Las interfaces loopback tienen una amplia gama de usos

a través de las características de IOS. Se mencionan aquí
con NTP porque NTP es una característica que puede
beneficiarse del uso de interfaces loopback. (Como
recordatorio, OSPF pasa a utilizar interfaces loopback
con la configuración OSPF para un propósito
completamente diferente).
ANÁLISIS DE LA TOPOLOGÍA MEDIANTE

CDP Y LLDP
Las dos primeras secciones principales de este capítulo
mostraron dos características-syslog y NTP-que
funcionan de la misma manera tanto en routers como en
switches. Esta última sección muestra aún
||||||||||||||||||||
||||||||||||||||||||
otra característica común a routers y switches, con dos

protocolos similares: el Cisco Discovery Protocol (CDP)
y el Link Layer Discovery Protocol (LLDP).
Esta sección se centra en CDP, seguido de LLDP.
Examinar la información obtenida

por CDP
CDP descubre información básica sobre los routers y
switches vecinos sin necesidad de conocer las
contraseñas de los dispositivos vecinos. Para descubrir
información, los routers y switches envían mensajes
CDP a través de cada una de sus interfaces. Los
mensajes esencialmente anuncian información sobre el
dispositivo que envió el mensaje CDP. Los dispositivos
que soportan CDP aprenden información sobre otros
escuchando los anuncios enviados por otros
dispositivos.
CDP descubre varios detalles útiles de los dispositivos

Cisco vecinos:
Identificador del dispositivo: Normalmente el nombre del host
Lista de direcciones: Direcciones de red y de enlace de datos
Identificador de puerto: La interfaz en el router remoto o switch

en el otro extremo del enlace que envió el anuncio CDP.
Lista de capacidades: Información sobre qué tipo de dispositivo

es (por ejemplo, un router o un switch).
Plataforma: El modelo y el nivel de SO que se ejecuta en el dispositivo
CDP desempeña dos funciones generales: proporcionar información a
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
los dispositivos para soportar alguna función y

proporcionar información a los ingenieros de red que
gestionan los dispositivos. Por ejemplo, los teléfonos IP
de Cisco utilizan CDP para aprender los IDs de VLAN
de datos y voz tal y como están configurados en el
switch de acceso. Para ese segundo rol, CDP tiene
comandos show que listan información acerca de
dispositivos vecinos, así como información acerca de
cómo está funcionando CDP. La Tabla 9-3 describe los
tres comandos show que listan la información CDP más
importante.
Tabla 9-3 Comandos show cdp que enumeran

información sobre los vecinos
show cdp Enumera una línea de resumen de información

neighbors sobre cada vecino o sólo el vecino encontrado en
[número de una interfaz específica si se ha enumerado una
tipo] interfaz.
show cdp Enumera un gran conjunto (aproximadamente 15

neighbors líneas) de información, un conjunto por cada
detail vecino.
mostrar Muestra la misma información que el comando

nombre de show cdp neighbors detail, pero sólo para el
entrada vecino nombrado (distingue entre mayúsculas y
cdp minúsculas).
Nota
||||||||||||||||||||
||||||||||||||||||||
Los routers y switches Cisco soportan los mismos

comandos CDP, con los mismos parámetros y los
mismos tipos de salida.
El siguiente ejemplo muestra el poder de la información

en los comandos CDP. El ejemplo utiliza la red mostrada
en la Figura 9-8, con el Ejemplo 9-15 listando la salida
de varios comandos show cdp.
Figura 9-8 Red pequeña utilizada en ejemplos CDP
Ejemplo 9-15 show cdp neighbors Ejemplos de

Comandos: SW2
SW2# show cdp neighbors
Códigos de capacidad: R - Router, T - Trans Bridge, B - Source
Route S - Switch, H - Host, I - IGMP, r -
Repeater, P D - Remote, C - CVTA, M - Two-port
ID del Intrfce local

Mac Relay Holdtme Plataforma de
dispositi capacidades
vo
SW1 Gig 1/0/21 155 S I WS-C296
Technet24
||||||||||||||||||||
||||||||||||||||||||
R1 Gig 1/0/2 131 R S I C1111-8
Total de entradas cdp mostradas

: 2
El comando show cdp neighbors lista una línea por

vecino. (Busque la columna Device ID y la lista que
incluye SW1 y R1.) Cada una de esas dos líneas lista la
información topológica más importante sobre cada
vecino: el nombre de host del vecino (Device ID), la
interfaz del dispositivo local y la interfaz del dispositivo
vecino (bajo el encabezado Port).
Preste mucha atención a la interfaz del dispositivo local

y a la interfaz del dispositivo vecino, comparando el
ejemplo con la figura. Por ejemplo, el comando show
cdp neighbors de SW2 lista una entrada para SW1, con
la interfaz local de SW2 de Gi0/2 y la interfaz de SW1
de Gi0/1 bajo el encabezado "Port ID".
Este comando también lista la plataforma, identificando

el modelo específico del router o switch vecino. Así
que, incluso utilizando esta información básica, podrías
construir una figura como la Figura 9-8 o confirmar que
los detalles de la figura son correctos.
La Figura 9-8 y el Ejemplo 9-15 proporcionan un buen

contexto de por qué los dispositivos aprenden sobre
vecinos directos con CDP, pero no sobre otros vecinos.
En primer lugar, CDP define una encapsulación que
utiliza la cabecera del enlace de datos, pero no la
cabecera IP. Para asegurar que todos los dispositivos
reciben un mensaje CDP, la cabecera Ethernet utiliza
una MAC de destino multidifusión.
||||||||||||||||||||
||||||||||||||||||||
(0100.0CCC.CCCC). Sin embargo, cuando cualquier

dispositivo que soporta CDP recibe un mensaje CP, el
dispositivo procesa el mensaje y luego lo descarta, en
lugar de reenviarlo. Así, por ejemplo, cuando el router R1
envía un mensaje CDP a la dirección Ethernet multicast
0100.0CCC.CCCC, el switch SW2 lo recibe, lo procesa,
pero no lo reenvía al switch SW1-por lo que SW1 no
listará al router R1 como vecino CDP.
Luego, considere el comando show cdp neighbors

detail como se muestra en el Ejemplo 9-16,
nuevamente tomado del switch SW2. Este comando
lista más detalles, como puede haber adivinado. El
detalle lista el nombre completo del modelo del switch
(WS-2960XR-24TS-I) y la dirección IP configurada en
el dispositivo vecino. Tiene que mirar con atención,
pero el ejemplo tiene un largo grupo de mensajes para
cada uno de los dos vecinos; el ejemplo incluye una
línea de comentario con resaltado gris para ayudarle a
encontrar el punto de división entre los grupos de
mensajes.
Ejemplo 9-16 Comando show cdp neighbors detail en

SW2
||||||||||||||||||||
||||||||||||||||||||
SW2# show cdp neighbors detail
ID del
dispositivo: SW1
Dirección(es) de
entrada:
Plataforma: cisco WS-C2960XR-24TS-I, Capacidades: Conmutador IGMP
Technet24
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
||||||||||||||||||||
Interfaz: GigabitEthernet1/0/21, ID de puerto (puerto saliente):
Gigab Tiempo de espera : 144 seg
Versión :
Software Cisco IOS, Software C2960X (C2960X-UNIVERSALK9-M), Versi
Soporte técnico: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 por Cisco Systems, Inc.
Compilado Thu 13-Sep-18 03:43 por prod_rel_team
versión del anuncio: 2
Protocolo Hello: OUI=0x00000C, Protocolo ID=0x0112; carga útil
len=27 Dominio de gestión VTP: 'fred'
VLAN nativa: 1
Dúplex:
completo
Dirección(es) de
gestión: Dirección IP:
1.1.1.1
ID del
dispositivo: R1
Dirección(es) de
entrada:
Plataforma: cisco C1111-8P, Capacidades: Router Switch IGMP
Interface: GigabitEthernet1/0/2, ID de puerto (puerto saliente):
Gigabi Tiempo de espera : 151 seg
Versión :
Software Cisco IOS [Fuji], Software ISR (ARMV8EB_LINUX_IOSD-UNIVE
|||||||||||||||||||| Soporte técnico: http://www.cisco.com/techsupport

||||||||||||||||||||
Compilado Mar 27-Mar-18 10:56 por mcpre
versión de anuncio: 2
Dominio de gestión VTP: ''
Dúplex: completo
Dirección(es) de gestión:
Dirección IP:
10.12.25.5
Total de entradas cdp mostradas : 2
Nota
El comando show cdp entry name lista exactamente

los mismos detalles mostrados en la salida del
comando show cdp neighbors detail, pero sólo para
el vecino listado en el comando.
Como puedes ver, puedes sentarte en un dispositivo y

descubrir mucha información sobre un dispositivo
vecino-un hecho que realmente crea una exposición de
seguridad. Cisco recomienda deshabilitar CDP en
cualquier interfaz que no necesite CDP. Para switches,
cualquier puerto de switch conectado a otro switch, un
router, o a un teléfono IP debería usar CDP.
Finalmente, tenga en cuenta que CDP muestra

información sobre vecinos conectados directamente.
Por ejemplo, show cdp neighbors on SW1 mostraría
una entrada para SW2 en esta lista
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
pero no R1, porque R1 no está conectado directamente

a SW1.
Configuración y verificación de CDP

La mayor parte del trabajo que hace con CDP se
relaciona con lo que CDP puede decirle con los
comandos show. Sin embargo, es una característica de
IOS, por lo que puede configurar CDP y utilizar algunos
comandos show para examinar el estado del propio CDP.
IOS normalmente habilita CDP globalmente y en cada

interfaz por defecto. A continuación, puede desactivar
CDP por interfaz con el subcomando de interfaz no cdp
enable y, posteriormente, volver a activarlo con el
subcomando de interfaz cdp enable.
Para desactivar y volver a activar CDP globalmente en el
dispositivo, utilice los comandos globales no cdp run y
cdp run, respectivamente.
Para examinar el estado del propio CDP, utilice los

comandos de la Tabla 9-4.
Tabla 9-4 Comandos utilizados para

verificar las operaciones CDP
mostrar Indica si CDP está habilitado globalmente y enumera

cdp los temporizadores de actualización y espera
predeterminados.
show cdp Indica si CDP está habilitado en cada interfaz, o en

interface una única interfaz si la interfaz está en la lista, y
[número establece los temporizadores de actualización y
de tipo] espera en esas interfaces.
mostrar Enumera las estadísticas globales del número de CDP

cdp
||||||||||||||||||||
||||||||||||||||||||
tráfico anuncios enviados y recibidos
En el Ejemplo 9-17 se muestra un ejemplo de salida de

cada uno de los comandos de la Tabla 9-4, basado en el
conmutador SW2 de la Figura 9-8.
Ejemplo 9-17 show cdp Comandos que muestran el

estado de CDP
SW2# show cdp

Información global sobre CDP:
Envío de paquetes CDP cada 60 segundos
Envío de un valor de tiempo de espera de
180 segundos El envío de anuncios CDPv2
está activado
SW2# show cdp interface GigabitEthernet1/0/2

GigabitEthernet1/0/2 está activada, el protocolo de
línea está activado Encapsulación ARPA
Envío de paquetes CDP cada 60 segundos
El tiempo de espera es de 180
segundos
SW2# show cdp traffic

Contadores CDP :
Salida total de paquetes: 304, Entrada: 305
Sintaxis Hdr: 0, Error Chksum: 0, Encaps fallido: 0
Sin memoria: 0, Paquete inválido: 0,
Salida de anuncios CDP versión 1: 0, Entrada: 0
Salida de anuncios CDP versión 2: 304, Entrada: 305
Los dos primeros comandos del ejemplo listan dos

parámetros relacionados con el funcionamiento de
CDP: el tiempo de envío y el tiempo de espera. Por
defecto, CDP envía mensajes cada 60 segundos, con un
tiempo de espera de 180 segundos. El tiempo de espera
le indica al dispositivo cuánto tiempo debe esperar
después de no recibir más noticias de un dispositivo
antes de eliminar esos detalles de las tablas CDP. Puede
anular los valores por defecto con el comando cdp
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
timer seconds y cdp holdtime seconds,

respectivamente.
Examinar la información obtenida

por LLDP
Cisco creó el CDP propietario de Cisco antes de que
existiera ningún estándar para un protocolo similar. CDP
tiene muchas ventajas. Como protocolo de Capa 2,
situado encima de Ethernet, no depende de un protocolo
de Capa 3 en funcionamiento. Proporciona información
del dispositivo que puede ser útil de varias maneras.
Cisco tenía una necesidad pero no vio un estándar que la
cubriera, así que se inventó un protocolo, como ha
ocurrido muchas veces a lo largo de la historia con
muchas empresas y protocolos.
El protocolo LLDP (Link Layer Discovery Protocol),

definido en el estándar 802.1AB del IEEE, proporciona
un protocolo estandarizado que ofrece las mismas
características generales que CDP. LLDP tiene una
configuración similar y comandos show prácticamente
idénticos en comparación con CDP.
Todos los ejemplos LLDP usan la misma topología

usada en los ejemplos CDP según la Figura 9-8 (la
misma figura usada en los ejemplos CDP). El Ejemplo 9-
18 lista los vecinos LLDP del switch SW2 aprendidos
después de habilitar LLDP en todos los dispositivos y
puertos de la figura. El ejemplo resalta los elementos que
coinciden con la salida similar del comando show cdp
neighbors listado al final del ejemplo, también del
switch SW2.
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 9-18 show lldp neighbors on SW2 with

Similarities to CDP Highlighted

imagen del código
SW2# show lldp neighbors
Códigos de capacidad:
(R) Enrutador, (B) Puente, (T) Teléfono, (C) Dispositivo de
cable DOCSIS
(W) Punto de acceso WLAN, (P) Repetidor, (S) Estación, (O)
Otro
Dispos ID Intf local Tiempo de Capacidad Por
itivo espera
R1 Gi1/0/2 120 R Gi0
SW1 Gi1/0/21 120 B Gi1
Total de entradas mostradas: 2
SW2# show cdp neighbors

Códigos de capacidad: R - Router, T - Trans Bridge, B - Source
Route S - Switch, H - Host, I - IGMP, r -
Repeater, P D - Remote, C - CVTA, M - Two-port
Mac Relay
Dispos ID Intrfce local Holdtme Capacidad Platfor

itivo
SW1 Gig 1/0/21 155 S I WS-C296
R1 Gig 1/0/2 131 R S I C1111-8
Total de entradas
mostradas: 2
Lo más importante de la salida es la consistencia entre

CDP y LLDP en como se refieren a las interfaces.
Ambos comandos show cdp neighbors y show lldp
neighbors tienen columnas "local intf" (interfaz) y "port
ID". Estas columnas se refieren a la interfaz del
dispositivo local y a la interfaz del dispositivo vecino,
respectivamente.
Sin embargo, la salida LLDP del ejemplo difiere de

CDP en algunos aspectos importantes:
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
LLDP utiliza B como código de capacidad para la conmutación,

en referencia a bridge, un término para el tipo de dispositivo que
existía antes de los switches y que realizaba las mismas funciones
básicas.
LLDP no identifica IGMP como una capacidad, mientras que CDP sí lo hace (I).
CDP enumera la plataforma del vecino, un código que define

el tipo de dispositivo, mientras que LLDP no lo hace.
LLDP lista las capacidades con diferentes convenciones (ver

próximo Ejemplo 9-19).
Los primeros tres ítems de la lista son relativamente

sencillos, pero el último ítem de la lista requiere una
mirada más detallada. Curiosamente, CDP lista todas las
capacidades del vecino en la salida del comando show
cdp neighbors, sin importar si el dispositivo
actualmente habilita todas esas características. LLDP en
cambio lista las capacidades habilitadas (configuradas),
en lugar de todas las capacidades soportadas, en la
salida del comando show lldp neighbors.
LLDP marca la diferencia en las capacidades totales

de un vecino y las capacidades configuradas con los
comandos show lldp neighbors detail y show lldp
entry hostname. Estos comandos proporcionan una
salida detallada idéntica, con el primer comando
proporcionando detalles para todos los vecinos, y el
segundo proporcionando detalles para el único vecino
listado. El ejemplo 9-19 muestra el detalle para el
vecino R1.
Ejemplo 9-19 Comando show lldp entry r2 en SW2
SW2# show lldp entry R1
||||||||||||||||||||
||||||||||||||||||||
Códigos de capacidad:
(R) Enrutador, (B) Puente, (T) Teléfono, (C) Dispositivo de
cable DOCSIS
(W) Punto de acceso WLAN, (P) Repetidor, (S) Estación, (O)
Otro
Intf. local Gi1/0/2

Chasis id: 70ea.1a9a.d300
Puerto id: Gi0/0/1
Descripción del puerto:
GigabitEthernet0/0/1 Nombre del
Sistema: R1
Descripción del sistema:

Software Cisco IOS [Fuji], Software ISR (ARMV8EB_LINUX_IOSD-UNIVE
Soporte técnico: http://www.cisco.com/techsupport
Copyright (c) 1986-2018 por Cisco Systems,
Inc. Compilado Tue 27-Mar-18 10:56 por mcpre
Tiempo restante: 100 segundos
Capacidades del sistema: B,R
Capacidades habilitadas: R
Direcciones de gestión:
IP: 10.12.25.5
Negociación automática - no compatible
Capacidades de medios físicos - no anunciado
Tipo de unidad de conexión de medios - no
anunciado ID de Vlan: - no anunciado
Total de entradas mostradas: 1
En primer lugar, respecto a las capacidades del

dispositivo, observe que la salida del comando LLDP
muestra dos líneas sobre las capacidades del vecino:
Capacidades del sistema: Qué puede hacer el dispositivo
Capacidades habilitadas: Lo que el dispositivo

hace ahora con su configuración actual
Por ejemplo, en el Ejemplo 9-19, el vecino R1 afirma

tener la capacidad de realizar enrutamiento y
conmutación (códigos R y B), pero también afirma estar
utilizando actualmente sólo su
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
capacidad de enrutamiento, como se indica en la línea

"capacidades habilitadas".
También, tómese un momento para mirar la salida por

las similitudes con CDP. Por ejemplo, esta salida lista
detalles para el vecino, R1, que usa su puerto local
G0/0/1, con un nombre de host de R1. La salida también
anota el nombre y versión del IOS, de lo que una
persona experimentada puede inferir el número de
modelo, pero no hay mención explícita del modelo.
Nota
LLDP utiliza los mismos conceptos de mensajería que

CDP, encapsulando los mensajes directamente en las
cabeceras de los enlaces de datos. Los dispositivos no
reenvían mensajes LLDP, por lo que LLDP sólo
conoce a los vecinos conectados directamente. LLDP
utiliza una dirección MAC multicast diferente
(0180.C200.000E).
Configuración y verificación de LLDP

LLDP utiliza un modelo de configuración similar a
CDP, pero con algunas diferencias clave. En primer
lugar, los dispositivos Cisco desactivan LLDP por
defecto. Además, LLDP separa el envío y la recepción
de mensajes LLDP como funciones independientes.
Por ejemplo, el procesamiento de soporte LLDP recibe
mensajes LLDP en una interfaz para que el switch o
router aprenda sobre el dispositivo vecino mientras que
no
||||||||||||||||||||
||||||||||||||||||||
transmitir mensajes LLDP al dispositivo vecino. Para

soportar ese modelo, los comandos incluyen opciones
para activar o desactivar la transmisión de mensajes
LLDP de forma separada del procesamiento de los
mensajes recibidos.
Los tres comandos de configuración LLDP son los siguientes:
[no] lldp run: Un comando de configuración global que establece

el modo predeterminado de funcionamiento LLDP para cualquier
interfaz que no tenga subcomandos LLDP más específicos (lldp
transmit, lldp receive). El comando global lldp run habilita LLDP
en ambas direcciones en esas interfaces, mientras que no lldp run
deshabilita LLDP.
[no] lldp transmit: Un subcomando de interfaz que define el

funcionamiento de LLDP en la interfaz independientemente del
comando global [no] lldp run. El subcomando de interfaz lldp
transmit hace que el dispositivo transmita mensajes LLDP,
mientras que no lldp transmit hace que no transmita mensajes
LLDP.
[no] lldp receive: Un subcomando de interfaz que define el

funcionamiento de LLDP en la interfaz independientemente del
comando global [no] lldp run. El subcomando de interfaz lldp
receive hace que el dispositivo procese los mensajes LLDP
recibidos, mientras que no lldp receive hace que no procese los
mensajes LLDP recibidos.
Por ejemplo, considere un conmutador que no tiene

ningún comando de configuración LLDP. El Ejemplo 9-
20 agrega una configuración que primero habilita LLDP
para todas las interfaces (en ambas direcciones) con el
comando global lldp run. Luego muestra cómo
deshabilitar LLDP en ambas direcciones en Gi1/0/17 y
cómo deshabilitar LLDP en una dirección en Gi1/0/18.
Ejemplo 9-20 Activar LLDP en todos los puertos, desactivar

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
en algunos puertos
lldp run
¡!
interface gigabitEthernet1/0/17
no lldp transmit
no lldp receive
¡!
no lldp receive
El Ejemplo 9-21 agrega otro ejemplo que nuevamente

comienza con un switch con todas las configuraciones
por defecto. En este caso, la configuración no habilita
LLDP para todas las interfaces con el comando lldp
run, lo que significa que todas las interfaces por
defecto no transmiten ni reciben mensajes LLDP. El
ejemplo muestra cómo habilitar LLDP para ambas
direcciones en una interfaz y en una dirección para una
segunda interfaz.
Ejemplo 9-21 Activación de LLDP en puertos

limitados, dejando desactivado en la mayoría
lldp transmit
lldp recibir
¡!
lldp receive
Por último, para comprobar el estado de LLDP se utiliza exactamente la

misma
||||||||||||||||||||
||||||||||||||||||||
comandos como CDP como se indica en la Tabla 9-4,

aparte del hecho de que se utiliza la palabra clave lldp
en lugar de cdp. Por ejemplo, show lldp interface lista
las interfaces en las que LLDP está habilitado. El
Ejemplo 9-22 muestra algunos ejemplos del switch
SW2 basados en la Figura 9-8 anterior (la misma figura
usada en los ejemplos CDP), con LLDP habilitado en
ambas direcciones en todas las interfaces con el
comando cdp run global.
Ejemplo 9-22 Comandos show lldp que muestran el

estado de LLDP
SW2# show lldp

Información global LLDP:
Estado: ACTIVO
Los anuncios LLDP se envían cada 30 segundos El
tiempo de espera LLDP anunciado es de 120
segundos
El retardo de reinicialización de la interfaz LLDP
es de 2 segundos SW2# show lldp interface g1/0/2
GigabitEthernet1/0/2:
Tx: activado
Rx: activado
Estado Tx:
IDLE
Estado Rx: WAIT FOR FRAME
SW2# show lldp traffic
Estadísticas de tráfico
LLDP: Total tramas
out: 259 Entradas
totales envejecidas:
0 Tramas totales
entrantes: 257
Total de tramas recibidas por
error: 0 Total de tramas
descartadas: 0
Total TLVs descartados: 0
Total TLVs no
reconocidos: 0
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Además, tenga en cuenta que al igual que CDP, LLDP

utiliza un temporizador de envío y un temporizador de
espera para los mismos propósitos que CDP. El ejemplo
muestra la configuración por defecto de 30 segundos
para el temporizador de envío y 120 segundos para el
temporizador de espera. Puede anular los valores
predeterminados con los comandos globales lldp timer
seconds y lldp holdtime seconds, respectivamente.
detalles. En la Tabla 9-5 se describen los elementos de
repaso clave y dónde encontrarlos. Para hacer un mejor
seguimiento de su progreso en el estudio, registre
columna.

Elemento de revisiónFecha(s) de
revisión Recurso utilizado
Repasar los temas clave Libro, página

web
Repasar los términos clave Libro, página

web
Responder a las preguntas DIKTA Libro, PTP
||||||||||||||||||||
||||||||||||||||||||
Revisar las tablas de memoria Libro, aplicación
Laboratorios Blog
||||||||||||||||||||
||||||||||||||||||||
Revisar las referencias de los Reserve

comandos

Elemento Número
Figura 9-1 Registro en consola y terminal 175
Figura 9-2 Registro en syslog y buffer 176
Figura 9-3 Niveles de los mensajes de registro 177
Tabla 9-2 Registro de comandos de configuración 177
Lista El maestro ntp y el servidor ntp 183

comandos
Lista Secuencia para que el cliente NTP elija un 188

reloj de referencia
Lista Datos clave sobre las interfaces loopback 189
Lista Información recogida por CDP 190
Tabla 9-3 Tres comandos CDP show que listan 190

información sobre vecinos
Lista Diferencias entre LLDP y CDP 195
Lista Comandos y lógica de configuración LLDP 197
Technet24
||||||||||||||||||||
||||||||||||||||||||

mensaje de registro
servidor syslog
Protocolo de tiempo de red (NTP)
Cliente NTP
Modo cliente/servidor NTP
Servidor NTP
Sincronización NTP
CDP
LLDP
hace el comando.
Tabla 9-7 Referencia de comandos de configuración

||||||||||||||||||||
||||||||||||||||||||
[no] consola Comando global que habilita (o deshabilita con

de registro la opción no) el registro en el dispositivo de
consola.
[no] monitor Comando global que habilita (o deshabilita con

de registro la opción no) el registro a usuarios conectados
al dispositivo con SSH o Telnet.
[no] logging Comando global que habilita (o deshabilita con

buffered la opción no) el registro en un búfer interno.
logging Comando global que habilita el registro en un

[host] servidor syslog.
direcció
n ip |
nombre
de host
consola de Comando global que establece el nivel de mensaje

registro de registro para los mensajes de registro de la
nivel-nombre consola.
| nivel-
número
logging Comando global que establece el nivel de

monitor mensajes de registro para los mensajes de registro
level-name enviados a los usuarios de SSH y Telnet.
| level-
number
logging Comando global que establece el nivel de

buffered mensaje de registro para los mensajes de
nombre- registro almacenados en búfer que se muestran
nivel | posteriormente mediante el comando show
número-nivel logging.
logging trap Comando global que establece el nivel de

nombre- mensajes de registro para los mensajes enviados
nivel | a los servidores syslog.
número-nivel
[no] Comando global para activar o desactivar (con

números de la opción no) el uso de números de secuencia
secuencia en los mensajes de registro.
||||||||||||||||||||
||||||||||||||||||||
de servicio
Technet24
||||||||||||||||||||
||||||||||||||||||||
reloj zona Comando global que nombra una zona horaria y

horaria define el desfase +/- respecto a UTC.
nombre +-
número
reloj verano Comando global que nombra un horario de

nombre verano para una zona horaria e indica a IOS que
recurrente ajuste el reloj automáticamente.
dirección del Comando global que configura el dispositivo

servidor ntp | como cliente NTP haciendo referencia a la
nombre de dirección o nombre de un servidor NTP.
host
maestro ntp Comando global que configura el dispositivo

a nivel de como servidor NTP y asigna su nivel de estrato de
estrato reloj local.
fuente ntp Comando global que indica a NTP que utilice la

nombre/númer interfaz indicada (por nombre/número) para la
o dirección IP de origen de los mensajes NTP.
número Comando global que, en su primer uso, crea una

de interfaz loopback. En todos los usos, también
loopback mueve al usuario al modo de configuración de
de la interfaz para esa interfaz.
interfaz
[no] cdp run Comando global que habilita y deshabilita (con

la opción no) CDP para todo el switch o router.
[no] cdp Subcomando de interfaz para activar y

enable desactivar (con la opción no) CDP para una
interfaz concreta.
temporizador Comando global que cambia el envío CDP

cdp
||||||||||||||||||||
||||||||||||||||||||
segundos temporizador (la frecuencia con la que CDP envía

mensajes).
cdp Comando global que cambia el tiempo que CDP

holdtime espera desde el último mensaje recibido de un
segundos vecino antes de creer que el vecino ha fallado,
eliminando la información del vecino de la tabla
CDP.
[no] lldp run Comando global para activar y desactivar (con la

tecla
no option) LLDP para todo el switch o router.
[no] lldp Subcomando de interfaz para activar y

transmit desactivar (con la opción no) la transmisión de
mensajes LLDP en la interfaz.
[no] lldp Subcomando de interfaz para activar y

receive desactivar (con la opción no) el
procesamiento de los mensajes LLDP
recibidos en la interfaz.
temporizador Comando global que cambia el temporizador de

lldp envío LLDP (la frecuencia con la que LLDP
segundos envía mensajes).
lldp Comando global que cambia el tiempo que

holdtime LLDP espera desde el último mensaje recibido
segundos de un vecino antes de creer que el vecino ha
fallado, eliminando la información del vecino de
la tabla LLDP.
mostrar Muestra la configuración de registro actual y

registro enumera los mensajes de registro almacenados al
final.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
terminal Para una sesión de usuario (SSH o Telnet), activa

monitor (monitor de terminal) o desactiva (monitor de
terminal no no terminal) la recepción de mensajes de
monitor registro, para esa sesión, si el monitor de
registro también está configurado.
[no] depurar EXEC para activar o desactivar (con el comando no

{varios} opción) una de las múltiples opciones de depuración
mostrar reloj Indica la hora y la fecha del dispositivo local
mostrar Muestra todos los clientes y servidores NTP con los

asociaciones que el dispositivo local está intentando sincronizarse
ntp con NTP
mostrar Muestra en detalle el estado actual del cliente NTP

estado
ntp
show Muestra el estado actual de la interfaz

interfaces loopback listada
loopback
number
show cdp Enumera una línea de resumen de información

| lldp sobre cada vecino; opcionalmente, enumera los
neighbors vecinos fuera de la interfaz enumerada.
[número
de tipo]
show cdp Enumera un gran conjunto de información

| lldp (aproximadamente 15 líneas) para cada vecino
neighbors
detail
show cdp Muestra la misma información que show

| lldp cdp|lldp neighbors detail pero sólo para el
entry vecino nombrado
name
||||||||||||||||||||
||||||||||||||||||||
show cdp Indica si CDP o LLDP está habilitado globalmente

| lldp y enumera los temporizadores de actualización y
espera predeterminados.
show cdp Indica si CDP o LDP está activado en cada

| lldp interfaz o en una sola interfaz si la interfaz
interfaz está en la lista.
[número
de tipo]
show cdp Muestra estadísticas globales del número de

| lldp anuncios CDP o LDP enviados y recibidos
traffic
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Capítulo 10. Traducción de

direcciones de red
4.0 Servicios IP
4.1 Configurar y verificar NAT de origen interno usando
estática y pools
Este capítulo examina una parte muy popular e

importante de las redes tanto empresariales como de
pequeñas oficinas/oficinas domésticas (SOHO): La
Traducción de Direcciones de Red, o NAT. NAT ayudó
a resolver un gran problema con IPv4: el espacio de
direcciones IPv4 se habría consumido por completo a
mediados de los noventa. Una vez consumido, Internet
no podría seguir creciendo, lo que habría ralentizado
considerablemente su desarrollo.
Este capítulo divide los temas en tres secciones

principales. La primera sección explica los desafíos al
espacio de direcciones IPv4 causados por la revolución
de Internet de los 90. La segunda sección explica el
concepto básico detrás de NAT, cómo funcionan varias
variaciones de NAT, y cómo la opción Port Address
Translation (PAT) conserva el espacio de direcciones
IPv4. La última sección muestra cómo configurar NAT
desde el Cisco IOS
||||||||||||||||||||
||||||||||||||||||||
Interfaz de línea de comandos (CLI) del software y

cómo solucionar problemas de NAT.


Perspectivas sobre la escalabilidad de las direcciones 1-2

IPv4
Conceptos de traducción de direcciones de red 3-4
Configuración y resolución de problemas de NAT 5-7
1. ¿Cuál de las siguientes subredes resumidas

representa rutas que podrían haberse creado para
el objetivo de CIDR de reducir el tamaño de las
tablas de enrutamiento de Internet?
1. 10.0.0.0 255.255.255.0
2. 10.1.0.0 255.255.0.0
3. 200.1.1.0 255.255.255.0
4. 200.1.0.0 255.255.0.0
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
2. ¿Cuáles de las siguientes no son direcciones

privadas según el RFC 1918? (Elija dos
respuestas.)
1. 172.31.1.1
2. 172.33.1.1
3. 10.255.1.1
4. 10.1.255.1
5. 191.168.1.1
3. Con NAT estática, que realiza la traducción sólo

para direcciones internas, ¿qué provoca la creación
de entradas en la tabla NAT?
1. El primer paquete de la red interior a la red exterior
2. El primer paquete de la red exterior a la red interior
3. Configuración mediante el comando ip nat inside source
4. Configuración mediante el comando ip nat outside source
4. Con NAT dinámico, que realiza la traducción sólo

para direcciones internas, ¿qué provoca la creación
de entradas en la tabla NAT?
1. El primer paquete de la red interior a la red exterior
2. El primer paquete de la red exterior a la red interior
3. Configuración mediante el comando ip nat inside source
4. Configuración mediante el comando ip nat outside source
5. Se ha configurado NAT para traducir las direcciones

de origen de los paquetes para la parte interna de la
red, pero sólo para algunos hosts identificados por
una lista de control de acceso. ¿Cuál de los
siguientes comandos identifica indirectamente los
hosts?
1. ip nat inside source list 1 pool barney
2. ip nat pool barney 200.1.1.1 200.1.1.254 máscara de red
255.255.255.0
3. ip nat inside
4. ip nat inside 200.1.1.1 200.1.1.2
||||||||||||||||||||
||||||||||||||||||||
6. Examine los siguientes comandos de

configuración: Haga clic aquí para ver la
imagen del código
interfaz Ethernet0/0
dirección ip 10.1.1.1
255.255.255.0 ip nat inside
interfaz Serial0/0
dirección ip 200.1.1.249 255.255.255.252
ip nat inside source list 1 interface
Serial0/0 access-list 1 permit 10.1.1.0
0.0.0.255
Si la configuración pretende habilitar la sobrecarga

NAT de origen, ¿cuál de los siguientes comandos
podría ser útil para completar la configuración?
1. El comando ip nat outside
2. El comando ip nat pat
3. La palabra clave de sobrecarga
4. El comando ip nat pool
7. Examine la siguiente salida del comando show en

un router configurado para NAT dinámico:
-- Inside Source
access-list 1 pool fred refcount 2288
pool fred: netmask 255.255.255.240
start 200.1.1.1 end 200.1.1.7
tipo genérico, total direcciones 7, asignadas 7 (100%), fallos
96
Los usuarios se quejan de que no pueden conectarse a

Internet. ¿Cuál de las siguientes es la causa más
probable?
1. El problema no está relacionado con NAT, según la información
de la salida del comando.
2. El pool NAT no tiene suficientes entradas para satisfacer todas las peticiones.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
3. No se puede utilizar la ACL 1 estándar; se debe utilizar una ACL ampliada.

4. La salida del comando no proporciona suficiente
información para identificar el problema.
1D
2 B, E
3C
4 A
5A
6 A, C
7B
Temas básicos
PERSPECTIVAS SOBRE LA
ESCALABILIDAD DE LAS DIRECCIONES
IPV4
El diseño original de Internet exigía que cada
organización solicitara, y recibiera, uno o más números
de red IPv4 de clase completa registrados. Los
administradores del programa se aseguraron de que no
se reutilizara ninguna de las redes IP. Mientras cada
organización utilizara sólo direcciones IP dentro de sus
propios números de red registrados, las direcciones IP
nunca se duplicarían y el enrutamiento IP podría
funcionar bien.
||||||||||||||||||||
||||||||||||||||||||
Conectarse a Internet utilizando sólo un número de red

registrado, o varios números de red registrados, funcionó
bien durante un tiempo. Entre principios y mediados de
los noventa, se hizo evidente que Internet estaba
creciendo tan rápido que todos los números de red IP
estarían asignados a mediados de los noventa. Surgió la
preocupación de que las redes disponibles se asignarían
por completo y algunas organizaciones no podrían
conectarse a Internet.
La principal solución a largo plazo para el problema de

escalabilidad de las direcciones IPv4 era aumentar el
tamaño de la dirección IP. Este hecho fue la razón más
convincente para la llegada de la versión 6 de IP (IPv6).
(La versión 5 se definió mucho antes, pero nunca llegó a
implantarse, por lo que el siguiente intento se etiquetó
como versión 6). IPv6 utiliza una dirección de 128 bits,
en lugar de la de 32 bits de IPv4. Con el mismo o
mejorado proceso de asignación de rangos de
direcciones únicos a cada organización conectada a
Internet, IPv6 puede dar soporte fácilmente a todas las
organizaciones e individuos del planeta, con un número
de direcciones IPv6 que teóricamente superará los 1038 .
Se sugirieron muchas soluciones a corto plazo para el

problema del direccionamiento, pero tres normas
trabajaron juntas para resolver el problema. Dos de ellas
están estrechamente relacionadas: Traducción de
direcciones de red (NAT) y direccionamiento privado.
Estas características juntas permiten a muchas
organizaciones utilizar internamente los mismos
números de red IPv4 no registrados y seguir
comunicándose bien con Internet. La tercera norma, el
interdominio sin clases
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
(CIDR), permite a los ISP reducir el despilfarro de

direcciones IPv4 asignando a una empresa un
subconjunto de un número de red en lugar de toda la
red. CIDR también puede permitir a los proveedores de
servicios de Internet (ISP) resumir rutas de forma que
varias redes de clase A, B o C coincidan con una única
ruta, lo que ayuda a reducir el tamaño de las tablas de
enrutamiento de Internet.
Nota
Estas herramientas han funcionado bien. Las

estimaciones de principios de los 90 predecían que el
mundo se quedaría sin direcciones IPv4 a mediados
de esa década, pero IANA no agotó el espacio de
direcciones IPv4 hasta febrero de 2011, y ARIN (el
RIR para Norteamérica) no agotó su suministro de
direcciones IPv4 públicas hasta septiembre de 2015.
CIDR
CIDR es una convención global de asignación de
direcciones que define el modo en que la Autoridad de
Asignación de Números de Internet (IANA), sus
organismos miembros y los ISP deben asignar el espacio
de direcciones IPv4 único en el mundo a las distintas
organizaciones.
CIDR, definido en RFC 4632, tiene dos objetivos

principales. En primer lugar, CIDR define una forma de
asignar direcciones IP públicas, en todo el mundo, para
permitir la agregación de rutas o la ruta
||||||||||||||||||||
||||||||||||||||||||
resumen. Estos resúmenes de rutas reducen

enormemente el tamaño de las tablas de enrutamiento
de los routers de Internet.
La Figura 10-1 muestra un caso típico de agregación de

rutas CIDR y cómo CIDR podría utilizarse para
reemplazar más de 65.000 rutas con una sola ruta. En
primer lugar, imaginemos que el ISP 1 posee las redes
de Clase C 198.0.0.0 a 198.255.255.0, no por accidente,
sino por un diseño intencionado y meditado para hacer
posible este ejemplo de agregación de rutas. En otras
palabras, IANA asignó todas las direcciones que
empiezan por 198 a uno de los cinco Registros
Regionales de Internet (RIR), y ese RIR asignó todo este
rango a un gran ISP de esa parte del mundo.
Figura 10-1 Uso típico de CIDR
La asignación de todas las direcciones que empiezan

por 198 a un ISP permite a otros ISPs utilizar una ruta -
una ruta para 198.0.0.0/8 - para coincidir con todas
esas direcciones, reenviando paquetes para esas
direcciones al ISP1. La Figura 10-1 muestra los ISPs de
la izquierda, cada uno con una ruta a 198.0.0.0/8 - en
otras palabras, una ruta a todos los hosts cuya
dirección IP empieza por 198. Esta única ruta resumida
||||||||||||||||||||
coincidirá con todas las direcciones IP de los ISPs de la
||||||||||||||||||||
izquierda. Esta ruta resumen coincidirá con
Technet24
||||||||||||||||||||
||||||||||||||||||||
paquetes enviados a todas las direcciones de las 65.536

redes IP de Clase C que empiezan por 198.
La segunda característica importante de CIDR permite

a los RIR e ISP reducir el desperdicio asignando un
subconjunto de una red classful a un solo cliente. Por
ejemplo, imaginemos que el cliente A del ISP1 necesita
sólo 10 direcciones IP y que el cliente C necesita 25
direcciones IP. El ISP1 hace algo así
Asigna al cliente A el bloque CIDR 198.8.3.16/28, con 14
direcciones asignables (198.8.3.17 a 198.8.3.30).
Asigna al cliente B el bloque CIDR 198.8.3.32/27, con 30

direcciones asignables (198.8.3.33 a 198.8.3.62).
Estos bloques CIDR de actúan de forma muy parecida a

una red IP pública; en concreto, proporcionan a cada
empresa un conjunto consecutivo de direcciones IPv4
públicas para su uso. El proceso de asignación de
direcciones públicas también tiene mucho menos
desperdicio que antes. De hecho, la mayoría de las
asignaciones de direcciones públicas de los últimos 20
años han sido un bloque CIDR en lugar de toda una red
de clase A, B o C.
Direccionamiento privado
Es posible que algunos ordenadores nunca estén
conectados a Internet. Las direcciones IP de estos
ordenadores podrían ser duplicados de direcciones IP
registradas en Internet. Al diseñar la convención de
direccionamiento IP para una red de este tipo, una
organización podría elegir y utilizar cualquier número(s)
de red que quisiera, y todo iría bien. Por ejemplo, puedes
comprar unos cuantos routers, conectarlos en tu oficina,
||||||||||||||||||||
||||||||||||||||||||
y configurar direcciones IP en la red 1.0.0.0, y

funcionaría. Las direcciones IP que utilices podrían ser
duplicados de direcciones IP reales en Internet, pero si
lo único que quieres es aprender en el laboratorio de tu
oficina, todo irá bien.
Cuando se construye una red privada que no tendrá

conectividad a Internet, se pueden utilizar números de
red IP denominados internets privados, tal y como se
define en el RFC 1918, "Address Allocation for Private
Internets". Este RFC define un conjunto de redes que
nunca serán asignadas a ninguna organización como
número de red registrado.
En lugar de utilizar los números de red registrados de
otra persona, puede utilizar números en un rango que
no son utilizados por nadie más en la Internet pública.
La Tabla 10-2 muestra el espacio de direcciones
privadas definido por RFC 1918.
Tabla 10-2 Espacio de direcciones privadas RFC 1918
Rango de red (es) IP Clase de

Númerode direcciones Redes
Redes
10.0.0.0 a 10.0.0.0 A 1
10.255.255.255
172.16.0.0 a 172.16.0.0 - B 16
172.31.255.255 172.31.0.0
192.168.0.0 a 192.168.0.0 - C 256

192.168.255.255 192.168.255.0
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
En otras palabras, cualquier organización puede utilizar

estos números de red. Sin embargo, ninguna
organización está autorizada a anunciar estas redes
mediante un protocolo de encaminamiento en Internet.
La Tabla 10-3 resume estas importantes características

que han ayudado a prolongar la vida de IPv4 durante
décadas.
Tabla 10-3 Tres funciones importantes que

prolongaron la vida de IPv4
Función RFC(s) Principales ventajas
R*
CID 4632 Asignar a las empresas bloques de direcciones
IPv4 públicas más específicas que las redes de
clase A, B y C.
Agregue rutas a direcciones IPv4 públicas
basadas en el plan mundial de asignación de
direcciones.
NAT*
3022 Permite soportar aproximadamente 65.000
sesiones TCP/UDP con una única dirección
IPv4 pública.
Redes 1918 Habilitar el uso de NAT para las conexiones

privadas a Internet de la empresa, con direcciones
privadas utilizadas dentro de la empresa.
*CIDR y NAT pueden ser más conocidos por sus RFC originales (1518,
1519 para CIDR; 1631 para NAT).
CONCEPTOS DE TRADUCCIÓN DE
DIRECCIONES DE RED
NAT, definido en RFC 3022, permite que un host que
no tiene una dirección IP válida, registrada y única en el
mundo pueda
||||||||||||||||||||
||||||||||||||||||||
comunicarse con otros hosts a través de Internet. Los

hosts pueden estar utilizando direcciones privadas o
direcciones asignadas a otra organización. En cualquier
caso, NAT permite que estas direcciones que no están
preparadas para Internet sigan utilizándose y permite la
comunicación con hosts a través de Internet.
NAT consigue su objetivo utilizando una dirección IP

registrada válida para representar la dirección privada
ante el resto de Internet. La función NAT cambia las
direcciones IP privadas por direcciones IP registradas
públicamente dentro de cada paquete IP, como se
muestra en la Figura 10-2.
Figura 10-2 NAT Intercambio de Direcciones IP:

Direccionamiento privado
Observe que el router, al realizar NAT, cambia el
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
la dirección IP de origen del paquete cuando éste sale

de la organización privada. El router que realiza NAT
también cambia la dirección de destino en cada paquete
que se reenvía de vuelta a la red privada. (La red
200.1.1.0 es una red registrada en la Figura 10-2.) La
función NAT, configurada en el router con la etiqueta
NAT, realiza la traducción.
Este libro trata sobre source NAT, que es el tipo de NAT

que permite a las empresas utilizar direcciones privadas
y seguir comunicándose con hosts en Internet. Dentro de
source NAT, Cisco IOS soporta varias formas diferentes
de configurar NAT. Las siguientes páginas cubren los
conceptos detrás de algunas de estas variaciones.
NAT estático
La NAT estática funciona igual que el ejemplo mostrado
en la Figura 10-2, pero con las direcciones IP mapeadas
estáticamente entre sí. Para ayudarte a entender las
implicaciones de la NAT estática y explicar varios
términos clave, la Figura 10-3 muestra un ejemplo
similar con más información.
||||||||||||||||||||
||||||||||||||||||||
Figura 10-3 NAT estática con direcciones internas

locales y globales
Primero, los conceptos: El ISP de la empresa le ha

asignado la red registrada 200.1.1.0. Por lo tanto, el
router NAT debe hacer que las direcciones IP privadas
parezcan estar en la red 200.1.1.0. Para ello, el router
NAT cambia las direcciones IP de origen en los
paquetes que van de izquierda a derecha en la figura.
En este ejemplo, el router NAT cambia la dirección de

origen (SA en la figura) de 10.1.1.1 a 200.1.1.1. Con la
NAT estática, el router NAT simplemente configura un
mapeo uno a uno entre la dirección privada y la
dirección registrada que se utiliza en su nombre. El
router NAT ha configurado estáticamente un mapeo
entre la dirección privada 10.1.1.1 y la dirección
pública registrada 200.1.1.1.
El soporte de un segundo host IP con NAT estático requiere un
Technet24
||||||||||||||||||||
||||||||||||||||||||
segundo mapeo estático uno a uno utilizando una

segunda dirección IP en el rango de direcciones
públicas. Por ejemplo, para soportar 10.1.1.2, el router
asigna estáticamente 10.1.1.2 a
200.1.1.2. Dado que la empresa dispone de una única
red de clase C registrada, puede admitir un máximo de
254 direcciones IP privadas con NAT, con los dos
números reservados habituales (el número de red y la
dirección de difusión de red).
La terminología utilizada con NAT, particularmente con

la configuración, puede ser un poco confusa. Observa
en la Figura 10-3 que la tabla NAT lista las direcciones
IP privadas como "privadas" y las direcciones públicas
registradas de la red 200.1.1.0 como "públicas". Cisco
utiliza el término inside local para las direcciones IP
privadas en este ejemplo y inside global para las
direcciones IP públicas.
Utilizando la terminología NAT, la red de la empresa

que utiliza direcciones privadas y, por tanto, necesita
NAT, es la parte "interior" de la red. El lado de Internet
de la función NAT es la parte "exterior" de la red. Un
host que necesita NAT (como 10.1.1.1 en el ejemplo)
tiene la dirección IP que utiliza dentro de la red, y
necesita una dirección IP que lo represente en la red
exterior. Por tanto, como el host necesita esencialmente
dos direcciones diferentes para representarlo, se
necesitan dos términos. Cisco llama a la dirección IP
privada utilizada en la red interna la dirección local
interna y a la dirección utilizada para representar al host
ante el resto de Internet la dirección global interna. La
Figura 10-4 repite el mismo ejemplo, con
||||||||||||||||||||
||||||||||||||||||||
parte de la terminología mostrada.
Figura 10-4 Terminología de NAT estático
Source NAT sólo cambia la dirección IP de los hosts

internos. Por lo tanto, la tabla NAT actual mostrada en
la Figura 10-4 muestra las direcciones registradas dentro
local y dentro global correspondientes. El término inside
local se refiere a la dirección utilizada para el host
dentro de la empresa, la dirección utilizada localmente
en lugar de globalmente, lo que significa en la empresa
en lugar de la Internet global. Por el contrario, el
término inside global todavía se refiere a una dirección
usada para el host dentro de la empresa, pero es la
dirección global usada mientras el paquete fluye a través
de Internet.
Tenga en cuenta que la función NAT llamada NAT de

destino, no tratada en este libro, utiliza términos
similares fuera local y fuera global. Sin embargo, con
NAT de origen, uno de los
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
términos, fuera global, se utiliza. Este término se

refiere al host que reside fuera de la empresa. Como la
NAT de origen no cambia esa dirección, el término
outside global se aplica en todo momento.
La Tabla 10-4 resume estos cuatro términos similares y

se refiere a las direcciones IPv4 utilizadas como
muestra en las tres últimas figuras a modo de ejemplo.
Tabla 10-4 Términos de direccionamiento NAT
TermValues en Significado
Cifras
Dentro 10.1.1.1 Interior: Se refiere a la ubicación

de local permanente del host, desde la perspectiva
de la empresa: está dentro de la empresa.
Local: Significa no global; es decir, local.
Es la dirección utilizada para ese host
mientras el paquete fluye en la empresa
local y no en la Internet global.
Alternativa: Piense en ello como privado
interior, porque esta dirección es
típicamente una dirección privada.
En todo 200.1.1.1 Interior: Se refiere a la ubicación

el mundo permanente del host, desde la perspectiva de
la empresa. Global: Significa global como
en la
Internet. Es la dirección utilizada para ese
host
mientras el paquete circula por Internet.
Alternativa: Piense en ello como dentro de
público, porque la dirección es típicamente un
IPv4 pública
dirección.
||||||||||||||||||||
||||||||||||||||||||
Global 170.1.1.1 Con NAT de origen, la única dirección

exterior utilizada por el host que reside fuera de la
empresa, que NAT no cambia, por lo que no
hay necesidad de un término de contraste.
Alternativa: Piense en ello como público
exterior, porque la dirección es típicamente
una dirección IPv4 pública.
Local - Este término no se utiliza con NAT de origen.

exterior Con NAT de destino, la dirección
representaría a un host que reside fuera de la
empresa, pero la dirección utilizada para
representar a ese host cuando los paquetes
pasan a través de la empresa local.
NAT dinámico
La NAT dinámica presenta algunas similitudes y
diferencias con respecto a la NAT estática. Al igual que
la NAT estática, el router NAT crea un mapeo uno a uno
entre una dirección local interna y una dirección global
interna, y cambia las direcciones IP en los paquetes a
medida que salen y entran en la red interna.
Sin embargo, la asignación de una dirección local
interna a una dirección global interna se produce de
forma dinámica.
La NAT dinámica establece un conjunto de posibles

direcciones IP internas globales y define criterios de
coincidencia para determinar qué direcciones IP internas
locales deben traducirse con NAT. Por ejemplo, en la
Figura 10-5, se ha establecido un grupo de cinco
direcciones IP internas globales: 200.1.1.1 a 200.1.1.5.
También se ha configurado NAT para traducir cualquier
dirección interna local que empiece por 10.1.1. NAT
también ha sido configurado para traducir cualquier
||||||||||||||||||||
dirección local interna que comience con 10.1.1.
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 10-5 NAT dinámico
Los números 1, 2, 3 y 4 de la figura se refieren a la

siguiente secuencia de acontecimientos:
1. El host 10.1.1.1 envía su primer paquete al servidor en 170.1.1.1.
2. Cuando el paquete entra en el router NAT, éste aplica cierta lógica de
coincidencia para decidir si se debe aplicar NAT al paquete. Como la
lógica se ha configurado para que coincida con las direcciones IP de
origen que empiezan por 10.1.1, el router añade una entrada en la tabla
NAT para 10.1.1.1 como una dirección local interna.
3. El router NAT necesita asignar una dirección IP del conjunto de

direcciones globales internas válidas. Elige la primera disponible
(200.1.1.1, en este caso) y la añade a la tabla NAT para completar
la entrada.
4. El router NAT traduce la dirección IP de origen y reenvía el
paquete.
La entrada dinámica permanece en la tabla mientras el

tráfico fluya ocasionalmente. Puede configurar un valor de
tiempo de espera
||||||||||||||||||||
||||||||||||||||||||
que define cuánto tiempo debe esperar el router, sin

haber traducido ningún paquete con esa dirección,
antes de eliminar la entrada dinámica. También puedes
borrar manualmente las entradas dinámicas de la tabla
utilizando el comando clear ip nat translation *.
NAT puede configurarse con más direcciones IP en la

lista de direcciones locales internas que en el pool de
direcciones globales internas. El router asigna
direcciones del pool hasta que todas están asignadas. Si
llega un nuevo paquete desde otro host interno, y
necesita una entrada NAT, pero todas las direcciones IP
del pool están en uso, el router simplemente descarta el
paquete. El usuario debe intentarlo de nuevo hasta que
una entrada NAT se agote, momento en el que la función
NAT funciona para el siguiente host que envíe un
paquete. Esencialmente, el pool global de direcciones
interno necesita ser tan grande como el número máximo
de hosts concurrentes que necesitan usar Internet al
mismo tiempo, a menos que uses PAT, como se explica
en la siguiente sección.
Sobrecarga de NAT con traducción

de direcciones de puerto
Algunas redes necesitan que la mayoría, si no todos, los
hosts IP lleguen a Internet. Si esa red utiliza direcciones
IP privadas, el router NAT necesita un conjunto muy
grande de direcciones IP registradas. Con la NAT
estática, por cada host IP privado que necesite acceso a
Internet, se necesita una dirección IP registrada
públicamente, lo que anula por completo el objetivo de
reducir el número de direcciones IPv4 públicas
necesarias para
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
esa organización. La NAT dinámica disminuye el

problema hasta cierto punto, porque cada host de una red
interna rara vez necesitará comunicarse con Internet al
mismo tiempo. Sin embargo, si un gran porcentaje de los
hosts IP de una red van a necesitar acceso a Internet
durante todo el horario laboral normal de esa empresa,
NAT sigue necesitando un gran número de direcciones
IP registradas, con lo que tampoco se consigue reducir el
consumo de direcciones IPv4.
La función NAT Overload, también llamada Port

Address Translation (PAT), resuelve este problema. La
sobrecarga permite a NAT escalar para soportar
muchos clientes con sólo unas pocas direcciones IP
públicas.
La clave para entender cómo funciona la sobrecarga es

recordar cómo los hosts utilizan los puertos TCP y del
Protocolo de Datagramas de Usuario (UDP). Para ver
por qué, primero considere la idea de tres conexiones
TCP separadas a un servidor web, desde tres hosts
diferentes, como se muestra en la Figura 10-6.
Figura 10-6 Tres conexiones TCP desde tres PCs
A continuación, compare esas tres conexiones TCP de la

Figura 10-6 con otras tres conexiones TCP similares,
ahora con las tres
||||||||||||||||||||
||||||||||||||||||||
Conexiones TCP desde un cliente, como se muestra en la Figura 10-.

7. El servidor se da cuenta de la diferencia porque ve la
dirección IP y el número de puerto TCP utilizados por
los clientes en ambas figuras. Sin embargo, al servidor
realmente no le importa si las conexiones TCP
provienen de hosts diferentes o del mismo host; el
servidor sólo envía y recibe datos a través de cada
conexión.
Figura 10-7 Tres conexiones TCP desde un PC
NAT aprovecha el hecho de que, desde la perspectiva de

la capa de transporte, al servidor no le importa si tiene
una conexión cada uno a tres hosts diferentes o tres
conexiones a una única dirección IP de host. La
sobrecarga NAT (PAT) traduce no sólo la dirección, sino
también el número de puerto cuando es necesario,
haciendo que lo que parecen muchos flujos TCP o UDP
de diferentes hosts parezcan el mismo número de flujos
de un host. La Figura 10-8 describe la lógica.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Figura 10-8 Sobrecarga NAT (PAT)
Cuando PAT crea el mapeo dinámico, selecciona no sólo

una dirección IP interna global, sino también un número
de puerto único para usar con esa dirección. El router
NAT mantiene una entrada en la tabla NAT para cada
combinación única de dirección IP local interna y puerto,
con traducción a la dirección global interna y un número
de puerto único asociado a la dirección global interna. Y
como el campo del número de puerto tiene 16 bits, la
sobrecarga NAT puede utilizar más de 65.000 números
de puerto, lo que le permite escalar bien sin necesidad de
muchas direcciones IP registradas; en muchos casos,
sólo necesita una dirección IP interna global.
De los tres tipos de NAT cubiertos hasta ahora en este

capítulo, PAT es con diferencia la opción más popular.
Tanto Static NAT como Dynamic NAT requieren un
mapeo uno a uno de
||||||||||||||||||||
||||||||||||||||||||
la dirección local interna a la dirección global interna.

PAT reduce significativamente el número de
direcciones IP registradas necesarias en comparación
con estas otras alternativas NAT.
CONFIGURACIÓN Y SOLUCIÓN DE
PROBLEMAS DE NAT
Las siguientes secciones describen cómo configurar las
tres variaciones más comunes de NAT: NAT estática,
NAT dinámica y PAT, junto con los comandos show y
debug utilizados para solucionar problemas de NAT.
Configuración NAT estática

La configuración de NAT estática sólo requiere unos
pocos pasos de configuración. Cada asignación estática
entre una dirección local (privada) y una dirección global
(pública) debe ser configurada. Además, dado que NAT
puede utilizarse en un subconjunto de interfaces, debe
indicarse al router en qué interfaces debe utilizar NAT.
Esos mismos subcomandos de interfaz indican a NAT si
la interfaz es interior o exterior. Los pasos específicos
son los siguientes:
Paso 1. Utilice el comando ip nat inside en el modo

de configuración de interfaz para configurar
las interfaces para que estén en la parte
interior del diseño NAT.
Paso 2. Utilice el comando ip nat outside en el
modo de configuración de interfaz para
configurar las interfaces que estarán en la
parte exterior del diseño NAT.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Paso 3. Utilice el comando ip nat inside source

static inside- local inside-global en el modo
de configuración global para configurar las
asignaciones estáticas.
La Figura 10-9 muestra la red familiar utilizada en la
descripción de NAT estático anterior en este capítulo,
que también se utiliza para los primeros ejemplos de
configuración. En la Figura 10-9, puede ver que
Certskills ha obtenido la red Clase C 200.1.1.0 como
número de red registrado. Toda esa red, con máscara
255.255.255.0, está configurada en el enlace serie entre
Certskills e Internet. Con un enlace serie punto a punto,
sólo se consumen dos de las 254 direcciones IP válidas
de esa red, quedando 252 direcciones.
Figura 10-9 Ejemplo de red para NAT, con clase

pública C 200.1.1.0/24
A la hora de planificar una configuración NAT, debe encontrar algún
||||||||||||||||||||
||||||||||||||||||||
Direcciones IP para usar como direcciones IP globales

internas. Dado que estas direcciones deben formar parte
de algún rango de direcciones IP registrado, es habitual
utilizar las direcciones adicionales de la subred que
conecta la empresa a Internet; por ejemplo, las 252
direcciones IP adicionales de la red
200.1.1.0 en este caso. El router también se puede
configurar con una interfaz loopback y asignarle una
dirección IP que forme parte de un rango único global
de direcciones IP registradas.
El Ejemplo 10-1 muestra la configuración NAT, utilizando

200.1.1.1 y 200.1.1.2 para las dos asignaciones NAT
estáticas.
Ejemplo 10-1 Configuración de NAT estático

imagen del código
NAT# show running-config
¡!
¡!
interfaz GigabitEthernet0/0
¡!
interfaz Serial0/0/0
dirección ip 200.1.1.251 255.255.255.0
ip nat outside
¡!
ip nat inside source static 10.1.1.2 200.1.1.2
ip nat inside source static 10.1.1.1 200.1.1.1
NAT# show ip nat translations

Pro En todo el Dentro de Local En el
--- mundo local exterior exterior
--- 200.1.1.1 10.1.1.1 --- ---
200.1.1.2 10.1.1.2 --- ---
NAT# show ip nat statistics
Total de traducciones activas: 2 (2 estáticas, 0 dinámicas; 0
extendidas) Interfaces externas:
Serial0/0/0
Interfaces
interiores:
GigabitEthernet0/0
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Aciertos: 100 Fallos: 0

Traducciones caducadas: 0
Asignaciones dinámicas:
Las asignaciones estáticas se crean utilizando el

comando ip nat inside source static. La palabra clave
inside significa que NAT traduce direcciones para
hosts en la parte interna de la red. La palabra clave
source significa que NAT traduce la dirección IP de
origen de los paquetes que llegan a sus interfaces
interiores. La palabra clave static significa que los
parámetros definen una entrada estática, que nunca debe
ser eliminada de la tabla NAT debido al tiempo de
espera.
Como el diseño requiere que dos hosts-10.1.1.1 y
10.1.1.2-tengan acceso a Internet, se necesitan dos
comandos ip nat inside.
Después de crear las entradas NAT estáticas, el router

necesita saber qué interfaces son "inside" y cuáles son
"outside". Los subcomandos de interfaz ip nat inside e
ip nat outside identifican cada interfaz apropiadamente.
Un par de comandos show listan la información más

importante sobre NAT. El comando show ip nat
translations lista las dos entradas NAT estáticas creadas
en la configuración. El comando show ip nat statistics
muestra estadísticas, como el número de entradas
activas en la tabla de traducción. Las estadísticas
también incluyen el número de hits, que se incrementa
por cada paquete para el que NAT debe traducir
direcciones.
||||||||||||||||||||
||||||||||||||||||||
Configuración NAT dinámica

Como puedes imaginar, la configuración de NAT
dinámica difiere en algunos aspectos de la NAT estática,
pero también tiene algunas similitudes. La NAT
dinámica sigue requiriendo que cada interfaz se
identifique como una interfaz interior o exterior, y por
supuesto ya no es necesario el mapeo estático. La NAT
dinámica utiliza una lista de control de acceso (ACL)
para identificar qué direcciones IP internas locales
(privadas) necesitan que se traduzcan sus direcciones, y
define un conjunto de direcciones IP públicas
registradas para asignar. Los pasos específicos son los
siguientes:
Paso 1. Utilice el comando ip nat inside en el modo

de configuración de interfaz para configurar
las interfaces para que estén en la parte
interior del diseño NAT (igual que con NAT
estática).
Paso 2. Utilice el comando ip nat outside en el
modo de configuración de interfaz para
configurar las interfaces para que estén en la
parte exterior del diseño NAT (igual que con
NAT estática).
Paso 3. Configurar una ACL Configure una ACL
que coincida con los paquetes que entran en
las interfaces interiores para las que se debe
realizar NAT.
Paso 4. Utilice el comando ip nat pool name first-
address last- address netmask subnet-mask
||||||||||||||||||||
||||||||||||||||||||
en el modo de configuración global para

configurar el grupo de direcciones IP
públicas registradas.
Technet24
||||||||||||||||||||
||||||||||||||||||||
Paso 5. Utilice el comando ip nat inside source list

acl- number pool pool-name en el modo de
configuración global para activar la NAT
dinámica. Tenga en cuenta que el comando
hace referencia a la ACL (paso 3) y al pool
(paso 4) según los pasos anteriores.
El siguiente ejemplo muestra una configuración NAT
dinámica de ejemplo utilizando la misma topología de
red que el ejemplo anterior (ver Figura 10-9). En este
caso, las mismas dos direcciones locales internas-10.1.1.1 y
10.1.1.2- necesitan traducción. Sin embargo, a diferencia
del ejemplo anterior de NAT estática, la configuración
del Ejemplo 10-2 coloca las direcciones IP públicas
(200.1.1.1 y 200.1.1.2) en un grupo de direcciones
globales internas asignables dinámicamente.
Ejemplo 10-2 Configuración NAT dinámica

imagen del código
¡!
¡!
¡!
dirección ip 200.1.1.251 255.255.255.0
ip nat outside
¡!
ip nat pool fred 200.1.1.1 200.1.1.2 netmask
255.255.255.252 ip nat inside source list 1 pool fred
¡!
La NAT dinámica configura el grupo de conexiones públicas (globales).
||||||||||||||||||||
||||||||||||||||||||
con el comando ip nat pool listando el primer y último

número en un rango inclusivo de direcciones globales
internas. Por ejemplo, si el pool necesitara 10
direcciones, el comando podría haber listado 200.1.1.1 y
200.1.1.10, lo que significa que NAT puede usar de
200.1.1.1 a 200.1.1.10.
Dynamic NAT también realiza una comprobación de

verificación en el comando ip nat pool con el parámetro
de máscara de red requerido. Si el rango de direcciones
no estuviera en la misma subred, suponiendo que la
máscara de red configurada se utilizara en las
direcciones del rango configurado, entonces IOS
rechazará el comando ip nat pool. Por ejemplo, como se
configura con el extremo inferior de 200.1.1.1, extremo
superior de 200.1.1.2, y una máscara de
255.255.255.252, IOS utilizaría las siguientes
comprobaciones, para asegurar que ambos cálculos
ponen
200.1.1.1 y 200.1.1.2 en la misma subred:
200.1.1.1 con máscara 255.255.255.252 implica la subred 200.1.1.0,
dirección de difusión 200.1.1.3.

Si el comando hubiera mostrado en su lugar valores de

extremo inferior y superior de 200.1.1.1 y 200.1.1.6, de
nuevo con máscara 255.255.255.252, IOS rechazaría el
comando. IOS haría los cálculos de la siguiente lista,
dándose cuenta de que los números estaban en subredes
diferentes:

||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Otra gran diferencia entre la configuración de NAT

dinámica y NAT estática en el Ejemplo 10-1 tiene que
ver con dos opciones en el comando ip nat inside
source. La versión de NAT dinámica de este comando se
refiere al nombre del pool NAT que quiere usar para las
direcciones globales internas - en este caso, fred.
También hace referencia a una ACL IP, que define la
lógica de coincidencia para las direcciones IP locales
internas. Por lo tanto, la lógica para el comando ip nat
inside source list 1 pool fred en este ejemplo es la
siguiente:
Crear entradas de tabla NAT que mapeen entre hosts

coincidentes con ACL 1, para paquetes que entren en
cualquier interfaz interior, asignando una dirección
global interior del pool llamado fred.
Verificación de NAT dinámica

Los ejemplos 10-3 y 10-4 muestran la evidencia de que
la NAT dinámica comienza sin entradas en la tabla NAT,
pero el router reacciona después de que el tráfico de
usuario impulsa correctamente la función NAT. El
Ejemplo 10-3 muestra la salida de los comandos show
ip nat translations y show ip nat statistics antes de
que cualquier usuario genere tráfico que haga que NAT
realice algún trabajo. El comando show ip nat
translations, que lista las entradas de la tabla NAT,
muestra una línea en blanco; el comando show ip nat
statistics, que muestra cuántas veces NAT ha creado
una entrada en la tabla NAT, muestra 0 traducciones
activas.
Ejemplo 10-3 Verificaciones NAT Dinámicas Antes de

||||||||||||||||||||
||||||||||||||||||||
Generar Tráfico
||||||||||||||||||||
||||||||||||||||||||
¡! El siguiente comando muestra una línea vacía porque no hay

entradas b
Todavía no se ha creado.

extendidas)
Pico de traducciones: 8, ocurridas hace
00:02:44 Interfaces externas:
Serial0/0/0
Interfaces
interiores:
GigabitEthernet0/0
CEF Paquetes traducidos: 0, CEF Paquetes punteados:
0 Traducciones caducadas: 0
-- Inside Source
[id 1] access-list 1 pool fred refcount 0
pool fred: netmask 255.255.255.252
inicio 200.1.1.1 fin 200.1.1.2
tipo genérico, total direcciones 2, asignadas 0 (0%),
perdidas 0
Total puertas: 0
Puertas Appl: 0
Puertas normales: 0
Paquetes en cola: 0
El comando show ip nat statistics al final del ejemplo

lista alguna información particularmente interesante para
la resolución de problemas con dos contadores diferentes
etiquetados como "misses", como se resalta en el
ejemplo. La primera ocurrencia de este contador cuenta
el número de veces que llega un nuevo paquete que
necesita una entrada NAT y no la encuentra. En ese
momento, la NAT dinámica reacciona y crea una
entrada. El segundo contador de fallos hacia el final de la
salida del comando lista el número de fallos en el pool.
Este contador se incrementa sólo cuando la NAT
dinámica intenta asignar una nueva entrada en la tabla
NAT y no encuentra ninguna.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
direcciones disponibles, por lo que el paquete no puede

ser traducido - probablemente resultando en que un
usuario final no llegue a la aplicación.
A continuación, el Ejemplo 10-4 actualiza la salida de

ambos comandos después de que el usuario del host en
10.1.1.1 telnet a host 170.1.1.1.
Ejemplo 10-4 Verificaciones de NAT dinámico

después de generar tráfico

imagen del código
Pro Inside globalInside Local En
local exterior --
--- 200.1.1.1 10.1.1.1 ---

ampliadas)
Pico de traducciones: 11, ocurridas hace 00:04:32
Interfaces externas:
Serial0/0/0
Interfaces
interiores:
GigabitEthernet0/0
Traducciones caducadas:
0 Asignaciones
dinámicas:
-- Inside Source
access-list 1 pool fred refcount 1
[eml fred: netmask 255.255.255.252
inicio 200.1.1.1 fin 200.1.1.2
tipo genérico, total direcciones 2, asignadas 1 (50%),
perdidas 0
El ejemplo comienza con el host 10.1.1.1 telnetando a

170.1.1.1 (no se muestra), con el router NAT creando una
entrada NAT. La tabla NAT muestra una única entrada,
asignando
10.1.1.1 a 200.1.1.1. Y, la primera línea en la salida del
comando show ip nat statistics lista un contador para
||||||||||||||||||||
||||||||||||||||||||
1 traducción activa, como se muestra en la tabla NAT de

la parte superior del ejemplo.
Tómese un momento extra para considerar la línea

resaltada, donde el comando show ip nat statistics lista
1 miss y 69 hits. El primer contador de errores, ahora en
1, significa que llegó un paquete que necesitaba NAT,
pero no había ninguna entrada en la tabla NAT. NAT
reaccionó y añadió una entrada en la tabla NAT, por lo
que el contador de 69 aciertos significa que los
siguientes 69 paquetes utilizaron la nueva entrada
añadida en la tabla NAT. El segundo contador de
errores, aún en 0, no se incrementó porque el pool NAT
tenía suficientes direcciones IP internas globales
disponibles para asignar la nueva entrada de la tabla
NAT. Observe también que la última línea muestra
estadísticas sobre el número de miembros del pool
asignados (1) y el porcentaje del pool actualmente en
uso (50%).
Las entradas de la tabla NAT dinámica expiran después

de un periodo de inactividad, poniendo esas direcciones
globales internas de nuevo en el pool para su uso futuro.
El Ejemplo 10-5 muestra una secuencia en la que dos
hosts diferentes hacen uso de la dirección global interna
200.1.1.1. El host 10.1.1.1 utiliza la dirección global interna
200.1.1.1 al principio del ejemplo. Entonces, en lugar de
esperar a que la entrada NAT se agote, el ejemplo borra
la entrada de la tabla NAT con el comando clear ip nat
translation *. En ese momento, el usuario en
10.1.1.2 telnet a 170.1.1.1, y aparece la nueva entrada de la
tabla NAT, utilizando la misma dirección global interna
200.1.1.1.
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 10-5 Ejemplo de reutilización de una

dirección IP global interna dinámica
Technet24
||||||||||||||||||||
||||||||||||||||||||

imagen del código
¡! El host 10.1.1.1 utiliza actualmente inside global
200.1.1.1
Pro Inside globalInside Local En
local exterior ---
--- 200.1.1.1 10.1.1.1 ---
NAT# clear ip nat translation *
¡!
telnet de 10.1.1.2 a 170.1.1.1 sucede a continuación; no se
muestra
¡!
¡! Ahora el host 10.1.1.2 usa inside global 200.1.1.1

Pro Inside global Dentro de Local En
--- 200.1.1.1 local exterior ---
¡! 10.1.1.2 ---
¡! Telnet de 10.1.1.1 a 170.1.1.1 sucede a continuación; no
se muestra
¡!
NAT# debug ip nat
La depuración IP NAT está activada
Oct 20 19:23:03.263: NAT*: s=10.1.1.1->200.1.1.2, d=170.1.1.1 [34

Oct 20 19:23:03.267: NAT*: s=170.1.1.1, d=200.1.1.2->10.1.1.1 [34
Oct 20 19:23:03.464: NAT*: s=10.1.1.1->200.1.1.2, d=170.1.1.1 [34
Oct 20 19:23:03.568: NAT*: s=170.1.1.1, d=200.1.1.2->10.1.1.1 [34
Por último, al final del Ejemplo 10-5, se ve que el host

10.1.1.1 ha hecho telnet a otro host en Internet, más la
salida del comando debug ip nat. Este comando debug
hace que el router emita un mensaje cada vez que un
paquete tiene su dirección traducida para NAT. Usted
genera los resultados de salida introduciendo unas pocas
líneas desde la conexión Telnet desde 10.1.1.1 a 170.1.1.1.
La salida de depuración te dice que el host 10.1.1.1
ahora usa la dirección global interna 200.1.1.2 para esta
nueva conexión.
Configuración de sobrecarga NAT (PAT)
||||||||||||||||||||
||||||||||||||||||||
Las configuraciones de NAT estática y dinámica

importan, pero la configuración de sobrecarga de NAT
(PAT) en esta sección importa más. Esta es la
característica que salva las direcciones IPv4 públicas y
prolonga la vida de IPv4.
La sobrecarga de NAT, como ya se ha mencionado,

permite que NAT admita muchas direcciones IP locales
internas con sólo una o unas pocas direcciones IP
globales internas. Al traducir esencialmente la dirección
IP privada y el número de puerto a una única dirección
IP interna global, pero con un único número de puerto,
NAT puede soportar muchos (más de 65.000) hosts
privados con una única dirección pública global.
Existen dos variaciones de configuración PAT en IOS. Si

PAT utiliza un conjunto de direcciones internas globales,
la configuración se ve exactamente como NAT
dinámica, excepto que el comando ip nat inside source
list global tiene una palabra clave de sobrecarga
agregada al final. Si PAT sólo necesita usar una
dirección IP interna global, el router puede usar una de
sus direcciones IP de interfaz. Debido a que NAT puede
soportar más de 65,000 flujos concurrentes con una sola
dirección global interna, una sola dirección IP pública
puede soportar las necesidades NAT de toda una
organización.
La siguiente declaración detalla la diferencia de

configuración entre sobrecarga NAT y NAT 1:1 cuando se
utiliza un pool NAT:
Siga los mismos pasos para configurar la NAT

dinámica, como se indica en la sección anterior,
pero incluya la palabra clave overload al final del
||||||||||||||||||||
||||||||||||||||||||
comando global ip nat inside source list.
Technet24
||||||||||||||||||||
||||||||||||||||||||
La siguiente lista de comprobación detalla la

configuración cuando se utiliza una dirección IP de
interfaz como única dirección IP global interna:
Paso 1. Al igual que con NAT dinámico y estático,

configure el subcomando ip nat inside
interface para identificar las interfaces
internas.
Paso 2. Al igual que con NAT dinámico y estático,
configure el subcomando ip nat outside
interface para identificar las interfaces
externas.
Paso 3. Al igual que con NAT dinámica, configure
una ACL que coincida con los paquetes que
entran en las interfaces interiores.
Paso 4. Configure el comando de configuración
global ip nat inside source list acl- number
interface type/number overload, haciendo
referencia a la ACL creada en el paso 3 y a la
interfaz cuya dirección IP se utilizará para las
traducciones.
El ejemplo 10-2 muestra una configuración NAT
dinámica. Para convertirla en una configuración PAT,
se utilizaría el comando ip nat inside source list 1
pool fred overload en su lugar, simplemente
añadiendo la palabra clave overload.
El siguiente ejemplo muestra la configuración PAT

utilizando una única dirección IP de interfaz. La Figura
||||||||||||||||||||
||||||||||||||||||||
10-10 muestra la misma red familiar, con algunos

cambios. En este caso, la
||||||||||||||||||||
||||||||||||||||||||
El ISP ha asignado a Certskills un subconjunto de la red

200.1.1.0: subred CIDR 200.1.1.248/30. En otras
palabras, esta subred tiene dos direcciones utilizables:
200.1.1.249 y 200.1.1.250.
Estas direcciones se utilizan en ambos extremos del
enlace serie entre Certskills y su ISP. La función NAT
del enrutador de Certskills traduce todas las direcciones
NAT a su dirección IP serie, 200.1.1.249.
Figura 10-10 Sobrecarga NAT y PAT
En el Ejemplo 10-6, que muestra la configuración de

sobrecarga NAT, NAT traduce utilizando sólo la
dirección global interna 200.1.1.249, por lo que no se
requiere el pool NAT. En el ejemplo, el host 10.1.1.2
crea dos conexiones Telnet, y el host 10.1.1.1 crea una
conexión Telnet, causando tres entradas NAT dinámicas,
cada una usando la dirección global interna 200.1.1.249,
pero cada una con un número de puerto único.
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Ejemplo 10-6 Configuración de sobrecarga NAT

imagen del código
¡!
¡!
¡!
dirección ip 200.1.1.249 255.255.255.252
ip nat outside
¡!
ip nat inside source list 1 interface Serial0/0/0 overload
¡!
¡!

ProDentro global Dentro local Fuera de Fue
tcp200.1.1.249:49712 10.1.1.1:49712 local ra
tcp 200.1.1.249:49713 10.1.1.2:49713 170.1.1.1:23 170
tcp 200.1.1.249:49913 10.1.1.2:49913 170.1.1.1:23 170
NAT# show ip nat statistics 170.1.1.1:23 170
Traducciones activas totales: 3 (0 estáticas, 3 dinámicas; 3
extendidas) Pico de traducciones: 12, ocurridas hace 00:01:11
Interfaces externas:
Serial0/0/0
Interfaces internas:
GigabitEthernet0/0
Traducciones caducadas: 0
-- Inside Source
access-list 1 interface Serial0/0/0 refcount 3
El comando ip nat inside source list 1 interface

serial 0/0/0 overload tiene varios parámetros, pero
si entiendes la configuración de NAT dinámica, los
nuevos parámetros no deberían ser muy difíciles de
entender. La lista
||||||||||||||||||||
||||||||||||||||||||
1 significa lo mismo que para la NAT dinámica: las

direcciones IP locales interiores que coincidan con ACL
1 tienen sus direcciones traducidas. El parámetro
interfaz serie 0/0/0 significa que la única dirección
IP global interior disponible es la dirección IP de la
interfaz serie 0/0/0 del router NAT. Por último, el
parámetro de sobrecarga significa que la sobrecarga
está activada. Sin este parámetro, el router no realiza
sobrecarga, sólo NAT dinámica.
Como puede ver en la salida del comando show ip

nat translations, se han añadido tres traducciones a
la tabla NAT. Antes de este comando, el host
10.1.1.1 crea una conexión Telnet a 170.1.1.1, y el host
10.1.1.2 crea dos conexiones Telnet. El router crea una
entrada en la tabla NAT para cada combinación única de
dirección IP local interna y puerto.
Resolución de problemas NAT

La mayoría de los problemas de NAT están relacionados
con la configuración correcta. Source NAT tiene varias
opciones de configuración-estática, dinámica, PAT-con
varios comandos de configuración para cada una.
Deberías esforzarte en desarrollar habilidades con la
configuración para que puedas reconocer rápidamente
los errores de configuración.
La siguiente lista de comprobación para la solución de
problemas resume los problemas NAT de origen más
comunes, la mayoría de los cuales están relacionados
con una configuración incorrecta.
Reversed inside and outside: Asegúrese de que la configuración
incluye los subcomandos de interfaz ip nat inside e ip nat outside
y de que los comandos no están invertidos (el subcomando ip nat
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
inside en interfaces externas, y viceversa). Con NAT de origen,

sólo la interfaz interior activa IOS para añadir nuevas traducciones,
por lo que designar las interfaces interiores correctas es
particularmente importante.
NAT estático: Compruebe el comando ip nat inside source

static para asegurarse de que enumera la dirección local interna
en primer lugar y la dirección IP global interna en segundo lugar.
NAT dinámico (ACL): Asegúrese de que la ACL configurada para

coincidir con los paquetes enviados por los hosts internos coincide con
los paquetes de ese host antes de que se haya producido cualquier
traducción NAT. Por ejemplo, si una dirección local interna de
10.1.1.1 debe traducirse a 200.1.1.1, asegúrese de que la ACL coincida
con la dirección de origen 10.1.1.1, no con 200.1.1.1.
NAT dinámico (pool): Para NAT dinámico sin PAT, asegúrese de

que el pool tiene suficientes direcciones IP. Cuando no se utiliza
PAT, cada host interno consume una dirección IP del pool. Un
valor grande o creciente en el contador de segundas faltas en la
salida del comando show ip nat statistics puede indicar este
problema. Además, compare el pool configurado con la lista de
direcciones en la tabla de traducción NAT (show ip nat
translations). Finalmente, si el pool es pequeño, el problema
puede ser que la configuración pretendía usar PAT y le falta la
palabra clave overload (ver el siguiente punto).
PAT: Es fácil olvidarse de añadir la opción overload al final del

comando ip nat inside source list. La configuración PAT es
idéntica a una configuración NAT dinámica válida, excepto que
PAT requiere la palabra clave overload. Sin ella, la NAT dinámica
funciona, pero el pool de direcciones suele consumirse muy
rápidamente. El router NAT no traducirá ni reenviará tráfico para
los hosts si no hay una dirección IP de pool disponible para su
tráfico, por lo que algunos hosts experimentan una interrupción.
ACL: Como se mencionó en el Capítulo 3, "Listas de Control de

Acceso IPv4 Avanzadas", siempre se puede añadir una
comprobación para ACLs que causen un problema. Quizás NAT ha
sido configurado correctamente, pero existe una ACL en una de las
interfaces, descartando los paquetes. Tenga en cuenta que el orden
de las operaciones dentro del router importa en este caso. Para los
paquetes que entran en una interfaz, IOS procesa las ACL antes que
NAT. Para los paquetes que salen de una interfaz, IOS procesa
cualquier ACL saliente después de traducir las direcciones con
NAT.
||||||||||||||||||||
||||||||||||||||||||
Se requiere tráfico de usuario: NAT reacciona al tráfico de

usuario. Si configuras NAT en un laboratorio, NAT no actúa para
crear traducciones (show ip nat translations) hasta que algún
tráfico de usuario entra en el router NAT en una interfaz interior,
activando NAT para hacer una traducción. La configuración de
NAT puede ser perfecta, pero si no hay tráfico entrante que
coincida con la configuración de NAT, NAT no hace nada.
Enrutamiento IPv4: El enrutamiento IPv4 podría impedir la

llegada de paquetes a ambos lados del router NAT. Tenga en cuenta
que el enrutamiento debe funcionar para las direcciones IP de
destino utilizadas en los paquetes.
Con NAT de origen, el usuario se sienta en algún

dispositivo de usuario como un PC. Intenta conectarse a
un servidor utilizando su nombre DNS. Tras la
resolución DNS, el cliente (el host interno) envía un
paquete IP con la dirección de destino del servidor. Por
ejemplo, como se muestra en la Figura
10-11, PC1 envía un paquete IP con dirección IP de
destino 170.1.1.1, algún servidor en Internet. PC1 es un
host interno, el servidor es un host externo, y 170.1.1.1
es la dirección global externa. (Observe que estas
direcciones coinciden con el ejemplo anterior, que hacía
referencia a la Figura 10-10).
Figura 10-11 Cambios de dirección de destino de

fuera a dentro (sólo) con NAT de origen
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
Tenga en cuenta que con NAT de origen en lo que

debería ser un diseño familiar, la dirección IP de destino
del paquete no cambia durante todo el viaje. Por lo tanto,
la resolución de problemas de enrutamiento IPv4 hacia la
red exterior se basará en la misma dirección IP durante
todo el trayecto.
Ahora fíjate en los pasos 3 y 4 de la figura, que te

recuerdan que el paquete de retorno fluirá primero hacia
la dirección global interna NAT (200.1.1.249 en este
caso) como se muestra en el paso 3. A continuación,
NAT convierte la dirección de destino en
10.1.1.1 en este caso. Por lo tanto, para solucionar el
problema de los paquetes que fluyen de derecha a
izquierda en este caso, tiene que solucionar el
problema basándose en dos direcciones IP de destino
diferentes.
detalles. En la Tabla 10-5 se describen los principales
elementos de repaso y dónde encontrarlos. Para hacer
un mejor seguimiento de su progreso en el estudio,
registre cuándo completó estas actividades en la
segunda columna.
||||||||||||||||||||
||||||||||||||||||||

Elemento de revisiónFecha(s) de
revisiónRecurso utilizado
||||||||||||||||||||
||||||||||||||||||||
Revisar las tablas de memoria Libro, página web
Revisar las tablas de comandos Reserve
Laboratorios Blog


Elemento Número
Cuadro Lista de números de redes IP privadas 206

10-2
Figura 10- Concepto principal de NAT que traduce las 207

2 direcciones IP privadas en direcciones
globales únicas para el público.
Figura 10- Diagrama típico de una red NAT con los 209
4 términos clave de NAT enumerados
Cuadro Lista de cuatro términos clave de NAT y sus 210

10-4 significados
Figura 10- Conceptos de conservación de direcciones 213

8 mediante sobrecarga NAT (PAT)
Párrafo Resumen de las diferencias entre la dinámica 220
Technet24
||||||||||||||||||||
||||||||||||||||||||
Configuración NAT y PAT utilizando un pool

CIDR
dentro de global
dentro de local
Sobrecarga NAT
fuera global
Traducción de direcciones de puerto
red IP privada
fuente NAT
hace el comando.

configuración
||||||||||||||||||||
||||||||||||||||||||
ip nat {interior | Subcomando de interfaz para activar

exterior} NAT e identificar si la interfaz está
dentro o fuera de la red.
ip nat inside source Comando global que habilita NAT

{list {número de lista de globalmente, haciendo referencia a
acceso | la ACL que define qué direcciones
access-list-name}} de origen NAT, y la interfaz o pool
{número de tipo de desde el que encontrar direcciones
interfaz | nombre de pool} globales.
[sobrecarga].
ip nat pool name start-ip Comando global para definir un pool

end-ip {máscara de red de direcciones NAT
máscara de red
| prefix-length prefix-
length}
ip nat inside source Comando global que enumera la

interno-local interno-global dirección interior y exterior (o, una
interfaz exterior cuya dirección IP
debe utilizarse) que debe emparejarse
y añadirse a la tabla de traducción
NAT.

EXEC
mostrar estadísticas ip nat Muestra contadores de

paquetes y entradas de la
tabla NAT, así como
información básica de
configuración.
mostrar traducciones ip nat Muestra la tabla NAT

[verbose]
clear ip nat translation {* | Borra todas o algunas de las

[inside global-ip local-ip] entradas dinámicas de la tabla
[outside local-ip global-ip]} NAT, dependiendo de qué
||||||||||||||||||||
||||||||||||||||||||
Technet24
||||||||||||||||||||
||||||||||||||||||||
se utilizan parámetros
clear ip nat translation Borra algunas de las entradas

protocol inside global-ip dinámicas de la tabla NAT,
global-port local-ip local-port en función de los parámetros
[outside local-ip global-ip] utilizados.
depurar ip nat Emite un mensaje de registro

que describe cada paquete
cuya dirección IP se traduce
con NAT
||||||||||||||||||||

CcnaPrimero Es

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

CcnaPrimero Es

Cargado por

Copyright:

Formatos disponibles

||||||||||||||||||||

1.0 Fundamentos de la red

El examen CCNA se centra principalmente en las

Este capítulo comienza examinando las funciones de dos

"¿ESTO YA LO SÉ?" PREGUNTA

Tabla 1-1 "¿Ya sé esto?" Asignación de secciones a

Sección de Temas Fundamentales Preguntas

Protocolos TCP/IP de capa 4: TCP y UDP 1-4

Aplicaciones TCP/IP 5-6

1. ¿Cuál de los siguientes campos de cabecera

2. ¿Cuáles de las siguientes son funciones típicas de

3. ¿Cuál de las siguientes funciones realizan tanto

4. ¿Cómo se llaman los datos que incluyen la

6. Fred abre un navegador web y se conecta al sitio

Respuestas al cuestionario "¿Lo sé ya?

La capa de transporte OSI (Capa 4) define varias

La diferencia clave entre TCP y UDP es que TCP

Sin embargo, no dejes que la falta de servicios de UDP te

y vídeo sobre IP, no necesitan recuperación de errores,

La Tabla 1-2 enumera las principales características

Tabla 1-2 Características de la capa de transporte TCP/IP

Multiplexació Función que permite a los hosts receptores elegir

Recuperació Proceso de numeración y acuse de recibo de los

Control de Proceso que utiliza tamaños de ventana para

Establecimient Proceso utilizado para inicializar los números de

Transferenci Flujo continuo de bytes de un proceso de capa

A continuación, esta sección describe las características

Protocolo de control de transmisión

TCP, tal y como se define en la Request For Comments

La Figura 1-1 muestra los campos de la cabecera TCP. Aunque

no es necesario que memorice los nombres de los

Figura 1-1 Campos de la cabecera TCP

El mensaje creado por TCP que comienza con la

Multiplexación mediante números de puerto TCP

La multiplexación por TCP y UDP implica el proceso de

La multiplexación indica al ordenador receptor a qué

Algunos ejemplos ayudarán a hacer evidente la

La Figura 1-2 muestra la red de ejemplo, con George

UDP Una aplicación de transferencia

por cable basada en TCP U n a

aplicación de servidor web TCP

Figura 1-2 Hannah enviando paquetes a George, con

George necesita saber a qué aplicación dar los datos,

TCP y UDP resuelven este problema utilizando un

Figura 1-3 Hannah Enviando Paquetes a George, con

La multiplexación se basa en un concepto llamado

Así, para una aplicación de servidor web en George, el

La Autoridad de Asignación de Números de Internet

Puertos de usuario (registrados): Números del 1024 al 49151,

nuevos puertos en comparación con los puertos conocidos.

Puertos efímeros (dinámicos, privados): Números del 49152 al

La Figura 1-4 muestra un ejemplo que utiliza tres

Figura 1-4 Conexiones entre tomas

Los números de puerto son una parte vital del

En las máquinas cliente, donde se originan las

número de puerto listado como puerto de destino. La

Los sockets de destino permiten a todos los hosts

Puede encontrar todas las RFC en línea en www.rfc-

Aplicaciones TCP/IP populares

La aplicación World Wide Web (WWW) existe a través

El Sistema de Nombres de Dominio (DNS) permite a los usuarios utilizar

para referirse a los ordenadores, y el DNS se utiliza para

El Protocolo Simple de Gestión de Red (SNMP) es un

Tradicionalmente, para mover archivos hacia y desde un