PDF Ccna2 v5-401-675

CCNA Routing and Switching.
Routing and Switching Essencials
El cuarto paso en el proceso de routing de estado de enlace es que cada router satura con LSP a
todos los vecinos, quienes luego almacenan todos los LSP recibidos en una base de datos.
Cada router inunda con su información de link-state a todos los demás routers de link-state en el
área de enrutamiento. Siempre que un router recibe un LSP de un router vecino, envía de
inmediato dicho LSP a todas las demás interfaces, excepto la interfaz que recibió el LSP. Este
proceso crea un efecto de saturación de los LSP desde todos los routers a través del área de
enrutamiento.
Haga clic en Reproducir en la ilustración para ver una animación de la saturación con LSP.
En la animación, observe cómo se lleva a cabo la saturación con LSP de forma casi inmediata
después de ser recibidos sin ningún cálculo intermedio. Los protocolos de routing de estado de
enlace calculan el algoritmo SPF una vez que finaliza la saturación. Como resultado, los protocolos
de routing de estado de enlace logran la convergencia muy rápidamente.
Recuerde que los LSP no necesitan enviarse periódicamente. Un LSP sólo necesita enviarse:
 Durante el arranque inicial del proceso del protocolo de routing (por ejemplo, en el reinicio del
router)
 Cuando hay un cambio en la topología (por ejemplo, un enlace que se desactiva o activa, o
una adyacencia de vecinos que se establece o se rompe)
Además de la información de estado de enlace, se incluye información adicional en el LSP, como

los números de secuencia y la información de vencimiento, para ayudar a administrar el proceso de
saturación. Cada router utiliza esta información para determinar si ya recibió el LSP de otro router o
si el LSP tiene información más nueva que la contenida en la base de datos de link-state. Este
Nicolás Contador 401

CCNA Routing and Switching. Routing and Switching Essencials
proceso permite que un router conserve sólo la información más actual en su base de datos de
link-state.
El paso final en el proceso de routing de estado de enlace es que cada router utiliza la base de
datos para construir un mapa completo de la topología y calcula la mejor ruta para cada red de
destino.
Finalmente, todos los routers reciben un LSP de todos los demás routers de estado de enlace en el
área de routing. Dichos LSP se almacenan en la base de datos de link-state.
En el ejemplo en la ilustración, se muestra el contenido de la base de datos de estado de enlace

del R1.
Como resultado del proceso de saturación, el R1 obtuvo la información de estado de enlace para
cada router de su área de routing. Observe que R1 también incluye su propia información de link-
state en la base de datos de link-state.
Con una base de datos de estado de enlace completa, el R1 ahora puede utilizar la base de datos
y el algoritmo SPF (Shortest Path First) para calcular la ruta preferida o la ruta más corta a cada
red, lo que da como resultado el árbol SPF.

Cada router en el área de routing utiliza la base de datos de estado de enlace y el algoritmo SPF
para armar el árbol SPF.
Por ejemplo, utilizando la información de estado de enlace de todos los demás routers, el R1 ahora
puede comenzar a armar un árbol SPF de la red. Para comenzar, el algoritmo SPF interpreta el
LSP de cada router para identificar las redes y los costos asociados.
En la figura 1, el R1 identifica sus redes conectadas directamente y los costos.
En las figuras 2 a 5, el R1 continúa agregando toda red desconocida y sus costos asociados al
árbol SPF. Observe que el R1 ignora cualquier red que ya haya identificado.
A continuación, el algoritmo SPF calcula las rutas más cortas para llegar a cada red individual, lo
que da como resultado el árbol SPF como se muestra en la figura 6. El R1 ahora tiene una vista de
topología completa del área de estado de enlace.
Cada router construye su propio árbol SPF independientemente de los otros routers. Para
garantizar el enrutamiento adecuado, las bases de datos de link-state utilizadas para construir
dichos árboles deben ser idénticas en todos los routers.



Al utilizar la información de la ruta más corta determinada por el algoritmo SPF, dichas rutas ahora
pueden agregarse a la tabla de enrutamiento. En la ilustración, se muestran las rutas que se
agregaron a la tabla de routing IPv4 del R1.
La tabla de routing también incluye todas las redes conectadas directamente y las rutas
provenientes de cualquier otro origen, tales como las rutas estáticas. Los paquetes ahora se
reenvían según dichas entradas en la tabla de routing.

7.5.3 Razones para utilizar protocolos de routing de estado de enlace
Como se muestra en la ilustración, los protocolos de routing de estado de enlace presentan varias
ventajas en comparación con los protocolos de routing vector distancia.
 Armado de un mapa topológico: los protocolos de routing de estado de enlace crean un

mapa topológico o árbol SPF de la topología de la red. Debido a que los protocolos de
enrutamiento de link-state intercambian estados de enlace, el algoritmo SPF puede crear un
árbol SPF de la red. Al utilizar el árbol SPF, cada router puede determinar en forma
independiente la ruta más corta a cada red.
 Convergencia rápida: cuando reciben un LSP, los protocolos de routing de estado de enlace
saturan de inmediato todas las interfaces con el LSP, excepto la interfaz desde la que se lo
recibió. En cambio, el protocolo RIP necesita procesar cada actualización de routing y
actualizar su tabla de routing antes de saturar otras interfaces.
 Actualizaciones desencadenadas por eventos: después de la saturación inicial con LSP,

los protocolos de routing de estado de enlace solo envían un LSP cuando se produce un
cambio en la topología. El LSP sólo incluye la información relacionada con el enlace afectado.
A diferencia de algunos protocolos de enrutamiento vector distancia, los protocolos de
enrutamiento de link-state no envían actualizaciones periódicas.
 Diseño jerárquico: los protocolos de routing de estado de enlace utilizan el concepto de

áreas. Las áreas múltiples crean un diseño jerárquico para redes y permiten un mejor
agregado de rutas (sumarización) y el aislamiento de los problemas de enrutamiento dentro
del área.

Los protocolos de estado de enlace también tienen algunas desventajas en comparación con los
protocolos de routing vector distancia:
 Requisitos de memoria: los protocolos de estado de enlace requieren memoria adicional

para crear y mantener la base de datos de estado de enlace y el árbol SPF.
 Requisitos de procesamiento: los protocolos de estado de enlace también pueden requerir

un mayor procesamiento de CPU que los protocolos de routing vector distancia. El algoritmo
SPF requiere un mayor tiempo de CPU que los algoritmos vector distancia, como Bellman-
Ford, ya que los protocolos de estado de enlace arman un mapa completo de la topología.
 Requisitos de ancho de banda: la saturación de paquetes de estado de enlace puede

ejercer un impacto negativo en el ancho de banda disponible en una red. Si bien esto sólo
debería ocurrir durante la puesta en marcha inicial de los routers, también podría ser un
problema en redes inestables.
Los protocolos de enrutamiento de link-state modernos están diseñados para minimizar los efectos
en la memoria, el CPU y el ancho de banda. La utilización y configuración de áreas múltiples puede
reducir el tamaño de las bases de datos de link-state. Las áreas múltiples también pueden limitar el
grado de saturación de información de link-state en un dominio de enrutamiento y enviar los LSP
sólo a aquellos routers que los necesitan. Cuando hay un cambio en la topología, solo los routers
del área afectada reciben el LSP y ejecutan el algoritmo SPF. Esto puede ayudar a aislar un enlace
inestable en un área específica en el dominio de enrutamiento.
Por ejemplo, en la ilustración hay tres dominios de routing independientes: área 1, área 0 y
área 51. Si una red en el área 51 deja de funcionar, solo los routers en esa área se saturan con el
LSP que contiene la información sobre dicho enlace fuera de servicio. Únicamente los routers del
área 51 necesitan actualizar sus bases de datos de estado de enlace, volver a ejecutar el algoritmo
SPF, crear un nuevo árbol SPF y actualizar sus tablas de routing. Los routers de otras áreas
descubren que esta ruta no funciona, pero esto se realiza con un tipo de LSP que no los obliga a
volver a ejecutar su algoritmo SPF. Los routers de otras áreas pueden actualizar sus tablas de
enrutamiento directamente.

Existen solamente dos protocolos de routing de estado de enlace: OSPF e IS-IS.
El protocolo OSPF (Open Shortest Path First) es la implementación más popular. Fue diseñado por
el grupo de trabajo de OSPF del Grupo de trabajo de ingeniería de Internet (IETF). El desarrollo de
OSPF comenzó en 1987 y actualmente hay dos versiones en uso:
 OSPFv2: OSPF para redes IPv4 (RFC 1247 y RFC 2328)
 OSPFv3: OSPF para redes IPv6 (RFC 2740)
Nota: con la característica de familias de direcciones de OSPFv3, esta versión del protocolo es
compatible con IPv4 e IPv6.
El protocolo IS-IS fue diseñado por la Organización Internacional para la Estandarización (ISO) y
se describe en ISO 10589. La primera versión de este protocolo de routing se desarrolló en la
Digital Equipment Corporation (DEC) y se conoce como “DECnet fase V”. Radia Perlman fue la
principal diseñadora del protocolo de routing IS-IS.
IS-IS se diseñó originalmente para el suite de protocolos de OSI y no para el suites de protocolo de
TCP/IP. Más adelante, IS-IS integrado, o IS-IS doble, incluyó la compatibilidad con redes IP. Si
bien se conoció a IS-IS como el protocolo de enrutamiento más utilizado por proveedores e ISP, se
están comenzando a utilizar más redes IS-IS corporativas.
OSPF e IS-IS presentan varias similitudes y diferencias. Existen diversas posturas a favor de
OSPF y a favor de IS-IS que analizan y debaten las ventajas de un protocolo de enrutamiento
frente al otro. Ambos protocolos de routing proporcionan la funcionalidad de routing necesaria.

7.6 La tabla de routing

7.6.1 Partes de una entrada de ruta IPv4
La topología que se muestra en la figura 1 se utiliza como la topología de referencia para esta
sección. Observe lo siguiente en la topología:
El R1 es el router perimetral que se conecta a Internet. Por lo tanto, propaga una ruta estática
predeterminada al R2 y al R3.
El R1, el R2 y el R3 contienen redes no contiguas separadas por otra red con clase.
El R3 también introduce una ruta de superred 192.168.0.0/16.
En la figura 2, se muestra la tabla de routing IPv4 del R1 con las rutas dinámicas, estáticas y
conectadas directamente.
Nota: en los inicios, la jerarquía de la tabla de routing en el IOS de Cisco se implementó con el
esquema de routing con clase. Si bien la tabla de enrutamiento incorpora el direccionamiento con
clase y sin clase, la estructura general aún se construye en base a este esquema con clase.

Como se destaca en la figura 1, la tabla de routing del R1 contiene tres redes conectadas
directamente. Observe que cuando se configura una interfaz del router activa con una dirección IP
y una máscara de subred, automáticamente se crean dos entradas en la tabla de routing.
En la figura 2, se muestra una de las entradas de la tabla de routing en el R1 para la red conectada
directamente 172.16.1.0. Estas entradas se agregaron de forma automática a la tabla de
enrutamiento cuando se configuró y se activó la interfaz GigabitEthernet 0/0. Las entradas
contienen la siguiente información:

 Origen de la ruta: identifica el modo en que se descubrió la ruta. Las interfaces conectadas
directamente tienen dos códigos de origen de ruta. Cidentifica una red conectada
directamente. Las redes conectadas directamente se crean de forma automática cada vez
que se configura una interfaz con una dirección IP y se activa. L identifica que la ruta es local.
Las rutas locales se crean de forma automática cada vez que se configura una interfaz con
una dirección IP y se activa.
 Red de destino: la dirección de la red remota y la forma en que se conecta esa red.
 Interfaz de salida: identifica la interfaz de salida que se utiliza para reenviar paquetes a la
red de destino.
Nota: antes del IOS versión 15, las entradas de la tabla de routing local no aparecían en las tablas
de routing.
En general, los routers tienen varias interfaces configuradas. En la tabla de routing se almacena
información acerca de las rutas conectadas directamente y de las rutas remotas. Tal como ocurre
con las redes conectadas directamente, el origen de la ruta identifica cómo se descubrió la ruta.
Por ejemplo, los códigos frecuentes para las redes remotas incluyen los siguientes:
 S: indica que un administrador creó la ruta manualmente para llegar a una red específica.
Esto se conoce como “ruta estática”.
 D: indica que la ruta se descubrió de forma dinámica de otro router mediante el protocolo de
routing EIGRP.
 O: indica que la ruta se descubrió de forma dinámica de otro router mediante el protocolo de
routing OSPF.
 R: indica que la ruta se descubrió de forma dinámica de otro router mediante el protocolo de
routing RIP.

En la ilustración, se muestra una entrada de la tabla de routing IPv4 en el R1 para la ruta hacia la
red remota 172.16.4.0 en el R3. La entrada indica la siguiente información:
 Origen de la ruta: identifica el modo en que se descubrió la ruta.
 Red de destino: identifica la dirección de la red remota.
 Distancia administrativa: identifica la confiabilidad del origen de la ruta.

 Métrica: identifica el valor asignado para llegar a la red remota. Los valores más bajos
indican las rutas preferidas.
 Siguiente salto: identifica la dirección IPv4 del router siguiente al que se debe reenviar el
paquete.
 Marca de hora de la ruta: identifica cuándo fue la última comunicación con la ruta.
 Interfaz de salida: identifica la interfaz de salida que se debe utilizar para reenviar un
paquete hacia el destino final.

7.6.2 Rutas IPv4 descubiertas en forma dinámica
Una tabla de routing armada dinámicamente proporciona mucha información, como se muestra en
la ilustración. Por lo tanto, es de vital importancia comprender el resultado generado por la tabla de
routing. Al analizar el contenido de una tabla de routing, se utilizan términos especiales.
La tabla de enrutamiento IP de Cisco no es una base de datos plana. La tabla de enrutamiento, en

realidad, es una estructura jerárquica que se usa para acelerar el proceso de búsqueda cuando se
ubican rutas y se reenvían paquetes. Dentro de esta estructura, la jerarquía incluye varios niveles.
Las rutas se analizan en términos de lo siguiente:
 Ruta final
 Ruta de Nivel 1
 Ruta principal de nivel 1
 Rutas secundarias de nivel 2

Una ruta final es una entrada de la tabla de routing que contiene una dirección IPv4 del siguiente
salto o una interfaz de salida. Las rutas conectadas directamente, las rutas descubiertas
dinámicamente y las rutas locales son rutas finales.
En la ilustración, las áreas resaltadas son ejemplos de rutas finales. Observe que todas estas rutas
especifican una dirección IPv4 del siguiente salto o una interfaz de salida.

Una ruta de nivel 1 con una máscara de subred igual o inferior a la máscara con clase de la
dirección de red. Por lo tanto, una ruta de nivel 1 puede ser cualquiera de las siguientes:
 Ruta de red: una ruta de red que tiene una máscara de subred igual a la de la máscara con
clase.
 Ruta de superred: una dirección de red con una máscara menor que la máscara con clase,
por ejemplo, una dirección de resumen.
 Ruta predeterminada: una ruta estática con la dirección 0.0.0.0/0.
El origen de la ruta de nivel 1 puede ser una red conectada directamente, una ruta estática o un
protocolo de enrutamiento dinámico.
En la figura 1, se destaca la forma en que las rutas de nivel 1 también son rutas finales.
En la figura 2, se destacan las rutas de nivel 1.

Como se ilustra en la figura 1, una ruta principal de nivel 1 es una ruta de red de nivel 1 que está
dividida en subredes. Una ruta principal nunca puede ser una ruta final.
En la figura 2, se destacan las rutas principales de nivel 1 en la tabla de routing del R1. En la tabla
de routing, básicamente se proporciona un encabezado para las subredes específicas que
contiene. Cada entrada muestra la dirección de red con clase, la cantidad de subredes y la
cantidad de máscaras de subred diferentes en las que se subdividió la dirección con clase.

Una ruta secundaria de nivel 2 es una ruta que constituye una subred de una dirección de red con
clase. Como se ilustra en la figura 1, una ruta principal de nivel 1 es una ruta de red de nivel 1 que
está dividida en subredes. Las rutas principales de nivel 1 contienen rutas secundarias de nivel 2,
como se muestra en la figura 2.

Al igual que en las rutas de nivel 1, el origen de una ruta de nivel 2 puede ser una red conectada
directamente, una ruta estática o una ruta descubierta en forma dinámica. Las rutas secundarias
de nivel 2 también son rutas finales.
Nota: la jerarquía de la tabla de routing en el IOS de Cisco tiene un esquema de routing con clase.
Una ruta principal de nivel 1 es la dirección de red con clase de la ruta de subred. Esto es así
incluso si un protocolo de enrutamiento sin clase es el origen de la ruta de subred.
En la figura 3, se destacan las rutas secundarias en la tabla de routing del R1.


7.6.3 Proceso de búsqueda de rutas IPv4
Cuando un paquete llega a una interfaz del router, el router analiza el encabezado de IPv4,
identifica la dirección IPv4 de destino y continúa a través del proceso de búsqueda del router.
En la figura 1, el router examina las rutas de red de nivel 1 en busca de la mejor coincidencia con
la dirección de destino del paquete IPv4.
1. Si la mejor coincidencia es una ruta final de nivel 1, se utiliza esa ruta para reenviar el paquete.
2. Si la mejor coincidencia es una ruta principal de nivel 1, se continúa con el siguiente paso.
En la figura 2, el router examina las rutas secundarias (las rutas de subred) de la ruta principal en
busca de la mejor coincidencia.
3. Si hay una coincidencia con una ruta secundaria de nivel 2, se utiliza esa subred para reenviar el
paquete.
4. Si no hay una coincidencia con ninguna de las rutas secundarias de nivel 2, se continúa con el
paso siguiente.
En la figura 3, el router continúa buscando rutas de superred de nivel 1 en la tabla de routing para
detectar una coincidencia, incluida la ruta predeterminada, si la hubiera.
5. Si ahora hay una coincidencia menor con las rutas predeterminadas o de superred de nivel 1, el
router usa esa ruta para reenviar el paquete.
6. Si no hay coincidencia con ninguna ruta de la tabla de enrutamiento, el router descarta el

paquete.
Nota: una ruta que solo hace referencia a una dirección IP del siguiente salto y no a una interfaz
de salida debe resolverse a una ruta con una interfaz de salida. Se realiza una búsqueda
recurrente en la dirección IP del siguiente salto hasta que la ruta se resuelva con una interfaz de
salida.

¿Qué significa que el router deba encontrar la mejor coincidencia en la tabla de routing? La mejor
coincidencia es la coincidencia más larga.
Para que haya una coincidencia entre la dirección IPv4 de destino de un paquete y una ruta en la
tabla de routing, una cantidad mínima de los bits del extremo izquierdo deben coincidir entre la
dirección IPv4 del paquete y la ruta en la tabla de routing. La máscara de subred de la ruta en la
tabla de routing se utiliza para determinar la cantidad mínima de bits del extremo izquierdo que
deben coincidir. Recuerde que un paquete IPv4 solo contiene la dirección IPv4 y no la máscara de
subred.
La mejor coincidencia es la ruta de la tabla de routing que contiene la mayor cantidad de bits del
extremo izquierdo coincidentes con la dirección IPv4 de destino del paquete. La ruta con la mayor
cantidad de bits del extremo izquierdo equivalentes, o la coincidencia más larga, es siempre la ruta
preferida.

En la ilustración, el destino de un paquete es 172.16.0.10. El router tiene tres rutas posibles que
coinciden con este paquete: 172.16.0.0/12, 172.16.0.0/18 y 172.16.0.0/26. De las tres rutas,
172.16.0.0/26 tiene la coincidencia más larga y, por lo tanto, se elige para reenviar el paquete.
Recuerde que para que cualquiera de estas rutas se considere una coincidencia debe tener al
menos la cantidad de bits coincidentes que se indica en la máscara de subred de la ruta.
7.6.4 Análisis de una tabla de routing IPv6
Los componentes de la tabla de routing IPv6 son muy similares a los de la tabla de routing IPv4.
Por ejemplo, se completa con las interfaces conectadas directamente, con las rutas estáticas y con
las rutas descubiertas de forma dinámica.
Dado que IPv6 fue diseñado como un protocolo sin clase, todas las rutas son en realidad rutas
finales de nivel 1. No hay rutas principales de nivel 1 para rutas secundarias de nivel 2.
La topología que se muestra en la ilustración se utiliza como la topología de referencia para esta
sección. Observe lo siguiente en la topología:
 El R1, el R2 y el R3 están configurados en una topología de malla completa. Todos los

routers tienen rutas redundantes hacia diversas redes.
 El R2 es el router perimetral y se conecta con el ISP. Sin embargo, no se anuncia una ruta
estática predeterminada.
 Se configuró EIGRP para IPv6 en los tres routers.

En la figura 1, se muestra la tabla de routing del R1 mediante el comando show ipv6 route. Si bien
el resultado del comando se muestra de manera levemente distinta de como se muestra en la
versión IPv4, aún contiene la información importante de la ruta.
En la figura 2, se destacan la red conectada y las entradas en la tabla de routing local de las
interfaces conectadas directamente. Las tres entradas se agregaron cuando las interfaces se
configuraron y activaron.
Como se muestra en la figura 3, en las entradas de las rutas conectadas directamente se muestra
la siguiente información:
 Origen de la ruta: identifica el modo en que se descubrió la ruta. Las interfaces conectadas
directamente tienen dos códigos de origen de ruta (“C” identifica una red conectada
directamente, mientras que “L” identifica que esta es una ruta local).
 Red conectada directamente: la dirección IPv6 de la red conectada directamente.
 Distancia administrativa: identifica la confiabilidad del origen de la ruta. IPv6 utiliza las
mismas distancias que IPv4. El valor 0 indica el mejor origen y el más confiable.
 Interfaz de salida: identifica la interfaz de salida que se utiliza para reenviar paquetes a la
red de destino.

Nota: los enlaces seriales tienen anchos de banda de referencia configurados para observar la
forma en que las métricas de EIGRP seleccionan la mejor ruta. El ancho de banda de referencia no
es una representación realista de las redes modernas. Se utiliza solamente para proporcionar una
idea visual de la velocidad del enlace.

En la figura 1, se destacan las entradas de la tabla de routing para las tres redes remotas (es decir,
la LAN del R2, la LAN del R3 y el enlace entre el R2 y el R3). Las tres entradas se agregaron
mediante EIGRP.
En la figura 2, se muestra una entrada de la tabla de routing en el R1 para la ruta hacia la red
remota 2001:DB8:CAFE:3::/64 en el R3. La entrada indica la siguiente información:
 Origen de la ruta: identifica el modo en que se descubrió la ruta. Los códigos comunes
incluyen O (OSPF), D (EIGRP), R (RIP) y S (ruta estática).
 Red de destino: identifica la dirección de la red IPv6 remota.
 Distancia administrativa: identifica cuán confiable es el origen de la ruta. IPv6 utiliza las
mismas distancias que IPv4.
 Siguiente salto: identifica la dirección IPv6 del router siguiente al que se debe reenviar el
paquete.
 Interfaz de salida: identifica la interfaz de salida que se debe utilizar para reenviar un
paquete hacia el destino final.
Cuando un paquete IPv6 llega a una interfaz del router, el router analiza el encabezado de IPv6 e
identifica la dirección IPv6 de destino. A continuación, el router continúa con el proceso de
búsqueda del siguiente router.

El router examina las rutas de red de nivel 1 en busca de la mejor coincidencia con la dirección de
destino del paquete IPv6. Al igual que en IPv4, la coincidencia más larga es la mejor coincidencia.
Por ejemplo, si hay varias coincidencias en la tabla de routing, el router elige la ruta con la
coincidencia más larga. La coincidencia se encuentra entre los bits del extremo izquierdo de la
dirección IPv6 de destino del paquete y el prefijo IPv6 y la duración de prefijo en la tabla de routing
IPv6.

7.7 Resumen
Los routers utilizan protocolos de routing dinámico para facilitar el intercambio de información de
routing entre ellos. El propósito de los protocolos de routing dinámico incluye lo siguiente:
detección de redes remotas, mantenimiento de información de routing actualizada, selección de la
mejor ruta hacia las redes de destino y capacidad para encontrar una mejor ruta nueva si la ruta
actual deja de estar disponible. Si bien los protocolos de routing dinámico requieren menos
sobrecarga administrativa que el routing estático, requieren dedicar parte de los recursos de un
router a la operación del protocolo, incluidos tiempo de CPU y ancho de banda del enlace de red.
Las redes generalmente utilizan una combinación de routing estático y dinámico. El routing
dinámico es la mejor opción para las redes grandes, y el routing estático es más adecuado para las
redes de rutas internas.
Los protocolos de routing se encargan de detectar redes remotas y de mantener información de

red precisa. Cuando se produce un cambio en la topología, los protocolos de routing propagan esa
información por todo el dominio de routing. El proceso para lograr que todas las tablas de routing
alcancen un estado de coherencia, en el cual todos los routers en el mismo dominio o área de
routing tienen información completa y precisa acerca de la red, se denomina “convergencia”.
Algunos protocolos de routing convergen más rápido que otros.
Los protocolos de routing pueden clasificarse como con clase o sin clase, vector distancia o estado
de enlace, y protocolo de gateway interior o protocolo de gateway exterior.
Los protocolos vector distancia utilizan routers como “letreros” a lo largo de la ruta hacia el destino
final. La única información que conoce el router sobre una red remota es la distancia o métrica para

llegar a esa red y qué ruta o interfaz usar para alcanzarla. Los protocolos de enrutamiento vector
distancia no tienen un mapa en sí de la topología de la red.
Un router configurado con un protocolo de routing de estado de enlace puede crear una “vista
completa” o una topología de la red al reunir información proveniente de todos los demás routers.
Los protocolos de enrutamiento usan métricas para determinar el mejor camino o la ruta más corta
para llegar a una red de destino. Diferentes protocolos de enrutamiento pueden usar diferentes
métricas. Por lo general, una métrica inferior indica un mejor camino. Las métricas se pueden
determinar mediante los saltos, el ancho de banda, el retraso, la confiabilidad y la carga.
Los routers a veces obtienen información sobre múltiples rutas hacia la misma red a partir de rutas
estáticas como de protocolos de enrutamiento dinámico. Cuando un router aprende sobre una red
de destino desde más de un origen de enrutamiento, los routers Cisco usan el valor de distancia
administrativa para determinar qué origen usar. Cada protocolo de enrutamiento dinámico tiene un
valor administrativo único junto con las rutas estáticas y las redes conectadas directamente.
Cuanto menor es el valor administrativo, mayor es la preferencia del origen de ruta. Una red
conectada directamente es siempre el origen preferido, seguido de las rutas estáticas y luego los
diversos protocolos de enrutamiento dinámico.
El comando show ip protocolsmuestra los parámetros del protocolo de routing IPv4 configurados
actualmente en el router. Para IPv6, utilice show ipv6 protocols.
En los protocolos de routing de estado de enlace, como OSPF, un enlace es una interfaz en un
router. La información acerca del estado de dichos enlaces se conoce como estados de enlace.
Todos los protocolos de routing de estado de enlace aplican el algoritmo de Dijkstra para calcular
la mejor ruta. A este algoritmo se le llama comúnmente “algoritmo SPF” (Shortest Path First). Para
determinar el costo total de una ruta, este algoritmo utiliza costos acumulados a lo largo de cada
ruta, de origen a destino.


8 OSPF de área única

8.1 Introducción
El protocolo OSPF (Open Shortest Path First) es un protocolo de routing de estado de enlace
desarrollado como reemplazo del protocolo de routing vector distancia RIP. Durante los comienzos
de la tecnología de redes y de Internet, RIP era un protocolo de routing aceptable. Sin embargo, el
hecho de que RIP dependiera del conteo de saltos como única métrica para determinar la mejor
ruta rápidamente se volvió problemático. El uso del conteo de saltos no escala bien en redes más
grandes con varias rutas de distintas velocidades. OSPF presenta ventajas importantes en
comparación con RIP, ya que ofrece una convergencia más rápida y escala a implementaciones de
red mucho más grandes.
OSPF es un protocolo de enrutamiento sin clase que utiliza el concepto de áreas para realizar la
escalabilidad. En este capítulo, se abarcan las implementaciones y configuraciones básicas de
OSPF de área única.

8.2 Características de OSPF

8.2.1 Open Shortest Path First
Como se muestra en la figura 1, OSPF versión 2 (OSPFv2) se encuentra disponible para IPv4,
mientras que OSPF versión 3 (OSPFv3) se encuentra disponible para IPv6.
El desarrollo inicial de OSPF comenzó en 1987 por parte del grupo de trabajo de OSPF, el Grupo
de trabajo de ingeniería de Internet (IETF). En aquel momento, Internet era fundamentalmente una
red académica y de investigación financiada por el gobierno de los EE. UU .
En 1989, se publicó la especificación para OSPFv1 en RFC 1131. Se escribieron dos

implementaciones. Una implementación se desarrolló para ejecutarse en routers, y la otra se
desarrolló para ejecutarse en estaciones de trabajo UNIX. Esta última implementación se convirtió
en un proceso UNIX generalizado que se conoce como GATED. OSPFv1 era un protocolo de
routing experimental y nunca se implementó.
En 1991, John Moy introdujo OSPFv2 en RFC 1247. OSPFv2 ofrecía significativas mejoras
técnicas con respecto a OSPFv1. Por su diseño, es un protocolo sin clase, de modo que admite
VLSM y CIDR.
Al mismo tiempo que se presentó OSPF, ISO trabajaba en un protocolo de routing de estado de
enlace propio, Intermediate System-to-Intermediate System (IS-IS). El IETF eligió OSPF como
protocolo de gateway interior (IGP) recomendado.
En 1998, se actualizó la especificación OSPFv2 en RFC 2328, que en la actualidad sigue siendo la
RFC para OSPF.
En 1999, OSPFv3 para IPv6 se publicó en RFC 2740. OSPF para IPv6, creado por John Moy, Rob
Coltun y Dennis Ferguson, no solo es una nueva implementación de protocolo para IPv6, sino
también una importante reforma del funcionamiento del protocolo.
En 2008, se actualizó OSPFv3 en RFC 5340 como OSPF para IPv6.
Nota: en este capítulo, a menos que se identifique explícitamente como OSPFv2 u OSPFv3, el
término OSPF se utiliza para indicar conceptos que comparten ambas versiones.

Las características de OSPF, las cuales se muestran en la figura 1, incluyen lo siguiente:
 Sin clase: por su diseño, es un protocolo sin clase, de modo que admite VLSM y CIDR.
 Eficaz: los cambios de routing dirigen actualizaciones de routing (no hay actualizaciones
periódicas). Usa el algoritmo SPF para elegir la mejor ruta.
 Convergencia rápida: propaga rápidamente los cambios que se realizan a la red.
 Escalable: funciona bien en tamaños de redes pequeños y grandes. Se pueden agrupar los
routers en áreas para admitir un sistema jerárquico.
 Seguro: admite la autenticación de síntesis del mensaje 5 (MD5). Cuando están habilitados,
los routers OSPF solo aceptan actualizaciones de routing cifradas de peers con la misma
contraseña compartida previamente.
La distancia administrativa (AD) es la confiabilidad (o preferencia) del origen de la ruta. OSPF tiene
una distancia administrativa predeterminada de 110. Como se muestra en la figura 2, se prefiere
OSPF a IS-IS y RIP.

Todos los protocolos de routing comparten componentes similares. Todos usan mensajes de
protocolo de routing para intercambiar información de la ruta. Los mensajes contribuyen a armar
estructuras de datos, que luego se procesan con un algoritmo de routing.
Los tres componentes principales del protocolo de routing OSPF incluyen lo siguiente:
Estructuras de datos
OSPF crea y mantiene tres bases de datos (consulte la figura 1):
 Base de datos de adyacencia: crea la tabla de vecinos.
 Base de datos de estado de enlace (LSDB): crea la tabla de topología.
 Base de datos de reenvío: crea la tabla de routing.
Estas tablas contienen una lista de routers vecinos para intercambiar información de routing, y se
guardan y mantienen en la RAM.
Mensajes de protocolo de routing
OSPF intercambia mensajes para transmitir información de routing mediante cinco tipos de
paquetes. Estos paquetes, los cuales se muestran en la figura 2, son los siguientes:
 Paquete de saludo
 Paquete de descripción de la base de datos
 Paquete de solicitud de estado de enlace
 Paquete de actualización de estado de enlace
 Paquete de acuse de recibo de estado de enlace

Estos paquetes se usan para descubrir routers vecinos y también para intercambiar información de
routing a fin de mantener información precisa acerca de la red.
Algoritmo
La CPU procesa las tablas de vecinos y de topología mediante el algoritmo SPF de Dijkstra. El
algoritmo SPF se basa en el costo acumulado para llegar a un destino.
El algoritmo SPF crea un árbol SPF posicionando cada router en la raíz del árbol y calculando la
ruta más corta hacia cada nodo. Luego, el árbol SPF se usa para calcular las mejores rutas. OSPF
coloca las mejores rutas en la base de datos de reenvío, que se usa para crear la tabla de routing.

A fin de mantener la información de routing, los routers OSPF realizan el siguiente proceso
genérico de routing de estado de enlace para alcanzar un estado de convergencia:
1. Establecimiento de las adyacencias de vecinos (figura 1): los routers con OSPF habilitado deben
reconocerse entre sí en la red antes de poder compartir información. Los routers con OSPF
habilitado envían paquetes de saludo por todas las interfaces con OSPF habilitado para determinar
si hay vecinos presentes en esos enlaces. Si se detecta un vecino, el router con OSPF habilitado
intenta establecer una adyacencia de vecino con ese vecino.
2. Intercambio de notificaciones de estado de enlace (figura 2): una vez que se establecen las
adyacencias, los routers intercambian notificaciones de estado de enlace (LSA). Las LSA
contienen el estado y el costo de cada enlace conectado directamente. Los routers saturan a los
vecinos adyacentes con sus LSA. Los vecinos adyacentes que reciben las LSA saturan de
inmediato a otros vecinos conectados directamente, hasta que todos los routers en el área tengan
todas las LSA.
3. Creación de la tabla de topología (figura 3): una vez que se reciben las LSA, los routers con
OSPF habilitado crean la tabla de topología (LSDB) sobre la base de las LSA recibidas.
Finalmente, esta base de datos contiene toda la información sobre la topología de la red.
4. Ejecución del algoritmo SPF (figuras 4 y 5): a continuación, los routers ejecutan el algoritmo
SPF. Los engranajes que se muestran en la ilustración se utilizan para indicar la ejecución del
algoritmo SPF. El algoritmo SPF crea el árbol SPF.
En la figura 6, se muestra el contenido del árbol SPF del R1.
Las mejores rutas del árbol SPF se insertan en la tabla de routing. Las decisiones de routing se
toman sobre la base de las entradas de la tabla de routing.



Para que OSPF sea más eficaz y escalable, este protocolo admite el routing jerárquico mediante
áreas. Un área OSPF es un grupo de routers que comparten la misma información de estado de
enlace en sus LSDB.
OSPF se puede implementar de dos maneras:
 OSPF de área única: en la figura 1, todos los routers se encuentran en un área llamada
“área backbone” (área 0).
 OSPF multiárea: en la figura 2, OSPF se implementa mediante varias áreas, de manera

jerárquica. Todas las áreas deben conectarse al área backbone (área 0). Los routers que
interconectan las áreas se denominan “routers fronterizos de área” (ABR).
Con OSPF multiárea, OSPF puede dividir un sistema autónomo (AS) grande en áreas más
pequeñas, a fin de admitir el routing jerárquico. Con el routing jerárquico, se sigue produciendo el
routing entre áreas, y muchas de las operaciones de routing que implican una gran exigencia para
el procesador, como volver a calcular la base de datos, se guardan en un área.
Por ejemplo, cada vez que un router recibe información nueva acerca de un cambio de topología
dentro del área (como el agregado, la eliminación o la modificación de un enlace), el router debe
volver a ejecutar el algoritmo SPF, crear un nuevo árbol SPF y actualizar la tabla de routing. El
algoritmo SPF representa una gran exigencia para el CPU y el tiempo que le toma realizar los
cálculos depende del tamaño del área.
Nota: los cambios de topología se distribuyen a los routers de otras áreas en formato vector
distancia. En otras palabras, estos routers solo actualizan sus tablas de routing y no necesitan
volver a ejecutar el algoritmo SPF.
Si hubiera demasiados routers en un área, la LSDB sería muy grande y se incrementaría la carga
en la CPU. Por lo tanto, la disposición de los routers en distintas áreas divide de manera eficaz una
base de datos potencialmente grande en bases de datos más pequeñas y más fáciles de
administrar.

Las posibilidades de topología jerárquica de OSPF multiárea presentan las siguientes ventajas:
 Tablas de routing más pequeñas: se crean menos entradas de tabla de routing, ya que las
direcciones de red pueden resumirse entre áreas. La sumarización de ruta no está habilitada
de manera predeterminada.
 Menor sobrecarga de actualización de estado de enlace: minimiza los requisitos de

procesamiento y memoria.
 Menor frecuencia de cálculos de SPF: localiza el impacto de un cambio de topología dentro

de un área. Por ejemplo, minimiza el impacto de las actualizaciones de routing debido a que
la saturación con LSA se detiene en el límite del área.
En la figura 3, se ilustran estas ventajas.
Por ejemplo, el R2 es un ABR para el área 51. Como ABR, resumiría las rutas del área 51 en el
área 0. Cuando uno de los enlaces resumidos falla, las LSA se intercambian solo dentro del
área 51. Los routers del área 51 deben volver a ejecutar el algoritmo SPF para identificar las
mejores rutas. Sin embargo, los routers del área 0 y el área 1 no reciben ninguna actualización,
motivo por el cual no ejecutan el algoritmo SPF.
Este capítulo se centra en OSPF de área única.


8.2.2 Mensajes OSPF
Los mensajes OSPF que se transmiten a través de un enlace Ethernet contienen la siguiente
información:
 Encabezado de la trama de Ethernet de enlace de datos:identifica las direcciones MAC de

multidifusión de destino 01-00-5E-00-00-05 o 01-00-5E-00-00-06. (figura 1)
 Encabezado del paquete IP:identifica el campo 89 del protocolo IPv4, que indica que se
trata de un paquete OSPF. También identifica una de dos direcciones OSPF de multidifusión,
224.0.0.5 o 224.0.0.6. (Figura 2)
 Encabezado del paquete OSPF:identifica el tipo de paquete OSPF, la ID del router y la ID

del área. (Figura 3)
 Datos específicos del tipo de paquete OSPF: contiene información del tipo de paquete
OSPF. El contenido varía según el tipo de paquete. En este caso, se trata de un encabezado
de IPv4. (figura 4)

OSPF utiliza paquetes de estado de enlace (LSP) para establecer y mantener adyacencias de
vecinos, así como para intercambiar actualizaciones de routing.
En la ilustración, se muestran los cinco tipos de LSP que usa OSPF. Cada paquete cumple una
función específica en el proceso de enrutamiento de OSPF:
 Tipo 1, paquete de saludo: se usa para establecer y mantener la adyacencia con otros
routers OSPF.
 Tipo 2, paquete de descripción de base de datos (DBD): contiene una lista abreviada de la
LSDB del router emisor, y los routers receptores la usan para compararla con la LSDB local.
Para crear un árbol SPF preciso, la LSDB debe ser idéntica en todos los routers de estado de
enlace dentro de un área.
 Tipo 3, paquete de solicitud de estado de enlace (LSR): los routers receptores pueden
requerir más información sobre cualquier entrada de la DBD mediante el envío de un LSR.

 Tipo 4, paquete de actualización de estado de enlace (LSU): se utiliza para responder a

los LSR y anunciar la nueva información. Los LSU contienen siete tipos de LSA.
 Tipo 5, paquete de acuse de recibo de estado de enlace (LSAck): cuando se recibe una
LSU, el router envía un LSAck para confirmar la recepción de la LSU. El campo de datos del
LSAck está vacío.
Paquete de saludo
El paquete OSPF de tipo 1 es el paquete de saludo. Los paquetes de saludo se utilizan para:
 Descubrir vecinos OSPF y establecer adyacencias de vecinos.
 Publicar parámetros en los que dos routers deben acordar convertirse en vecinos.
 Elegir el Router designado (DR) y el Router designado de respaldo (BDR) en redes de

accesos múltiples, como Ethernet y Frame Relay. Los enlaces punto a punto no requieren DR
o BDR.
En la ilustración, se muestran los campos contenidos en el paquete de tipo 1, el paquete de saludo.

Los campos importantes que se muestran en la figura incluyen:
 Tipo: identifica el tipo de paquete. Un uno (1) indica un paquete de saludo. Un valor de 2
identifica un paquete DBD, un valor de 3 identifica un paquete LSR, un valor de 4 identifica un
paquete LSU, y un valor de 5 identifica un paquete LSAck.
 ID del router: un valor de 32 bits expresado en notación decimal con puntos (una dirección
IPv4) que se utiliza para identificar exclusivamente el router de origen.
 ID de área: el área en la cual se originó el paquete.
 Máscara de red: la máscara de subred asociada a la interfaz emisora.
 Intervalo de saludo: especifica la frecuencia, en segundos, a la que un router envía

paquetes de saludo. El intervalo de saludo predeterminado en redes de accesos múltiples es
de 10 segundos. Este temporizador debe ser el mismo en los routers vecinos; de lo contrario,
no se establece ninguna adyacencia.

 Prioridad del router: se utiliza en una elección de DR/BDR. La prioridad predeterminada

para todos los routers OSPF es 1, pero se puede modificar manualmente desde 0 hasta 255.
Cuanto mayor es el valor, mayor es la probabilidad de que el router sea el DR en el enlace.
 Intervalo muerto: es el tiempo en segundos que espera un router para establecer

comunicación con un vecino antes de declarar que el router vecino no funciona. De manera
predeterminada, el intervalo muerto del router es cuatro veces el intervalo de saludo. Este
temporizador debe ser el mismo en los routers vecinos; de lo contrario, no se establece
ninguna adyacencia.
 Router designado (DR): la ID del router del DR.
 Router designado de respaldo (BDR): la ID del router del BDR.
 Lista de vecinos: la lista en la que se identifican las ID del router de todos los routers
adyacentes.
Como se muestra en la ilustración, los paquetes de saludo OSPF se transmiten a la dirección de

multidifusión 224.0.0.5 en IPv4 y FF02::5 en IPv6 (todos los routers OSPF) cada:
 10 segundos (intervalo predeterminado en redes de accesos múltiples y punto a punto)
 30 segundos (intervalo predeterminado en redes multiacceso sin difusión [NBMA], por

ejemplo, Frame Relay)
El intervalo muerto es el período que el router espera para recibir un paquete de saludo antes de
declarar al vecino como inactivo. Si el intervalo muerto caduca antes de que los routers reciban un
paquete de saludo, OSPF elimina ese vecino de su LSDB. El router satura la LSDB con
información acerca del vecino inactivo por todas las interfaces con OSPF habilitado.

Cisco utiliza un intervalo predeterminado de cuatro veces el intervalo de saludo:
 40 segundos (intervalo predeterminado en redes de accesos múltiples y punto a punto)
 120 segundos (intervalo predeterminado en redes NBMA, por ejemplo, Frame Relay.
Los routers inicialmente intercambian paquetes DBD de tipo 2, que son una lista abreviada de la
LSDB del router emisor que los routers receptores usan para compararla con la LSDB local.
Los routers receptores usan paquetes LSR de tipo 3 para solicitar más información acerca de una
entrada de la DBD.
El paquete LSU de tipo 4 se utiliza para responder a un paquete LSR.
Los paquetes LSU también se usan para reenviar actualizaciones de routing OSPF, como cambios
de enlace. Específicamente, un paquete LSU puede contener 11 tipos de LSA OSPFv2, como se
muestra en la ilustración. OSPFv3 cambió el nombre de varias de estas LSA y también contiene
dos LSA adicionales.
Nota: en ocasiones, la diferencia entre los términos LSU y LSA puede resultar confusa, ya que
estos términos a menudo se usan de manera indistinta. Sin embargo, una LSU contiene una o más
LSA.

8.2.3 Funcionamiento de OSPF
Cuando un router OSPF se conecta inicialmente a una red, intenta hacer lo siguiente:
 Crear adyacencias con los vecinos
 Intercambiar información de routing
 Calcular las mejores rutas
 Lograr la convergencia
Al intentar lograr la convergencia, OSPF atraviesa varios estados:
 Estado Down
 Estado Init
 Estado Two-Way
 Estado ExStart

 Estado Exchange
 Estado Loading
 Estado Full
Cuando se habilita OSPF en una interfaz, el router debe determinar si existe otro vecino OSPF en
el enlace. Para hacerlo, el router reenvía un paquete de saludo con la ID del router por todas las
interfaces con OSPF habilitado. El proceso OSPF utiliza la ID del router OSPF para identificar cada
router en el área OSPF de manera exclusiva. Una ID de router es una dirección IP asignada para
identificar un router específico entre peers OSPF.
Cuando un router vecino con OSPF habilitado recibe un paquete de saludo con una ID de router
que no figura en su lista de vecinos, el router receptor intenta establecer una adyacencia con el
router que inició la comunicación.
Consulte el R1 de la figura 1. Cuando se habilita OSPF, la interfaz Gigabit Ethernet 0/0 habilitada
pasa del estado Down al estado Init. El R1 comienza a enviar paquetes de saludo por todas las
interfaces con OSPF habilitado para descubrir vecinos OSPF a fin de desarrollar adyacencias con
ellos.
En la figura 2, el R2 recibe el paquete de saludo del R1 y agrega la ID del router R1 a su lista de

vecinos. A continuación, el R2 envía un paquete de saludo al R1. El paquete contiene la ID del
router R2 y la ID del router R1 en la lista de vecinos de la misma interfaz.
En la figura 3, el R1 recibe el saludo y agrega la ID del router R2 a su lista de vecinos OSPF.

También advierte su propia ID de router en la lista de vecinos del paquete de saludo. Cuando un
router recibe un paquete de saludo en el que se indica su ID de router en la lista de vecinos, el
router pasa del estado Init al estado Two-Way.

La acción realizada en el estado Two-Way depende del tipo de interconexión de los routers
adyacentes:
 Si los dos vecinos adyacentes se interconectan a través de un enlace punto a punto, pasan
de inmediato del estado Two-Way a la fase de sincronización de bases de datos.
 Si los routers se interconectan a través de una red Ethernet común, se debe elegir un router
designado DR y un BDR.
Debido a que el R1 y el R2 se interconectan a través de una red Ethernet, se elije un DR y un BDR.

Como se muestra en la figura 4, el R2 se convierte en el DR, y el R1 es el BDR. Este proceso tiene
lugar solo en las redes de accesos múltiples, como las LAN Ethernet.
Los paquetes de saludo se intercambian de manera continua para mantener la información del
router.
¿Por qué se necesita elegir un DR y un BDR?
Las redes de accesos múltiples pueden crear dos retos para OSPF en relación con la saturación
de las LSA:
 Creación de varias adyacencias: las redes Ethernet podrían interconectar muchos routers
OSPF con un enlace común. La creación de adyacencias con cada router es innecesaria y no
se recomienda, ya que conduciría al intercambio de una cantidad excesiva de LSA entre
routers en la misma red.
 Saturación intensa con LSA: los routers de estado de enlace saturan con sus LSA cada vez
que se inicializa OSPF o cuando se produce un cambio en la topología. Esta saturación
puede llegar a ser excesiva.
Para comprender el problema de las adyacencias múltiples, se debe estudiar una fórmula:
Para cualquier cantidad de routers (designada como n) en una red de accesos múltiples, hay n (n –
1) / 2 adyacencias.

En la figura 1, se muestra una topología simple de cinco routers, los cuales están conectados a la
misma red Ethernet de accesos múltiples. Sin ningún tipo de mecanismo para reducir la cantidad
de adyacencias, estos routers en forma colectiva formarán 10 adyacencias:
5 (5 – 1) / 2 = 10
Puede parecer poco, pero a medida que se agregan routers a la red, la cantidad de adyacencias
aumenta notablemente, como se muestra en la figura 2.
Para comprender el problema de la saturación intensa con LSA, reproduzca la animación de la

figura 3. En la animación, el R2 envía una LSA. Este evento hace que cada router también envíe
una LSA. Los acuses de recibo requeridos que se envían por cada LSA recibida no se muestran en
la animación. Si cada router en una red de accesos múltiples tuviera que saturar y reconocer todas
las LSA recibidas a todos los demás routers en la misma red de accesos múltiples, el tráfico de la
red se volvería bastante caótico.
La solución para administrar la cantidad de adyacencias y la saturación con LSA en una red de
accesos múltiples es el DR. En las redes de accesos múltiples, OSPF elige un DR para que
funcione como punto de recolección y distribución de las LSA enviadas y recibidas. También se
elige un BDR en caso de que falle el DR. Todos los otros routers se convierten en DROTHER. Un
DROTHER es un router que no funciona como DR ni como BDR.

Después del estado Two-Way, los routers pasan a los estados de sincronización de bases de
datos. Mientras que el paquete de saludo se utilizó para establecer adyacencias de vecinos, los
otros cuatro tipos de paquetes OSPF se utilizan durante el proceso de intercambio y sincronización
de LSDB.
En el estado ExStart, se crea una relación de maestro y esclavo entre cada router y su DR y su
BDR adyacentes. El router con la mayor ID de router funciona como maestro para el estado
Exchange. En la figura 1, el R2 se convierte en maestro.
En el estado Exchange, los routers maestros y esclavos intercambian uno o más paquetes DBD.
Un paquete DBD incluye información acerca del encabezado de la entrada de LSA que aparece en
la LSDB del router. Las entradas pueden hacer referencia a un enlace o a una red. Cada
encabezado de entrada de LSA incluye información acerca del tipo de estado de enlace, la
dirección del router que realiza el anuncio, el costo del enlace y el número de secuencia. El router
usa el número de secuencia para determinar qué tan nueva es la información de estado de enlace
recibida.
En la figura 2, el R2 envía un paquete DBD al R1. Cuando el R1 recibe la DBD, realiza las
siguientes acciones:
1. Confirma la recepción de la DBD con el paquete LSAck.
2. A continuación, el R1 envía paquetes DBD al R2.
3. El R2 acusa recibo al R1.
El R1 compara la información recibida con la información que tiene en su propia LSDB. Si el

paquete DBD tiene una entrada de estado de enlace más actual, el router pasa al estado Loading.
Por ejemplo, en la figura 3, el R1 envía una LSR con respecto a la red 172.16.6.0 al R2. El R2
responde con la información completa sobre 172.16.6.0 en un paquete LSU. Una vez más, cuando

el R1 recibe una LSU, envía un LSAck. A continuación, el R1 agrega las nuevas entradas de
estado de enlace a su LSDB.
Después de cumplir con todas las LSR para un router determinado, los routers adyacentes se
consideran sincronizados y en estado Full.
En la medida en que los routers vecinos sigan recibiendo paquetes de saludo, la red en las LSA
transmitidas permanece en la base de datos de topología. Una vez que se sincronizan las bases
de datos topológicas, se envían actualizaciones (LSU) a los vecinos solo en las siguientes
circunstancias:
 Cuando se percibe un cambio (actualizaciones incrementales).
 Cada 30 minutos.


8.3 Configuración de OSPFv2 de área única

8.3.1 ID del router OSPF
OSPFv2 es un protocolo de routing de estado de enlace para IPv4 que se presentó en 1991. OSPF
se diseñó como alternativa a otro protocolo de routing IPv4, RIP.
En la ilustración, se muestra la topología que se usa para configurar OSPFv2 en esta sección. Es
posible que los tipos de interfaces seriales y sus anchos de banda asociados no reflejen
necesariamente los tipos de conexiones más frecuentes que se encuentran en las redes en la
actualidad. Los anchos de banda de los enlaces seriales que se usan en esta topología se eligieron
para ayudar a explicar el cálculo de las métricas de los protocolos de routing y el proceso de
selección de la mejor ruta.
Los routers en la topología tienen una configuración inicial, incluidas las direcciones de interfaz. En
este momento, ninguno de los routers tiene configurado routing estático o routing dinámico. Todas
las interfaces en los routers R1, R2 y R3 (excepto la interfaz loopback en el R2) se encuentran
dentro del área backbone de OSPF. El router ISP se usa como gateway del dominio de routing a
Internet.
Nota: en esta topología, la interfaz loopback se usa para simular el enlace WAN a Internet.
En la figura 1, se muestra la topología de referencia para este tema. OSPFv2 se habilita con el
comando router ospfid-proceso del modo de configuración global. El valor id-proceso representa
un número entre 1 y 65 535, y lo elige el administrador de red. El valor id-procesotiene importancia
en el ámbito local, lo que significa que no necesita ser el mismo valor en los demás routers OSPF
para establecer adyacencias con esos vecinos.
En la figura 2, se proporciona un ejemplo del ingreso al modo de configuración de OSPF del router
en el R1.
Nota: la lista de comandos se modificó para que se muestren solo los comandos que se utilizan en
este capítulo. Para obtener una lista completa de comandos, utilice los verificadores de sintaxis de
la figura 3.

Utilice el verificador de sintaxis de la figura 3 para ingresar al modo de configuración de router

OSPF en el R2 y enumerar los comandos disponibles en la petición de entrada.
Para participar en un dominio OSPF, cada router requiere una ID de router. La ID del router puede
estar definida por un administrador o puede ser asignada en forma automática por el router. El
router con OSPF habilitado usa la ID del router para realizar lo siguiente:
 Identificar el router de manera exclusiva: otros routers usan la ID del router para identificar
de forma exclusiva cada router dentro del dominio OSPF y todos los paquetes que se originan
en ellos.
 Participar en la elección del DR: en un entorno LAN de accesos múltiples, la elección del
DR se lleva a cabo durante el establecimiento inicial de la red OSPF. Cuando se activan los
enlaces OSPF, el dispositivo de routing configurado con la prioridad más alta se elige como
DR. Si se parte de la suposición de que no hay ninguna prioridad configurada o de que hay
un empate, se elige como DR el router con la mayor ID de router. El dispositivo de routing con
la segunda ID de router más alta se elige como BDR.

¿Pero de qué manera el router determina la ID de router? Como se muestra en la ilustración, los
routers Cisco derivan la ID del router sobre la base de uno de tres criterios, en el siguiente orden
de preferencia:
 La ID del router se configura explícitamente con el comando router-id id-router del modo de
configuración de OSPF del router. El valor id-router es cualquier valor de 32 bits expresado
como dirección IPv4. Este es el método recomendado para asignar una ID de router.
 Si la ID del router no se configura explícitamente, el router elige la dirección IPv4 más alta de
cualquiera de las interfaces loopback configuradas. Esta constituye la segunda mejor opción
para asignar una ID de router.
 Si no se configuró ninguna interfaz loopback, el router elige la dirección IPv4 activa más alta
de cualquiera de sus interfaces físicas. Este es el método menos recomendado, ya que hace
que a los administradores les resulte más difícil diferenciar entre routers específicos.
Si el router usa la dirección IPv4 más alta para la ID del router, la interfaz no necesita tener OSPF
habilitado. Esto significa que no se necesita incluir la dirección de interfaz en uno de los
comandos network de OSPF para que el router use esa dirección IP como ID del router. El único
requisito es que la interfaz esté activa y en estado up (activo).
Nota: la ID del router parece una dirección IP, pero no es enrutable y, por lo tanto, no se incluye en
la tabla de routing, a menos que el proceso de routing de OSPF elija una interfaz (física o
loopback) que esté definida en forma adecuada por un comando network.
Utilice el comando router-id id-router del modo de configuración del router para asignar
manualmente un valor de 32 bits expresado como dirección IPv4 a un router. Un router OSPF se
identifica ante otros routers mediante esta ID del router.
Como se muestra en la figura 1, se configuró una ID de router 1.1.1.1 en el R1, una ID 2.2.2.2 en el
R2 y una ID 3.3.3.3 en el R3.

En la figura 2, se asigna la ID de router 1.1.1.1 al R1. Utilice el comando show ip protocols para
verificar la ID del router.
Nota: el R1 nunca se había configurado con una ID de router OSPF. De haber sido así, se debería
modificar la ID del router.
Si la ID del router es la misma en dos routers vecinos, el router muestra un mensaje de error similar
al siguiente:
%OSPF-4-DUP_RTRID1: Detected router with duplicate router ID (Se detectó un router con una ID
de router duplicada).
Para corregir este problema, configure todos los routers para que tengan una ID del router OSPF
única.
Utilice el verificador de sintaxis de la figura 3 para asignar la ID del router al R2 y al R3.

En ocasiones, es necesario modificar una ID de router, por ejemplo, cuando un administrador de

red establece un nuevo esquema de ID de router para la red. Sin embargo, una vez que un router
selecciona una ID de router, un router OSPF activo no permite que se modifique la ID del router
hasta que se vuelva a cargar el router o se borre el proceso OSPF.
En la figura 1, observe que la ID del router actual es 192.168.10.5. La ID del router debería ser
1.1.1.1.
En la figura 2, se asigna la ID de router 1.1.1.1 al R1. Observe que aparece un mensaje informativo
que indica que se debe borrar el proceso OSPF o se debe volver a cargar el router. Esto ocurre
debido a que el R1 ya tiene adyacencias con otros vecinos que utilizan la ID de router
192.168.10.5. Se deben volver a negociar esas adyacencias utilizando la nueva IP de router
1.1.1.1.
El método preferido para restablecer la ID del router es borrar el proceso OSPF.
En la figura 3, se borra el proceso de routing de OSPF con el comando clear ip ospf process del
modo EXEC privilegiado. Esto obliga al protocolo OSPF en el R1 a pasar a los estados Down e Init.
Observe los mensajes de cambio de adyacencia de Full a Down y de Loading a Full. El
comando show ip protocols verifica que se haya cambiado la ID del router.
Utilice el verificador de sintaxis de la figura 4 para modificar la ID del router para el R1.

Una ID de router también se puede asignar mediante una interfaz loopback.
La dirección IPv4 de la interfaz loopback se debe configurar con una máscara de subred de 32 bits
(255.255.255.255). Esto crea una ruta de host. Una ruta de host de 32 bits no se anuncia como
ruta a otros routers OSPF.

En el ejemplo de la ilustración, se muestra cómo configurar una interfaz loopback con una ruta de
host en el R1. El R1 usa la ruta de host como ID del router, suponiendo que no se configuró
ninguna ID de router de manera explícita o que no se obtuvo anteriormente.
Nota: algunas versiones anteriores de IOS no reconocen el comando router-id; por lo tanto, la
mejor forma de establecer la ID del router en esos routers es mediante una interfaz loopback.
8.3.2 Configuración de OSPFv2 de área única
El comando network determina qué interfaces participan en el proceso de routing para un área
OSPF. Cualquier interfaz de un router que coincida con la dirección de red en el comando network
está habilitada para enviar y recibir paquetes OSPF. Como consecuencia, se incluye la dirección
de red (o de subred) para la interfaz en las actualizaciones de routing OSPF.
La sintaxis básica del comando es network dirección-red máscara-wildcard area id-área.
La sintaxis area id-área se refiere al área OSPF. Al configurar OSPF de área única, se debe
configurar el comando network con el mismo valor id-área en todos los routers. Si bien se puede
usar cualquier ID de área, es aconsejable utilizar una ID de área 0 con OSPF de área única. Esta
convención facilita la tarea si posteriormente se modifica la red para admitir OSPF multiárea.
En la ilustración, se muestra la topología de referencia.

OSPFv2 usa la combinación de argumentos dirección-red máscara-wildcard para habilitar OSPF en

las interfaces. Por su diseño, OSPF es un protocolo sin clase; por lo tanto, siempre se requiere la
máscara wildcard. Al identificar las interfaces que participan en un proceso de routing, la máscara
wildcard generalmente es el valor inverso a la máscara de subred configurada en esa interfaz.
Una máscara wildcard es una cadena de 32 dígitos binarios que el router utiliza para determinar
qué bits de la dirección debe examinar para obtener una coincidencia. En una máscara de subred,
un 1 binario equivale a una coincidencia, y un 0 binario no es una coincidencia. En una máscara
wildcard, sucede lo contrario:
 Bit 0 de máscara wildcard: coincide con el valor de bit correspondiente en la dirección.
 Bit 1 de máscara wildcard: omite el valor del bit correspondiente en la dirección.
El método más sencillo para calcular una máscara wildcard es restar la máscara de subred de la
red a 255.255.255.255.
En el ejemplo de la figura 1, se calcula la máscara wildcard a partir de la dirección de red

192.168.10.0/24. Para hacerlo, se resta la máscara de subred 255.255.255.0 a 255.255.255.255,
cuyo resultado es 0.0.0.255. Por lo tanto,192.168.10.0/24 es 192.168.10.0 con una máscara
wildcard 0.0.0.255.
En el ejemplo de la figura 2, se calcula la máscara wildcard a partir de la dirección de red

192.168.10.64/26. Para hacerlo, se resta la máscara de subred 255.255.255.192 a
255.255.255.255, cuyo resultado es 0.0.0.63. Por lo tanto,192.168.10.0/26 es 192.168.10.0 con
una máscara wildcard 0.0.0.63.

Existen varias maneras de identificar las interfaces que participan en el proceso de routing
OSPFv2.
En la figura 1, se muestran los comandos requeridos para determinar qué interfaces del R1
participan en el proceso de routing OSPFv2 para un área. Observe el uso de las máscaras wildcard
para identificar las respectivas interfaces sobre la base de sus direcciones de red. Dado que se
trata de una red OSPF de área única, todas las ID de área se establecen en 0.
Como alternativa, se puede habilitar OSPFv2 con el comando network dirección-ip-

interfaz 0.0.0.0area id-área del modo de configuración del router.
En la figura 2, se proporciona un ejemplo de cómo especificar la dirección IPv4 de interfaz con una
máscara wildcard de cuádruple cero. La introducción de network 172.16.3.1 0.0.0.0 area 0 en el
R1 le indica al router que habilite la interfaz Serial0/0/0 para el proceso de routing. Como resultado,
el proceso OSPFv2 anuncia la red que se encuentra en esta interfaz (172.16.3.0/30).
La ventaja de especificar la interfaz es que no se necesita calcular la máscara wildcard. OSPFv2

usa la dirección y máscara de subred de la interfaz para determinar qué red debe anunciar.
Algunas versiones de IOS permiten introducir la máscara de subred en lugar de la máscara

wildcard. Luego, IOS convierte la máscara de subred al formato de la máscara wildcard.
Utilice el verificador de sintaxis de la figura 3 para anunciar las redes conectadas al R2.
Nota: mientras completa el verificador de sintaxis, observe los mensajes informativos que
describen la adyacencia entre el R1 (1.1.1.1) y el R2 (2.2.2.2). El esquema de direccionamiento
IPv4 utilizado para la ID del router facilita la identificación del vecino.
De manera predeterminada, los mensajes OSPF se reenvían por todas las interfaces con OSPF
habilitado. Sin embargo, estos mensajes solo necesitan enviarse por las interfaces que se
conectan a otros routers con OSPF habilitado.

Consulte la topología de la ilustración. Los mensajes OSPF se reenvían por la interfaz G0/0 de los
tres routers, aunque no exista ningún vecino OSPF en esa LAN. El envío de mensajes
innecesarios en una LAN afecta la red de tres maneras:
 Uso ineficaz del ancho de banda:se consume el ancho de banda disponible con el
transporte de mensajes innecesarios. Los mensajes se transmiten por multidifusión; por lo
tanto, los switches también reenvían los mensajes por todos los puertos.
 Uso ineficaz de los recursos: todos los dispositivos en la LAN deben procesar el mensaje y,
finalmente, descartarlo.
 Mayor riesgo de seguridad: anunciar actualizaciones en una red de difusión constituye un

riesgo de seguridad. Los mensajes OSPF se pueden interceptar con software de detección de
paquetes. Las actualizaciones de enrutamiento se pueden modificar y enviar de regreso al
router, y dañar la tabla de enrutamiento con métricas falsas que desorientan el tráfico.
Utilice el comando passive-interfacedel modo de configuración del router para evitar la

transmisión de mensajes de routing a través de una interfaz del router, pero sin dejar de permitir
que se anuncie esa red a otros routers, como se muestra en la figura 1. Concretamente, el
comando evita que se envíen los mensajes de routing por la interfaz especificada. Sin embargo, la
red a la que pertenece la interfaz especificada se sigue anunciando en los mensajes de routing que
se envían por otras interfaces.
Por ejemplo, no es necesario que el R1, el R2 y el R3 reenvíen mensajes OSPF por sus interfaces
LAN. La configuración identifica la interfaz G0/0 del R1 como pasiva.
Es importante saber que no se puede formar una adyacencia de vecino a través de una interfaz
pasiva. Esto se debe a que los paquetes de estado de enlace no se pueden enviar ni confirmar.
A continuación, se usa el comando show ip protocols para verificar que la interfaz Gigabit
Ethernet sea pasiva, como se muestra en la figura 2. Observe que la interfaz G0/0 ahora figura en
la sección Passive Interface(s) (Interfaces pasivas). La red 172.16.1.0 aún figura en Routing for

Networks (Routing para redes), lo que significa que esta red aún se incluye como entrada de ruta
en las actualizaciones OSPF que se envían al R2 y al R3.
Nota: OSPFv2 y OSPFv3 admiten el comando passive-interface.
Utilice el verificador de sintaxis de la figura 3 para configurar la interfaz LAN como interfaz pasiva
en el R2.
Como alternativa, todas las interfaces se pueden convertir en pasivas con el comandopassive-
interface default. Las interfaces que no deben ser pasivas se pueden volver a habilitar con el
comando no passive-interface.
Continúe utilizando el verificador de sintaxis de la figura 3 para configurar la interfaz LAN como
interfaz pasiva en el R3.
Nota: mientras completa el verificador de sintaxis, observe los mensajes informativos de estado de
OSPF a medida que todas las interfaces se hacen pasivas y las dos interfaces seriales se hacen
no pasivas.

8.3.3 Costo OSPF
Recuerde que un protocolo de routing utiliza una métrica para determinar la mejor ruta de un
paquete a través de una red. Una métrica indica la sobrecarga que se requiere para enviar
paquetes a través de una interfaz determinada. OSPF utiliza el costo como métrica. Cuando el
costo es menor, la ruta es mejor que una con un costo mayor.
El costo de una interfaz es inversamente proporcional al ancho de banda de la interfaz. Por lo

tanto, cuanto mayor es el ancho de banda, menor es el costo. Cuanto más sobrecarga y retraso,
mayor es el costo. Por lo tanto, una línea Ethernet de 10 Mb/s tiene un costo mayor que una línea
Ethernet de 100 Mb/s.
La fórmula que se usa para calcular el costo de OSPF es la siguiente:
 Costo = ancho de banda de referencia / ancho de banda de la interfaz
El ancho de banda de referencia predeterminado es 10^8 (100 000 000); por lo tanto, la fórmula es
la siguiente:
 Costo = 100 000 000 bps /ancho de banda de la interfaz en bps
Consulte la tabla de la ilustración para obtener un desglose del cálculo del costo. Observe que las
interfaces FastEthernet, Gigabit Ethernet y 10 GigE comparten el mismo costo, debido a que el
valor del costo de OSPF debe ser un número entero. En consecuencia, dado que el ancho de
banda de referencia predeterminado se establece en 100 Mb/s, todos los enlaces que son más
rápidos que Fast Ethernet también tienen un costo de 1.
El costo de una ruta OSPF es el valor acumulado desde un router hasta la red de destino.

Por ejemplo, en la figura 1, el costo para llegar desde el R1 hasta la LAN 172.16.2.0/24 del R2
debe ser el siguiente:
 Costo del enlace serial del R1 al R2 = 64
 Costo del enlace Gigabit Ethernet en el R2 = 1
 Costo total para llegar a 172.16.2.0/24=65
En la tabla de routing del R1 de la figura 2, se confirma que la métrica para llegar a la LAN del R2
equivale a un costo de 65.
OSPF utiliza un ancho de banda de referencia de 100 Mb/s para todos los enlaces que sean
iguales o más rápidos que una conexión Fast Ethernet. Por lo tanto, el costo asignado a una
interfaz Fast Ethernet con un ancho de banda de interfaz de 100 Mb/s sería igual a 1.

Costo = 100 000 000 bps /100 000 000 = 1
Si bien este cálculo funciona para las interfaces Fast Ethernet, es problemático para los enlaces
que son más rápidos que 100 Mb/s, debido a que la métrica de OSPF solo utiliza números enteros
como costo final de un enlace. Si se calcula un valor menor que un número entero, OSPF
redondea al número entero más cercano. Por este motivo, desde la perspectiva de OSPF, una
interfaz con un ancho de banda de interfaz de 100 Mb/s (un costo de 1) tiene el mismo costo que
una interfaz con un ancho de banda de 100 Gb/s (un costo de 1).
Para ayudar a OSPF a determinar la ruta correcta, se debe cambiar el ancho de banda de
referencia a un valor superior, a fin de admitir redes con enlaces más rápidos que 100 Mb/s.
Ajuste del ancho de banda de referencia
El cambio del ancho de banda de referencia en realidad no afecta la capacidad de ancho de banda
en el enlace, sino que simplemente afecta el cálculo utilizado para determinar la métrica. Para
ajustar el ancho de banda de referencia, use el comando de configuración del router auto-cost
reference-bandwidth Mb/s. Se debe configurar este comando en cada router en el dominio OSPF.
Observe que el valor se expresa en Mb/s; por lo tanto, a fin de ajustar los costos para estas
interfaces, utilice los siguientes comandos:
 Gigabit Ethernet: auto-cost reference-bandwidth 1000
 10 Gigabit Ethernet: auto-cost reference-bandwidth 10000
Para volver al ancho de banda de referencia predeterminado, use el comando auto-cost

reference-bandwidth 100.
En la tabla de la figura 1, se muestra el costo de OSPF si el ancho de banda de referencia se

establece en Gigabit Ethernet. Si bien los valores de métrica aumentan, OSPF toma mejores
decisiones debido a que ahora puede diferenciar entre enlaces FastEthernet y enlaces Gigabit
Ethernet.
En la figura 2, se muestra el costo de OSPF si se ajusta el ancho de banda de referencia para

admitir 10 enlaces Gigabit Ethernet. Se debe ajustar el ancho de banda de referencia cada vez que
haya enlaces más rápidos que FastEthernet (100 Mb/s).
Nota: los costos representan números enteros que se redondearon hacia abajo.
En la figura 3, todos los routers se configuraron para admitir el enlace Gigabit Ethernet con el
comando de configuración del router auto-cost reference-bandwidth 1000. El nuevo costo
acumulado para llegar desde el R1 hasta la LAN 172.16.2.0/24 del R2 es el siguiente:
 Costo del enlace serial del R1 al R2 = 647
 Costo del enlace Gigabit Ethernet en el R2 = 1
 Costo total para llegar a 172.16.2.0/24=648

Utilice el comando show ip ospf interface s0/0/0 para verificar el costo de OSPF actual asignado
a la interfaz Serial 0/0/0 del R1, como se muestra en la figura 4. Observe que se muestra un costo
de 647.
En la tabla de routing del R1 de la figura 5, se confirma que la métrica para llegar a la LAN del R2
equivale a un costo de 648.


Todas las interfaces tienen asignados valores de ancho de banda predeterminados. Al igual que el
ancho de banda de referencia, los valores del ancho de banda de interfaz en realidad no afectan la
velocidad o la capacidad del enlace. En cambio, OSPF los utiliza para calcular la métrica de
routing. Por lo tanto, es importante que el valor del ancho de banda refleje la velocidad real del
enlace para que la tabla de routing tenga información precisa acerca de la mejor ruta.
Si bien los valores de ancho de banda de las interfaces Ethernet suelen coincidir con la velocidad
del enlace, es posible que en otras interfaces no lo hagan. Por ejemplo, la velocidad real de las
interfaces seriales a menudo es distinta del ancho de banda predeterminado. En los routers Cisco,
el ancho de banda predeterminado en la mayoría de las interfaces seriales se establece en
1,544 Mb/s.
Nota: es posible que las interfaces seriales antiguas tengan un valor predeterminado de 128 kb/s.
Consulte el ejemplo de la figura 1. Observe lo siguiente:
 El enlace entre el R1 y el R2 se debe establecer en 1544 kb/s (valor predeterminado).
 El enlace entre el R2 y el R3 se debe establecer en 1024 kb/s.
 El enlace entre el R1 y el R3 se debe establecer en 64 kb/s.
Utilice el comando show interfaces para ver la configuración del ancho de banda de interfaz. En la
figura 2, se muestra la configuración de la interfaz serial 0/0/0 para el R1. La configuración del
ancho de banda es precisa y, por lo tanto, no es necesario ajustar la interfaz serial.
En la figura 3, se muestra la configuración de la interfaz serial 0/0/1 para el R1. También se

confirma que la interfaz usa el ancho de banda de interfaz predeterminado de 1544 kb/s. Según la
topología de referencia, este se debe establecer en 64 kb/s. Por lo tanto, se debe ajustar la interfaz
serial 0/0/1 del R1.
En la figura 4, se muestra la métrica de costo resultante de 647, que se basa en el ancho de banda
de referencia establecido en 1 000 000 000 bps y en el ancho de banda de interfaz predeterminado
de 1544 kb/s (1 000 000 000 / 1 544 000).


Ajuste del ancho de banda de interfaz
Para ajustar el ancho de banda de la interfaz, utilice el comando de configuración de

interfaz bandwidth kilobits. Utilice el comando no bandwidth para restaurar el valor
predeterminado.
En el ejemplo de la figura 1, se ajusta el ancho de banda de la interfaz Serial 0/0/1 del R1 a

64 kb/s. Una verificación rápida confirma que la configuración del ancho de banda de la interfaz
ahora es de 64 kb/s.
Se debe ajustar el ancho de banda en cada extremo de los enlaces seriales, de lo cual se deriva lo
siguiente:
 El R2 requiere que su interfaz S0/0/1 se ajuste a 1024 kb/s.
 El R3 requiere que su interfaz serial 0/0/0 se ajuste a 64 kb/s y que su interfaz serial 0/0/1 se
ajuste a 1024 kb/s.
Utilice el verificador de sintaxis de la figura 2 para ajustar la interfaz serial del R2 y del R3.
Nota: un concepto erróneo habitual de los estudiantes nuevos en la tecnología de redes y en IOS
de Cisco es suponer que el comando bandwidth cambia el ancho de banda físico del enlace. Este
comando solo modifica la métrica de ancho de banda que usan EIGRP y OSPF. El comando no
modifica el ancho de banda real en el enlace.

Como alternativa a la configuración del ancho de banda de interfaz predeterminado, es posible

configurar el costo de forma manual en una interfaz con el comando de configuración de interfaz ip
ospf cost valor.
Una ventaja de configurar un costo en lugar del ancho de banda de la interfaz es que, cuando se
configura el costo manualmente, el router no necesita calcular la métrica. En cambio, cuando se
configura el ancho de banda de la interfaz, el router debe calcular el costo de OSPF sobre la base
del ancho de banda. El comando ip ospf cost es útil en entornos de varios proveedores, donde los
routers que no son de Cisco pueden usar una métrica distinta del ancho de banda para calcular los
costos de OSPF.
Con los comandos de interfaz bandwidth e ip ospf cost se logra el mismo resultado, que es
proporcionar a OSPF un valor preciso para determinar la mejor ruta.
Por ejemplo, en la figura 1, el ancho de banda de interfaz de serial 0/0/1 se restablece al valor
predeterminado, y el costo de OSPF se establece de forma manual en 15 625. Si bien el ancho de
banda de interfaz se restablece al valor predeterminado, el costo de OSPF se establece como si
aún se calculara el ancho de banda.
En la figura 2, se muestran las dos alternativas que se pueden utilizar para modificar los costos de
los enlaces seriales en la topología. En el lado derecho de la ilustración, se muestran los
comandos ip ospf cost equivalentes a los comandos bandwidth de la izquierda.

En la figura 1, se muestra la topología de referencia.
Utilice el comando show ip ospf neighbor para verificar que el router haya formado una
adyacencia con los routers vecinos. Si no se muestra la ID del router vecino o este no se muestra
en el estado FULL, los dos routers no formaron una adyacencia OSPF.
Si dos routers no establecen una adyacencia, no se intercambia la información de estado de

enlace. Las LSDB incompletas pueden producir imprecisiones en los árboles SPF y en las tablas
de routing. Es posible que no existan rutas hacia las redes de destino o que estas no representen
la ruta más óptima.
En la figura 2, se muestra la adyacencia de vecino del R1. Este comando muestra el siguiente
resultado para cada vecino:
 Neighbor ID: la ID del router vecino.
 Pri: la prioridad OSPF de la interfaz. Este valor se utiliza en la elección del DR y del BDR.
 State: el estado de OSPF de la interfaz. El estado FULL significa que el router y su vecino
poseen LSDB de OSPF idénticas. En las redes de accesos múltiples, como Ethernet, dos
routers adyacentes pueden mostrar sus estados como 2WAY. El guion indica que no se
requiere ningún DR o BDR debido al tipo de red.
 Dead Time: la cantidad de tiempo restante que el router espera para recibir un paquete de
saludo OSPF del vecino antes de declararlo inactivo. Este valor se reestablece cuando la
interfaz recibe un paquete de saludo.
 Address: la dirección IPv4 de la interfaz del vecino a la que el router está conectado
directamente.
 Interface: la interfaz en la que este router formó adyacencia con el vecino.

Utilice el verificador de sintaxis de la figura 3 para verificar los vecinos del R2 y del R3 con el
comando show ip ospf neighbor.
Dos routers pueden no formar una adyacencia OSPF si:
 Las máscaras de subred no coinciden, esto hace que los routers se encuentren en redes
separadas.
 Los temporizadores muerto y de saludo de OSPF no coinciden.
 Los tipos de redes OSPF no coinciden.
 Falta un comando network de OSPF o este es incorrecto.
Como se muestra en la figura 1, el comando show ip protocols es una manera rápida de verificar
la información fundamental de configuración OSPF. Esta incluye la ID del proceso OSPF, la ID del
router, las redes que anuncia el router, los vecinos de los que el router recibe actualizaciones y la
distancia administrativa predeterminada, que para OSPF es de 110.
Utilice el verificador de sintaxis de la figura 2 para verificar la configuración del protocolo OSPF del
R2 y el R3 con el comando show ip protocols.

El comando show ip ospf también se puede usar para examinar la ID del proceso OSPF y la ID
del router, como se muestra en la figura 1. Este comando muestra información del área OSPF y la
última vez que se calculó el algoritmo SPF.
Utilice el verificador de sintaxis de la figura 2 para verificar el proceso OSPF del R2 y el R3 con el
comando show ip ospf.
La forma más rápida de verificar la configuración de interfaz OSPF es utilizar el comando show ip
ospf interface. Este comando proporciona una lista detallada para cada interfaz con OSPF
habilitado. El comando es útil para determinar si se compusieron correctamente las instrucciones
del comando network.
Para obtener un resumen de las interfaces con OSPF habilitado, utilice el comando show ip ospf
interface brief, como se muestra en la figura 1.

Utilice el verificador de sintaxis de la figura 2 para recuperar y ver un resumen de las interfaces con
OSPF habilitado en el R2 mediante el comando show ip ospf interface brief. Observe que
especificar el nombre de la interfaz como se hace en el comando show ip ospf interface serial
0/0/1 proporciona información detallada de OSPF.
Continúe utilizando el verificador de sintaxis de la figura 2 para obtener un resumen de las

interfaces con OSPF habilitado en el R3 mediante el comando show ip ospf interface brief.
Recupere y vea información adicional de la interfaz Serial 0/0/0 con el comando show ip ospf
interface serial 0/0/0.
8.4 Configuración de OSPFv3 de área única

8.4.1 Comparación de los protocolos OSPFv2 y OSPFv3
OSPFv3 es el equivalente a OSPFv2 para intercambiar prefijos IPv6. Recuerde que, en IPv6, la
dirección de red se denomina “prefijo” y la máscara de subred se denomina “longitud de prefijo”.
De manera similar a su equivalente de IPv4, OSPFv3 intercambia la información de routing para

completar la tabla de routing IPv6 con prefijos remotos, como se muestra en la ilustración.
Nota: con la característica de familias de direcciones de OSPFv3, esta versión del protocolo es
compatible con IPv4 e IPv6.
OSPFv2 se ejecuta a través de la capa de red IPv4, por lo que se comunica con otros peers IPv4
OSPF y solo anuncia rutas IPv4.
OSPFv3 tiene la misma funcionalidad que OSPFv2, pero utiliza IPv6 como transporte de la capa de
red, por lo que se comunica con peers OSPFv3 y anuncia rutas IPv6. OSPFv3 también utiliza el
algoritmo SPF como motor de cómputo para determinar las mejores rutas a lo largo del dominio de
routing.
Al igual que con todos los protocolos de routing IPv6, OSPFv3 tiene procesos diferentes de los de
su equivalente de IPv4. Los procesos y las operaciones son básicamente los mismos que en el
protocolo de routing IPv4, pero se ejecutan de forma independiente. OSPFv2 y OSPFv3 tienen
tablas de adyacencia, tablas de topología OSPF y tablas de routing IP independientes, como se
muestra en la ilustración.

Los comandos de configuración y verificación de OSPFv3 son similares a los que se utilizan en
OSPFv2.
Como se muestra en la ilustración, las similitudes entre OSPFv2 y OSPFv3 son las siguientes:
 Estado de enlace: OSPFv2 y OSPFv3 son protocolos de routing de estado de enlace sin
clase.
 Algoritmo de routing: OSPFv2 y OSPFv3 usan el algoritmo SPF para tomar decisiones de
routing.
 Métrica: las RFC para OSPFv2 y OSPFv3 definen la métrica como el costo del envío de
paquetes por la interfaz. OSPFv2 y OSPFv3 pueden modificarse mediante el comando del
modo de configuración del router auto-cost reference-bandwidth ancho-banda-referencia.
El comando solo afecta la métrica de OSPF donde se configuró. Por ejemplo, si se introdujo
este comando para OSPFv3, no afecta las métricas de routing de OSPFv2.
 Áreas: el concepto de varias áreas en OSPFv3 es el mismo que en OSPFv2. Varias áreas
que minimizan la saturación de estado de enlace y proporcionan mejor estabilidad con el
dominio OSPF.
 Tipos de paquetes OSPF: OSPFv3 usa los mismos cinco tipos de paquetes básicos que
OSPFv2 (saludo, DBD, LSR, LSU y LSAck).
 Mecanismo de descubrimiento de vecinos: la máquina de estado de vecinos, incluida la

lista de estados y eventos de vecinos OSPF, no se modifica. OSPFv2 y OSPFv3 utilizan el
mecanismo de saludo para obtener información sobre los routers vecinos y formar
adyacencias. Sin embargo, en OSPFv3, no existe ningún requisito con respecto a la
coincidencia de subredes para formar adyacencias de vecinos. Esto se debe a que las
adyacencias de vecinos se forman mediante direcciones link-local, no direcciones de
unidifusión global.

 Proceso de elección del DR/BDR: el proceso de elección del DR/BDR no se modifica en

OSPFv3.
 ID del router: tanto OSPFv2 como OSPFv3 usan un número de 32 bits para la ID del router
representada en notación decimal con puntos. Por lo general, se trata de una dirección IPv4.
Se debe utilizar el comando de OSPF router-id para configurar la ID del router. El proceso
para determinar la ID del router de 32 bits es el mismo en ambos protocolos. Utilice una ID de
router configurada explícitamente; de lo contrario, la dirección IPv4 de loopback más alta se
convierte en la ID del router.
En la ilustración, se muestran las diferencias entre OSPFv2 y OSPFv3:
 Anuncios: OSPFv2 anuncia rutas IPv4, mientras que OSPFv3 anuncia rutas para IPv6.
 Dirección de origen: los mensajes OSPFv2 se originan en la dirección IPv4 de la interfaz de

salida. En OSPFv3, los mensajes OSPF se originan con la dirección link-local de la interfaz
de salida.
 Dirección de multidifusión de todos los routers OSPF: OSPFv2 utiliza la dirección

224.0.0.5, mientras que OSPFv3 utiliza la dirección FF02::5.
 Dirección de multidifusión de DR/BDR: OSPFv2 utiliza la dirección 224.0.0.6, mientras que

OSPFv3 utiliza la dirección FF02::6.
 Anuncio de redes: OSPFv2 anuncia las redes mediante el comando de configuración del
router network, mientras que OSPFv3 utiliza el comando de configuración de interfazipv6
ospf id-proceso areaid-área.
 Routing de unidifusión IP: habilitado de manera predeterminada en IPv4; en cambio, el

comando de configuración global ipv6 unicast-routing se debe configurar.
 Autenticación: OSPFv2 utiliza autenticación de texto no cifrado o autenticación MD5.

OSPFv3 utiliza autenticación IPv6.

Los routers que ejecutan un protocolo de routing dinámico, como OSPF, intercambian mensajes
entre vecinos en la misma subred o el mismo enlace. Los routers solo necesitan enviar y recibir
mensajes de protocolo de routing con sus vecinos conectados directamente. Estos mensajes
siempre se envían desde la dirección IPv4 de origen del router que realiza el reenvío.
Las direcciones IPv6 link-local son ideales para este propósito. Una dirección IPv6 link-local
permite que un dispositivo se comunique con otros dispositivos con IPv6 habilitado en el mismo
enlace y solo en ese enlace (subred). Los paquetes con una dirección link-local de origen o de
destino no se pueden enrutar más allá del enlace en el cual se originó el paquete.
Como se muestra en la ilustración, los mensajes OSPFv3 se envían utilizando lo siguiente:
 Dirección IPv6 de origen: esta es la dirección IPv6 link-local de la interfaz de salida.
 Dirección IPv6 de destino: se pueden enviar los paquetes OSPFv3 a una dirección de
unidifusión mediante la dirección IPv6 link-local del vecino. También es posible enviarlos
utilizando una dirección de multidifusión. La dirección FF02::5 es la dirección de todos los
routers OSPF, mientras que FF02::6 es la dirección de multidifusión del DR/BDR.

8.4.2 Configuración de OSPFv3
En la figura 1, se muestra la topología de la red que se utiliza para configurar OSPFv3.
En la figura 2, se muestra el routing de unidifusión IPv6 y la configuración de las direcciones de

unidifusión global del R1, como se identifican en la topología de referencia. Suponga que las
interfaces del R2 y el R3 también se configuraron con sus direcciones de unidifusión global, como
se identifica en la topología mencionada.
En esta topología, ninguno de los routers tiene direcciones IPv4 configuradas. Una red con las
interfaces del router configuradas con direcciones IPv4 e IPv6 se denomina “dual-stack”. Una red
dual-stack puede tener OSPFv2 y OSPFv3 habilitados de manera simultánea.
En la figura 3, se muestran los pasos para configurar OSPFv3 básico en un área única.

En la ilustración, el resultado del comandoshow ipv6 interface brief confirma que se configuraron
correctamente las direcciones IPv6 globales y que se habilitaron las interfaces. Además, observe
que cada interfaz generó automáticamente una dirección link-local, como se destaca en la
ilustración.
Las direcciones link-local se crean de manera automática cuando se asigna una dirección IPv6 de
unidifusión global a la interfaz. No se requieren direcciones de unidifusión global en una interfaz,
pero sí se requieren direcciones IPv6 link-local.
A menos que se configure manualmente, los routers Cisco crean la dirección link-local utilizando el
prefijo FE80::/10 y el proceso EUI-64. EUI-64 implica usar la dirección MAC de Ethernet de 48 bits,
insertar FFFE en el medio e invertir el séptimo bit. Para las interfaces seriales, Cisco usa la
dirección MAC de una interfaz Ethernet. Observe en la ilustración que las tres interfaces usan la
misma dirección link-local.

Las direcciones link-local creadas con el formato EUI-64 o, en algunos casos, con ID de interfaz
aleatorias hacen que resulte difícil reconocer y recordar esas direcciones. Debido a que los
protocolos de routing IPv6 utilizan direcciones IPv6 link-local para el direccionamiento de
unidifusión y la información de dirección de siguiente salto en la tabla de routing, es habitual hacer
que sea una dirección fácil de reconocer.
Configurar la dirección link-local de forma manual permite crear una dirección reconocible y más
fácil de recordar. Además, un router con varias interfaces puede asignar la misma dirección link-
local a cada interfaz IPv6. Esto se debe a que la dirección link-local solo se requiere para las
comunicaciones locales.
Las direcciones link-local pueden configurarse de forma manual con el mismo comando de interfaz
que se usa para crear direcciones IPv6 de unidifusión global, pero agregando la palabra clave link-
local al comando ipv6 address.
Una dirección link-local tiene un prefijo dentro del rango FE80 a FEBF. Cuando una dirección
comienza con este hexteto (segmento de 16 bits), la palabra clavelink-local debe seguir la
dirección.
En el ejemplo de la figura 1, se configura la misma dirección link-local FE80::1 en las tres interfaces
del R1. Se eligió FE80::1 para que las direcciones link-local del R1 sean fáciles de recordar.
Con una vista rápida de las interfaces como se muestran en la figura 2, se confirma que las
direcciones link-local de las interfaces del R1 se cambiaron a FE80::1.
Utilice el verificador de sintaxis de la figura 3 para configurar y verificar la dirección link-local

FE80::2 en el R2 y la dirección link-local FE80::3 en el R3.

Utilice el comando ipv6 router ospfid-proceso del modo de configuración global para ingresar al
modo de configuración del router. La petición de entrada del modo de configuración del router IPv6
es distinta de la petición de entrada del modo de configuración del router IPv4. Utilice el modo de
confirmación del router IPv6 para configurar los parámetros globales de OSPFv3, como la
asignación de la ID del router OSPF de 32 bits y del ancho de banda de referencia.
Los protocolos de routing IPv6 se habilitan en una interfaz, no desde el modo de configuración del
router, como sus equivalentes de IPv4. El comando network del modo de configuración del router
IPv4 no existe en IPv6.
Al igual que en OSPFv2, el valor id-proceso es un número entre 1 y 65 535, y lo elige el

administrador de red. El valor id-proceso tiene importancia en el ámbito local, lo que significa que
no hace falta que coincida con otros routers OSPF para establecer adyacencias con esos vecinos.
OSPFv3 requiere que se asigne una ID de router de 32 bits antes de que se pueda habilitar OSPF
en una interfaz. En el diagrama de lógica de la figura 1, se muestra cómo se elige una ID de router.
Al igual que OSPFv2, OSPFv3 utiliza lo siguiente:

 En primer lugar, una ID de router configurada explícitamente.
 Si no se configuró ninguna, el router usa la dirección IPv4 configurada más alta de una
interfaz loopback.
 Si no se configuró ninguna, el router usa la dirección IPv4 configurada más alta de una
interfaz activa.
 Si un router no tiene ningún origen de direcciones IPv4, este muestra un mensaje de consola
para configurar la ID del router de forma manual.
Nota: para mantener la coherencia, los tres routers usan la ID de proceso 10.
Como se muestra en la topología de la figura 2, se deben asignar las ID de router indicadas a los
routers R1, R2 y R3. El comando router-id id-router utilizado para asignar una ID de router en
OSPFv2 es el mismo comando que se utiliza en OSPFv3.
En el ejemplo de la figura 3, se realiza lo siguiente:
 Se ingresa al modo de configuración de OSPFv3 del router. Observe que la petición de

entrada del router es distinta de la petición de entrada predeterminada del router del modo de
protocolo de routing IPv4. Además, observe que apareció un mensaje informativo de consola
cuando se accedió al modo de configuración de router OSPFv3.
 Se asigna la ID de router 1.1.1.1.
 Se ajusta el ancho de banda de referencia a 1 000 000 000 bps (1 Gb/s), debido a que hay
enlaces Gigabit Ethernet en la red. Observe el mensaje informativo de consola que indica que
se debe configurar este comando en todos los routers en el dominio de routing.
 El comando show ipv6 protocols se usa para verificar que la ID de proceso OSPFv3 10
utiliza la ID de router 1.1.1.1.
Utilice el verificador de sintaxis de la figura 4 para configurar los parámetros globales de OSPFv3
en el R2 y el R3.


En ocasiones, se deben cambiar las ID de router, por ejemplo, si el administrador de red estableció
un nuevo esquema de identificación de ID de router. Sin embargo, después de que un router
OSPFv3 establece una ID de router, esta no se puede cambiar hasta que se vuelva a cargar el
router o se borre el proceso OSPF.
En la figura 1, observe que la ID del router actual es 10.1.1.1. La ID del router OSPFv3 debería ser
1.1.1.1.
En la figura 2, se asigna la ID de router 1.1.1.1 al R1.
Nota: el método preferido para restablecer la ID del router es borrar el proceso OSPF.
En la figura 3, se borra el proceso de routing de OSPF con el comando clear ipv6 ospf
process del modo EXEC privilegiado. Hacer esto obliga al protocolo OSPF en el R1 a volver a
negociar las adyacencias de vecinos con la nueva ID del router.
El comando show ipv6 protocols verifica que se haya cambiado la ID del router.
Utilice el verificador de sintaxis de la figura 4 para modificar la ID del router para el R1.

OSPFv3 utiliza un método diferente para habilitar una interfaz para OSPF. En lugar de usar el
comando network del modo de configuración del router para especificar las direcciones de interfaz
que coinciden, OSPFv3 se configura directamente en la interfaz.
Para habilitar OSPFv3 en una interfaz, utilice el comando ipv6 ospf id-proceso area id-área del
modo de configuración de interfaz.
El valor id-proceso identifica el proceso de routing específico y debe coincidir con la ID de proceso
utilizada para crear el proceso de routing en el comando ipv6 router ospf id-proceso.

El valor id-área es el área que se debe asociar a la interfaz OSPFv3. Aunque pudo haberse
configurado cualquier valor para el área, se seleccionó 0 debido a que el área 0 es el área
backbone a la que se deben conectar todas las demás áreas, como se muestra en la figura 1. Esto
contribuye a la migración a OSPF multiárea, si surge la necesidad.
En la figura 2, se habilita OSPFv3 en las interfaces del R1 con el comando ipv6 ospf 10 area 0. El
comando show ipv6 ospf interface brief muestra las interfaces OSPFv3 activas.
Utilice el verificador de sintaxis de la figura 3 para habilitar OSPFv3 en las interfaces del R2 y el
R3.

8.4.3 Verificación de OSPFv3
Utilice el comando show ipv6 ospf neighbor para verificar que el router haya formado una
adyacencia con los routers vecinos. Si no se muestra la ID del router vecino o este no se muestra
en el estado FULL, los dos routers no formaron una adyacencia OSPF.
Si dos routers no establecen una adyacencia de vecino, no se intercambia la información de estado

de enlace. Las LSDB incompletas pueden producir imprecisiones en los árboles SPF y en las
tablas de routing. Es posible que no existan rutas hacia las redes de destino o que estas no
representen la ruta más óptima.
En la figura 1, se muestra la adyacencia de vecino del R1. Este comando muestra el siguiente
resultado para cada vecino:
 Neighbor ID: la ID del router vecino.
 Pri: la prioridad OSPF de la interfaz. El valor se utiliza en la elección del DR y del BDR.
 State: el estado de OSPF de la interfaz. El estado FULL significa que el router y su vecino
poseen LSDB de OSPF idénticas. En el caso de redes de accesos múltiples como Ethernet,
dos routers adyacentes pueden mostrar sus estados como 2WAY. El guion indica que no se
requiere ningún DR o BDR debido al tipo de red.
 Dead Time: la cantidad de tiempo restante que el router espera para recibir un paquete de
saludo OSPF del vecino antes de declararlo inactivo. Este valor se reestablece cuando la
interfaz recibe un paquete de saludo.
 Interface ID: la ID de interfaz o de enlace.
 Interface: la interfaz en la que este router formó adyacencia con el vecino.
Utilice el verificador de sintaxis de la figura 2 para verificar los vecinos del R2 y el R3 con el
comando show ipv6 ospf neighbor.
Como se muestra en la figura 1, el comando show ipv6 protocols es una manera rápida de
verificar la información fundamental de configuración OSPFv3, incluidas la ID del proceso OSPF, la
ID del router y las interfaces habilitadas para OSPFv3.

Utilice el verificador de sintaxis de la figura 2 para verificar la configuración del protocolo OSPF del
R2 y el R3 con el comando show ipv6 protocols.
Además, utilice el comando show ipv6 ospf para examinar la ID del proceso OSPFv3 y la ID del
router. Este comando muestra información del área OSPF y la última vez que se calculó el
algoritmo SPF.
La forma más rápida de verificar la configuración de interfaz OSPF es utilizar el comando show
ipv6 ospf interface. Este comando proporciona una lista detallada para cada interfaz con OSPF
habilitado.
Para recuperar y ver un resumen de las interfaces con OSPFv3 habilitado en el R1, utilice el
comando show ipv6 ospf interface brief, como se muestra en la figura 1.
Utilice el verificador de sintaxis de la figura 2 para ver un resumen de las interfaces con OSPF
habilitado en el R2 mediante el comando show ipv6 ospf interface brief. Observe que especificar
el nombre de la interfaz como se hace en el comando show ipv6 ospf interface serial
0/0/1 proporciona información detallada de OSPF.
Continúe utilizando el verificador de sintaxis de la figura 2 para obtener un resumen de las

interfaces con OSPF habilitado en el R3 mediante el comando show ipv6 ospf interface brief.
Recupere y vea información adicional de la interfaz Serial 0/0/0 con el comando show ipv6 ospf
interface serial 0/0/0.

En la figura 1, el comando show ipv6 route ospf proporciona datos específicos sobre las rutas
OSPF en la tabla de routing.
Utilice el verificador de sintaxis de la figura 2 para verificar la tabla de routing OSPFv3 del R2 y el
R3; use el comando show ipv6 route ospf.
8.5 Resumen
La versión actual de OSPF para IPv4 es OSPFv2, introducida en RFC 1247 y actualizada en RFC
2328 por John Moy. En 1999, OSPFv3 para IPv6 se publicó en RFC 2740.
OSPF es un protocolo de routing de estado de enlace sin clase con una distancia administrativa
predeterminada de 110 y se indica en la tabla de routing con el código de origen de ruta O.
OSPF se habilita con el comando router ospf id-proceso del modo de configuración global. El
valor id-procesotiene importancia en el ámbito local, lo que significa que no necesita coincidir con
otros routers OSPF para establecer adyacencias con esos vecinos.
El comando network utilizado con OSPF cumple la misma función que cuando se lo utiliza con
otros protocolos de routing IGP, pero con una sintaxis ligeramente diferente. El valor máscara-
wildcard es el valor inverso a la máscara de subred, y el valor id-área se debe establecer en 0.
De manera predeterminada, los paquetes de saludo OSPF se envían cada 10 segundos en

segmentos de accesos múltiples y punto a punto, y cada 30 segundos en los segmentos NBMA
(Frame Relay, X.25, ATM), y OSPF los usa para establecer adyacencias de vecinos. De manera
predeterminada, el intervalo muerto es equivalente a cuatro veces el valor del intervalo de saludo.
Para que los routers establezcan una adyacencia, sus intervalos de saludo, intervalos muertos,
tipos de red y máscaras de subred deben coincidir. Use el comando show ip ospf neighbors para
verificar las adyacencias OSPF.

En una red de accesos múltiples, OSPF elige un DR para que funcione como punto de recopilación
y distribución de las LSA enviadas y recibidas. Un BDR se elige para cumplir la función del DR en
caso de que este falle. Todos los demás routers se conocen como DROTHER. Todos los routers
envían sus LSA al DR, que luego satura con la LSA todos los demás routers en la red de accesos
múltiples.
El comando show ip protocols se utiliza para verificar la información importante de configuración

OSPF, incluidas la ID del proceso OSPF, la ID del router y las redes que anuncia el router.
OSPFv3 se habilita en una interfaz, no en el modo de configuración del router. OSPFv3 necesita
que se configuren direcciones link-local. Se debe habilitar el routing de unidifusión IPv6 para
OSPFv3. Para habilitar una interfaz para OSPFv3, antes se requiere una ID de router de 32 bits.

9 Listas de control de acceso

La seguridad de red es un tema muy amplio, y gran parte de este tema se encuentra más allá del
ámbito de este curso. Sin embargo, una de las habilidades más importantes que necesita un
administrador de red es el dominio de las listas de control de acceso (ACL).
Los diseñadores de red utilizan firewalls para proteger las redes del uso no autorizado. Los
firewalls son soluciones de hardware o de software que aplican las políticas de seguridad de la red.
Imagine una cerradura en la puerta de una habitación dentro de un edificio. La cerradura permite
que solo los usuarios autorizados que poseen una llave o una tarjeta de acceso puedan entrar. De
igual forma, un firewall filtra los paquetes no autorizados o potencialmente peligrosos e impide que
ingresen a la red. En un router Cisco, puede configurar un firewall simple que proporcione
capacidades básicas de filtrado de tráfico mediante ACL. Los administradores utilizan las ACL para
detener el tráfico o para permitir solamente tráfico específico en sus redes.
Una ACL es una lista secuencial de instrucciones permit (permitir) o deny (denegar) que se aplican
a los protocolos de capa superior o a las direcciones. Las ACL son una herramienta potente para
controlar el tráfico hacia y desde la red. Se pueden configurar ACL para todos los protocolos de red
enrutada.
El motivo más importante para configurar ACL es aportar seguridad a una red. En este capítulo, se
explica cómo utilizar las ACL estándar y extendidas en un router Cisco como parte de una solución
de seguridad. Se incluyen consejos, consideraciones, recomendaciones y pautas generales sobre
cómo utilizar las ACL.
En este capítulo, se ofrece la oportunidad de desarrollar su dominio de las ACL con una serie de
lecciones, actividades y ejercicios de práctica de laboratorio.

9.1 Funcionamiento de ACL de IP

9.1.1 Propósito de los ACLs
Una ACL es una serie de comandos del IOS que controlan si un router reenvía o descarta
paquetes según la información que se encuentra en el encabezado del paquete. Las ACL son una
de las características del software IOS de Cisco más utilizadas.
Cuando se las configura, las ACL realizan las siguientes tareas:
 Limitan el tráfico de la red para aumentar su rendimiento. Por ejemplo, si la política

corporativa no permite el tráfico de video en la red, se pueden configurar y aplicar ACL que
bloqueen el tráfico de video. Esto reduciría considerablemente la carga de la red y
aumentaría su rendimiento.
 Proporcionan control del flujo de tráfico. Las ACL pueden restringir la entrega de
actualizaciones de routing. Si no se requieren actualizaciones debido a las condiciones de la
red, se preserva ancho de banda.
 Proporcionan un nivel básico de seguridad para el acceso a la red. Las ACL pueden permitir
que un host acceda a una parte de la red y evitar que otro host acceda a la misma área. Por
ejemplo, se puede restringir el acceso a la red de Recursos Humanos a los usuarios
autorizados.
 Filtran el tráfico según el tipo de tráfico. Por ejemplo, una ACL puede permitir el tráfico de
correo electrónico, pero bloquear todo el tráfico de Telnet.

 Filtran a los hosts para permitirles o denegarles el acceso a los servicios de red. Las ACL
pueden permitirles o denegarles a los usuarios el acceso a determinados tipos de archivos,
como FTP o HTTP.
Los routers no tienes ACL configuradas de manera predeterminada, por lo que no filtran el tráfico
de manera predeterminada. El tráfico que ingresa al router se enruta solamente en función de la
información de la tabla de routing. Sin embargo, cuando se aplica una ACL a una interfaz, el router
realiza la tarea adicional de evaluar todos los paquetes de red a medida que pasan a través de la
interfaz para determinar si el paquete se puede reenviar.
Además de permitir o denegar tráfico, las ACL se pueden utilizar para seleccionar tipos de tráfico
para analizar, reenviar o procesar de otras formas. Por ejemplo, se pueden utilizar ACL para
clasificar el tráfico a fin de permitir el procesamiento por prioridad. Esta capacidad es similar a tener
un pase vip para un concierto o un evento deportivo. El pase vip brinda a ciertos invitados
privilegios que no se ofrecen a los asistentes que poseen entradas de admisión general, como
prioridad de entrada o el ingreso a un área restringida.
En la ilustración, se muestra una topología de ejemplo a la que se le aplicaron ACL.
Las ACL permiten a los administradores controlar el tráfico hacia y desde la red. Este control puede
ser tan simple como permitir o denegar el tráfico según las direcciones de red o tan complejo como
controlar el tráfico de la red según el puerto TCP solicitado. Es más fácil comprender cómo filtra el
tráfico una ACL si se examina el diálogo que se produce durante una conversación TCP, por
ejemplo, cuando se solicita una página web.

Comunicación TCP
Cuando un cliente solicita datos a un servidor web, IP administra la comunicación entre la

computadora (origen) y el servidor (destino). TCP administra la comunicación entre el navegador
web (aplicación) y el software del servidor de red.
Cuando envía un correo electrónico, observa una página web o descarga un archivo, TCP se
encarga de descomponer los datos en segmentos para IP antes de que se envíen. TCP también
administra el montaje de los datos de los segmentos cuando estos llegan. El proceso de TCP es
muy similar a una conversación en la que dos nodos en una red acuerdan transmitirse datos entre
sí.
TCP proporciona un servicio de flujo de bytes confiable y orientado a la conexión. Que sea
orientado a la conexión significa que las dos aplicaciones deben establecer una conexión TCP
antes de intercambiar datos. TCP es un protocolo full-duplex, lo que significa que cada conexión
TCP admite un par de flujos de bytes, y cada flujo fluye en una sentido. TCP incluye un mecanismo
de control del flujo para cada flujo de bytes que permite que el receptor limite la cantidad de datos
que puede transmitir el emisor. TCP también implementa un mecanismo de control de la
congestión.
En la animación que se muestra en la figura 1, se ilustra cómo se lleva a cabo una conversación
TCP/IP. Los segmentos TCP se marcan con indicadores que denotan su objetivo: la sesión
comienza (se sincroniza) con un indicador SYN, el indicador ACK es un acuse de recibo de un
segmento esperado, y un indicador FIN finaliza la sesión. Un indicador SYN/ACK confirma que la
transferencia está sincronizada. Los segmentos de datos TCP incluyen el protocolo del nivel más
alto necesario para dirigir los datos de aplicación a la aplicación correcta.
Los segmentos de datos TCP también identifican el puerto que coincide con el servicio solicitado.
Por ejemplo, para HTTP es el puerto 80, para SMTP es el puerto 25 y para FTP son los puertos 20
y 21. En la figura 2, se muestran los rangos de puertos UDP y TCP.
En las figuras 3 a 5, se exploran los puertos TCP/UDP.


Entonces, ¿cómo es que una ACL utiliza la información transferida durante una conversación
TCP/IP para filtrar tráfico?
El filtrado de paquetes, a veces denominado “filtrado de paquetes estático”, controla el acceso a

una red mediante el análisis de los paquetes entrantes y salientes y la transferencia o el descarte
de estos según determinados criterios, como la dirección IP de origen, la dirección IP de destino y
el protocolo incluido en el paquete.

Cuando reenvía o deniega los paquetes según las reglas de filtrado, un router funciona como filtro
de paquetes. Cuando llega un paquete a un router que filtra paquetes, el router extrae cierta
información del encabezado. Con esta información, el router decide si el paquete puede pasar o si
se debe descartar, según las reglas de los filtros configurados. Como se muestra en la ilustración,
el filtrado de paquetes puede operar en diversas capas del modelo OSI o en la capa de Internet de
TCP/IP.
Un router que filtra paquetes utiliza reglas para determinar si permite o deniega el tráfico. Un router
también puede realizar el filtrado de paquetes en la capa 4, la capa de transporte. El router puede
filtrar paquetes según el puerto de origen y de destino del segmento TCP o UDP. Estas reglas se
definen mediante el uso de ACL.
Una ACL es una lista secuencial de instrucciones permit (permitir) o deny (denegar), conocidas
como “entradas de control de acceso” (ACE). Las ACE también se denominan comúnmente
“instrucciones de ACL”. Las ACE se pueden crear para filtrar tráfico según ciertos criterios, como la
dirección de origen, la dirección de destino, el protocolo y los números de puerto. Cuando el tráfico
de la red atraviesa una interfaz configurada con una ACL, el router compara la información dentro
del paquete con cada ACE, en orden secuencial, para determinar si el paquete coincide con una de
las instrucciones. Si se encuentra una coincidencia, el paquete se procesa según corresponda. De
esta manera, se pueden configurar ACL para controlar el acceso a una red o a una subred.
Para evaluar el tráfico de la red, la ACL extrae la siguiente información del encabezado de capa 3
del paquete:
 Dirección IP de origen
 Dirección IP de destino
 Tipo de mensaje ICMP
La ACL también puede extraer información de capa superior del encabezado de capa 4, incluido lo
siguiente:
 Puerto de origen TCP/UDP
 Puerto de destino TCP/UDP

Ejemplo del filtrado de paquetes
Para entender el concepto de cómo utiliza el router el filtrado de paquetes, imagine que se coloca
un guarda en una puerta cerrada con llave. Las instrucciones del guarda son que solo permita el
acceso por esa puerta a aquellas personas cuyos nombres aparecen en una lista. El guarda filtra
las personas según el criterio de que los nombres aparezcan en la lista autorizada. Las ACL
funcionan de manera similar: toman decisiones sobre la base de criterios establecidos.
Por ejemplo, una ACL se puede configurar para “permitir el acceso web a los usuarios de la red A,
pero denegar el resto de los servicios a los usuarios de esa red. Denegar el acceso HTTP a los
usuarios de la red B, pero permitir que los usuarios de esa red tengan todos los otros tipos de
acceso”, de manera lógica. Consulte la ilustración para examinar la ruta de decisión que utiliza el
filtro de paquetes para llevar a cabo esta tarea.
Para esta situación, el filtro de paquetes examina cada paquete de la siguiente manera:
 Si el paquete es un SYN de TCP de la red A que utiliza el puerto 80, tiene permiso para
pasar. El resto de los tipos de acceso se deniega a esos usuarios.
 Si el paquete es un SYN de TCP de la red B que utiliza el puerto 80, se bloquea. Sin
embargo, se permite el resto de los tipos de acceso.
Este es solo un ejemplo sencillo. Se pueden configurar varias reglas para permitir o denegar otros
servicios a usuarios específicos.

Las ACL definen el conjunto de reglas que proporcionan un control adicional para los paquetes que
ingresan por las interfaces de entrada, para los que retransmiten a través del router y para los que
salen por las interfaces de salida del router. Las ACL no operan sobre paquetes que se originan en
el router mismo.
Las ACL se configuran para aplicarse al tráfico entrante o al tráfico saliente, como se muestra en la
ilustración.
 ACL de entrada: los paquetes entrantes se procesan antes de enrutarse a la interfaz de

salida. Las ACL de entrada son eficaces, porque ahorran la sobrecarga de enrutar búsquedas
si el paquete se descarta. Si las pruebas permiten el paquete, este se procesa para el routing.
Las ACL de entrada son ideales para filtrar los paquetes cuando la red conectada a una
interfaz de entrada es el único origen de los paquetes que se deben examinar.
 ACL de salida: los paquetes entrantes se enrutan a la interfaz de salida y después se

procesan mediante la ACL de salida. Las ACL de salida son ideales cuando se aplica el
mismo filtro a los paquetes que provienen de varias interfaces de entrada antes de salir por la
misma interfaz de salida.
La última sentencia de una ACL es siempre una denegación implícita. Esta sentencia se inserta
automáticamente al final de cada ACL, aunque no esté presente físicamente. La denegación
implícita bloquea todo el tráfico. Debido a esta denegación implícita, una ACL que no tiene, por lo
menos, una instrucción permit bloqueará todo el tráfico.

9.1.2 Comparación entre ACL de IPv4 estándar y extendidas
Los dos tipos de ACL de IPv4 de Cisco son estándar y extendida.
Nota: las ACL de IPv6 de Cisco son similares a las ACL de IPv4 extendidas y se abordarán en una
sección posterior.
ACL estándar
Las ACL estándar se pueden utilizar para permitir o denegar el tráfico de direcciones IPv4 de
origen únicamente. El destino del paquete y los puertos involucrados no se evalúan. En el ejemplo
de la figura 1, se permite todo el tráfico de la red 192.168.30.0/24. Debido al “deny any” (denegar
todo) implícito al final, todo el resto del tráfico se bloquea con esta ACL. Las ACL estándar se
crean en el modo de configuración global.
ACL extendidas
Las ACL extendidas filtran paquetes IPv4 según varios atributos:
 Tipo de protocolo
 Dirección IPv4 de origen
 Dirección IPv4 de destino
 Puertos TCP o UDP de origen
 Puertos TCP o UDP de destino
 Información optativa de tipo de protocolo para un control más preciso
En la figura 2, la ACL 103 permite el tráfico que se origina desde cualquier dirección en la red
192.168.30.0/24 hasta cualquier red IPv4 si el puerto de host de destino es 80 (HTTP). Las ACL
extendidas se crean en el modo de configuración global.

Los comandos para las ACL se abordan en los siguientes temas.
Nota: las ACL estándar y extendidas se analizarán en mayor detalle más adelante en este
capítulo.
Las ACL estándar y extendidas se pueden crear con un número o un nombre para identificar la
ACL y su lista de instrucciones.
El uso de ACL numeradas es un método eficaz para determinar el tipo de ACL en redes más
pequeñas con tráfico definido de forma más homogénea. Sin embargo, un número no proporciona
información sobre el propósito de la ACL. Por este motivo, a partir de la versión 11.2 del IOS de
Cisco, se puede utilizar un nombre para identificar una ACL de Cisco.
En la ilustración, se resumen las reglas que se deben seguir para designar las ACL numeradas y
con nombre.
En relación con las ACL numeradas, se omiten los números del 200 al 1299 debido a que esos
números los utilizan otros protocolos, muchos de los cuales son antiguos u obsoletos. Este curso
se centra solamente en las ACL de IP. Algunos ejemplos de números de protocolos ACL antiguos
van del 600 al 699, utilizados por AppleTalk y del 800 al 899, utilizados por IPX.

9.1.3 Máscaras wildcard en ACL
Máscara wildcard
Las ACE de IPv4 incluyen el uso de máscaras wildcard. Una máscara wildcard es una cadena de
32 dígitos binarios que el router utiliza para determinar los bits de la dirección que debe examinar
para encontrar una coincidencia.
Nota: a diferencia de las ACL de IPv4, las ACL de IPv6 no utilizan máscaras wildcard. En cambio,
se utiliza la longitud de prefijo para indicar cuánto de una dirección IPv6 de origen o destino debe
coincidir. Las ACL de IPv6 se analizan más adelante en este capítulo.
Como ocurre con las máscaras de subred, los números 1 y 0 en la máscara wildcard identifican lo
que hay que hacer con los bits de dirección IP correspondientes. Sin embargo, en una máscara
wildcard, estos bits se utilizan para fines diferentes y siguen diferentes reglas.
Las máscaras de subred utilizan unos y ceros binarios para identificar la red, la subred y la porción
de host de una dirección IP. Las máscaras wildcard utilizan unos y ceros binarios para filtrar
direcciones IP individuales o grupos de direcciones IP para permitir o denegar el acceso a los
recursos.
Las máscaras wildcard y las máscaras de subred se diferencian en la forma en que establecen la
coincidencia entre los unos y ceros binarios. Las máscaras wildcard utilizan las siguientes reglas
para establecer la coincidencia entre los unos y ceros binarios:
 Bit 0 de máscara wildcard: se establecer la coincidencia con el valor del bit correspondiente
en la dirección.
 Bit 1 de máscara wildcard: se omite el valor del bit correspondiente en la dirección.
En la figura 1, se muestra cómo las diferentes máscaras wildcard filtran las direcciones IP.
Recuerde que, en el ejemplo, el valor binario 0 indica un bit que debe coincidir y el valor binario 1
indica un bit que se puede ignorar.

Nota: a las máscaras wildcard a menudo se las denomina “máscaras inversas”. La razón es que, a
diferencia de una máscara de subred en la que el 1 binario equivale a una coincidencia y el 0
binario no es una coincidencia, en las máscaras wildcard es al revés.
Uso de una máscara wildcard
En la tabla de la figura 2, se muestran los resultados de la aplicación de una máscara wildcard

0.0.255.255 a una dirección IPv4 de 32 bits. Recuerde que un 0 binario indica un valor con
coincidencia.
Las máscaras wildcard también se utilizan para configurar algunos protocolos de routing IPv4,
como OSPF, a fin de habilitar el protocolo en interfaces específicas.

Máscaras wildcard para establecer coincidencias con subredes IPv4
Se necesita práctica para calcular la máscara wildcard. En la figura 1, se proporcionan tres

ejemplos de máscara wildcard.
En el primer ejemplo, la máscara wildcard estipula que cada bit en la IPv4 192.168.1.1 debe
coincidir con exactitud.
En el segundo ejemplo, la máscara wildcard estipula que no habrá coincidencias.
En el tercer ejemplo, la máscara wildcard estipula que cualquier host dentro de la red
192.168.1.0/24 tendrá una coincidencia.
Estos ejemplos son bastante simples y directos. Sin embargo, el cálculo de máscaras wildcard
puede ser más complejo.
Máscaras wildcard para establecer coincidencias con rangos
Los dos ejemplos en la figura 2 son más complejos. En el ejemplo 1, los primeros dos octetos y los
primeros cuatro bits del tercer octeto deben coincidir con exactitud. Los cuatro últimos bits del
tercer octeto y el último octeto pueden ser cualquier número válido. Esto genera una máscara que
verifica el rango de redes 192.168.16.0 a 192.168.31.0.
En el ejemplo 2, se muestra una máscara wildcard que coincide con los primeros dos octetos y el
bit con menor importancia del tercer octeto. El último octeto y los primeros siete bits en el tercer
octeto pueden ser cualquier número válido. Esto genera una máscara que permite o deniega todos
los hosts de subredes impares de la red principal 192.168.0.0.

El cálculo de máscaras wildcard puede ser difícil. Un método abreviado es restar la máscara de
subred a 255.255.255.255.
Cálculo de máscara wildcard: ejemplo 1
En el primer ejemplo en la ilustración, suponga que desea permitir el acceso a todos los usuarios
en la red 192.168.3.0. Dado que la máscara de subred es 255.255.255.0, podría tomar
255.255.255.255 y restarle la máscara de subred 255.255.255.0. El resultado genera la máscara
wildcard 0.0.0.255.
En el segundo ejemplo en la ilustración, suponga que desea permitir el acceso a la red a

los 14 usuarios en la subred 192.168.3.32/28. La máscara de subred para la subred IP es
255.255.255.240; por lo tanto, tome 255.255.255.255 y réstele la máscara de subred
255.255.255.240. Esta vez, el resultado genera la máscara wildcard 0.0.0.15.
En el tercer ejemplo en la ilustración, suponga que solo quiere establecer la coincidencia con las
redes 192.168.10.0 y 192.168.11.0. Una vez más, tome 255.255.255.255 y reste la máscara de
subred regular que, en este caso, es 255.255.252.0. El resultado es 0.0.3.255.
Puede lograr el mismo resultado con instrucciones como las dos que se muestran a continuación:
R1(config)# access-list 10 permit 192.168.10.0

Resulta mucho más eficaz configurar la máscara wildcard de la siguiente manera:
R1(config)# access-list 10 permit 192.168.10.0 0.0.3.255
Tenga en cuenta la configuración que se indica a continuación para establecer coincidencias con
las redes en el rango entre 192.168.16.0 y 192.168.31.0:
Las 16 instrucciones de configuración indicadas anteriormente se pueden reducir a una sola

instrucción con la máscara wildcard correcta, como se muestra a continuación:

Palabras clave de la máscara de bits wildcard
Trabajar con representaciones decimales de los bits binarios de máscaras wildcard puede ser
tedioso. Para simplificar esta tarea, las palabras clave host y anyayudan a identificar los usos
más comunes de las máscaras wildcard. Estas palabras clave eliminan la necesidad de introducir
máscaras wildcard para identificar un host específico o toda una red. También facilitan la lectura de
una ACL, ya que proporcionan pistas visuales en cuanto al origen o el destino de los criterios.
La palabra clave host reemplaza la máscara 0.0.0.0. Esta máscara indica que todos los bits de
direcciones IPv4 deben coincidir o que solo un host coincide.
La opción any sustituye la dirección IP y la máscara 255.255.255.255. Esta máscara establece que
se omita la dirección IPv4 completa o que se acepte cualquier dirección.
Ejemplo 1: proceso de máscara wildcard con una única dirección IP
En el ejemplo 1 en la ilustración, en vez de introducir 192.168.10.10 0.0.0.0, puede

utilizar host 192.168.10.10.
Ejemplo 2: proceso de máscara wildcard con coincidencia con cualquier dirección IP
En el ejemplo 2 en la ilustración, en vez de introducir 0.0.0.0 255.255.255.255, puede utilizar

la palabra clave any(cualquier) sola.
Nota: Las palabras clave host y any solo se pueden utilizar al configurar una ACL de IPv6.

Las palabras clave any y host
En el ejemplo 1 en la ilustración, se muestra cómo utilizar la palabra clave any para sustituir la
dirección IPv4 0.0.0.0 por una máscara wildcard 255.255.255.255.
En el ejemplo 2, se muestra cómo utilizar la palabra clave host para sustituir la máscara wildcard
para identificar un único host.

9.1.4 Pautas para la creación de ACL
La composición de ACL puede ser una tarea compleja. Para cada interfaz, puede haber varias
políticas necesarias para administrar el tipo de tráfico que tiene permitido ingresar a la interfaz o
salir de ella. El router en la ilustración tiene dos interfaces configuradas para IPv4 e IPv6. Si
necesitáramos ACL para ambos protocolos, en ambas interfaces y en ambos sentidos, esto
requeriría ocho ACL diferentes. Cada interfaz tendría cuatro ACL: dos ACL para IPv4 y dos ACL
para IPv6. Para cada protocolo, una ACL es para el tráfico entrante y otra para el tráfico saliente.
Nota: las ACL no deben configurarse en ambos sentidos. La cantidad de ACL y el sentido aplicado
a la interfaz dependen de los requisitos que se implementen.

Las siguientes son algunas pautas para el uso de ACL:
 Utilice las ACL en los routers de firewall ubicados entre su red interna y una red externa,
como Internet.
 Utilice las ACL en un router ubicado entre dos partes de la red para controlar el tráfico que
entra a una parte específica de su red interna o que sale de esta.
 Configure las ACL en los routers de frontera, es decir, los routers ubicados en los límites de
las redes. Esto proporciona una separación muy básica de la red externa o entre un área
menos controlada y un área más importante de su propia red.
 Configure las ACL para cada protocolo de red configurado en las interfaces del router de
frontera.
Las tres P
Para recordar una regla general de aplicación de ACL en un router, puede pensar en “las tres P”.
Se puede configurar una ACL por protocolo, por sentido y por interfaz:
 Una ACL por protocolo: para controlar el flujo de tráfico en una interfaz, se debe definir una
ACL para cada protocolo habilitado en la interfaz.
 Una ACL por sentido: las ACL controlan el tráfico en una interfaz de a un sentido por vez.
Se deben crear dos ACL diferentes para controlar el tráfico entrante y saliente.
 Una ACL por interfaz: las ACL controlan el tráfico para una interfaz, por ejemplo,
GigabitEthernet 0/0.

El uso de las ACL requiere prestar atención a los detalles y un extremo cuidado. Los errores
pueden ser costosos en términos de tiempo de inactividad, esfuerzos de resolución de problemas y
servicio de red deficiente. Antes de configurar una ACL, se requiere una planificación básica. En la
ilustración, se presentan pautas que constituyen la base de una lista de prácticas recomendadas
para ACL.
9.1.5 Pautas para la colocación de ACL
La correcta colocación de las ACL puede contribuir a que la red funcione de forma más eficaz. Se
puede colocar una ACL para reducir el tráfico innecesario. Por ejemplo, el tráfico que se denegará
en un destino remoto no se debe reenviar mediante recursos de red por la ruta hacia ese destino.
Cada ACL se debe colocar donde tenga más impacto en la eficiencia. Como se muestra en la
ilustración, las reglas básicas son las siguientes:

 ACL extendidas: coloque las ACL extendidas lo más cerca posible del origen del tráfico que
se filtrará. De esta manera, el tráfico no deseado se deniega cerca de la red de origen, sin
que cruce la infraestructura de red.
 ACL estándar: debido a que en las ACL estándar no se especifican las direcciones de
destino, colóquelas tan cerca del destino como sea posible. Si coloca una ACL estándar en el
origen del tráfico, evitará de forma eficaz que ese tráfico llegue a cualquier otra red a través
de la interfaz a la que se aplica la ACL.
La colocación de la ACL y, por lo tanto, el tipo de ACL que se utiliza también puede depender de lo
siguiente:
 Alcance del control del administrador de la red: la colocación de la ACL puede depender
de si el administrador de red controla tanto la red de origen como la de destino o no.
 Ancho de banda de las redes involucradas: el filtrado del tráfico no deseado en el origen
impide la transmisión de ese tráfico antes de que consuma ancho de banda en la ruta hacia
un destino. Esto es de especial importancia en redes con un ancho de banda bajo.
 Facilidad de configuración: si un administrador de red desea denegar el tráfico proveniente

de varias redes, una opción es utilizar una única ACL estándar en el router más cercano al
destino. La desventaja es que el tráfico de dichas redes utilizará ancho de banda de manera
innecesaria. Se puede utilizar una ACL extendida en cada router donde se origina tráfico.
Esto ahorra ancho de banda, ya que el tráfico se filtra en el origen, pero requiere la creación
de ACL extendidas en varios routers.
Nota: para la certificación CCNA, la regla general es que las ACL extendidas se coloquen lo más
cerca posible del origen y que las ACL estándar se coloquen lo más cerca posible del destino.

Las ACL estándar solo pueden filtrar tráfico según la dirección de origen. La regla básica para la
colocación de una ACL estándar es colocar la ACL lo más cerca posible de la red de destino. Esto
permite que el tráfico llegue a todas las demás redes, excepto la red que filtra los paquetes.
En la ilustración, el administrador desea impedir que el tráfico que se origina en la red

192.168.10.0/24 llegue a la red 192.168.30.0/24.
Si la ACL estándar se coloca en la interfaz de salida del R1, eso evitaría que el tráfico de la red
192.168.10.0/24 alcance cualquier red a la que se pueda llegar a través de la interfaz Serial 0/0/0
del R1.
De acuerdo con las pautas básicas de colocación de ACL estándar cerca del destino, en la
ilustración se muestran dos interfaces posibles del R3 a las que aplicar la ACL estándar:
 Interfaz S0/0/1 del R3: la aplicación de una ACL estándar para impedir que el tráfico de
192.168.10.0/24 ingrese a la interfaz S0/0/1 evita que dicho tráfico llegue a 192.168.30.0/24 y
al resto de las redes a las que puede llegar el R3. Esto incluye la red 192.168.31.0/24. Dado
que el objetivo de la ACL es filtrar el tráfico destinado solo a 192.168.30.0/24, no se debe
aplicar una ACL estándar a esta interfaz.
 Interfaz G0/0 del R3: al aplicar una ACL estándar al tráfico que sale por la interfaz G0/0, se
filtran los paquetes que van de 192.168.10.0/24 a 192.168.30.0/24. Esto no afecta a las otras
redes a las que puede llegar el R3. Los paquetes de 192.16810.0/24 aún pueden llegar a
192.168.31.0/24.

Al igual que las ACL estándar, las ACL extendidas pueden filtrar el tráfico según la dirección de
origen. Sin embargo, las ACL extendidas también pueden filtrar el tráfico según la dirección de
destino, el protocolo y el número de puerto. Esto permite que los administradores de red tengan
más flexibilidad en cuanto al tipo de tráfico que se puede filtrar y dónde colocar la ACL. La regla
básica para la colocación de una ACL extendida es colocarla lo más cerca posible del origen. Esto
evita que el tráfico no deseado se envíe a través de varias redes y luego sea denegado cuando
llegue a destino.
Los administradores de red solo pueden colocar ACL en los dispositivos que controlan. Por lo
tanto, la colocación se debe determinar en el contexto de hasta dónde se extiende el control del
administrador de red. En la ilustración, se muestra que el administrador de la empresa A, que
incluye las redes 192.168.10.0/24 y 192.168.11.0/24 (denominadas .10 y .11 en este ejemplo),
desea controlar el tráfico a la empresa B. Lo que el administrador desea específicamente es
denegar el tráfico de Telnet y FTP de la red .11 a la red 192.168.30.0/24 de la empresa B (.30 en
este ejemplo). Al mismo tiempo, se debe permitir que el resto del tráfico de la red .11 salga de la
empresa A sin restricciones.
Existen varias formas de lograr estos objetivos. Una ACL extendida en el R3 que bloquee Telnet y
FTP de la red .11 cumpliría el objetivo, pero el administrador no controla el R3. Además, esta
solución también permite que el tráfico no deseado cruce toda la red y luego sea bloqueado en el
destino. Esto afecta la eficacia general de la red.
Una mejor solución es colocar una ACL extendida en el R1 que especifique tanto las direcciones
de origen como las de destino (redes .11 y .30, respectivamente) y que aplique la regla “no se
permite que el tráfico de Telnet y FTP de la red .11 vaya a la red .30”. En la ilustración, se
muestran dos interfaces posibles en el R1 para aplicar la ACL extendida:

 Interfaz S0/0/0 del R1 (de salida):una de las posibilidades es aplicar una ACL extendida de
salida en la interfaz S0/0/0. Debido a que la ACL extendida puede examinar tanto la dirección
de origen como la de destino, solo se deniegan los paquetes FTP y Telnet de
192.168.11.0/24, y el R1 reenvía el resto del tráfico de 192.168.11.0/24 y de otras redes. La
desventaja de colocar la ACL extendida en esta interfaz es que la ACL debe procesar todo el
tráfico que sale de S0/0/0, incluidos los paquetes de 192.168.10.0/24.
 Interfaz G0/1 del R1 (de entrada): la aplicación de una ACL extendida al tráfico que ingresa
a la interfaz G0/1 implica que solamente los paquetes de la red 192.168.11.0/24 están sujetos
al procesamiento de la ACL en el R1. Debido a que el filtro se debe limitar solo a aquellos
paquetes que salen de la red 192.168.11.0/24, la aplicación de una ACL extendida a G0/1 es
la mejor solución.

9.2 ACL de IPv4 estándar

9.2.1 Configuración de ACL de IPv4 estándar
Cuando el tráfico ingresa al router, se compara con todas las ACE en el orden en que las entradas
se encuentran en la ACL. El router continúa procesando las ACE hasta que encuentra una
coincidencia. El router procesa el paquete según la primera coincidencia y no se examinan más
ACE.
Si no se encuentran coincidencias cuando el router llega al final de la lista, se deniega el tráfico.

Esto se debe a que, de manera predeterminada, hay una denegación implícita al final de todas las
ACL para el tráfico sin coincidencias con una entrada configurada. Una ACL de entrada única con
solo una entrada de denegación tiene el efecto de denegar todo el tráfico. Se debe configurar al
menos una ACE permit en una ACL. En caso contario, se bloquea todo el tráfico.
Para la red en la ilustración, si se aplica la ACL 1 o la ACL 2 a la interfaz S0/0/0 del R1 en el

sentido de salida, se obtiene el mismo resultado. A la red 192.168.10.0 se le permite acceder a las
redes a las que puede llegar mediante S0/0/0, mientras que a 192.168.11.0 no se le permite
acceder a esas redes.

Lógica de las ACL estándar
En la ilustración, se revisa la dirección de origen de los paquetes que ingresan al router a través de
la interfaz G0/0 según las siguientes entradas:
access-list 2 deny 192.168.10.10
access-list 2 permit 192.168.10.0 0.0.0.255
access-list 2 deny 192.168.0.0 0.0.255.255
access-list 2 permit 192.0.0.0 0.255.255.255
Si se permiten los paquetes, se enrutan a través del router hacia una interfaz de salida. Si se
deniegan los paquetes, se descartan en la interfaz de entrada.

Configurar las ACL estándar.
Para utilizar ACL estándar numeradas en un router Cisco, primero debe crear la ACL estándar y, a
continuación, activarla en una interfaz.
El comando de configuración globalaccess-list define una ACL estándar con un número entre 1
y 99. La versión 12.0.1 del software IOS de Cisco amplió ese intervalo y permite que se utilicen los
números que van de 1300 a 1999 para las ACL estándar. Esto permite que se genere un máximo
de 798 ACL estándar posibles. A estos números adicionales se los denomina “ACL de IP
extendidas”.
La sintaxis completa del comando de ACL estándar es la siguiente:
Router(config)# access-listaccess-list-
number { deny |permit | remark } Origen [source-wildcard ][ log ]
En la figura 1, se explica detalladamente la sintaxis para una ACL estándar.
Las ACE pueden permitir o denegar un solo host o un rango de direcciones host. Para crear una
instrucción de host en la ACL numerada 10 que permita un host específico con la dirección IP
192.168.10.0, debe introducir lo siguiente:
R1(config)# access-list 10 permit host 192.168.10.10
Como se muestra en la figura 2, para crear una instrucción que permita un rango de direcciones
IPv4 en una ACL numerada 10 que permite todas las direcciones IPv4 en la red 192.168.10.0/24,
debe introducir lo siguiente:

Para eliminar la ACL, se utiliza el comando de configuración global no access-list. La

ejecución del comando show access-list confirma que se eliminó la lista de acceso 10.
Por lo general, cuando un administrador crea una ACL, conoce y entiende el objetivo de cada
instrucción. Sin embargo, para asegurar que el administrador y otras personas recuerden el
propósito de las instrucciones, se deben incluir comentarios (remarks). La palabra clave remark se
utiliza en los documentos y hace que sea mucho más fácil comprender las listas de acceso. El
texto de cada comentario tiene un límite de 100 caracteres. La ACL que se muestra en la figura 3,
que es bastante simple, se utiliza a modo de ejemplo. Cuando se revisa la ACL en la configuración
mediante el comando show running-config, también se muestra el comentario.

El IOS de Cisco aplica una lógica interna al aceptar y procesar las ACE estándar. Como se
mencionó anteriormente, las ACE se procesan en forma secuencial, por lo que el orden en que se
introducen es importante.
Por ejemplo, en la figura 1, la ACL 3 contiene dos ACE. La primera ACE utiliza una máscara
wildcard para denegar un rango de direcciones que incluye todos los hosts en la red
192.168.10.0/24. La segunda ACE es una instrucción de host que examina un host específico:
192.168.10.10. Este es un host dentro del rango de hosts que se configuró en la instrucción
anterior. Es decir, 192.168.10.10 es un host en la red 192.168.10.0/24. La lógica interna del IOS
para las listas de acceso estándar rechaza la segunda instrucción y envía un mensaje de error,
porque es un subconjunto de la instrucción anterior. Observe que, en la ilustración, el router asigna
automáticamente el número de secuencia 10 como número de secuencia asignado a la primera
instrucción introducida en este ejemplo. El resultado del router incluye el mensaje “part of the
existing rule at sequence num 10” en referencia a la regla (“parte de la regla existente en el número
de secuencia 10”) y no acepta la instrucción.
Nota: actualmente, las ACL extendidas no producen errores similares.
La configuración en la figura 2 de la ACL 4 tiene las mismas dos instrucciones, pero en orden
inverso. Esta es una secuencia válida de instrucciones, porque la primera instrucción se refiere a
un host específico, no a un rango de hosts.

En la figura 3, la ACL 5 muestra que se puede configurar una instrucción de host después de una
instrucción que denota un rango de hosts. El host no debe estar dentro del rango que abarca una
instrucción anterior. La dirección host 192.168.11.10 no forma parte de la red 192.168.10.0/24, por
lo que se trata de una instrucción válida.
Nota: es posible que el orden en que se introducen las ACE estándar no sea el orden en que se
almacenen, se muestren o se procesen en el router. Esto se analizará en una sección posterior.
Procedimientos de configuración de ACL estándar

Después de que se configura una ACL estándar, se vincula a una interfaz mediante el comando ip
access-groupdel modo de configuración de interfaz:
Router(config-if)# ip access-group { access-list-number |nombre-lista-

acceso } { pre | out}
Para eliminar una ACL de una interfaz, primero introduzca el comando no ip access-group en
la interfaz y, a continuación, introduzca el comando globalno access-list para eliminar la ACL
completa.
En la figura 1, se enumeran los pasos y la sintaxis para configurar y aplicar una ACL estándar
numerada en un router.
En la figura 2, se muestra un ejemplo de una ACL para permitir una sola red.
Esta ACL solo permite que se reenvíe mediante la interfaz S0/0/0 el tráfico de la red de origen
192.168.10.0. El tráfico proveniente de redes distintas de la red 192.168.10.0 se bloquea.
En la primera línea, se identifica la ACL como lista de acceso 1. Esta lista permite el tráfico que
coincide con los parámetros seleccionados. En este caso, la dirección IPv4 y la máscara wildcard
que identifican a la red de origen son 192.168.10.0 0.0.0.255. Recuerde que existe una denegación
implícita de todas las instrucciones que equivale a agregar la línea access-list 1 deny
0.0.0.0 255.255.255.255.
El comando de configuración de interfazip access-group 1 out vincula la ACL 1 a la interfaz

Serial 0/0/0 como filtro de salida.
Por lo tanto, la ACL 1 solo permite que los hosts de la red 192.168.10.0/24 salgan por el router R1.
Esta lista deniega cualquier otra red, incluida la red 192.168.11.0.

En la figura 1, se muestra un ejemplo de una ACL que permite una subred específica, a excepción
de un host específico en esa subred.
Esta ACL reemplaza el ejemplo anterior, pero también bloquea el tráfico de una dirección
específica. El primer comando elimina la versión anterior de la ACL 1. La siguiente instrucción de
ACL deniega el host de la PC1 ubicado en 192.168.10.10. Todos los demás hosts en la red

192.168.10.0/24 se permiten. En este caso, la instrucción deny implícita también coincide con
todas las demás redes.
La ACL se vuelva a aplicar a la interfaz S0/0/0 en sentido de salida.
En la figura 2, se muestra un ejemplo de una ACL que deniega un host específico. Esta ACL
reemplaza el ejemplo anterior. En este ejemplo, se sigue bloqueando el tráfico del host PC1, pero
se permite el resto del tráfico.
Los primeros dos comandos son los mismos que en el ejemplo anterior. El primer comando elimina
la versión anterior de la ACL 1, y la siguiente instrucción de ACL deniega el host PC1 que está
ubicado en 192.168.10.10.
La tercera línea es nueva y permite el resto de los hosts. Esto significa que se permiten todos los
hosts de la red 192.168.10.0/24, excepto PC1, que se denegó en la instrucción anterior.
Esta ACL se aplica a la interfaz G0/0 en sentido de entrada. Debido a que el filtro afecta
únicamente a la LAN 192.168.10.0/24 en G0/0, es más eficaz aplicar la ACL a la interfaz de
entrada. Se puede aplicar la ACL a s0/0/0 en sentido de salida, pero entonces el R1 tendría que
examinar los paquetes de todas las redes, incluida 192.168.11.0/24.

La asignación de nombres a las ACL hace más fácil comprender su función. Por ejemplo, una ACL
configurada para denegar el tráfico FTP se podría llamar NO_FTP. Cuando se identifica la ACL con
un nombre en lugar de un número, el modo de configuración y la sintaxis de los comandos son
sutilmente diferentes.
En la figura 1, se muestran los pasos necesarios para crear una ACL estándar con nombre.
Paso 1. En el modo de configuración global, utilice el comando ip access-list para crear una
ACL con nombre. Los nombres de las ACL son alfanuméricos, distinguen mayúsculas de
minúsculas y deben ser únicos. El comando ip access-list standard nombre se utiliza
para crear una ACL estándar con nombre, mientras que el comando ip access-list
extended nombre se utiliza para una lista de acceso extendida. Después de introducir el
comando, el router se encuentra en el modo de configuración de ACL estándar con nombre, según
lo que indica la petición de entrada.
Nota: las ACL numeradas utilizan el comando de configuración global access-list, mientras
que las ACL de IPv4 con nombre utilizan el comando ip access-list.
Paso 2. En el modo de configuración de ACL con nombre, utilice las

instruccionespermit o deny a fin de especificar una o más condiciones para determinar si un
paquete se reenvía o se descarta.
Paso 3. Aplique la ACL a una interfaz con el comando ip access-group. Especifique si la ACL
se debe aplicar a los paquetes cuando ingresan por la interfaz (in) o cuando salen de la interfaz
(out).

En la figura 2, se muestran los comandos que se utilizan para configurar una ACL estándar con
nombre en el router R1, en la que la interfaz G0/0 deniega el acceso del host 192.168.11.10 a la
red 192.168.10.0. La ACL se llama NO_ACCESS.
No es necesario que los nombres de las ACL comiencen con mayúscula, pero esto los hace
destacarse cuando se observa el resultado de show running-config. También hace que sea menos
probable que cree accidentalmente dos ACL diferentes con el mismo nombre pero con distinto uso
de mayúsculas.

Puede utilizar la palabra clave remark para incluir comentarios (remarks) sobre entradas en
cualquier ACL de IP estándar o extendida. Estos comentarios facilitan la comprensión y la revisión
de las ACL. Cada línea de comentarios tiene un límite de 100 caracteres.
El comentario puede ir antes o después de una instrucción permit o deny. Debe ser coherente en
cuanto a la ubicación del comentario, de manera que quede claro qué comentario describe cuál de
las instrucciones permit o deny. Por ejemplo, sería confuso colocar algunos comentarios antes
de las instrucciones permit o deny correspondientes y otros después de estas.
Para incluir un comentario para las ACL de IPv4 estándar o extendidas numeradas, utilice el
comando de configuración global access-list lista-acceso_número
remark comentario. Para eliminar el comentario, utilice la versión no de este comando.
En el primer ejemplo, se muestra que la ACL numerada deniega la salida de la estación de trabajo
de invitado 192.168.10.10 por S0/0/0, pero permite el resto de los dispositivos de 192.168.0.0/16.
Para crear una entrada en una ACL estándar o extendida con nombre, utilice el comando de
configuración de lista de acceso remark. Para eliminar el comentario, utilice la versión no de este
comando. En el ejemplo 2, se muestra una ACL estándar con nombre. En este ejemplo, las
instrucciones remark indican que se deniega la estación de trabajo de laboratorio con la dirección
host 192.168.11.10, pero que los dispositivos de las demás redes están permitidos.
9.2.2 Modificación de ACL de IPv4
Edición de ACL numeradas

Cuando se configura una ACL estándar, las instrucciones se agregan a la configuración en

ejecución. Sin embargo, no hay una característica de edición incorporada que permita realizar
cambios en una ACL.
Existen dos maneras de editar una ACL estándar numerada.
Método 1: uso de un editor de texto
Después de familiarizarse con el proceso de creación y edición de ACL, puede ser más fácil
generar la ACL mediante un editor de texto como el Bloc de notas de Microsoft. Esto permite crear
o editar la ACL y luego pegarla en el router. Para una ACL existente, puede utilizar el
comandoshow running-config para mostrar la ACL, copiarla y pegarla en el editor de texto,
realizar los cambios necesarios y pegarla nuevamente en el router.
Configuración. Suponga, por ejemplo, que la dirección host IPv4 de la ilustración se introdujo
incorrectamente. En lugar del host 192.168.10.99, debería ser el host 192.168.10.10. Los pasos
para editar y corregir la ACL 1 son los siguientes:
Paso 1. Muestre la ACL mediante el comando show running-config. En el ejemplo de la

ilustración, se utiliza la palabra clave include para mostrar solamente las ACE.
Paso 2. Seleccione la ACL, cópiela y, luego, péguela en el Bloc de notas de Microsoft. Edite la lista
según sea necesario. Una vez que la ACL se muestre correctamente en el Bloc de notas de
Microsoft, selecciónela y cópiela.
Paso 3. En el modo de configuración global, elimine la lista de acceso con el comando no

access-list 1. De lo contrario, las nuevas instrucciones se agregarán a la ACL existente. A
continuación, pegue la nueva ACL en la configuración del router.
Paso 4. Verifique los cambios mediante el comando show running-config.
Es necesario recordar que, al utilizar el comando no access-list, las distintas versiones del
software IOS actúan de forma diferente. Si la ACL que se eliminó sigue estando aplicada a una
interfaz, algunas versiones del IOS actúan como si no hubiera ninguna ACL que proteja la red,
mientras que otras deniegan todo el tráfico. Por esta razón, es aconsejable eliminar la referencia a
la lista de acceso de la interfaz antes de modificar la lista. Además, tenga en cuenta que si hay un
error en la nueva lista, debe deshabilitarla y solucionar el problema. En ese caso, la red no tiene
ninguna ACL durante el proceso de corrección.

Método 2: uso del número de secuencia
Como se muestra en la ilustración, en la configuración inicial de la ACL 1 se incluyó una instrucción

de host para el host 192.168.10.99, pero eso fue un error. Se debería haber configurado el host
192.168.10.10. Para editar la ACL con los números de secuencia, siga estos pasos:
Paso 1. Muestre la ACL actual mediante el comando show access-lists 1. El resultado de

este comando se analizará en mayor detalle más adelante en esta sección. El número de
secuencia se muestra al principio de cada instrucción. El número de secuencia se asignó
automáticamente cuando se introdujo la instrucción de la lista de acceso. Observe que la
instrucción que está mal configurada tiene el número de secuencia 10.
Paso 2. Introduzca el comando ip access-lists standard que se utiliza para configurar las
ACL con nombre. El número de la ACL, 1, se utiliza como nombre. Primero, la instrucción mal
configurada se debe eliminar con el comando no 10, donde “10” se refiere al número de
secuencia. Luego, se agrega una nueva instrucción de número de secuencia 10 mediante el
comando 10 deny host 192.168.10.10.
Nota: las instrucciones no se pueden sobrescribir con el mismo número de secuencia que el de
una instrucción existente. Primero se debe eliminar la instrucción actual y, luego, se puede agregar
la nueva.
Paso 3. Verifique los cambios mediante el comando show access-lists.
Como se mencionó anteriormente, el IOS de Cisco implementa una lógica interna en las listas de
acceso estándar. Es posible que el orden en que se introducen las ACE estándar no sea el orden
en que se almacenen, se muestren o se procesen en el router. El comando show access-
lists muestra las ACE con sus números de secuencia.

En un ejemplo anterior, se utilizaron los números de secuencia para editar una ACL estándar
numerada. Mediante una referencia a los números de secuencia de la instrucción, se pueden
insertar o eliminar fácilmente instrucciones individuales. Este método también se puede utilizar
para editar las ACL estándar con nombre.
En la ilustración, se muestra un ejemplo de inserción de una línea en una ACL con nombre.
 En el primer resultado del comandoshow, se puede ver que la ACL con el nombre
NO_ACCESS tiene dos líneas numeradas que indican las reglas de acceso para una estación
de trabajo con la dirección IPv4 192.168.11.10.
 El comando ip access-list standard se utiliza para configurar las ACL con nombre. Se
pueden insertar o eliminar instrucciones desde el modo de configuración de listas de acceso
con nombre. El comando nonúmero-secuencia se utiliza para eliminar instrucciones
individuales.
 Para agregar una instrucción para denegar otra estación de trabajo, se debe insertar una
línea numerada. En el ejemplo, se agrega la estación de trabajo con la dirección IPv4
192.168.11.11 mediante el nuevo número de secuencia 15.
 Mediante el último resultado del comando show, se verifica que la nueva estación de trabajo
ahora tiene el acceso denegado.

Como se muestra en la figura 1, el comando show ip interface se utiliza para verificar la ACL
en la interfaz El resultado de este comando incluye el número o el nombre de la lista de acceso y el
sentido en el que se aplicó la ACL. El resultado muestra que la lista de acceso 1 se aplica a la
interfaz de salida S0/0/0 del router R1 y que la lista de acceso NO_ACCESS se aplica a la interfaz
g0/0, también en sentido de salida.
En el ejemplo de la figura 2, se muestra el resultado de emitir el comando show access-

lists en el router R1. Para ver una lista de acceso individual, utilice el comando show access-
lists seguido del número o el nombre de la lista de acceso. Es posible que las instrucciones de
NO_ACCESS se vean extrañas. Observe que el número de secuencia 15 se muestra antes que el
número de secuencia 10. Esto se debe al proceso interno del router y se analizará más adelante
en esta sección.

Una vez que la ACL se aplicó a una interfaz y se realizaron algunas pruebas, el comando show
access-lists muestra las estadísticas para cada instrucción que tiene coincidencias. En el
resultado que se muestra en la figura 1, observe que se encontraron coincidencias para algunas de
las instrucciones. Cuando se genera tráfico que debe coincidir con una instrucción de ACL, las
coincidencias que se muestran en el resultado del comando show access-lists deberían
aumentar. Por ejemplo, en este caso, si se hace ping de la PC1 a la PC3 o la PC4, en el resultado
se mostrará un aumento en las coincidencias para la instrucción deny de ACL 1.
Tanto las instrucciones permit como las deny realizan un seguimiento de las estadísticas de
coincidencias; sin embargo, recuerde que cada ACL tiene una instrucción deny any implícita como
última instrucción. Esta instrucción no aparece en el comando show access-lists, por lo que
no se muestran estadísticas para esa instrucción. Para ver las estadísticas de la instrucción deny
any implícita, la instrucción se puede configurar manualmente y aparecerá en el resultado. Se debe
tener sumo cuidado cuando se configura manualmente la instrucción deny any, ya que coincidirá
con todo el tráfico. Si esta instrucción no se configura como la última instrucción en la ACL, podría
ocasionar resultados inesperados.
Durante la prueba de una ACL, se pueden borrar los contadores mediante el comando clear
access-list counters. Este comando se puede utilizar solo o con el número o el nombre de
una ACL específica. Como se muestra en la figura 2, este comando borra los contadores de
estadísticas para una ACL.

El IOS de Cisco implementa una lógica interna en las ACL estándar. Como se mencionó
anteriormente, una parte de esta lógica evita que las instrucciones de host se configuren después
de una instrucción de rango si el host es parte de ese rango, como se muestra en la figura 1.
Otra parte de la lógica interna del IOS es responsable de la secuenciación interna de las ACE
estándar. En la figura 2, se muestra la configuración de una lista de acceso estándar. Las
instrucciones de rango que deniegan tres redes se configuran primero, y después se configuran
cinco instrucciones de host. Las instrucciones de host son todas instrucciones válidas, porque sus
direcciones IP host no forman parte de las instrucciones de rango introducidas previamente.
El comando show running-config se utiliza para verificar la configuración de la ACL. Observe

que las instrucciones se enumeran en un orden distinto al orden en que se introdujeron.
Utilizaremos el comando show access-lists para comprender la lógica detrás de esto.
Como se muestra en la figura 3, el comando show access-lists muestra las ACE junto con sus
números de secuencia. Sería de esperar que el orden de las instrucciones en el resultado reflejara
el orden en que se introdujeron. Sin embargo, el resultado de show access-lists muestra que
este no es el caso.
El orden en que se enumeran las ACE estándar es la secuencia utilizada por el IOS para procesar
la lista. Observe que las instrucciones se agrupan en dos secciones: las instrucciones de host
seguidas por las instrucciones de rango. El número de secuencia indica el orden en que se
introdujo la instrucción, no el orden en que se procesará.
Las instrucciones de host se enumeran primero, pero no necesariamente en el orden en que se

introdujeron. El IOS ordena las instrucciones de host mediante una función de hash especial. El
orden resultante optimiza la búsqueda de una entrada de ACL de host.
Las instrucciones de rango se muestran después de las instrucciones de host. Estas instrucciones
se enumeran en el orden en que se introdujeron.
Recuerde que las ACL estándar y numeradas se pueden editar con números de secuencia. El
número de secuencia que se muestra en el resultado del comandoshow access-lists es el

número utilizado para eliminar las instrucciones individuales de la lista. Cuando se introduce una
nueva instrucción de ACL, el número de secuencia solo afecta a la ubicación de una instrucción de
rango en la lista. Las instrucciones de host siempre se ordenan con la función de hash.
Siguiendo con el ejemplo, una vez que se guarda la configuración en ejecución, el router se vuelve
a cargar (se reinicia). Como se muestra en la figura 3, el comando show access-lists muestra
la ACL en el mismo orden, sin embargo, las instrucciones se volvieron a numerar. Los números de
secuencia ahora están en orden numérico.
Nota: la función de hash se aplica solamente a las instrucciones de host en listas de acceso de
IPv4 estándar. El algoritmo no se utiliza para las ACL de IPv4 extendidas ni las ACL de IPv6. Esto
se debe a que las ACL extendidas e IPv6 filtran más de una sola dirección de origen. Los detalles
de la función de hash exceden el ámbito de este curso.

9.2.3 Protección de puertos VTY con una ACL de IPv4 estándar
Uso de una ACL para controlar el acceso a VTY
Cisco recomienda utilizar SSH para las conexiones administrativas a los routers y switches. Si la
imagen del software IOS de Cisco en su router no admite SSH, puede mejorar la seguridad de las
líneas administrativas mediante la restricción del acceso a VTY. La restricción del acceso a VTY es
una técnica que permite definir las direcciones IP a las que se les permite acceder por Telnet al
proceso de EXEC del router. Puede controlar qué estación de trabajo administrativa o qué red
administra el router mediante la configuración de una ACL y una instrucción access-class en las
líneas VTY. También puede utilizar esta técnica con SSH para mejorar aún más la seguridad de
acceso administrativo.
El comando access-class configurado en el modo de configuración de línea restringe las

conexiones de entrada y salida entre una VTY determinada (en un dispositivo de Cisco) y las
direcciones en una lista de acceso.
Las listas de control de acceso estándar y extendidas se aplican a los paquetes que se transportan
a través de un router, no están diseñadas para bloquear los paquetes que se originan en el router.
Una ACL extendida para Telnet de salida no evita las sesiones de Telnet iniciadas por el router de
manera predeterminada.
Por lo general, se considera que el filtrado del tráfico de Telnet o SSH es una función de una ACL
de IP extendida, porque filtra un protocolo de nivel superior. Sin embargo, debido a que se utiliza el
comando access-class para filtrar sesiones de Telnet/SSH entrantes o salientes por dirección
de origen, se puede utilizar una ACL estándar.
La sintaxis del comando access-classes la siguiente:

Router (config)# access-class número-lista-acceso { pre [ vrf-

also ] | out }
El parámetro in limita las conexiones de entrada entre las direcciones en la lista de acceso y el
dispositivo de Cisco, mientras que el parámetro out limita las conexiones de salida entre un
dispositivo de Cisco en particular y las direcciones en la lista de acceso.
En la figura 1, se muestra un ejemplo en el que se permite que un rango de direcciones acceda a

las líneas VTY de 0 a 4. La ACL de la ilustración se configuró para permitir que la red 192.168.10.0
acceda a las líneas VTY de 0 a 4, pero para denegar las demás redes.
Para configurar listas de acceso en los VTY, se debe tener en cuenta lo siguiente:
 Solamente se pueden aplicar listas de acceso numeradas a los VTY.
 Se deben establecer restricciones idénticas en todos los VTY, porque un usuario puede
intentar conectarse a cualquiera de ellos.
Utilice el verificador de sintaxis de la figura 2 para poner en práctica la protección del acceso a
VTY.
Después de configurar la ACL para restringir el acceso a las líneas VTY, es importante verificar que
funcione correctamente. En la ilustración, se muestran dos dispositivos que intentan conectarse al
R1 mediante SSH. Se configuró la lista de acceso 21 en las líneas VTY en el R1. La PC1 logra
conectarse, mientras que la PC2 no puede establecer una conexión SSH. Este es el

comportamiento que se espera, ya que la lista de acceso configurada permite el acceso a VTY
desde la red 192.168.10.0/24 y deniega al resto de los dispositivos.
El resultado del R1 muestra lo que se produce al emitir el comando show access-

lists después de que la PC1 y la PC2 intentan conectarse mediante SSH. La coincidencia en la
línea permit del resultado es producto de una conexión SSH correcta de la PC1. La coincidencia en
la instrucción deny se debe al intento fallido de la PC2, un dispositivo en la red 192.168.11.0/24, de
establecer una conexión SSH.
9.3 ACL de IPv4 extendidas

9.3.1 Estructura de una ACL de IPv4 extendida
Prueba de paquetes con ACL extendidas
Para un control más preciso del filtrado del tráfico, se pueden crear ACL de IPv4 extendidas. Las
ACL extendidas se numeran del 100 al 199 y del 2000 a 2699, lo que da un total de 799 ACL
extendidas numeradas posibles. Las ACL extendidas también pueden tener nombre.
Las ACL extendidas se utilizan con más frecuencia que las ACL estándar, porque proporcionan un
mayor grado de control. Como se muestra en la ilustración, al igual que las ACL estándar, las ACL
extendidas revisan las direcciones de origen de los paquetes, pero también revisan la dirección de
destino, los protocolos y los números de puerto (o de servicios). Esto proporciona una gama de
criterios más amplia sobre la cual basar la ACL. Por ejemplo, una ACL extendida puede permitir el
tráfico de correo electrónico de una red a un destino específico y, simultáneamente, denegar la
transferencia de archivos y la navegación Web.

Prueba de puertos y servicios
La capacidad de filtrar por protocolos y números de puerto permite que los administradores de red
creen ACL extendidas muy específicas. Se puede especificar una aplicación mediante la
configuración del número o el nombre de un puerto bien conocido.
En la figura 1, se muestran algunos ejemplos de la forma en que un administrador especifica un

número de puerto TCP o UDP colocándolo al final de la instrucción de la ACL extendida. Se
pueden utilizar operaciones lógicas, por ejemplo, igual que (eq), distinto de (neq), mayor que (gt) y
menor que (lt).
En la figura 2, se muestra cómo visualizar una lista de números de puerto y de palabras clave que
pueden utilizarse al generar una ACL mediante el siguiente comando:
R1(config)# access-list 101 permit tcp any any eq?

9.3.2 Configuración de ACL de IPv4 extendidas
Los pasos del procedimiento para configurar ACL extendidas son los mismos que para las ACL
estándar. Primero se configura la ACL extendida y, a continuación, se activa en una interfaz. Sin
embargo, la sintaxis de los comandos y los parámetros son más complejos, a fin de admitir las
funciones adicionales proporcionadas por las ACL extendidas.
Nota: la lógica interna aplicada al ordenamiento de las instrucciones de las ACL estándar no se
aplica a las ACL extendidas. El orden en que se introducen las instrucciones durante la
configuración es el orden en que se muestran y se procesan.

En la figura 1, se muestra la sintaxis frecuente de los comandos para las ACL de IPv4 extendidas.
Observe que hay muchas palabras clave y parámetros para las ACL extendidas. No es necesario
utilizar todas las palabras clave y todos los parámetros al configurar una ACL extendida. Recuerde
que puede utilizar el símbolo? para obtener ayuda al introducir comandos complejos.
En la figura 2, se muestra un ejemplo de una ACL extendida. En este ejemplo, el administrador de

red configuró las ACL para restringir el acceso de red a fin de permitir la navegación de sitios web
solo desde la LAN conectada a la interfaz G0/0 a cualquier red externa. La ACL 103 permite que el
tráfico proveniente de cualquier dirección en la red 192.168.10.0 vaya a cualquier destino, sujeto a
la limitación de que el tráfico utilice solo los puertos 80 (HTTP) y 443 (HTTPS).
La naturaleza de HTTP requiere que el tráfico fluya nuevamente hacia la red desde los sitios web a
los que se accede mediante clientes internos. El administrador de red desea restringir ese tráfico
de retorno a los intercambios HTTP de los sitios web solicitados y denegar el resto del tráfico. La
ACL 104 logra esto mediante el bloqueo de todo el tráfico entrante, excepto las conexiones
establecidas previamente. La instrucción permit en la ACL 104 permite el tráfico entrante con el
parámetro established.
El parámetro established permite que solo las respuestas al tráfico procedente de la red
192.168.10.0/24 vuelvan a esa red. Si el segmento TCP que regresa tiene los bits ACK o de
restablecimiento (RST) establecidos, que indican que el paquete pertenece a una conexión
existente, se produce una coincidencia. Sin el parámetro established en la instrucción de ACL,
los clientes pueden enviar tráfico a un servidor web, pero no recibir el tráfico que vuelve de dicho
servidor.

En el ejemplo anterior, el administrador de red configuró una ACL para permitir que los usuarios de
la red 192.168.10.0/24 exploren sitios web seguros e inseguros. Aunque se configuró, la ACL no
filtrará el tráfico hasta que se aplique a una interfaz. Para aplicar una ACL a una interfaz, primero
debe considerar si el tráfico que se filtrará es entrante o saliente. Cuando un usuario de la LAN
interna accede a un sitio web en Internet, hay tráfico que sale hacia Internet. Cuando un usuario
interno recibe un correo electrónico de Internet, el tráfico ingresa al router local. Sin embargo,
cuando se aplica una ACL a una interfaz, los términos “entrada” y “salida” tienen otros significados.
Desde el punto de vista de una ACL, la entrada y salida son respecto de la interfaz del router.
En la topología de la ilustración, el R1 tiene tres interfaces: una interfaz serial, S0/0/0, y dos
interfaces Gigabit Ethernet, G0/0 y G0/1. Recuerde que una ACL extendida comúnmente se
debería aplicar cerca del origen. En esta topología, la interfaz más cercana al origen del tráfico de
destino es la interfaz G0/0.
La solicitud de tráfico web de los usuarios en la LAN 192.168.10.0/24 entra a la interfaz G0/0. El
tráfico de retorno de las conexiones establecidas a los usuarios en la LAN sale de la interfaz G0/0.
En el ejemplo, se aplica la ACL a la interfaz G0/0 en ambos sentidos. La ACL de entrada, 103,
revisa el tipo de tráfico. La ACL de salida, 104, revisa si hay tráfico de retorno de las conexiones
establecidas. Esto restringe el acceso a Internet desde 192.168.10.0 para permitir solamente la
navegación de sitios web.

Nota: las listas de acceso se podrían haber aplicado a la interfaz S0/0/0, pero en ese caso el
proceso de ACL del router tendría que examinar todos los paquetes que ingresan al router y no
solo el tráfico que va hacia 192.168.11.0 y que vuelve de esa red. Esto provocaría que el router
realice un procesamiento innecesario.
En el ejemplo que se muestra en la figura 1, se deniega el tráfico FTP de la subred 192.168.11.0

que va a la subred 192.168.10.0, pero se permite el resto del tráfico. Observe el uso de las
máscaras wildcard y de la instrucción deny any explícita. Recuerde que FTP utiliza los puertos TCP
20 y 21, por lo tanto, la ACL requiere ambas palabras claves de nombre de puerto ftp y ftp-
data o eq 20 y eq 21 para denegar el tráfico FTP.
Si se utilizan números de puerto en vez de nombres de puerto, los comandos se deben escribir de
la siguiente forma:
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq 20
access-list 114 permit tcp 192.168.20.0 0.0.0.255 any eq 21
Para evitar que la instrucción deny any implícita al final de la ACL bloquee todo el tráfico, se agrega
la instrucción permit ip any any. Si no hay por lo menos una instrucción permit en una ACL,
todo el tráfico en la interfaz donde se aplicó esa ACL se descarta. La ACL se debe aplicar en
sentido de entrada en la interfaz G0/1 para filtrar el tráfico de la LAN 192.168.11.0/24 cuando
ingresa a la interfaz del router.
En el ejemplo que se muestra en la figura 2, se deniega el tráfico de Telnet de cualquier origen a la

LAN 192.168.11.0/24, pero se permite el resto del tráfico IP. Debido a que el tráfico destinado a la
LAN 192.168.11.0/24 sale de la interfaz G0/1, la ACL se aplica a G0/1 con la palabra claveout.

Observe el uso de las palabras claveany en la instrucción permit. Esta instrucción permit se agrega
para asegurar que no se bloquee ningún otro tipo de tráfico.
Nota: en ambos ejemplos en las figuras 1 y 2, se utiliza la instrucción permit ip any any al
final de la ACL. Para obtener mayor seguridad, se puede utilizar el comando permit
192.168.11.0 0.0.0.255 any.

Las ACL extendidas con nombre se crean esencialmente de la misma forma que las ACL estándar
con nombre. Para crear una ACL extendida con nombre, realice los siguientes pasos:
Paso 1. En el modo de configuración global, utilice el comando ip access-list

extended nombre para definir un nombre para la ACL extendida.
Paso 2. En el modo de configuración de ACL con nombre, especifique las condiciones

para permit o deny.
Paso 3. Vuelva al modo EXEC privilegiado y verifique la ACL con el comando show access-
lists nombre.
Paso 4. Guarde las entradas en el archivo de configuración mediante el comando copy

running-config startup-config.
Para eliminar una ACL extendida con nombre, utilice el comando de configuración global no ip
access-list extended nombre.
En la ilustración, se muestran las versiones con nombre de las ACL creadas en los ejemplos
anteriores. La ACL con nombre SURFING permite que los usuarios en la LAN 192.168.10.0/24
accedan a sitios web. La ACL con nombre BROWSING permite el tráfico de retorno de las
conexiones establecidas. Cuando se utilizan las ACL con nombre, las reglas se aplican en sentido
de entrada y de salida en la interfaz G0/0.
Después de configurar una ACL y aplicarla a una interfaz, utilice los comandos show del IOS de
Cisco para verificar la configuración. En la ilustración, en el ejemplo de arriba se muestra el
comando del IOS de Cisco que se utiliza para mostrar el contenido de todas las ACL. En el ejemplo

de abajo, se muestra el resultado de emitir el comando show ip interface g0/0 en el router

R1.
A diferencia de las ACL estándar, las ACL extendidas no implementan la misma lógica interna ni la
misma función de hash. El resultado y los números de secuencia que se muestran en el resultado
del comando show access-lists están en el orden en que se introdujeron las instrucciones.
Las entradas de host no se enumeran automáticamente antes de las entradas de rango.
El comando show ip interface se utiliza para verificar la ACL en la interfaz y el sentido en el

que se aplicó. El resultado de este comando incluye el número o el nombre de la lista de acceso y
el sentido en el que se aplicó la ACL. Los nombres de las ACL BROWSING y SURFING en
mayúscula se destacan en el resultado que se ve en la pantalla.
Después de verificar la configuración de una ACL, el siguiente paso es confirmar que la ACL
funcione según lo esperado, es decir, que bloquee y permita el tráfico según se espera.
Las pautas analizadas anteriormente en esta sección sugieren que las ACL se configuren en una
red de prueba y después se implementen en la red de producción.
Se puede editar una ACL extendida mediante el mismo proceso que una ACL estándar, el cual se
analizó en una sección anterior. Las ACL extendidas se pueden modificar mediante los métodos
siguientes:
 Método 1: editor de texto. Con este método, la ACL se copia y pega en el editor de texto,
donde se realizan los cambios. La lista de acceso actual se elimina mediante el comando no
access-list. Luego, la ACL modificada se pega nuevamente en la configuración.
 Método 2: números de secuencia.Los números de secuencia se pueden utilizar para

eliminar o para insertar una instrucción de ACL. El comandoip access-list
extendednombre se utiliza para ingresar al modo de configuración de ACL con nombre. Si
la ACL es numerada en vez de tener un nombre, se utiliza el número de la ACL en el
parámetronombre. Las ACE se pueden insertar o eliminar.

En la ilustración, se muestra que el administrador debe editar la ACL con nombre SURFING para
corregir una errata en la instrucción de la red de origen. Para ver los números de secuencia
actuales, se utiliza el comando show access-lists. La instrucción que se edita se identifica
como instrucción 10. La instrucción original se elimina con el comando nonúmero_secuencia. La
instrucción corregida se agrega y se reemplaza la instrucción original.
9.4 Resolución de problemas de ACL

9.4.1 Procesamiento de paquetes con ACL
Lógica de ACL de entrada
En la figura 1, se muestra la lógica para una ACL de entrada. Si hay una coincidencia entre la
información en un encabezado de paquete y una instrucción de ACL, el resto de las instrucciones
de la lista se omiten y se permite o se deniega el paquete según lo especificado por la instrucción
de la coincidencia. Si no existe una coincidencia entre un encabezado de paquete y una instrucción
de ACL, el paquete se prueba en relación con la siguiente instrucción de la lista. Este proceso de
búsqueda de coincidencias continúa hasta que se llega al final de la lista.
Al final de cada ACL, hay una instrucción deny any implícita. Esta instrucción no se muestra en el
resultado. Esta instrucción implícita final se aplica a todos los paquetes cuyas condiciones no se
probaron como verdaderas. Esta condición de prueba final coincide con el resto de los paquetes y
da como resultado una acción de denegación. En lugar de avanzar en el sentido de entrada o de
salida de una interfaz, el router descarta todos los paquetes restantes. A esta instrucción final se la
suele conocer como instrucción “deny any implícita” o “denegación de todo el tráfico”. Debido a
esta instrucción, una ACL debería incluir, por lo menos, una instrucción permit. De lo contrario, la
ACL bloquea todo el tráfico.
Lógica de ACL de salida
En la figura 2, se muestra la lógica para una ACL de salida. Antes de que se reenvíe un paquete a
una interfaz de salida, el router revisa la tabla de routing para ver si el paquete es enrutable. Si no
lo es, se descarta y no se prueba en relación con las ACE. A continuación, el router revisa si la

interfaz de salida está agrupada en una ACL. Si la interfaz de salida no está agrupada en una ACL,
el paquete se puede enviar al búfer de salida. A continuación, se indican algunos ejemplos de la
operación de la ACL de salida:
 Ninguna ACL aplicada a la interfaz:si la interfaz de salida no está agrupada en una ACL de
salida, el paquete se envía directamente a la interfaz de salida.
 ACL aplicada a la interfaz: si la interfaz de salida está agrupada en una ACL de salida, el
paquete no se envía por la interfaz de salida hasta que se lo prueba mediante la combinación
de ACE relacionadas con esa interfaz. Según las pruebas de ACL, el paquete se permite o se
deniega.
Para las listas de salida, “permit” (permitir) significa enviar el paquete al búfer de salida y “deny”
(denegar) significa descartar el paquete.
ACL y routing, y procesos de ACL en un router
En la ilustración, se muestra la lógica de los procesos de routing y ACL. Cuando un paquete llega a
una interfaz del router, el proceso del router es el mismo, ya sea si se utilizan ACL o no. Cuando
una trama ingresa a una interfaz, el router revisa si la dirección de capa 2 de destino coincide con
la dirección de capa 2 de la interfaz, o si dicha trama es una trama de difusión.

Si se acepta la dirección de la trama, se desmonta la información de la trama y el router revisa si

hay una ACL en la interfaz de entrada. Si existe una ACL, el paquete se prueba en relación con las
instrucciones de la lista.
Si el paquete coincide con una instrucción, se permite o se deniega. Si se acepta el paquete, se

compara con las entradas en la tabla de routing para determinar la interfaz de destino. Si existe
una entrada para el destino en la tabla de routing, el paquete se conmuta a la interfaz de salida. De
lo contrario, se descarta.
A continuación, el router revisa si la interfaz de salida tiene una ACL. Si existe una ACL, el paquete
se prueba en relación con las instrucciones de la lista.
Si el paquete coincide con una instrucción, se permite o se deniega.
Si no hay una ACL o si se permite el paquete, este se encapsula en el nuevo protocolo de capa 2 y
se reenvía por la interfaz al siguiente dispositivo.
Las ACL estándar solo examinan la dirección IPv4 de origen. El destino del paquete y los puertos
involucrados no se tienen en cuenta.
El proceso de decisión de una ACL estándar se detalla en la ilustración. El software IOS de Cisco
prueba las direcciones en relación con cada una de las condiciones de la ACL. La primera
coincidencia determina si el software acepta o rechaza la dirección. Dado que el software deja de
probar las condiciones después de la primera coincidencia, el orden de las condiciones es
fundamental. Si no coincide ninguna condición, la dirección se rechaza.

En la ilustración, se muestra la ruta de decisión lógica que utiliza una ACL extendida creada para
filtrar direcciones de origen y destino, y números de protocolo y de puerto. En este ejemplo, la ACL
primero filtra sobre la dirección de origen y, a continuación, sobre el puerto y el protocolo de origen.
Luego, filtra sobre la dirección de destino y después sobre el puerto y el protocolo de destino, y
toma la decisión final de permiso o denegación.
Recuerde que las entradas en las ACL se procesan una tras otra, de modo que una decisión
negativa (“no”) no es necesariamente una decisión de denegación (“deny”). A medida que avanza
a través de la ruta de decisión lógica, tenga en cuenta que un “no” significa que se debe pasar a la
siguiente entrada hasta que se encuentre una coincidencia para una condición.
9.4.2 Errores comunes de ACL
Mediante los comandos show descritos anteriormente, se revela la mayoría de los errores más
comunes de ACL. Los errores más comunes incluyen introducir las ACE en el orden incorrecto y no
aplicar los criterios adecuados a las reglas de ACL.
Ejemplo de error 1
En la ilustración, el host 192.168.10.10 no tiene conectividad con 192.168.30.12. Al observar el

resultado del comando show access-lists, se muestran las coincidencias para la primera
instrucción deny. Esto indica que la instrucción coincidió con el tráfico.
Solución: mire el orden de las ACE. El host 192.168.10.10 no tiene conectividad con
192.168.30.12, debido al orden de la regla 10 en la lista de acceso. Dado que el router procesa las
ACL en orden descendente, la instrucción 10 deniega el host 192.168.10.10, por lo que la
instrucción 20 nunca puede tener una coincidencia. Las instrucciones 10 y 20 deben invertirse. La
última línea permite el resto del tráfico que no es TCP y que se clasifica como IP (ICMP, UDP,
etcétera).

Ejemplo de error 2
En la ilustración, la red 192.168.10.0/24 no puede utilizar TFTP para conectarse a la red

192.168.30.0/24.
Solución: la red 192.168.10.0/24 no puede utilizar TFTP para conectarse a la red 192.168.30.0/24,
porque TFTP utiliza el protocolo de transporte UDP. La instrucción 30 en la lista de acceso 120
permite todo el resto del tráfico TCP. Sin embargo, debido a que TFTP utiliza UDP en lugar de
TCP, se deniega implícitamente. Recuerde que la instrucción deny any implícita no aparece en el
resultado del comando show access-lists y, por lo tanto, las coincidencias no se muestran.
La instrucción 30 debería ser ip any any.
Esta ACL funciona si se aplica a G0/0 del R1, a S0/0/1 del R3 o a S0/0/0 del R2 en sentido de
entrada. Sin embargo, según la regla que indica colocar las ACL extendidas más cerca del origen,
la mejor opción es colocarla en sentido de entrada en G0/0 del R1, porque permite que el tráfico no
deseado se filtre sin cruzar la infraestructura de la red.

Ejemplo de error 3
En la ilustración, la red 192.168.11.0/24 puede utilizar Telnet para conectarse a 192.168.30.0/24,

pero según la política de la empresa, esta conexión no debería permitirse. Los resultados del
comando show access-lists 130 indican que se encontró una coincidencia para la instrucción
permit.
Solución: la red 192.168.11.0/24 puede utilizar Telnet para conectarse a la red 192.168.30.0/24,
porque el número de puerto Telnet en la instrucción 10 de la lista de acceso 130 aparece en una
posición incorrecta en la instrucción de ACL. Actualmente, la instrucción 10 deniega cualquier
paquete de origen con un número de puerto que equivalga a Telnet. Para denegar el tráfico
entrante de Telnet en G0/1, deniegue el número de puerto de destino que equivale a Telnet, por
ejemplo, deny tcp any any eq telnet.

Ejemplo de error 4
En la ilustración, el host 192.168.30.12 puede conectarse a 192.168.31.12 mediante Telnet, pero la

política de la empresa establece que esta conexión no debe permitirse. Los resultados del
comando show access-lists 140indican que se encontró una coincidencia para la instrucción
permit.
Solución: el host 192.168.30.12 puede utilizar Telnet para conectarse a 192.168.31.12 porque no
hay reglas que denieguen el host 192.168.30.12 o su red como origen. La instrucción 10 de la lista
de acceso 140 deniega la interfaz del router por la que el tráfico ingresa a este. La dirección host
IPv4 en la instrucción 10 debería ser 192.168.30.12.

Ejemplo de error 5
En la ilustración, el host 192.168.30.12 puede utilizar Telnet para conectarse a 192.168.31.12, pero
según la política de seguridad, esta conexión no debe permitirse. El resultado del comando show
access-lists 150 indica que no se encontraron coincidencias para la instrucción deny según
se esperaba.
Solución: el host 192.168.30.12 puede utilizar Telnet para conectarse a 192.168.31.12, debido al
sentido en el que se aplica la lista de acceso 150 a la interfaz G0/1. La instrucción 10 deniega que
cualquier dirección de origen se conecte al host 192.168.31.12 mediante Telnet. Sin embargo, para
un filtrado correcto, este filtro se debe aplicar en sentido de salida en G0/1.

9.5 ACL de IPv6

9.5.1 Creación de ACL de IPv6
Las ACL de IPv6 son similares a las ACL de IPv4 en cuanto a la configuración y el funcionamiento.
Si ya está familiarizado con las listas de acceso de IPv4, las ACL de IPv6 serán fáciles de
comprender y configurar.
Existen dos tipos de ACL en IPv4: las estándar y las extendidas. Ambos tipos de ACL pueden ser
numeradas o con nombre.
En cuanto a IPv6, hay solamente un tipo de ACL, que equivale a la ACL de IPv4 extendida con
nombre. No existen ACL numeradas en IPv6. En resumen, las características de las ACL de IPv6
son las siguientes:
 Son ACL con nombre únicamente.
 Equivalen a la funcionalidad de una ACL de IPv4 extendida.
Una ACL de IPv4 y una ACL de IPv6 no pueden tener el mismo nombre.

Aunque las ACL de IPv4 y de IPv6 son muy similares, hay tres diferencias fundamentales entre
ellas.
 Aplicación de una ACL de IPv6
La primera diferencia es el comando que se utiliza para aplicar una ACL de IPv6 a una interfaz.
IPv4 utiliza el comando ip access-group para aplicar una ACL de IPv4 a una interfaz IPv4. IPv6
utiliza el comando ipv6 traffic-filter para realizar la misma función para las interfaces
IPv6.
 Ausencia de máscaras wildcard
A diferencia de las ACL de IPv4, las ACL de IPv6 no utilizan máscaras wildcard. En cambio, se
utiliza la longitud de prefijo para indicar cuánto de una dirección IPv6 de origen o destino debe
coincidir.
 Instrucciones predeterminadas adicionales
La última diferencia principal tiene que ver con la inclusión de dos instrucciones permit implícitas al
final de cada lista de acceso de IPv6. Al final de todas las ACL de IPv4 estándar o extendidas, hay
una instrucción deny any o deny any anyimplícita. En IPv6 se incluye una instrucción deny
ipv6 any any similar al final de cada ACL de IPv6. La diferencia es que en IPv6 también se
incluyen otras dos instrucciones implícitas de manera predeterminada:
 permit icmp any any nd-na
 permit icmp any any nd-ns
Estas dos instrucciones permiten que el router participe en el equivalente de ARP para IPv4 en
IPv6. Recuerde que ARP se utiliza en IPv4 para resolver las direcciones de capa 3 a direcciones
MAC de capa 2. Como se muestra en la ilustración, en IPv6 se utilizan mensajes ICMP de
descubrimiento de vecinos (ND) para lograr el mismo propósito. ND utiliza mensajes de solicitud de
vecino (NS) y de anuncio de vecino (NA).

Los mensajes ND se encapsulan en paquetes IPv6 y requieren los servicios de la capa de red
IPv6, mientras que ARP para IPv4 no utiliza la capa 3. Dado que IPv6 utiliza el servicio de la
capa 3 para el descubrimiento de vecinos, las ACL de IPv6 deben permitir implícitamente que los
paquetes ND se envíen y reciban por una interfaz. Específicamente, se permiten tanto los
mensajes de descubrimiento de vecinos-anuncio de vecino (nd-na) como los de descubrimiento de
vecinos-solicitud de vecino (nd-ns).
En la figura 1, se muestra la topología que se utilizará para configurar las ACL de IPv6. Esta es
similar a la topología de IPv4 anterior, excepto por el esquema de direccionamiento IPv6. Hay tres
subredes de 2001:DB8:CAFE::/64: 2001:DB8:CAFE:10::/64, 2001:DB8:CAFE:11::/64 y
2001:DB8:CAFE:30::/64. Hay dos redes seriales que conectan los tres routers:
2001:DB8:FEED:1::/64 y 2001:DB8:FEED:2::/64.
En las figuras 2, 3 y 4, se muestra la configuración de la dirección IPv6 para cada uno de los
routers. El comando show ipv6 interface brief se utiliza para verificar la dirección y el
estado de la interfaz.
Nota: el comando no shutdown y el comando clock rate no se muestran.


En IPv6 solo hay ACL con nombre. La configuración es similar a la de una ACL de IPv4 extendida
con nombre.
En la figura 1, se muestra la sintaxis de los comandos para las ACL de IPv6. La sintaxis es similar
a la que se utiliza en ACL de IPv4 extendidas. Una diferencia importante es el uso de la longitud de
prefijo IPv6 en lugar de una máscara wildcard IPv4.
Hay tres pasos básicos para configurar una ACL de IPv6:
Paso 1. En el modo de configuración global, utilice el comando ipv6 access-

list nombre para crear una ACL de IPv6. Al igual que las ACL de IPv4 con nombre, los nombres
en IPv6 son alfanuméricos, distinguen mayúsculas de minúsculas y deben ser únicos. A diferencia
de IPv4, no hay necesidad de una opción estándar o extendida.

Paso 2. En el modo de configuración de ACL con nombre, utilice las

instruccionespermit o deny para especificar una o más condiciones para determinar si un
paquete se debe reenviar o descartar.
Paso 3. Regrese al modo EXEC privilegiado con el comando end.
En la figura 2, se muestran los pasos para crear una ACL de IPv6 con un ejemplo simple basado
en la topología anterior. La primera instrucción da el nombre NO-R3-LAN-ACCESS a la lista de
acceso de IPv6. Al igual sucede que con las ACL de IPv4 con nombre, no es necesario el uso de
mayúsculas en los nombres de las ACL de IPv6, pero esto hace que se destaquen cuando se
observa el resultado de la configuración en ejecución.
La segunda instrucción deniega todos los paquetes 2001:DB8:CAFE:30::/64 destinados a cualquier

red IPv6. La tercera instrucción permite el resto de los paquetes IPv6.
En la figura 3, se muestra la ACL en contexto con la topología.

Después de que se configura una ACL de IPv6, se la vincula a una interfaz mediante el
comando ipv6 traffic-filter:
Router(config-if)# ipv6 traffic-filter nombre-lista-acceso { pre| out }
En la ilustración, se muestra la ACL NO-R3-LAN-ACCESS configurada anteriormente y los

comandos utilizados para aplicar la ACL de IPv6 de entrada a la interfaz S0/0/0. Si se aplica la ACL
a la interfaz S0/0/0 de entrada, se denegarán los paquetes de 2001:DB8:CAFE:30::/64 en ambas
LAN en el R1.
Para eliminar una ACL de una interfaz, primero introduzca el comando no ipv6 traffic-
filter en la interfaz y, luego, introduzca el comando global no ipv6 access-list para
eliminar la lista de acceso.

Nota: tanto en IPv4 como en IPv6 se utiliza el comando ip access-class para aplicar una lista
de acceso a los puertos VTY.
Denegar FTP
La topología para los ejemplos se muestra en la figura 1.
En el primer ejemplo que se muestra en la figura 2, el router R1 está configurado con una lista de
acceso de IPv6 para denegar el tráfico FTP a 2001:DB8:CAFE:11::/64. Se deben bloquear los
puertos para los datos FTP (puerto 20) y el control FTP (puerto 21). Debido a que el filtro se aplica
en sentido de entrada a la interfaz G0/0 en el R1, solo se denegará el tráfico de la red
2001:DB8:CAFE:10::/64.
Acceso restringido
En el segundo ejemplo que se muestra en la figura 3, se configura una ACL de IPv6 para
proporcionarle a la LAN en el R3 acceso limitado a las LAN en el R1. Se agregan comentarios en
la configuración para documentar la ACL. Se marcaron las siguientes características en la ACL:
1. Las primeras dos instrucciones permit proporcionan acceso desde cualquier dispositivo al
servidor web en 2001:DB8:CAFE:10::10.
2. El resto de los dispositivos tienen denegado el acceso a la red 2001:DB8:CAFE:10::/64.
3. A la PC3 en 2001:DB8:CAFE:30::12 se le permite el acceso por Telnet a la PC2, que tiene la

dirección IPv6 2001:DB8:CAFE:11::11.
4. El resto de los dispositivos tiene denegado el acceso por Telnet a la PC2.

5. El resto del tráfico IPv6 se permite al resto de los destinos.
6. La lista de acceso de IPv6 se aplica a la interfaz G0/0 en sentido de entrada, por lo que solo la
red 2001:DB8:CAFE:30::/64 se ve afectada.

Los comandos que se utilizan para verificar una lista de acceso de IPv6 son similares a los que se
utilizan para las ACL de IPv4. Con estos comandos, se puede verificar la lista de acceso de IPv6
RESTRICTED-ACCESS que se configuró anteriormente. En la figura 1, se muestra el resultado del
comando show ipv6 interface. El resultado confirma que la ACL RESTRICTED-ACCESS
está configurada en sentido de entrada en la interfaz G0/0.
Como se muestra en la figura 2, el comando show access-lists muestra todas las listas de
acceso en el router, incluidas las ACL de IPv4 y de IPv6. Observe que, en las ACL de IPv6, los
números de secuencia se colocan al final de la instrucción y no al principio, como ocurre en las
listas de acceso de IPv4. Aunque las instrucciones aparecen en el orden en que se introdujeron, no
siempre se presentan en incrementos de 10. Esto se debe a que las instrucciones remark que se
introdujeron utilizan un número de secuencia, pero no se muestran en el resultado del
comando show access-lists.
Al igual que las ACL extendidas para IPv4, las listas de acceso de IPv6 se muestran y se procesan
en el orden en que se introducen las instrucciones. Recuerde que las ACL de IPv4 estándar utilizan
una lógica interna que cambia el orden y la secuencia de procesamiento.
Como se muestra en la figura 3, el resultado del comando show running-config incluye todas
las ACE y las instrucciones remark. Las instrucciones remark pueden colocarse antes o después
de las instrucciones permit o deny, pero se debe mantener una ubicación coherente.

9.6 Resumen
Los routers no filtran tráfico de manera predeterminada. El tráfico que ingresa al router se enruta
solamente en función de la información de la tabla de routing.
El filtrado de paquetes controla el acceso a una red mediante el análisis de los paquetes entrantes
y salientes y la transferencia o el descarte de estos según criterios como la dirección IP de origen,
la dirección IP de destino y el protocolo incluido en el paquete. Un router que filtra paquetes utiliza
reglas para determinar si permite o deniega el tráfico. Un router también puede realizar el filtrado
de paquetes en la capa 4, la capa de transporte.

Una ACL es una lista secuencial de instrucciones permit o deny. La última instrucción de una ACL
siempre es una instrucción deny implícita que bloquea todo el tráfico. Para evitar que la instrucción
deny any implícita al final de la ACL bloquee todo el tráfico, es posible agregar la
instrucción permit ip any any.
Cuando el tráfico de la red atraviesa una interfaz configurada con una ACL, el router compara la
información dentro del paquete con cada entrada, en orden secuencial, para determinar si el
paquete coincide con una de las instrucciones. Si se encuentra una coincidencia, el paquete se
procesa según corresponda.
Las ACL se configuran para aplicarse al tráfico entrante o al tráfico saliente.
Las ACL estándar se pueden utilizar para permitir o denegar el tráfico de direcciones IPv4 de
origen únicamente. El destino del paquete y los puertos involucrados no se evalúan. La regla
básica para la colocación de una ACL estándar es colocarla cerca del destino.
Las ACL extendidas filtran paquetes según varios atributos: el tipo de protocolo, la dirección IPv4
de origen o de destino y los puertos de origen o de destino. La regla básica para la colocación de
una ACL extendida es colocarla lo más cerca posible del origen.
El comando de configuración globalaccess-list define una ACL estándar con un número en el

intervalo de 1 a 99 o una ACL extendida con un número en el intervalo de 100 a 199 y de 2000 a
2699. Tanto las ACL estándar como las extendidas pueden tener un nombre. El comando ip
access-list standardnombre se utiliza para crear una ACL estándar con nombre, mientras
que el comando ip access-list extendednombre se utiliza para una lista de acceso
extendida. Las ACE de IPv4 incluyen el uso de máscaras wildcard.
Después de que se configura una ACL, se vincula a una interfaz mediante el comando ip
access-group del modo de configuración de interfaz. Recuerde la regla de las tres P: una ACL
por protocolo, por sentido y por interfaz.
Para eliminar una ACL de una interfaz, primero introduzca el comando no ip access-group en
la interfaz y, a continuación, introduzca el comando globalno access-list para eliminar la ACL
completa.
Los comandos show running-config yshow access-lists se utilizan para verificar la

configuración de la ACL. El comando show ip interface se utiliza para verificar la ACL en la
interfaz y el sentido en el que se aplicó.
El comando access-class configurado en el modo de configuración de línea restringe las

conexiones de entrada y salida entre una VTY determinada y las direcciones en una lista de
acceso.
Al igual que las ACL de IPv4 con nombre, los nombres en IPv6 son alfanuméricos, distinguen
mayúsculas de minúsculas y deben ser únicos. A diferencia de IPv4, no hay necesidad de una
opción estándar o extendida.
En el modo de configuración global, utilice el comando ipv6 access-list nombre para crear
una ACL de IPv6. A diferencia de las ACL de IPv4, las ACL de IPv6 no utilizan máscaras wildcard.

En cambio, se utiliza la longitud de prefijo para indicar cuánto de una dirección IPv6 de origen o
destino debe coincidir.
Después de que se configura una ACL de IPv6, se la vincula a una interfaz mediante el
comando ipv6 traffic-filter.

10 DHCP
10.1 Introducción
Todo dispositivo que se conecta a una red necesita una dirección IP única. Los administradores de
red asignan direcciones IP estáticas a los routers, a los servidores, a las impresoras y a otros
dispositivos de red cuyas ubicaciones (físicas y lógicas) probablemente no cambien. Por lo general,
se trata de dispositivos que proporcionan servicios a los usuarios y dispositivos en la red. Por lo
tanto, las direcciones que se les asignan se deben mantener constantes. Además, las direcciones
estáticas habilitan a los administradores para que administren estos dispositivos en forma remota.
A los administradores de red les resulta más fácil acceder a un dispositivo cuando pueden
determinar fácilmente su dirección IP.
Sin embargo, las computadoras y los usuarios en una organización, a menudo, cambian de
ubicación, física y lógicamente. Para los administradores de red, asignar direcciones IP nuevas
cada vez que un empleado cambia de ubicación puede ser difícil y llevar mucho tiempo. Además,
para los empleados móviles que trabajan desde ubicaciones remotas, puede ser difícil establecer
de forma manual los parámetros de red correctos. Incluso para los clientes de escritorio, la
asignación manual de direcciones IP y otra información de direccionamiento plantea una carga
administrativa, especialmente a medida que crece la red.
La introducción de un servidor de protocolo de configuración dinámica de host (DHCP) en la red

local simplifica la asignación de direcciones IP tanto a los dispositivos de escritorio como a los
móviles. El uso de un servidor de DHCP centralizado permite a las organizaciones administrar
todas las asignaciones de direcciones IP desde un único servidor. Esta práctica hace que la
administración de direcciones IP sea más eficaz y asegura la coherencia en toda la organización,
incluso en las sucursales.
DHCP está disponible tanto para IPv4 (DHCPv4) como para IPv6 (DHCPv6). En este capítulo, se
explora la funcionalidad, la configuración y la resolución de problemas de DHCPv4 y de DHCPv6.

10.2 Protocolo de configuración dinámica de host v4

10.2.1 Funcionamiento de DHCPv4
DHCPv4 asigna direcciones IPv4 y otra información de configuración de red en forma dinámica.
Dado que los clientes de escritorio suelen componer gran parte de los nodos de red, DHCPv4 es
una herramienta extremadamente útil para los administradores de red y que ahorra mucho tiempo.
Un servidor de DHCPv4 dedicado es escalable y relativamente fácil de administrar. Sin embargo,

en una sucursal pequeña o ubicación SOHO, se puede configurar un router Cisco para
proporcionar servicios DHCPv4 sin necesidad de un servidor dedicado. Un conjunto de
características del IOS de Cisco (denominado “Easy IP”) ofrece un servidor de DHCPv4 optativo
con todas las características.
DHCPv4 incluye tres mecanismos diferentes de asignación de direcciones para proporcionar

flexibilidad al asignar las direcciones IP:
 Asignación manual: el administrador asigna una dirección IPv4 preasignada al cliente, y

DHCPv4 comunica solo la dirección IPv4 al dispositivo.
 Asignación automática: DHCPv4 asigna automáticamente una dirección IPv4 estática de

forma permanente a un dispositivo y la selecciona de un conjunto de direcciones disponibles.
No hay arrendamiento, y la dirección se asigna de forma permanente al dispositivo.

 Asignación dinámica: DHCPv4 asigna dinámicamente, o arrienda, una dirección IPv4 de un

conjunto de direcciones durante un período limitado elegido por el servidor o hasta que el
cliente ya no necesite la dirección.
La asignación dinámica es el mecanismo DHCPv4 que se utiliza más comúnmente y es el eje de

esta sección. Al utilizar la asignación dinámica, los clientes arriendan la información del servidor
durante un período definido administrativamente, como se muestra en la ilustración. Los
administradores configuran los servidores de DHCPv4 para establecer los arrendamientos, a fin de
que caduquen a distintos intervalos. El arrendamiento típicamente dura de 24 horas a una semana
o más. Cuando caduca el arrendamiento, el cliente debe solicitar otra dirección, aunque
generalmente se le vuelve a asignar la misma.
Como se muestra en la figura 1, DHCPv4 funciona en un modo cliente/servidor. Cuando un cliente

se comunica con un servidor de DHCPv4, el servidor asigna o arrienda una dirección IPv4 a ese
cliente. El cliente se conecta a la red con esa dirección IP arrendada hasta que caduque el
arrendamiento. El cliente debe ponerse en contacto con el servidor de DHCP periódicamente para
extender el arrendamiento. Este mecanismo de arrendamiento asegura que los clientes que se
trasladan o se desconectan no mantengan las direcciones que ya no necesitan. Cuando caduca un
arrendamiento, el servidor de DHCP devuelve la dirección al conjunto, donde se puede volver a
asignar según sea necesario.
Origen del arrendamiento
Cuando el cliente arranca (o quiere unirse a una red), comienza un proceso de cuatro pasos para
obtener un arrendamiento. Como se muestra en la figura 2, un cliente inicia el proceso con un
mensaje de difusión DHCPDISCOVER con su propia dirección MAC para detectar los servidores
de DHCPv4 disponibles.
Detección de DHCP (DHCPDISCOVER)
El mensaje DHCPDISCOVER encuentra los servidores de DHCPv4 en la red. Dado que el cliente
no tiene información de IPv4 válida durante el arranque, utiliza direcciones de difusión de capa 2 y
de capa 3 para comunicarse con el servidor.

Oferta de DHCP (DHCPOFFER)
Cuando el servidor de DHCPv4 recibe un mensaje DHCPDISCOVER, reserva una dirección IPv4
disponible para arrendar al cliente. El servidor también crea una entrada ARP que consta de la
dirección MAC del cliente que realiza la solicitud y la dirección IPv4 arrendada del cliente. Como se
muestra en la figura 3, el servidor de DHCPv4 envía el mensaje DHCPOFFER asignado al cliente
que realiza la solicitud. El mensaje DHCPOFFER se envía como una unidifusión, y se utiliza la
dirección MAC de capa 2 del servidor como la dirección de origen y la dirección MAC de capa 2 del
cliente como el destino.
Solicitud de DHCP (DHCPREQUEST)
Cuando el cliente recibe el mensaje DHCPOFFER proveniente del servidor, envía un mensaje
DHCPREQUEST, como se muestra en la figura 4. Este mensaje se utiliza tanto para el origen
como para la renovación del arrendamiento. Cuando se utiliza para el origen del arrendamiento, el
mensaje DHCPREQUEST sirve como notificación de aceptación vinculante al servidor
seleccionado para los parámetros que ofreció y como un rechazo implícito a cualquier otro servidor
que pudiera haber proporcionado una oferta vinculante al cliente.
Muchas redes empresariales utilizan varios servidores de DHCPv4. El mensaje DHCPREQUEST

se envía en forma de difusión para informarle a este servidor de DHCPv4 y a cualquier otro
servidor de DHCPv4 acerca de la oferta aceptada.
Acuse de recibo de DHCP (DHCPACK)
Al recibir el mensaje DHCPREQUEST, el servidor verifica la información del arrendamiento con un

ping ICMP a esa dirección para asegurarse de que no esté en uso, crea una nueva entrada ARP
para el arrendamiento del cliente y responde con un mensaje DHCPACK de unidifusión, como se
muestra en la figura 5. El mensaje DHCPACK es un duplicado del mensaje DHCPOFFER, a
excepción de un cambio en el campo de tipo de mensaje. Cuando el cliente recibe el mensaje
DHCPACK, registra la información de configuración y realiza una búsqueda de ARP para la
dirección asignada. Si no hay respuesta al ARP, el cliente sabe que la dirección IPv4 es válida y
comienza a utilizarla como propia.
Renovación del arrendamiento
Solicitud de DHCP (DHCPREQUEST)
Como se muestra en la figura 6, cuando caduca el arrendamiento, el cliente envía un mensaje

DHCPREQUEST directamente al servidor de DHCPv4 que ofreció la dirección IPv4 en primera
instancia. Si no se recibe un mensaje DHCPACK dentro de una cantidad de tiempo especificada, el
cliente transmite otro mensaje DHCPREQUEST de modo que uno de los otros servidores de
DHCPv4 pueda extender el arrendamiento.
Acuse de recibo de DHCP (DHCPACK)
Al recibir el mensaje DHCPREQUEST, el servidor verifica la información del arrendamiento al

devolver un DHCPACK, como se muestra en la figura 7.


El formato del mensaje DHCPv4 se utiliza para todas las transacciones DHCPv4. Los mensajes
DHCPv4 se encapsulan dentro del protocolo de transporte UDP. Los mensajes DHCPv4 que se
envían desde el cliente utilizan el puerto de origen UDP 68 y el puerto de destino 67. Los mensajes
DHCPv4 que se envían del servidor al cliente utilizan el puerto de origen UDP 67 y el puerto de
destino 68.

En la ilustración, se muestra el formato de un mensaje DHCPv4. Los campos son los siguientes:
 Código de operación (OP):especifica el tipo de mensaje general. El valor 1 indica un

mensaje de solicitud y el valor 2 es un mensaje de respuesta.
 Tipo de hardware: identifica el tipo de hardware que se utiliza en la red. Por ejemplo, 1 es
Ethernet, 15 es Frame Relay y 20 es una línea serial. Estos son los mismos códigos que se
utilizan en mensajes ARP.
 Longitud de dirección de hardware:especifica la longitud de la dirección.
 Saltos: controla el reenvío de mensajes. Un cliente lo establece en 0 antes de transmitir una

solicitud.
 Identificador de transacción: lo utiliza el cliente para hacer coincidir la solicitud con

respuestas recibidas de los servidores de DHCPv4.
 Segundos: identifica la cantidad de segundos transcurridos desde que un cliente comenzó a

intentar adquirir o renovar un arrendamiento. Lo utilizan los servidores de DHCPv4 para
priorizar respuestas cuando hay varias solicitudes del cliente pendientes.
 Indicadores: los utiliza un cliente que no conoce su dirección IPv4 cuando envía una
solicitud. Se utiliza solo uno de los 16 bits, que es el indicador de difusión. El valor 1 en este
campo le indica al servidor de DHCPv4 o al agente de retransmisión que recibe la solicitud
que la respuesta se debe enviar como una difusión.
 Dirección IP del cliente: la utiliza un cliente durante la renovación del arrendamiento cuando
la dirección del cliente es válida y utilizable, no durante el proceso de adquisición de una
dirección. El cliente coloca su propia dirección IPv4 en este campo solamente si tiene una
dirección IPv4 válida mientras se encuentra en el estado vinculado. De lo contrario, establece
el campo en 0.
 Su dirección IP: la utiliza el servidor para asignar una dirección IPv4 al cliente.
 Dirección IP del servidor: la utiliza el servidor para identificar la dirección del servidor que
debe utilizar el cliente para el próximo paso en el proceso bootstrap, que puede ser, o no, el
servidor que envía esta respuesta. El servidor emisor siempre incluye su propia dirección
IPv4 en un campo especial llamado opción DHCPv4 Server Identifier (Identificador de
servidores DHCPv4).
 Dirección IP del gateway: enruta los mensajes DHCPv4 cuando intervienen los agentes de
retransmisión DHCPv4. La dirección del gateway facilita las comunicaciones de las solicitudes
y respuestas de DHCPv4 entre el cliente y un servidor que se encuentran en distintas
subredes o redes.
 Dirección de hardware del cliente:especifica la capa física del cliente.
 Nombre del servidor: lo utiliza el servidor que envía un mensaje DHCPOFFER o DHCPACK.
El servidor puede, de manera optativa, colocar su nombre en este campo. Puede tratarse de
un simple apodo de texto o un nombre de dominio DNS, como dhcpserver.netacad.net.

 Nombre del archivo de arranque: lo utiliza un cliente de manera optativa para solicitar un
determinado tipo de archivo de arranque en un mensaje DHCPDISCOVER. Lo utiliza un
servidor en un DHCPOFFER para especificar completamente un directorio de archivos y un
nombre de archivo de arranque.
 Opciones de DHCP: contiene las opciones de DHCP, incluidos varios parámetros requeridos
para el funcionamiento básico de DHCP. Este campo es de longitud variable. Tanto el cliente
como el servidor pueden utilizarlo.
Si un cliente está configurado para recibir su configuración IPv4 dinámicamente y desea unirse a la
red, solicita valores de direccionamiento del servidor de DHCPv4. El cliente transmite un mensaje
DHCPDISCOVER en su red local cuando arranca o detecta una conexión de red activa. Dado que
el cliente no tiene forma de obtener información acerca de la subred a la que pertenece, el mensaje
DHCPDISCOVER es una difusión IPv4 (dirección IPv4 de destino 255.255.255.255). El cliente aún
no tiene una dirección IPv4 configurada, de modo que se utiliza la dirección IPv4 de origen 0.0.0.0.
Como se muestra en la figura 1, la dirección IPv4 del cliente (CIADDR), la dirección de gateway
predeterminado (GIADDR) y la máscara de subred están marcados para indicar que se utiliza la
dirección 0.0.0.0.
Nota: la información desconocida se envía como 0.0.0.0.
Cuando el servidor de DHCPv4 recibe el mensaje DHCPDISCOVER, responde con un mensaje

DHCPOFFER. Este mensaje incluye información de configuración inicial para el cliente, como la
dirección IPv4 que el servidor ofrece, la máscara de subred, la duración del arrendamiento y la
dirección IPv4 del servidor de DHCPv4 que hace la oferta.
Es posible configurar el mensaje DHCPOFFER para que incluya otra información, como el tiempo
de renovación del arrendamiento y la dirección DNS.

Como se muestra en la figura 2, el servidor de DHCP responde al mensaje DHCPDISCOVER

asignando valores a la CIADDR y a la máscara de subred. La trama se crea mediante la dirección
de hardware del cliente (CHADDR) y se envía al cliente que realiza la solicitud.
El cliente y el servidor envían mensajes de acuse de recibo, y finaliza el proceso.

10.2.2 Configuración de un servidor de DHCPv4 básico
Un router Cisco que ejecuta el software IOS de Cisco puede configurarse para que funcione como
servidor de DHCPv4. El servidor de DHCPv4 que utiliza IOS de Cisco asigna y administra

direcciones IPv4 de conjuntos de direcciones especificados dentro del router para los clientes
DHCPv4. La topología que se muestra en la figura 1 se utiliza para ilustrar esta funcionalidad.
Paso 1. Excluir direcciones IPv4
El router que funciona como servidor de DHCPv4 asigna todas las direcciones IPv4 en un conjunto
de direcciones DHCPv4, a menos que esté configurado para excluir direcciones específicas.
Generalmente, algunas direcciones IPv4 de un conjunto se asignan a dispositivos de red que
requieren asignaciones de direcciones estáticas. Por lo tanto, estas direcciones IPv4 no deben
asignarse a otros dispositivos. Para excluir direcciones específicas, utilice el comando ip dhcp
excluded-address, como se muestra en la figura 2.
Se puede excluir una única dirección o un rango de direcciones especificando la dirección más
baja y la dirección más alta del rango. Las direcciones excluidas deben incluir las direcciones
asignadas a los routers, a los servidores, a las impresoras y a los demás dispositivos que se
configuraron manualmente.
Paso 2. Configurar un pool de DHCPv4
La configuración de un servidor de DHCPv4 implica definir un conjunto de direcciones que se

deben asignar. Como se muestra en la figura 3, el comando ip dhcp pool nombre-pool crea
un pool con el nombre especificado e ingresa el router en el modo de configuración DHCPv4, que
se identifica por la petición de entrada Router(dhcp-config)#.
Paso 3. Configurar tareas específicas
En la figura 4, se indican las tareas para finalizar la configuración del pool de DHCPv4. Algunas de
ellas son optativas, mientras que otras deben configurarse.
El conjunto de direcciones y el router de gateway predeterminado deben estar configurados. Utilice

la instrucciónnetwork para definir el rango de direcciones disponibles.
Utilice el comando default-router para definir el router de gateway predeterminado.

Normalmente, el gateway es la interfaz LAN del router más cercano a los dispositivos clientes. Se
requiere un gateway, pero se pueden indicar hasta ocho direcciones si hay varios gateways.
Otros comandos del pool de DHCPv4 son optativos. Por ejemplo, la dirección IPv4 del servidor
DNS que está disponible para un cliente DHCPv4 se configura mediante el comando dns-server.
El comando domain-name dominio se utiliza para definir el nombre de dominio. La duración del
arrendamiento de DHCPv4 puede modificarse mediante el comando lease. El valor de
arrendamiento predeterminado es un día. El comando netbios-name-server se utiliza para
definir el servidor WINS con NetBIOS.
Ejemplo de DHCPv4
En la figura 5, se utiliza la topología de ejemplo de la figura 1 para mostrar una configuración de

ejemplo con parámetros básicos de DHCPv4 configurados en el router R1, un servidor de DHCPv4
para la LAN 192.168.10.0/24.
Deshabilitación de DHCPv4

El servicio DHCPv4 está habilitado, de manera predeterminada, en versiones del software IOS de
Cisco que lo admiten. Para deshabilitar el servicio, utilice el comando del modo de configuración
global no service dhcp. Utilice el comando del modo de configuración global service
dhcp para volver a habilitar el proceso del servidor de DHCPv4. Si los parámetros no se
configuran, habilitar el servicio no tiene ningún efecto.
Utilice la actividad del verificador de sintaxis en la figura 6 para configurar parámetros de DHCPv4
similares en el R1 para la LAN 192.168.11.0/24.

En el resultado de ejemplo, se utiliza la topología que se muestra en la figura 1. En este ejemplo,

se configuró el R1 para que proporcione servicios DHCPv4. Dado que la PC1 no se encendió, no
tiene una dirección IP.
Como se muestra en la figura 2, en el resultado del comando show running-config |

section dhcp, se muestran los comandos de DHCPv4 configurados en el R1. El parámetro |
section muestra solamente los comandos asociados a la configuración de DHCPv4.

Como se muestra en la figura 3, se puede verificar el funcionamiento de DHCPv4 mediante el

comando show ip dhcp binding. Este comando muestra una lista de todas las vinculaciones
de la dirección IPv4 con la dirección MAC que fueron proporcionadas por el servicio DHCPv4. El
segundo comando en la figura 3, show ip dhcp server statistics, se utiliza para verificar
si el router recibe o envía los mensajes. Este comando muestra información de conteo con
respecto a la cantidad de mensajes DHCPv4 que se enviaron y recibieron.
Como se observa en el resultado de estos comandos, actualmente no hay vinculaciones, y las

estadísticas indican que no hay mensajes enviados o recibidos. En este momento, ningún
dispositivo solicitó servicios DHCPv4 del router R1.
En la figura 4, los comandos se emiten después de que la PC1 y la PC2 se encendieron y

finalizaron el proceso de arranque.
Observe que en la información acerca de las vinculaciones ahora se muestra que las direcciones
IPv4 192.168.10.10 a 192.168.11.10 se unieron a las direcciones MAC. Las estadísticas también
muestran actividad DHCPDISCOVER, DHCPREQUEST, DHCPOFFER y DHCPACK.
Como se muestra en la figura 5, el comando ipconfig /all, cuando se emite en la PC1,

muestra los parámetros TCP/IP. Dado que la PC1 se conectó al segmento de red 192.168.10.0/24,
recibió automáticamente un sufijo DNS, una dirección IPv4, una máscara de subred, un gateway
predeterminado y una dirección del servidor DNS de ese pool. No se requiere configurar la interfaz
del router. Si una computadora está conectada a un segmento de red que tiene un pool de
DHCPv4 disponible, la computadora puede obtener una dirección IPv4 del pool adecuado de
manera automática.



¿Qué es la retransmisión de DHCP?
En una red jerárquica compleja, los servidores empresariales suelen estar ubicados en una granja
de servidores. Estos servidores pueden proporcionar servicios DHCP, DNS, TFTP y FTP para la
red. Generalmente, los clientes de red no se encuentran en la misma subred que esos servidores.
Para ubicar los servidores y recibir servicios, los clientes con frecuencia utilizan mensajes de
difusión.
En la figura 1, la PC1 intenta adquirir una dirección IPv4 de un servidor de DHCP mediante un
mensaje de difusión. En esta situación, el router R1 no está configurado como servidor de DHCPv4
y no reenvía el mensaje de difusión. Dado que el servidor de DHCPv4 está ubicado en una red
diferente, la PC1 no puede recibir una dirección IP mediante DHCP.
En la figura 2, la PC1 intenta renovar su dirección IPv4. Para hacerlo, se emite el

comando ipconfig /release. Observe que se libera la dirección IPv4, y se muestra que la
dirección es 0.0.0.0. A continuación, se emite el comandoipconfig /renew. Este comando hace
que la PC1 transmita por difusión un mensaje DHCPDISCOVER. En el resultado se muestra que la
PC1 no puede ubicar el servidor de DHCPv4. Dado que los routers no reenvían mensajes de
difusión, la solicitud no es correcta.

Como solución a este problema, un administrador puede agregar servidores de DHCPv4 en todas
las subredes. Sin embargo, ejecutar estos servicios en varias computadoras genera un costo
adicional y sobrecarga administrativa.
Una mejor solución consiste en configurar una dirección de ayuda de IOS de Cisco. Esta solución
permite que el router reenvíe difusiones de DHCPv4 al servidor de DHCPv4. Cuando un router
reenvía solicitudes de asignación/parámetros de direcciones, actúa como agente de retransmisión
DHCPv4. En la topología de ejemplo, la PC1 transmitiría por difusión una solicitud para ubicar un
servidor de DHCPv4. Si el R1 estuviera configurado como agente de retransmisión DHCPv4,
reenviaría la solicitud al servidor de DHCPv4 ubicado en la subred 192.168.11.0.
Como se muestra en la figura 3, la interfaz en el R1 que recibe la difusión se configura con el

comando del modo de configuración de interfaz ip helper-address. La dirección del servidor
de DHCPv4 se configura como el único parámetro.
Cuando se configura el R1 como agente de retransmisión DHCPv4, acepta solicitudes de difusión

para el servicio DHCPv4 y, a continuación, reenvía dichas solicitudes en forma de unidifusión a la
dirección IPv4 192.168.11.6. El comandoshow ip interface se utiliza para verificar la
configuración.
Como se muestra en la figura 4, la PC1 ahora puede adquirir una dirección IPv4 del servidor de
DHCPv4.
DHCPv4 no es el único servicio que puede configurarse para que retransmita el router. De manera
predeterminada, el comando ip helper-address reenvía los siguientes ocho siguientes
servicios UDP:
 Puerto 37: Tiempo
 Puerto 49: TACACS
 Puerto 53: DNS
 Puerto 67: cliente DHCP/BOOTP
 Puerto 68: servidor de DHCP/BOOTP
 Puerto 69: TFTP
 Puerto 137: servicio de nombres NetBIOS
 Puerto 138: servicio de datagrama NetBIOS
Mediante el verificador de sintaxis de la figura 5, configure los comandos de retransmisión de

DHCPv4 en el router correcto de modo que la PC3 pueda recibir información de direccionamiento
IPv4 del servidor de DHCPv4. Consulte nuevamente la figura 1 para ver la topología de la red.


10.2.3 Configuración de cliente DHCPv4
En ocasiones, los routers Cisco en oficinas pequeñas y oficinas domésticas (SOHO) y en los sitios
de sucursales deben configurarse como clientes DHCPv4 de manera similar a los equipos cliente.
El método específico utilizado depende del ISP. Sin embargo, en su configuración más simple, se
utiliza la interfaz Ethernet para conectarse a un cable módem o a un módem DSL. Para configurar
una interfaz Ethernet como cliente DHCP, utilice el comando del modo de configuración de
interfaz ip address dhcp.
En la figura 1, suponga que un ISP se configuró para proporcionar direcciones IP del rango de red
209.165.201.0/27 a clientes selectos. Después de que se configura la interfaz G0/1 con el

comando ip address dhcp, el comando show ip interface g0/1 confirma que la interfaz
está activada y que la dirección fue asignada por un servidor de DHCPv4.
Utilice el verificador de sintaxis de la figura 2 para configurar la interfaz que está conectada al ISP,
a fin de adquirir una dirección del servidor de DHCP.
Normalmente, los routers con poca banda ancha para uso doméstico, como los routers Linksys, se
pueden configurar para conectarse a un ISP mediante un cable módem o un módem DSL. En la
mayoría de los casos, los routers SOHO están establecidos para adquirir una dirección IPv4
automáticamente del ISP.
Por ejemplo, en la ilustración se muestra la página de configuración de WAN predeterminada para

un router Linksys EA6500. Observe que el tipo de conexión a Internet está establecido en
Automatic Configuration - DHCP (Configuración automática, DHCP). Esto significa que cuando el
router se conecta a un cable módem, por ejemplo, es un cliente DHCPv4 y solicita una dirección
IPv4 del ISP.
Nota: la característica de clonación de la dirección MAC utiliza una dirección especificada como la
dirección MAC de origen en el ISP que interactúa con la interfaz del router. Muchos ISP asignan
direcciones IPv4 sobre la base de la dirección MAC del dispositivo durante la instalación inicial.
Cuando otro dispositivo, como un router SOHO, está conectado al ISP, el ISP puede requerir que
se configure la dirección MAC del dispositivo original en la interfaz WAN.

10.2.4 Resolución de problemas de DHCPv4
Los problemas de DHCPv4 pueden surgir debido a diversos motivos, como defectos de software
en los sistemas operativos, controladores de NIC o agentes de retransmisión DHCP. Sin embargo,
la causa más frecuente son los problemas de configuración. Debido a la cantidad de áreas
posiblemente problemáticas, se requiere adoptar un enfoque sistemático a la resolución de
problemas, como se muestra en la ilustración.
Tarea 1 de la resolución de problemas: resolver conflictos de direcciones IPv4
El arrendamiento de una dirección IPv4 puede caducar en un cliente que aún está conectado a una
red. Si el cliente no renueva el arrendamiento, el servidor de DHCPv4 puede volver a asignar esa
dirección IPv4 a otro cliente. Cuando el cliente se reinicia, solicita una dirección IPv4. Si el servidor
de DHCPv4 no responde rápidamente, el cliente utiliza la última dirección IPv4. El problema surge
cuando dos clientes utilizan la misma dirección IPv4, lo cual crea un conflicto.
El comando show ip dhcp conflicto muestra todos los conflictos de direcciones que registra
el servidor de DHCPv4. El servidor utiliza el comando ping para detectar clientes. El cliente utiliza
el protocolo de resolución de direcciones (ARP) para detectar conflictos. Si se detecta un conflicto
de dirección, esta última se elimina del pool y no se asigna hasta que un administrador resuelva el
conflicto.
Este resultado muestra las direcciones IP que tienen conflictos con el servidor de DHCP. Muestra
el método de detección y el tiempo de detección para las direcciones IP en conflicto que ofreció el
servidor de DHCP.
R1# show ip dhcp conflict
IP address Detection Method Detection time
192.168.10.32 Ping Feb 16 2013 12:28 PM

192.168.10.64 Gratuitous ARP Feb 23 2013 08:12 AM
Tarea 2 de la resolución de problemas: verificar la conectividad física
Primero, utilice el comando show interface interfaz para confirmar que la interfaz del router
que funciona como el gateway predeterminado para el cliente esté en funcionamiento. Si la interfaz
tiene otro estado que no sea activado, el puerto no pasa tráfico, incluso solicitudes de cliente
DHCP.
Tarea 3 de la resolución de problemas: probar la conectividad mediante una dirección IP

estática
Al llevar a cabo la resolución de cualquier problema de DHCPv4, verifique la conectividad de red

configurando información de la dirección IPv4 estática en una estación de trabajo cliente. Si la
estación de trabajo no puede llegar a los recursos de red con una dirección IPv4 configurada
estáticamente, la causa raíz del problema no es DHCPv4. En este punto, es necesario resolver los
problemas de conectividad de la red.
Tarea 4 de la resolución de problemas: verificar la configuración de puertos del switch
Si el cliente DHCPv4 no puede obtener una dirección IPv4 del servidor de DHCPv4 durante el
inicio, intente obtener una dirección IPv4 del servidor de DHCPv4 forzando manualmente al cliente
para que envíe una solicitud de DHCPv4.
Nota: si hay un switch entre el cliente y el servidor de DHCPv4 y el cliente no puede obtener la
configuración de DHCP, la causa pueden ser problemas con la configuración de puertos del switch.
Estas causas pueden incluir problemas de enlaces troncales y canalización, STP y RSTP.
Mediante la configuración de PortFast y las configuraciones de los puertos perimetrales se
resuelven los problemas de cliente DHCPv4 más comunes que se presentan con la instalación
inicial de un switch Cisco.
Tarea 5 de la resolución de problemas: probar el funcionamiento de DHCPv4 en la misma

subred o VLAN
Es importante distinguir si DHCPv4 funciona correctamente cuando el cliente se encuentra en la

misma subred o VLAN que el servidor de DHCPv4. Si DHCPv4 funciona correctamente cuando el
cliente se encuentra en la misma subred o VLAN, el problema puede ser el agente de
retransmisión DHCP. Si el problema persiste incluso con la prueba de DHCPv4 en la misma subred
o VLAN que el servidor de DHCPv4, en realidad puede haber un problema con el servidor de
DHCPv4.

Cuando el servidor de DHCPv4 está ubicado en una LAN distinta de la del cliente, la interfaz del
router que interactúa con el cliente se debe configurar para retransmitir las solicitudes de DHCPv4
mediante la configuración de la dirección IPv4 de ayuda. Si la dirección IPv4 de ayuda no se
configura correctamente, las solicitudes de cliente DHCPv4 no se reenvían al servidor de DHCPv4.
Siga estos pasos para verificar la configuración del router:
Paso 1. Verificar que el comando ip helper-address esté configurado en la interfaz correcta.

Este comando debe estar presente en la interfaz de entrada de la LAN que contiene las estaciones
de trabajo cliente DHCPv4 y debe estar dirigido al servidor de DHCPv4 correcto. En la ilustración,
el resultado del comando show running-config verifica que la dirección IPv4 de retransmisión
DHCP4 hace referencia a la dirección del servidor de DHCPv4 en 192.168.11.6.
El comando show ip interface también se puede utilizar para verificar la retransmisión

DHCPv4 en una interfaz.
Paso 2. Verificar que no se haya configurado el comando de configuración global no service

dhcp. Este comando deshabilita toda la funcionalidad del servidor de DHCP y de retransmisión del
router. El comando service dhcp no aparece en la configuración en ejecución, debido a que es
la configuración predeterminada
En la ilustración, el comando show running-config | include no service dhcp verifica

que el servicio DHCPv4 esté habilitado, debido a que no hay coincidencia para el comando show
running-config | include no service dhcp. Si se hubiera deshabilitado el servicio, en el
resultado se mostraría el comando no service dhcp.

En los routers configurados como servidores de DHCPv4, el proceso DHCPv4 falla si el router no
recibe solicitudes del cliente. A modo de tarea de resolución de problemas, verifique que el router
reciba la solicitud de DHCPv4 del cliente. Este paso de la resolución de problemas comprende la
configuración de una ACL para el resultado de la depuración.
En la ilustración, se muestra una ACL extendida que permite solamente paquetes con puertos de
destino UDP de 67 o 68. Estos son los puertos típicos que utilizan los clientes y los servidores de
DHCPv4 al enviar mensajes DHCPv4. La ACL extendida se utiliza con el comando debug ip
packet para mostrar solamente los mensajes DHCPv4.
En el resultado que aparece en la ilustración, se muestra que el router recibe solicitudes de DHCP
del cliente. La dirección IP de origen es 0.0.0.0, debido a que el cliente aún no tiene una dirección
IP. El destino es 255.255.255.255, debido a que el mensaje de detección de DHCP del cliente se
envía como difusión. En este resultado, solo se muestra un resumen del paquete, y no el mensaje
DHCPv4 en sí. Sin embargo, el router recibió un paquete de difusión con los puertos UDP e IP de
origen y destino adecuados para DHCPv4. En el resultado de depuración completo, se muestran
todos los paquetes en las comunicaciones DHCPv4 entre el cliente y el servidor de DHCPv4.
Otro comando útil para llevar a cabo la resolución de problemas del funcionamiento de DHCPv4 es
el comando debug ip dhcp server events. Este comando informa eventos del servidor,
como asignaciones de direcciones y actualizaciones de bases de datos. También se utiliza para
decodificar recepciones y transmisiones DHCPv4.

10.3 Protocolo de configuración dinámica de host v6

10.3.1 SLAAC y DHCPv6
De manera similar a lo que ocurre con IPv4, las direcciones IPv6 de unidifusión global pueden
configurarse manualmente o de forma dinámica. Sin embargo, existen dos métodos en los que las
direcciones IPv6 de unidifusión global pueden asignarse dinámicamente:
 Configuración automática de dirección sin estado (SLAAC), como se muestra en la ilustración
 Protocolo de configuración dinámica de host para IPv6 (DHCPv6 con estado)
Introducción a SLAAC
SLAAC es un método en el cual un dispositivo puede obtener una dirección IPv6 de unidifusión
global sin los servicios de un servidor de DHCPv6. ICMPv6 se encuentra en el centro de SLAAC.
ICMPv6 es similar a ICMPv4, pero incluye funcionalidad adicional y es un protocolo mucho más
sólido. SLAAC utiliza mensajes de solicitud y de anuncio de router ICMPv6 para proporcionar
direccionamiento y otra información de configuración que normalmente proporcionaría un servidor
de DHCP:
 Mensaje de solicitud de router (RS):cuando un cliente está configurado para obtener la

información de direccionamiento de forma automática mediante SLAAC, el cliente envía un
mensaje RS al router. El mensaje RS se envía a la dirección IPv6 de multidifusión de todos
los routers, FF02::2.
 Mensaje de anuncio de router (RA):los routers envían mensajes RA para proporcionar

información de direccionamiento a los clientes configurados para obtener sus direcciones

IPv6 de forma automática. El mensaje RA incluye el prefijo y la longitud de prefijo del

segmento local. Un cliente utiliza esta información para crear su propia dirección IPv6 de
unidifusión global. Los routers envían mensajes RA de forma periódica o en respuesta a un
mensaje RS. De manera predeterminada, los routers Cisco envían mensajes de RA cada
200 segundos. Los mensajes RA siempre se envían a la dirección IPv6 de multidifusión de
todos los nodos, FF02::1.
Como lo indica el nombre, SLAAC quiere decir “sin estado”. Un servicio sin estado significa que no
hay ningún servidor que mantenga la información de la dirección de red. A diferencia de DHCP, no
hay servidor de SLAAC que tenga información acerca de cuáles son las direcciones IPv6 que están
en uso y cuáles son las que se encuentran disponibles.
Para poder enviar mensajes RA, un router se debe habilitar como router IPv6. Para habilitar el
routing IPv6, un router se configura con el siguiente comando:
Router(config)# ipv6 unicast-routing
1. En la topología de ejemplo que se muestra en la figura 1, la PC1 está configurada para obtener
el direccionamiento IPv6 de manera automática. Desde el arranque, la PC1 no recibió un mensaje
RA, de modo que envía un mensaje RS a la dirección de multidifusión de todos los routers para
informarle al router IPv6 local que necesita un RA.
2. Como se muestra en la figura 2, el R1 recibe el mensaje RS y responde con un mensaje RA. En

el mensaje RA, se incluyen el prefijo y la longitud de prefijo de la red. El mensaje RA se envía a la
dirección IPv6 de multidifusión de todos los nodos, FF02::1, con la dirección link-local del router
como la dirección IPv6 de origen.
3. La PC1 recibe el mensaje RA que contiene el prefijo y la longitud de prefijo para la red local. La
PC1 utiliza esta información para crear su propia dirección IPv6 de unidifusión global. La PC1
ahora tiene un prefijo de red de 64 bits, pero necesita una ID de interfaz (IID) de 64 bits para crear
una dirección de unidifusión global.

Hay dos maneras en las que la PC1 puede crear su propia IID única:
 EUI-64: mediante el proceso EUI-64, la PC1 crea una IID utilizando su dirección MAC de
48 bits.
 De generación aleatoria: la IID de 64 bits puede ser un número aleatorio generado por el
sistema operativo cliente.
Como se muestra en la figura 3, la PC1 puede crear una dirección IPv6 de unidifusión global de
128 bits combinando el prefijo de 64 bits con la IID de 64 bits. La PC1 utiliza la dirección link-local
del router como su dirección IPv6 de gateway predeterminado.
4. Dado que SLAAC es un proceso sin estado, para que la PC1 pueda utilizar esta dirección IPv6
creada recientemente, debe verificar que sea única. Como se muestra en la figura 4, la PC1 envía
un mensaje de solicitud de vecino ICMPv6 con su propia dirección como la dirección IPv6 de
destino. Si ningún otro dispositivo responde con un mensaje de anuncio de vecino, la dirección es
única y puede ser utilizada por la PC1. Si la PC1 recibe un anuncio de vecino, la dirección no es
única, y el sistema operativo debe determinar una nueva ID de interfaz para utilizar.
Este proceso forma parte de la detección de vecinos ICMPv6 y se conoce como “detección de
direcciones duplicadas (DAD)”.
La decisión de si un cliente se configura para obtener su información de direccionamiento IPv6 de

forma automática mediante SLAAC, mediante DHCPv6 o mediante una combinación de ambos
depende de la configuración dentro del mensaje RA. Los mensajes RA ICMPv6 contienen dos
indicadores para señalar cuál es la opción que debe utilizar el cliente.

Los dos indicadores son el indicador de configuración de dirección administrada (indicador M) y el

indicador de otra configuración (indicador O).
Mediante distintas combinaciones de los indicadores M y O, los mensajes RA tienen una de tres
opciones de direccionamiento para el dispositivo IPv6, como se muestra en la ilustración:
 SLAAC (anuncio de router solamente)
 DHCPv6 sin estado (anuncio de router y DHCPv6)
 DHCPv6 con estado (DHCPv6 solamente)
Independientemente de la opción que se utilice, en RFC 4861 se recomienda que todos los
dispositivos IPv6 realicen la detección de direcciones duplicadas (DAD) en cualquier dirección de
unidifusión, entre las que se incluyen las direcciones configuradas mediante SLAAC o DHCPv6.
Nota: aunque el mensaje RA especifique el proceso que debe utilizar el cliente para obtener una
dirección IPv6 de forma dinámica, el sistema operativo cliente puede elegir omitir el mensaje RA y
utilizar los servicios de un servidor de DHCPv6 exclusivamente.
Opción de SLAAC (anuncio de router solamente)
SLAAC es la opción predeterminada en los routers Cisco. Tanto el indicador M como el indicador O
están establecidos en 0 en el RA, como se muestra en la ilustración.

Esta opción le indica al cliente que utilice la información que se incluye en el mensaje RA de
manera exclusiva. Esto incluye información del prefijo, de la longitud de prefijo, del servidor DNS,
de la MTU y del gateway predeterminado. No se encuentra disponible ninguna otra información de
un servidor de DHCPv6. La dirección IPv6 de unidifusión global se crea combinando el prefijo del
mensaje RA y la ID de interfaz mediante EUI-64 o mediante un valor generado aleatoriamente.
Los mensajes RA se configuran en una interfaz individual de un router. Para volver a habilitar una
interfaz para SLAAC que pudo haberse establecido en otra opción, se deben restablecer los
indicadores M y O a sus valores iniciales de 0. Esto se realiza mediante los siguientes comandos
del modo de configuración de interfaz:
Router(config-if)# no ipv6 nd managed-config-flag
Router(config-if)# no ipv6 nd other-config-flag
Si bien DHCPv6 es similar a DHCPv4 en cuanto a lo que proporciona, los dos protocolos son
independientes respecto sí. DHCPv6 se define en RFC 3315. Se trabajó mucho en esta
especificación a través de los años, como lo indica el hecho de que RFC DHCPv6 tiene el número
de revisión más alto que cualquier borrador de Internet.
Opción de DHCPv6 sin estado (anuncio de router y DHCPv6)
La opción de DHCPv6 sin estado informa al cliente que utilice la información del mensaje RA para
el direccionamiento, pero que hay más parámetros de configuración disponibles de un servidor de
DHCPv6.
Mediante el prefijo y la longitud de prefijo en el mensaje RA, junto con EUI-64 o una IID generada
aleatoriamente, el cliente crea la dirección IPv6 de unidifusión global.
A continuación, el cliente se comunica con un servidor de DHCPv6 sin estado para obtener
información adicional que no se proporciona en el mensaje RA. Puede tratarse de una lista de
direcciones IPv6 del servidor DNS, por ejemplo. Este proceso se conoce como DHCPv6 sin estado,

debido a que el servidor no mantiene información de estado del cliente (es decir, una lista de
direcciones IPv6 asignadas y disponibles). El servidor de DHCPv6 sin estado solo proporciona
parámetros de configuración para los clientes, no direcciones IPv6.
Para DHCPv6 sin estado, el indicador O se configura en 1 y el indicador M se deja en la

configuración predeterminada de 0. El valor 1 del indicador O se utiliza para informarle al cliente
que hay información de configuración adicional disponible de un servidor de DHCPv6 sin estado.
Para modificar el mensaje RA enviado en la interfaz de un router e indicar DHCPv6 sin estado,
utilice el siguiente comando:
Router(config-if)# ipv6 nd other-config-flag
DHCPv6 con estado (DHCPv6 solamente)
Esta opción es la más similar a DHCPv4. En este caso, el mensaje RA le informa al cliente que no
utilice la información contenida en el mensaje RA. Toda la información de direccionamiento y de
configuración debe obtenerse de un servidor de DHCPv6 con estado. Esto se conoce como
DHCPv6 con estado, debido a que el servidor de DHCPv6 mantiene información de estado de
IPv6. Esto es similar a la asignación de direcciones para IPv4 por parte de un servidor de DHCPv4.
El indicador M señala si se debe utilizar DHCPv6 con estado o no. El indicador O no interviene. El
siguiente comando se utiliza para cambiar el indicador M de 0 a 1 para indicar DHCPv6 con
estado:
Router(config-if)# ipv6 nd managed-config-flag

Como se muestra en la figura 1, DHCPv6 sin estado o con estado, o ambos, comienzan con un
mensaje RA ICMPv6 del router. El mensaje RA puede ser un mensaje periódico o un mensaje
solicitado por el dispositivo mediante un mensaje RS.
Si en el mensaje RA se indica DHCPv6 con estado o sin estado, el dispositivo inicia las
comunicaciones cliente/servidor DHCPv6.
Comunicaciones DHCPv6
Cuando el mensaje RA indica DHCPv6 sin estado o DHCPv6 con estado, se invoca el
funcionamiento de DHCPv6. Los mensajes DHCPv6 se envían a través de UDP. Los mensajes
DHCPv6 del servidor al cliente utilizan el puerto de destino UDP 546. El cliente envía mensajes
DHCPv6 al servidor mediante el puerto de destino UDP 547.
El cliente, ahora un cliente DHCPv6, necesita ubicar el servidor de DHCPv6. En la figura 2, el

cliente envía un mensaje DHCPv6 SOLICIT a la dirección IPv6 de multidifusión de todos los
servidores de DHCPv6 reservada, FF02::1:2. Esta dirección de multidifusión tiene alcance link-
local, lo cual significa que los routers no reenvían los mensajes a otras redes.
Uno o más servidores de DHCPv6 responden con un mensaje DHCPv6 ADVERTISE, como se
muestra en la figura 3. El mensaje ADVERTISE le informa al cliente DHCPv6 que el servidor se
encuentra disponible para el servicio DHCPv6.
En la figura 4, el cliente responde con un mensaje INFORMATION-REQUEST o DHCPv6

REQUEST al servidor, según si utiliza DHCPv6 con estado o DHCPv6 sin estado.
 Cliente DHCPv6 sin estado: el cliente envía un mensaje DHCPv6 INFORMATION-

REQUEST al servidor de DHCPv6 en el que solicita solamente parámetros de configuración,
como la dirección del servidor DNS. El cliente creó su propia dirección IPv6 mediante el uso
del prefijo del mensaje RA y una ID de interfaz autogenerada aleatoriamente.

 Cliente DHCPv6 con estado: el cliente envía un mensaje DHCPv6 REQUEST al servidor
para obtener una dirección IPv6 y todos los demás parámetros de configuración del servidor.
El servidor envía un mensaje DHCPv6 REPLY al cliente que contiene la información solicitada en
el mensaje REQUEST o INFORMATION-REQUEST, como se muestra en la figura 5.


10.3.2 DHCPv6 sin estado
Como se muestra en la figura 1, hay cuatro pasos para configurar un router como servidor de
DHCPv6:

Paso 1. Habilitar el routing IPv6
Se requiere el uso del comando ipv6 unicast-routing para habilitar el routing IPv6. Este
comando no es necesario para que el router sea un servidor de DHCPv6 sin estado, pero se
requiere para enviar mensajes RA ICMPv6.
El comando ipv6 dhcp pool nombre-pool crea un pool e ingresa el router en el modo de
configuración DHCPv6, que se identifica por la petición de entradaRouter(config-dhcpv6)#.
Paso 3. Configurar los parámetros del pool
Durante el proceso SLAAC, el cliente recibió la información que necesitaba para crear una
dirección IPv6 de unidifusión global. El cliente también recibió la información de gateway
predeterminado mediante la dirección IPv6 de origen del mensaje RA, que es la dirección link-local
del router. Sin embargo, el servidor de DHCPv6 sin estado puede configurarse para proporcionar
otra información que pudo no haberse incluido en el mensaje RA, como la dirección del servidor
DNS y el nombre de dominio.
Paso 4. Configurar la interfaz DHCPv6
El comando del modo de configuración de interfaz ipv6 dhcp server nombre-pool vincula el
pool de DHCPv6 con la interfaz. El router responde a las solicitudes de DHCPv6 sin estado en esta
interfaz con la información incluida en el pool. El indicador O debe cambiarse de 0 a 1 mediante el
comando de interfaz ipv6 nd other-config-flag. Los mensajes RA enviados en esta interfaz
indican que hay información adicional disponible de un servidor de DHCPv6 sin estado.
Ejemplo de servidor de DHCPv6 sin estado
En la figura 2, se muestra una configuración de ejemplo para que un router se configure como
servidor de DHCPv6 sin estado. Observe que el router R3 se muestra como cliente DHCPv6. El R3
está configurado como cliente para ayudar a verificar las operaciones de DHCPv6 sin estado.

En el ejemplo de esta ilustración, se utiliza un router Cisco como cliente DHCPv6 sin estado. Esta
no es una situación típica y se utiliza solo con fines de demostración. Generalmente, un cliente
DHCPv6 sin estado es un dispositivo, como una computadora, una tablet PC, un dispositivo móvil o
una cámara web.

El router cliente necesita una dirección IPv6 link-local en la interfaz para enviar y recibir mensajes
IPv6, como mensajes RS y mensajes DHCPv6. La dirección link-local de un router se crea
automáticamente cuando se habilita IPv6 en la interfaz. Esto puede suceder cuando se configura
una dirección de unidifusión global en la interfaz o cuando se utiliza el comando ipv6 enable.
Una vez que el router recibe una dirección link-local, puede enviar mensajes RS y participar en
DHCPv6.
En este ejemplo, se utiliza el comandoipv6 enable, porque el router aún no tiene una dirección
de unidifusión global.
El comando ipv6 address autoconfig habilita la configuración automática del

direccionamiento IPv6 mediante SLAAC. A continuación, se utiliza un mensaje RA para informarle
al router cliente que utilice DHCPv6 sin estado.
Verificación del servidor de DHCPv6 sin estado
En la figura 1, el comando show ipv6 dhcp pool verifica el nombre del pool de DHCPv6 y sus
parámetros. La cantidad de clientes activos es 0, porque el servidor no mantiene ningún estado.
El comando show running-config también se puede utilizar para verificar todos los comandos
que se configuraron anteriormente.
Verificación del cliente DHCPv6 sin estado
En este ejemplo, se utiliza un router como cliente DHCPv6 sin estado. En la figura 2, el resultado
del comando show ipv6 interface muestra que el router tiene “Stateless address
autoconfig enabled” (Configuración automática de dirección sin estado habilitada) y una
dirección IPv6 de unidifusión global. La dirección IPv6 de unidifusión global se creó mediante

SLAAC, que incluye el prefijo contenido en el mensaje RA. La IID se generó mediante EUI-64. No
se utilizó DHCPv6 para asignar la dirección IPv6.
La información de router predeterminado también proviene del mensaje RA. Esta era la dirección
IPv6 de origen del paquete que contenía el mensaje RA y la dirección link-local del router.
En el resultado del comando debug ipv6 dhcp detail de la figura 3, se muestran los
mensajes DHCPv6 intercambiados entre el cliente y el servidor. En este ejemplo, se introdujo el
comando en el cliente. Se muestra el mensaje INFORMATION-REQUEST, debido a que se envía
desde un cliente DHCPv6 sin estado. Observe que el cliente, el router R3, envía los mensajes
DHCPv6 desde su dirección link-local hacia la dirección de todos los agentes de retransmisión y
servidores de DHCPv6, FF02::1:2.
El resultado de depuración muestra todos los mensajes DHCPv6 enviados entre el cliente y el
servidor, entre los que se incluyen las opciones de servidor DNS y de nombre de dominio que se
configuraron en el servidor.
Utilice el verificador de sintaxis de la figura 4 para configurar y verificar DHCPv6 sin estado en el
router.


10.3.3 Servidor de DHCPv6 con estado
Configurar un servidor de DHCPv6 con estado es similar a configurar un servidor sin estado. La
diferencia más importante es que un servidor con estado también incluye información de
direccionamiento IPv6 de manera similar a un servidor DHCPv4.
Paso 1. Habilitar el routing IPv6
Como se muestra en la ilustración, se requiere el uso del comando ipv6 unicast-routing para
habilitar el routing IPv6. Este comando no es necesario para que el router sea un servidor de
DHCPv6 con estado, pero se requiere para enviar mensajes RA ICMPv6.
El comando ipv6 dhcp pool nombre-pool crea un pool e ingresa el router en el modo de
configuración DHCPv6, que se identifica por la petición de entrada Router(config-dhcpv6)#.
Paso 3. Configurar los parámetros del pool
Con DHCPv6 con estado, todos los parámetros de direccionamiento y otros parámetros de
configuración deben ser asignados por el servidor de DHCPv6. El
comando address longitud/prefijo se utiliza para indicar el conjunto de direcciones que
debe asignar el servidor. La opción lifetime indica el tiempo de arrendamiento válido y preferido
en segundos. Al igual que con DHCPv6 sin estado, el cliente utiliza la dirección IPv6 de origen del
paquete que contenía el mensaje RA.
Otra información proporcionada por el servidor de DHCPv6 con estado suele incluir la dirección del
servidor DNS y el nombre de dominio.
Paso 4. Comandos de interfaz
El comando de interfaz ipv6 dhcp server nombre-pool vincula el pool de DHCPv6 con la
interfaz. El router responde a las solicitudes de DHCPv6 sin estado en esta interfaz con la
información incluida en el pool. El indicador M debe cambiarse de 0 a 1 mediante el comando de
interfazipv6 nd managed-config-flag. Esto le informa al dispositivo que no utilice SLAAC,
sino que obtenga el direccionamiento IPv6 y todos los parámetros de configuración de un servidor
de DHCPv6 con estado.
Ejemplo de servidor de DHCPv6 con estado
En la figura 2, se muestra un ejemplo de comandos de servidor de DHCPv6 con estado para un

router configurado en el R1. Observe que no se especifica el gateway predeterminado, debido a
que el router enviará automáticamente su propia dirección link-local como el gateway
predeterminado. El router R3 está configurado como cliente para ayudar a verificar las operaciones
de DHCPv6 con estado.

Como se muestra en la ilustración, utilice el comando del modo de configuración de interfaz ipv6
enable para permitir que el router reciba una dirección link-local para enviar mensajes RS y
participe en DHCPv6.

El comando del modo de configuración de interfaz ipv6 address dhcp habilita al router para
que funcione como cliente DHCPv6 en esta interfaz.
Verificación del servidor de DHCPv6 con estado
En la figura 1, el comando show ipv6 dhcp pool verifica el nombre del pool de DHCPv6 y sus
parámetros. La cantidad de clientes activos es 1, lo que refleja que el R3 cliente recibe su dirección
IPv6 de unidifusión global de este servidor.
El comando show ipv6 dhcp binding, como se muestra en la figura 2, muestra la vinculación
automática entre la dirección link-local del cliente y la dirección asignada por el servidor.
FE80::32F7:DFF:FE25:2DE1 es la dirección link-local del cliente. En este ejemplo, esta es la
interfaz G0/1 del R3. Esta dirección está vinculada a la dirección IPv6 de unidifusión global,
2001:DB8:CAFE:1:5844:47B2:2603:C171, la cual fue asignada por el R1, el servidor de DHCPv6.
Esta información la mantiene un servidor de DHCPv6 con estado, y no un servidor de DHCPv6 sin
estado.
Verificación del cliente DHCPv6 con estado
El resultado del comando show ipv6 interface que se muestra en la figura 3 verifica la
dirección IPv6 de unidifusión global en el R3 cliente DHCPv6 que asignó el servidor de DHCPv6.
La información de router predeterminado no proviene del servidor de DHCPv6, sino que se
determinó mediante el uso de la dirección IPv6 de origen del mensaje RA. Si bien el cliente no
utiliza la información contenida en el mensaje RA, puede utilizar la dirección IPv6 de origen para
obtener la información del gateway predeterminado.
Utilice el verificador de sintaxis de la figura 4 para configurar y verificar DHCPv6 sin estado.


Si el servidor de DHCPv6 está ubicado en una red distinta de la del cliente, el router IPv6 puede
configurarse como agente de retransmisión DHCPv6. La configuración de un agente de
retransmisión DHCPv6 es similar a la configuración de un router IPv4 como retransmisor DHCPv4.
Nota: si bien la configuración de un agente de retransmisión DHCPv6 es similar a DHCPv4, los

routers o los agentes de retransmisión IPv6 reenvían mensajes DHCPv6 de manera levemente
distinta que los retransmisores DHCPv4. Los mensajes y el proceso exceden el ámbito de este
currículo.
En la figura 1, se muestra una topología de ejemplo en la que un servidor de DHCPv6 se encuentra

en la red 2001:DB8:CAFE:1::/64. El administrador de red desea utilizar este servidor de DHCPv6
como un servidor de DHCPv6 central con estado para asignar direcciones IPv6 a todos los clientes.
Por lo tanto, los clientes en otras redes, como la PC1 en la red 2001:DB8:CAFE:A::/64, deben
comunicarse con el servidor de DHCPv6.
Los mensajes DHCPv6 de los clientes se envían a la dirección IPv6 de multidifusión FF02::1:2.
Dirección de todos los agentes de retransmisión y servidores de DHCPv6: esta dirección tiene
alcance link-local, lo que significa que los routers no reenvían estos mensajes. El router se debe
configurar como agente de retransmisión DHCPv6 para habilitar al cliente y al servidor de DHCPv6
para que se comuniquen.
Configuración del agente de retransmisión DHCPv6
Como se muestra en la figura 2, un agente de retransmisión DHCPv6 se configura mediante el

comando ipv6 dhcp relay destination. Este comando se configura en la interfaz que
interactúa con el cliente DHCPv6, y se utiliza la dirección del servidor de DHCPv6 como destino.

El comando show ipv6 dhcp interface verifica que la interfaz G0/0 esté en modo de
retransmisión con 2001:DB8:CAFE:1::6 configurado como el servidor de DHCPv6.
Mediante el verificador de sintaxis de la figura 3, configure los comandos de retransmisión de

DHCPv6 en el router correcto de modo que la PC3 pueda recibir información de direccionamiento
IPv6 del servidor de DHCPv6. Consulte la figura 1 para ver la topología de la red.
10.3.4 Resolución de problemas de DHCPv6
El proceso de resolución de problemas de DHCPv6 es similar al de DHCPv4.

Tarea 1 de la resolución de problemas: resolver conflictos
De manera similar a lo que sucede con las direcciones IPv4, el arrendamiento de una dirección
IPv6 puede caducar en un cliente que aún necesita conectarse a la red. El comando show ipv6
dhcp conflicto muestra todos los conflictos de direcciones que registra el servidor de DHCPv6
con estado. Si se detecta un conflicto de dirección IPv6, el cliente, por lo general, elimina la
dirección y genera una nueva mediante SLAAC o mediante DHCPv6 con estado.
Tarea 2 de la resolución de problemas: verificar el método de asignación
El comando show ipv6 interfaceinterfaz puede utilizarse para verificar el método de

asignación de direcciones que aparece en el mensaje RA, según lo indica la configuración de los
indicadores M y O. Esta información se muestra en las últimas líneas del resultado. Si un cliente no
recibe la información de la dirección IPv6 de un servidor de DHCPv6 con estado, esto podría
deberse a indicadores M y O incorrectos en el mensaje RA.
Tarea 3 de la resolución de problemas: probar con una dirección IPv6 estática
Al llevar a cabo la resolución de cualquier problema de DHCP, ya sea DHCPv4 o DHCPv6, se

puede verificar la conectividad de red mediante la configuración de una dirección IP estática en una
estación de trabajo cliente. En el caso de IPv6, si la estación de trabajo no puede llegar a los
recursos de red con una dirección IPv6 configurada estáticamente, la causa raíz del problema no
es SLAAC o DHCPv6. En este punto, es necesario resolver los problemas de conectividad de la
red.
Tarea 4 de la resolución de problemas: verificar la configuración de puertos del switch
Si el cliente DHCPv6 no puede obtener información de un servidor de DHCPv6, verifique que el

puerto de switch esté habilitado y funcione correctamente.
Nota: si hay un switch entre el cliente y el servidor de DHCPv6, y el cliente no puede obtener la
configuración de DHCP, la causa pueden ser problemas con la configuración de puertos del switch.
Estas causas pueden incluir problemas de enlaces troncales y canalización, STP y RSTP.
Mediante la configuración de PortFast y las configuraciones de los puertos perimetrales se
resuelven los problemas de cliente DHCPv6 más comunes que se presentan con la instalación
inicial de un switch Cisco.
Tarea 5 de la resolución de problemas: probar el funcionamiento de DHCPv6 en la misma

subred o VLAN
Si el servidor de DHCPv6 con estado o sin estado funciona correctamente pero se encuentra en
una VLAN o red IPv6 distinta de la del cliente, es posible que el problema sea el agente de
retransmisión DHCPv6. El cliente que interactúa con la interfaz en el router debe configurarse con
el comando ipv6 dhcp relay destination.

Las configuraciones del router para los servicios DHCPv6 con estado y sin estado tienen muchas
similitudes, pero también incluyen diferencias significativas. En la figura 1, se muestran los
comandos de configuración para los dos tipos de servicios DHCPv6.
DHCPv6 con estado
Los routers configurados para servicios DHCPv6 con estado tienen el comando address
prefix para proporcionar información de direccionamiento.
Para servicios DHCPv6 con estado, se utiliza el comando del modo de configuración de
interfaz ipv6 nd managed-config-flag. En este caso, el cliente omite la información de
direccionamiento en el mensaje RA y se comunica con un servidor de DHCPv6 para obtener
información de direccionamiento y otra información.
DHCPv6 sin estado
Para servicios DHCPv6 sin estado, se utiliza el comando del modo de configuración de
interfaz ipv6 nd other-config-flag. Esto le informa al dispositivo que utilice SLAAC para la
información de direccionamiento y un servidor de DHCPv6 sin estado para otros parámetros de
configuración.
El comando show ipv6 interface puede utilizarse para ver la configuración actual para el
método de asignación. Como se muestra en la figura 2, la última línea del resultado indica la forma
en que los clientes obtienen direcciones y otros parámetros.

Cuando el router está configurado como servidor de DHCPv6 con estado o sin estado, el
comando debug ipv6 dhcp detail es útil para verificar la recepción y la transmisión de

mensajes DHCPV6. Como se muestra en la ilustración, un router DHCPv6 con estado recibió un
mensaje SOLICIT de un cliente. El router utiliza la información de direccionamiento en su pool
IPV6-STATEFUL para la información de asignación.
10.4 Resumen
Todos los nodos en una red requieren una dirección IP única que se comunique con otros
dispositivos. La asignación estática de información de direccionamiento IP en una red grande
produce una carga administrativa que puede eliminarse mediante el uso de DHCPv4 o DHCPv6
para asignar de forma dinámica información de direccionamiento IPv4 e IPv6, respectivamente.
DHCPv4 incluye tres mecanismos diferentes de asignación de direcciones para proporcionar

flexibilidad al asignar las direcciones IP:
 Asignación manual: el administrador asigna una dirección IPv4 preasignada al cliente, y

DHCPv4 comunica solo la dirección IPv4 al dispositivo.
 Asignación automática: DHCPv4 asigna automáticamente una dirección IPv4 estática de

forma permanente a un dispositivo y la selecciona de un conjunto de direcciones disponibles.
No hay arrendamiento, y la dirección se asigna de forma permanente al dispositivo.
 Asignación dinámica: DHCPv4 asigna dinámicamente, o arrienda, una dirección IPv4 de un

conjunto de direcciones durante un período limitado según lo configurado en el servidor o
hasta que el cliente ya no necesite la dirección.
La asignación dinámica es el mecanismo DHCPv4 utilizado más comúnmente y comprende el

intercambio de diversos paquetes entre el servidor de DHCPv4 y el cliente DHCPv4, lo que deriva
en el arrendamiento de información de direccionamiento válida durante un período predefinido.

Los mensajes cuyo origen es el cliente (DHCPDISCOVER, DHCPREQUEST) son mensajes de

difusión para permitir que todos los servidores de DHCPv4 en la red escuchen la solicitud de
información de direccionamiento y la recepción de dicha información por parte del cliente. Los
mensajes cuyo origen es el servidor de DHCPv4 (DHCPOFFER, DHCPACK) se envían como
mensajes de unidifusión directamente al cliente que solicita la información.
Existen dos métodos disponibles para la configuración dinámica de las direcciones IPv6 de
unidifusión global.
 Configuración automática de dirección sin estado (SLAAC)
 Protocolo de configuración dinámica de host para IPv6 (DHCPv6 con estado)
Con la configuración automática sin estado, el cliente utiliza información proporcionada por el
mensaje RA IPv6 para seleccionar y configurar automáticamente una dirección IPv6 única. La
opción de DHCPv6 sin estado informa al cliente que utilice la información del mensaje RA para el
direccionamiento, pero que hay más parámetros de configuración disponibles de un servidor de
DHCPv6.
DHCPv6 con estado es similar a DHCPv4. En este caso, el mensaje RA le informa al cliente que no
utilice la información contenida en el mensaje RA. Toda la información de direccionamiento y de
configuración se obtiene de un servidor de DHCPv6 con estado. El servidor de DHCPv6 mantiene
la información de estado IPv6 de manera similar a la que un servidor de DHCPv4 asigna
direcciones para IPv4.
Si el servidor de DHCP está ubicado en un segmento de red distinto del segmento del cliente
DHCP, se debe configurar un agente de retransmisión. El agente de retransmisión reenvía
mensajes de difusión específicos que se originan en un segmento LAN a un servidor especificado
ubicado en un segmento LAN distinto (en este caso, un mensaje de difusión DHCP se reenviaría a
un servidor de DHCP).
La resolución de problemas con DHCPv4 y DHCPv6 incluye las mismas tareas:
 Resolver conflictos de dirección
 Verificar la conectividad física
 Probar la conectividad con una dirección IP estática
 Verificar la configuración de puertos del switch
 Probar el funcionamiento en la misma subred o VLAN


11 Traducción de direcciones de red para IPv4 NAT.

11.1 Introducción
Todas las direcciones IPv4 públicas que se usan en Internet deben registrarse en un registro
regional de Internet (RIR). Las organizaciones pueden arrendar direcciones públicas de un SP,
pero solo el titular registrado de una dirección pública de Internet puede asignar esa dirección a un
dispositivo de red. Sin embargo, con un máximo teórico de 4300 millones de direcciones, el
espacio de direcciones IPv4 es muy limitado. Cuando Bob Kahn y Vint Cerf desarrollaron por
primera vez la suite de protocolos TCP/IP que incluía IPv4 en 1981, nunca imaginaron en qué
podría llegar a convertirse Internet. En aquel entonces, la computadora personal era, en la mayoría
de los casos, una curiosidad para los aficionados, y todavía faltaba más de una década para la
aparición de la World Wide Web.
Con la proliferación de los dispositivos informáticos personales y la llegada de la World Wide Web,
pronto resultó evidente que las 4300 millones de direcciones IPv4 no serían suficientes. La
solución a largo plazo era el protocolo IPv6, pero se necesitaban soluciones más inmediatas para
abordar el agotamiento. A corto plazo, el IETF implementó varias soluciones, entre las que se
incluía la traducción de direcciones de red (NAT) y las direcciones IPv4 privadas definidas en RFC
1918. En este capítulo, se analiza cómo se utiliza NAT combinada con el espacio de direcciones
privadas para conservar y usar de forma más eficaz las direcciones IPv4, a fin de proporcionar
acceso a Internet para las redes de todos los tamaños. En este capítulo, se abarcan los siguientes
temas:
 Las características, la terminología y las operaciones generales de NAT
 Los diferentes tipos de NAT, incluidas la NAT estática, la NAT dinámica y la NAT con
sobrecarga
 Las ventajas y las desventajas de NAT
 La configuración, la verificación y el análisis de la NAT estática, la NAT dinámica y la NAT con

sobrecarga
 La forma en que se puede usar el reenvío de puertos para acceder a los dispositivos internos
desde Internet
 La resolución de problemas de NAT mediante los comandos show ydebug
 La forma en que se utiliza NAT para IPv6 para traducir entre direcciones IPv6 y direcciones
IPv4

11.2 Funcionamiento de NAT

11.2.1 Características de NAT
No existen suficientes direcciones IPv4 públicas para asignar una dirección única a cada
dispositivo conectado a Internet. Las redes suelen implementarse mediante el uso de direcciones
IPv4 privadas, según se definen en RFC 1918. En la figura 1, se muestra el rango de direcciones
incluidas en RFC 1918. Es muy probable que la computadora que utiliza para ver este curso tenga
asignada una dirección privada.
Estas direcciones privadas se utilizan dentro de una organización o un sitio para permitir que los
dispositivos se comuniquen localmente. Sin embargo, como estas direcciones no identifican
empresas u organizaciones individuales, las direcciones privadas IPv4 no se pueden enrutar a
través de Internet. Para permitir que un dispositivo con una dirección IPv4 privada acceda a
recursos y dispositivos fuera de la red local, primero se debe traducir la dirección privada a una
dirección pública.

Como se muestra en la figura 2, NAT proporciona la traducción de direcciones privadas a

direcciones públicas. Esto permite que un dispositivo con una dirección IPv4 privada acceda a
recursos fuera de su red privada, como los que se encuentran en Internet. La combinación de NAT
con las direcciones IPv4 privadas resultó ser un método útil para preservar las direcciones IPv4
públicas. Se puede compartir una única dirección IPv4 pública entre cientos o incluso miles de
dispositivos, cada uno configurado con una dirección IPv4 privada exclusiva.
Sin NAT, el agotamiento del espacio de direcciones IPv4 habría ocurrido mucho antes del año
2000. Sin embargo, NAT presenta algunas limitaciones, las cuales se analizan más adelante en
este capítulo. La solución al agotamiento del espacio de direcciones IPv4 y a las limitaciones de
NAT es la transición final a IPv6.
NAT tiene muchos usos, pero el principal es conservar las direcciones IPv4 públicas. Esto se logra
al permitir que las redes utilicen direcciones IPv4 privadas internamente y al proporcionar la
traducción a una dirección pública solo cuando sea necesario. NAT tiene el beneficio adicional de
proporcionar cierto grado de privacidad y seguridad adicional a una red, ya que oculta las
direcciones IPv4 internas de las redes externas.
Los routers con NAT habilitada se pueden configurar con una o más direcciones IPv4 públicas
válidas. Estas direcciones públicas se conocen como “conjunto de NAT”. Cuando un dispositivo
interno envía tráfico fuera de la red, el router con NAT habilitada traduce la dirección IPv4 interna

del dispositivo a una dirección pública del conjunto de NAT. Para los dispositivos externos, todo el
tráfico entrante y saliente de la red parece tener una dirección IPv4 pública del conjunto de
direcciones proporcionado.
En general, los routers NAT funcionan en la frontera de una red de rutas internas. Una red de rutas
internas es aquella que tiene una única conexión a su red vecina, una entrada hacia la red y una
salida desde ella. En el ejemplo de la ilustración, el R2 es un router de frontera. Visto desde el ISP,
el R2 forma una red de rutas internas.
Cuando un dispositivo dentro de la red de rutas internas desea comunicarse con un dispositivo
fuera de su red, el paquete se reenvía al router de frontera. El router de frontera realiza el proceso
de NAT, es decir, traduce la dirección privada interna del dispositivo a una dirección pública,
externa y enrutable.
Nota: la conexión al ISP también puede utilizar una dirección privada o pública compartida entre
clientes. A los fines de este capítulo, se muestra una dirección pública.
Según la terminología de NAT, la red interna es el conjunto de redes sujetas a traducción. La red
externa se refiere a todas las otras redes.
Al utilizar NAT, las direcciones IPv4 se designan de distinto modo, según si están en la red privada
o en la red pública (Internet), y si el tráfico es entrante o saliente.
NAT incluye cuatro tipos de direcciones:
 Dirección local interna

 Dirección global interna
 Dirección local externa
 Dirección global externa
Al determinar qué tipo de dirección se utiliza, es importante recordar que la terminología de NAT
siempre se aplica desde la perspectiva del dispositivo con la dirección traducida:
 Dirección interna: la dirección del dispositivo que se traduce por medio de NAT.
 Dirección externa: la dirección del dispositivo de destino.
NAT también usa los conceptos de local o global con relación a las direcciones:
 Dirección local: cualquier dirección que aparece en la porción interna de la red.
 Dirección global: cualquier dirección que aparece en la porción externa de la red.
En la ilustración, la PC1 tiene la dirección local interna 192.168.10.10. Desde la perspectiva de la

PC1, el servidor web tiene la dirección externa 209.165.201.1. Cuando se envían los paquetes de
la PC1 a la dirección global del servidor web, la dirección local interna de la PC1 se traduce a
209.165.200.226 (dirección global interna). En general, la dirección del dispositivo externo no se
traduce, ya que suele ser una dirección IPv4 pública.
Observe que la PC1 tiene distintas direcciones locales y globales, mientras que el servidor web
tiene la misma dirección IPv4 pública en ambos casos. Desde la perspectiva del servidor web, el
tráfico que se origina en la PC1 parece provenir de 209.165.200.226, la dirección global interna.
El router NAT, el R2 en la ilustración, es el punto de demarcación entre las redes internas y

externas, así como entre las direcciones locales y globales.

Los términos “interna” y “externa” se combinan con los términos “global” y “local” para hacer
referencia a direcciones específicas. En la ilustración, el router R2 se configuró para proporcionar
NAT. Este tiene un conjunto de direcciones públicas para asignar a los hosts internos.
 Dirección local interna: la dirección de origen vista desde el interior de la red. En la

ilustración, la dirección IPv4 192.168.10.10 se asignó a la PC1. Esta es la dirección local
interna de la PC1.
 Dirección global interna: la dirección de origen vista desde la red externa. En la ilustración,
cuando se envía el tráfico de la PC1 al servidor web en 209.165.201.1, el R2 traduce la
dirección local interna a una dirección global interna. En este caso, el R2 cambia la dirección
IPv4 de origen de 192.168.10.10 a 209.165.200.226. De acuerdo con la terminología de NAT,
la dirección local interna 192.168.10.10 se traduce a la dirección global interna
209.165.200.226.
 Dirección global externa: la dirección del destino vista desde la red externa. Es una
dirección IPv4 enrutable globalmente y asignada a un host en Internet. Por ejemplo, se puede
llegar al servidor web en la dirección IPv4 209.165.201.1. Por lo general, las direcciones
externas globales y locales son iguales.
 Dirección local externa: la dirección del destino vista desde la red interna. En este ejemplo,
la PC1 envía tráfico al servidor web en la dirección IPv4 209.165.201.1. Si bien es poco
frecuente, esta dirección podría ser diferente de la dirección globalmente enrutable del
destino.

En la ilustración, se muestra cómo se dirige el tráfico que se envía desde una computadora interna
hacia un servidor web externo a través del router con NAT habilitada. También se muestra cómo se
dirige y se traduce inicialmente el tráfico de retorno.
Nota: el uso de la dirección local externa excede el ámbito de este curso.
En este ejemplo, la PC1 con la dirección privada 192.168.10.10 desea comunicarse con un
servidor web externo con la dirección pública 209.165.201.1.
Haga clic en el botón Reproducir de la figura para iniciar la animación.
La PC1 envía un paquete dirigido al servidor web. El R1 reenvía el paquete al R2.
Cuando el paquete llega al R2, el router con NAT habilitada para la red, el R2 lee la dirección IPv4
de destino del paquete para determinar si este cumple con los criterios especificados para la
traducción.
En este caso, la dirección IPv4 de origen cumple con los criterios y se traduce de 192.168.10.10
(dirección local interna) a 209.165.200.226 (dirección global interna). El R2 agrega esta asignación
de dirección local a global a la tabla de NAT.
El R2 envía el paquete con la dirección de origen traducida hacia el destino.
El servidor web responde con un paquete dirigido a la dirección global interna de la PC1
(209.165.200.226).
El R2 recibe el paquete con la dirección de destino 209.165.200.226. El R2 revisa la tabla de NAT

y encuentra una entrada para esta asignación. El R2 usa esta información y traduce la dirección

global interna (209.165.200.226) a la dirección local interna (192.168.10.10), y el paquete se

reenvía a la PC1.
11.2.2 Tipos de NAT
Existen tres tipos de traducción NAT:
 Traducción estática de direcciones (NAT estática): asignación de direcciones uno a uno

entre una dirección local y una global.
 Traducción dinámica de direcciones (NAT dinámica):asignación de varias direcciones a

varias direcciones entre direcciones locales y globales.
 Traducción de la dirección del puerto (PAT): asignación de varias direcciones a una

dirección entre direcciones locales y globales. Este método también se conoce como
“sobrecarga” (NAT con sobrecarga).

NAT estática
La NAT estática consiste en una asignación uno a uno entre direcciones locales y globales. Estas
asignaciones son configuradas por el administrador de red y se mantienen constantes.
En la ilustración, el R2 se configuró con las asignaciones estáticas para las direcciones locales
internas del Svr1, la PC2 y la PC3. Cuando estos dispositivos envían tráfico a Internet, sus
direcciones locales internas se traducen a las direcciones globales internas configuradas. Para las
redes externas, estos dispositivos tienen direcciones IPv4 públicas.
La NAT estática resulta útil, en especial para los servidores web o los dispositivos que deben tener
una dirección constante que sea accesible tanto desde Internet, como desde el servidor web de
una empresa. También es útil para los dispositivos a los que debe poder acceder el personal
autorizado cuando no está en su lugar de trabajo, pero no el público en general en Internet. Por
ejemplo, un administrador de red puede acceder a la dirección global interna del Svr1
(209.165.200.226) desde la PC4 mediante SSH. El R2 traduce esta dirección global interna a la
dirección local interna y conecta la sesión del administrador al Svr1.
La NAT estática requiere que haya suficientes direcciones públicas disponibles para satisfacer la
cantidad total de sesiones de usuario simultáneas.
La NAT dinámica utiliza un conjunto de direcciones públicas y las asigna según el orden de
llegada. Cuando un dispositivo interno solicita acceso a una red externa, la NAT dinámica asigna
una dirección IPv4 pública disponible del conjunto.

En la ilustración, la PC3 accede a Internet mediante la primera dirección disponible del conjunto de
NAT dinámica. Las demás direcciones siguen disponibles para utilizarlas. Al igual que la NAT
estática, la NAT dinámica requiere que haya suficientes direcciones públicas disponibles para
satisfacer la cantidad total de sesiones de usuario simultáneas.

La traducción de la dirección del puerto (PAT), también conocida como “NAT con sobrecarga”,
asigna varias direcciones IPv4 privadas a una única dirección IPv4 pública o a algunas direcciones.
Esto es lo que hace la mayoría de los routers domésticos. El ISP asigna una dirección al router, no
obstante, varios miembros del hogar pueden acceder a Internet de manera simultánea. Esta es la
forma más común de NAT.
Con PAT, se pueden asignar varias direcciones a una o más direcciones, debido a que cada
dirección privada también se rastrea con un número de puerto. Cuando un dispositivo inicia una
sesión TCP/IP, genera un valor de puerto de origen TCP o UDP para identificar la sesión de forma
exclusiva. Cuando el router NAT recibe un paquete del cliente, utiliza su número de puerto de
origen para identificar de forma exclusiva la traducción NAT específica.
PAT garantiza que los dispositivos usen un número de puerto TCP distinto para cada sesión con
un servidor en Internet. Cuando llega una respuesta del servidor, el número de puerto de origen,
que se convierte en el número de puerto de destino en la devolución, determina a qué dispositivo el
router reenvía los paquetes. El proceso de PAT también valida que los paquetes entrantes se
hayan solicitado, lo que añade un grado de seguridad a la sesión.
Haga clic en los botones Reproducir y Pausa de la ilustración para controlar la animación.
En la animación, se muestra el proceso de PAT. PAT agrega números de puerto de origen únicos a
la dirección global interna para distinguir las traducciones.
A medida que el R2 procesa cada paquete, utiliza un número de puerto (1331 y 1555, en este
ejemplo) para identificar el dispositivo en el que se originó el paquete. La dirección de origen (SA)
es la dirección local interna a la que se agregó el número de puerto TCP/IP asignado. La dirección
de destino (DA) es la dirección local externa a la que se agregó el número de puerto de servicio.
En este ejemplo, el puerto de servicio es 80: HTTP.

Para la dirección de origen, el R2 traduce la dirección local interna a una dirección global interna
con el número de puerto agregado. La dirección de destino no se modifica, pero ahora se la
denomina “dirección IP global externa”. Cuando el servidor web responde, se invierte la ruta.
En el ejemplo anterior, los números de puerto del cliente, 1331 y 1555, no se modificaron en el
router con NAT habilitada. Esta no es una situación muy probable, porque existe una gran
posibilidad de que estos números de puerto ya se hayan conectado a otras sesiones activas.

PAT intenta conservar el puerto de origen inicial. Sin embargo, si el puerto de origen inicial ya está
en uso, PAT asigna el primer número de puerto disponible desde el comienzo del grupo de puertos
correspondiente de 0 a 511, 512 a 1023 o 1024 a 65 535. Cuando no hay más puertos disponibles
y hay más de una dirección externa en el conjunto de direcciones, PAT avanza a la siguiente
dirección para intentar asignar el puerto de origen inicial. Este proceso continúa hasta que no haya
más direcciones IP externas o puertos disponibles.
Haga clic en el botón Reproducir de la ilustración para ver el funcionamiento de PAT.
En la animación, los hosts eligieron el mismo número de puerto 1444. Esto resulta aceptable para
la dirección interna, porque los hosts tienen direcciones IP privadas únicas. Sin embargo, en el
router NAT, se deben cambiar los números de puerto; de lo contrario, los paquetes de dos hosts
distintos saldrían del R2 con la misma dirección de origen. En este ejemplo, PAT asignó el
siguiente puerto disponible (1445) a la segunda dirección host.

Hacer un resumen de las diferencias entre NAT y PAT contribuye a la comprensión de ambas.
Como se muestran en la ilustración, NAT traduce direcciones IPv4 en una relación de 1:1 entre
direcciones IPv4 privadas y direcciones IPv4 públicas. Sin embargo, PAT modifica la dirección y el
número de puerto.
NAT reenvía los paquetes entrantes a su destino interno mediante la dirección IPv4 de origen de
entrada proporcionada por el host en la red pública. En general, con PAT hay solo una o muy
pocas direcciones IPv4 públicamente expuestas. Los paquetes entrantes de la red pública se
enrutan a sus destinos en la red privada consultando una tabla en el router NAT. Esta tabla hace
un seguimiento de los pares de puertos públicos y privados. Esto se denomina “seguimiento de
conexiones”.
Paquetes sin segmento de capa 4
¿Qué sucede con los paquetes IPv4 que transportan datos que no son segmentos TCP o UDP?
Estos paquetes no contienen un número de puerto de capa 4. PAT traduce la mayoría de los
protocolos comunes transmitidos mediante IPv4 que no utilizan TCP o UDP como protocolo de la
capa de transporte. El más común de ellos es ICMPv4. PAT maneja cada uno de estos tipos de
protocolos de manera diferente. Por ejemplo, los mensajes de consulta, las solicitudes de eco y las
respuestas de eco de ICMPv4 incluyen una ID de consulta. ICMPv4 utiliza la ID de consulta para
identificar una solicitud de eco con su respectiva respuesta. La ID de consulta aumenta con cada
solicitud de eco enviada. PAT utiliza la ID de consulta en lugar de un número de puerto de capa 4.
Nota: otros mensajes ICMPv4 no utilizan la ID de consulta. Estos mensajes y otros protocolos que
no utilizan los números de puerto TCP o UDP varían y exceden el ámbito de este currículo.

11.2.3 Beneficios de NAT
NAT ofrece varios beneficios, incluidos los siguientes:
 NAT conserva el esquema de direccionamiento legalmente registrado al permitir la

privatización de las intranets. NAT conserva las direcciones mediante la multiplexación de
aplicaciones en el nivel de puerto. Con la NAT con sobrecarga, los hosts internos pueden
compartir una única dirección IPv4 pública para todas las comunicaciones externas. En este
tipo de configuración, se requieren muy pocas direcciones externas para admitir varios hosts
internos.
 NAT aumenta la flexibilidad de las conexiones a la red pública. Se pueden implementar varios
conjuntos y conjuntos de respaldo y de equilibrio de carga para asegurar conexiones de red
pública confiables.
 NAT proporciona coherencia a los esquemas de direccionamiento de red interna. Para

cambiar el esquema de direcciones IPv4 públicas en una red que no utiliza direcciones IPv4
privadas ni NAT, se requiere redireccionar todos los hosts en la red existente. Los costos de
redireccionamiento de hosts pueden ser considerables. NAT permite mantener el esquema de
direcciones IPv4 privadas existente a la vez que facilita el cambio a un nuevo esquema de
direccionamiento público. Esto significa que una organización podría cambiar los ISP sin
necesidad de modificar ninguno de sus clientes internos.
 NAT proporciona seguridad de red. Debido a que las redes privadas no anuncian sus
direcciones ni su topología interna, son razonablemente seguras cuando se utilizan en
conjunto con NAT para obtener acceso externo controlado. Sin embargo, NAT no reemplaza
a los firewalls.

NAT presenta algunas desventajas. El hecho de que los hosts en Internet parezcan comunicarse
de forma directa con el dispositivo con NAT habilitada, en lugar de hacerlo con el host real dentro
de la red privada, genera una serie de inconvenientes.
Una desventaja del uso de NAT se relaciona con el rendimiento de la red, en especial, en el caso
de los protocolos en tiempo real como VoIP. NAT aumenta los retrasos de switching porque la
traducción de cada dirección IPv4 dentro de los encabezados del paquete lleva tiempo. Al primer
paquete se aplica el switching de procesos; esto siempre se realiza por la ruta más lenta. El router
debe revisar todos los paquetes para decidir si necesitan traducción. El router debe modificar el
encabezado de IPv4 y, posiblemente, el encabezado TCP o UDP. El checksum del encabezado de
IPv4, junto con el checksum de TCP o UDP, se debe volver a calcular cada vez que se realiza una
traducción. Si existe una entrada de caché, el resto de los paquetes atraviesan la ruta de switching
rápido; de lo contrario, también se demoran.
Otra desventaja del uso de NAT es que se pierde el direccionamiento de extremo a extremo.
Muchos protocolos y aplicaciones de Internet dependen del direccionamiento de extremo a
extremo desde el origen hasta el destino. Algunas aplicaciones no funcionan con NAT. Por
ejemplo, algunas aplicaciones de seguridad, como las firmas digitales, fallan porque la dirección
IPv4 de origen cambia antes de llegar a destino. Las aplicaciones que utilizan direcciones físicas,
en lugar de un nombre de dominio calificado, no llegan a los destinos que se traducen a través del
router NAT. En ocasiones, este problema se puede evitar al implementar las asignaciones de NAT
estática.
También se reduce el seguimiento IPv4 de extremo a extremo. El seguimiento de los paquetes que
pasan por varios cambios de dirección a través de varios saltos de NAT se torna mucho más difícil
y, en consecuencia, dificulta la resolución de problemas.
El uso de NAT también genera complicaciones para los protocolos de tunneling como IPsec, ya
que NAT modifica los valores en los encabezados que interfieren en las verificaciones de
integridad que realizan IPsec y otros protocolos de tunneling.
Los servicios que requieren que se inicie una conexión TCP desde la red externa, o “protocolos sin
estado”, como los servicios que utilizan UDP, pueden interrumpirse. A menos que el router NAT
esté configurado para admitir dichos protocolos, los paquetes entrantes no pueden llegar a su
destino. Algunos protocolos pueden admitir una instancia de NAT entre los hosts participantes (por
ejemplo, FTP de modo pasivo), pero fallan cuando NAT separa a ambos sistemas de Internet.

11.3 Configuración de NAT estática
La NAT estática es una asignación uno a uno entre una dirección interna y una dirección externa.
La NAT estática permite que los dispositivos externos inicien conexiones a los dispositivos internos
mediante la dirección pública asignada de forma estática. Por ejemplo, se puede asignar una
dirección global interna específica a un servidor web interno de modo que se pueda acceder a este
desde redes externas.
En la figura 1, se muestra una red interna que contiene un servidor web con una dirección IPv4
privada. El router R2 se configuró con NAT estática para permitir que los dispositivos en la red
externa (Internet) accedan al servidor web. El cliente en la red externa accede al servidor web
mediante una dirección IPv4 pública. La NAT estática traduce la dirección IPv4 pública a la
dirección IPv4 privada.
Existen dos pasos básicos para configurar las traducciones NAT estáticas.
Paso 1. El primer paso consiste en crear una asignación entre la dirección local interna y las
direcciones globales internas. Por ejemplo, en la figura 1, la dirección local interna 192.168.10.254
y la dirección global interna 209.165.201.5 se configuraron como traducción NAT estática.
Paso 2. Una vez configurada la asignación, las interfaces que participan en la traducción se
configuran como interna o externa con respecto a NAT. En el ejemplo, la interfaz Serial 0/0/0 del
R2 es una interfaz interna, y la interfaz Serial 0/1/0 es una interfaz externa.
Los paquetes que llegan hasta la interfaz interna del R2 (Serial 0/0/0) desde la dirección IPv4 local
interna configurada (192.168.10.254) se traducen y, luego, se reenvían hacia la red externa. Los
paquetes que llegan a la interfaz externa del R2 (Serial 0/1/0), que están dirigidos a la dirección
IPv4 global interna configurada (209.165.201.5), se traducen a la dirección local interna
(192.168.10.254) y, luego, se reenvían a la red interna.
En la figura 2, se describen los comandos necesarios para configurar la NAT estática.
En la figura 3, se muestran los comandos necesarios en el R2 para crear una asignación de NAT
estática al servidor web en la topología de ejemplo. Con la configuración que se muestra, el R2
traduce los paquetes del servidor web con la dirección 192.168.10.254 a la dirección IPv4 pública
209.165.201.5. El cliente de Internet dirige solicitudes web a la dirección IPv4 pública
209.165.201.5. El R2 reenvía ese tráfico al servidor web en 192.168.10.254.
Utilice el verificador de sintaxis de la figura 4 para configurar una entrada de NAT estática adicional
en el R2.


Con la configuración anterior, en la ilustración se muestra el proceso de traducción de NAT estática

entre el cliente y el servidor web. En general, las traducciones estáticas se utilizan cuando los
clientes en la red externa (Internet) necesitan llegar a los servidores en la red interna.
1. El cliente desea establecer una conexión al servidor web. El cliente envía un paquete al servidor
web con la dirección IPv4 pública de destino 209.165.201.5. Esta es la dirección global interna del
servidor web.
2. El primer paquete que recibe del cliente en su interfaz NAT externa ocasiona que el R2 revise su
tabla de NAT. Una vez que se encuentra la dirección IPv4 de destino en la tabla de NAT, se
traduce.
3. El R2 reemplaza la dirección global interna 209.165.201.5 por la dirección local interna

192.168.10.254. Luego, el R2 reenvía el paquete hacia el servidor web.
4. El servidor web recibe el paquete y responde al cliente con la dirección local interna,
192.168.10.254.
5a. El R2 recibe el paquete del servidor web en su interfaz NAT interna con la dirección de origen
de la dirección local interna del servidor web, 192.168.10.254.
5b. El R2 busca una traducción para la dirección local interna en la tabla de NAT. La dirección se
encuentra en esa tabla. El R2 traduce la dirección de origen a la dirección global interna
209.165.201.5 y reenvía el paquete por su interfaz serial 0/1/0 hacia el cliente.

6. El cliente recibe el paquete y continúa la conversación. El router NAT lleva a cabo los pasos 2 a
5b para cada paquete. (El paso 6 no aparece en la ilustración).
El comando show ip nat translations es útil para verificar el funcionamiento de NAT. Este
comando muestra las traducciones NAT activas. A diferencia de las traducciones dinámicas, las
traducciones estáticas siempre figuran en la tabla de NAT. En la figura 1, se muestra el resultado
de este comando con el ejemplo de configuración anterior. Debido a que el ejemplo es una
configuración NAT estática, siempre figura una traducción en la tabla de NAT, independientemente
de que haya comunicaciones activas. Si se emite el comando durante una sesión activa, el
resultado también indica la dirección del dispositivo externo, como se muestra en la figura 1.
Otro comando útil es show ip nat statistics. Como se muestra en la figura 2, el

comando show ip nat statistics muestra información sobre la cantidad total de
traducciones activas, los parámetros de configuración NAT, la cantidad de direcciones en el
conjunto y la cantidad de direcciones que se asignaron.
Para verificar que la traducción NAT funcione, es conveniente borrar las estadísticas de todas las
traducciones anteriores con el comando clear ip nat statistics antes de realizar la
prueba.
Antes de cualquier comunicación con el servidor web, el comando show ip nat statistics no
muestra ningún acierto actual. Una vez que el cliente establece una sesión con el servidor web, el
comando show ip nat statistics muestra cinco aciertos. De este modo, se verifica que se
lleva a cabo la traducción de NAT estática en el R2.


11.3.1 Configuración de NAT dinámica
Mientras que la NAT estática proporciona una asignación permanente entre una dirección local
interna y una dirección global interna, la NAT dinámica permite la asignación automática de
direcciones locales internas a direcciones globales internas. Por lo general, estas direcciones
globales internas son direcciones IPv4 públicas. La NAT dinámica utiliza un grupo o un conjunto de
direcciones IPv4 públicas para la traducción.
Al igual que la NAT estática, la NAT dinámica requiere que se configuren las interfaces interna y
externa que participan en la NAT. Sin embargo, mientras que la NAT estática crea una asignación
permanente a una única dirección, la NAT dinámica utiliza un conjunto de direcciones.
Nota: la traducción entre direcciones IPv4 públicas y privadas es el uso más frecuente de NAT. No
obstante, las traducciones de NAT se pueden realizar entre cualquier par de direcciones.
La topología de ejemplo que se muestra en la ilustración tiene una red interna que usa direcciones
del espacio de direcciones privadas definido en RFC 1918. Hay dos LAN conectadas al router R1:
192.168.10.0/24 y 192.168.11.0/24. El router R2, es decir, el router de frontera, se configuró para
NAT dinámica con un conjunto de direcciones IPv4 públicas de 209.165.200.226 a
209.165.200.240.
El conjunto de direcciones IPv4 públicas (conjunto de direcciones globales internas) se encuentra

disponible para cualquier dispositivo en la red interna según el orden de llegada. Con la NAT
dinámica, una única dirección interna se traduce a una única dirección externa. Con este tipo de
traducción, debe haber suficientes direcciones en el conjunto para admitir a todos los dispositivos
internos que necesiten acceso a la red externa al mismo tiempo. Si se utilizaron todas las
direcciones del conjunto, los dispositivos deben esperar que haya una dirección disponible para
poder acceder a la red externa.

En la figura 1, se muestran los pasos y los comandos utilizados para configurar la NAT dinámica.
Paso 1. Defina el conjunto de direcciones que se utilizará para la traducción con el comando ip
nat pool. Por lo general, este conjunto es un grupo de direcciones públicas. Las direcciones se
definen indicando la primera y la última dirección IP del conjunto. Las palabras
clavenetmask o prefix-length indican qué bits de la dirección pertenecen a la red y cuáles al
host en el rango de direcciones.
Paso 2. Configure una ACL estándar para identificar (permitir) solo aquellas direcciones que se
deben traducir. Una ACL demasiado permisiva puede generar resultados impredecibles. Recuerde
que al final de cada ACL hay una instrucción implícita para denegar todo.
Paso 3. Conecte la ACL al conjunto. Para conectar la ACL al conjunto, se utiliza el comando ip
nat inside source list número-lista-acceso number pool nombre-conjunto. El
router utiliza esta configuración para determinar qué dirección (pool) recibe cada dispositivo
(list).
Paso 4. Identifique qué interfaces son internas con respecto a NAT; es decir, cualquier interfaz que
se conecte a la red interna.
Paso 5. Identifique qué interfaces son externas con respecto a NAT; es decir, cualquier interfaz
que se conecte a la red externa.
En la figura 2, se muestra una topología y una configuración de ejemplo. Esta configuración

permite la traducción para todos los hosts en la red 192.168.0.0/16, que incluye las LAN
192.168.10.0 y 192.168.11.0, cuando generan tráfico que ingresa por S0/0/0 y sale por S0/1/0.

Estos hosts se traducen a una dirección disponible del conjunto en el rango de 209.165.200.226 a
209.165.200.240.
En la figura 3, se muestra la topología utilizada para la configuración del verificador de sintaxis.

Utilice el verificador de sintaxis de la figura 4 para configurar la NAT dinámica en el R2.


Con la configuración anterior, en las ilustraciones se muestra el proceso de traducción de NAT

dinámica entre dos clientes y el servidor web:
En la figura 1, se muestra el flujo de tráfico desde adentro hacia fuera:
1. Los hosts con las direcciones IPv4 de origen (192.168.10.10 [PC1] y 192.168.11.10 [PC2])
envían paquetes para solicitar la conexión al servidor en la dirección IPv4 pública
(209.165.200.254).
2. El R2 recibe el primer paquete del host 192.168.10.10. Debido a que este paquete se recibió en
una interfaz configurada como interfaz NAT interna, el R2 verifica la configuración NAT para
determinar si este paquete debe traducirse. Como la ACL permite este paquete, el R2 lo traduce.
El R2 consulta su tabla de NAT. Debido a que no hay entrada de traducción para esta dirección IP,
el R2 determina que la dirección de origen 192.168.10.10 se debe traducir de manera dinámica. El
R2 selecciona una dirección global disponible del conjunto de direcciones dinámicas y crea una
entrada de traducción, 209.165.200.226. La dirección IPv4 de origen inicial (192.168.10.10) es la
dirección local interna, y la dirección traducida es la dirección global interna (209.165.200.226) en
la tabla de NAT.
Para el segundo host, 192.168.11.10, el R2 repite el procedimiento, selecciona la siguiente

dirección global disponible del conjunto de direcciones dinámicas y crea una segunda entrada de
traducción, 209.165.200.227.
3. El R2 reemplaza la dirección de origen local interna de la PC1, 192.168.10.10, por la dirección

global interna traducida 209.165.200.226 y reenvía el paquete. El mismo proceso se lleva a cabo
para el paquete de la PC2 con la dirección traducida para esta computadora (209.165.200.227).
En la figura 2, se muestra el flujo de tráfico desde adentro hacia fuera:
4. El servidor recibe el paquete de la PC1 y responde con la dirección IPv4 de destino

209.165.200.226. Cuando el servidor recibe el segundo paquete, responde a la PC2 con la
dirección IPv4 de destino 209.165.200.227.
5a. Cuando el R2 recibe el paquete con la dirección IPv4 de destino 209.165.200.226, realiza una
búsqueda en la tabla de NAT. Con la asignación de la tabla, el R2 vuelve a traducir la dirección a la
dirección local interna (192.168.10.10) y reenvía el paquete hacia la PC1.

5b. Cuando el R2 recibe el paquete con la dirección IPv4 de destino 209.165.200.227, realiza una
búsqueda en la tabla de NAT. Con la asignación de la tabla, el R2 vuelve a traducir la dirección a la
dirección local interna (192.168.11.10) y reenvía el paquete hacia la PC2.
6. La PC1 en 192.168.10.10 y la PC2 en 192.168.11.10 reciben los paquetes y continúan la

conversación. El router lleva a cabo los pasos 2 a 5 para cada paquete. (El paso 6 no aparece en
las ilustraciones).

El resultado del comando show ip nat translations que aparece en la figura 1 muestra los
detalles de las dos asignaciones de NAT anteriores. El comando muestra todas las traducciones
estáticas que se configuraron y todas las traducciones dinámicas que se crearon a causa del
tráfico.
Si se agrega la palabra clave verbose, se muestra información adicional acerca de cada

traducción, incluido el tiempo transcurrido desde que se creó y se utilizó la entrada.
De manera predeterminada, a las entradas de traducción se les agota el tiempo de espera después
de 24 horas, a menos que se vuelvan a configurar los temporizadores con el comando ip nat
translation timeout segundos-tiempo-esperaen el modo de configuración global.
Para borrar las entradas dinámicas antes de que se agote el tiempo de espera, utilice el
comando clear ip nat translation en el modo de configuración global (figura 2). Es útil
borrar las entradas dinámicas al probar la configuración NAT. Como se muestra en la tabla, este
comando se puede utilizar con palabras clave y variables para controlar qué entradas se deben
borrar. Se pueden borrar entradas específicas para evitar interrumpir las sesiones activas. Utilice el
comando de configuración global clear ip nat translation * para borrar todas las
traducciones de la tabla.
Nota: solo se borran de la tabla las traducciones dinámicas. Las traducciones estáticas no pueden
borrarse de la tabla de traducción.
En la figura 3, el comando show ip nat statistics muestra la información sobre la cantidad

total de traducciones activas, los parámetros de configuración NAT, la cantidad de direcciones en
el conjunto y la cantidad de direcciones que se asignaron.

También puede utilizar el comando show running-config y buscar los comandos de NAT,
ACL, interfaz o conjunto con los valores requeridos. Examínelos detenidamente y corrija cualquier
error que detecte.

11.3.2 Configuración de la traducción de la dirección del puerto (PAT)
PAT (también denominada “NAT con sobrecarga”) conserva las direcciones del conjunto de
direcciones globales internas al permitir que el router use una dirección global interna para muchas
direcciones locales internas. En otras palabras, se puede utilizar una única dirección IPv4 pública
para cientos, incluso miles de direcciones IPv4 privadas internas. Cuando se configura este tipo de
traducción, el router mantiene suficiente información acerca de los protocolos de nivel superior, de
los números de puerto TCP o UDP, por ejemplo, para volver a traducir la dirección global interna a
la dirección local interna correcta. Cuando se asignan varias direcciones locales internas a una
dirección global interna, los números de puerto TCP o UDP de cada host interno distinguen entre
las direcciones locales.
Nota: la cantidad total de direcciones internas que se pueden traducir a una dirección externa
teóricamente podría ser de hasta 65 536 por dirección IP. Sin embargo, la cantidad de direcciones
internas a las que se puede asignar una única dirección IP es aproximadamente 4000.
Existen dos formas de configurar PAT, según cómo el ISP asigna las direcciones IPv4 públicas. En
primer lugar, el ISP asigna más de una dirección IPv4 pública a la organización y, en segundo
lugar, asigna una única dirección IPv4 pública que se requiere para que la organización se conecte
al ISP.
Configuración de PAT para un conjunto de direcciones IP públicas
Si se emitió más de una dirección IPv4 pública para un sitio, estas direcciones pueden ser parte de
un conjunto utilizado por PAT. Esto es similar a la NAT dinámica, con la excepción de que no
existen suficientes direcciones públicas para realizar una asignación uno a uno entre direcciones

internas y externas. Una gran cantidad de dispositivos comparte el pequeño conjunto de

direcciones.
En la figura 1, se muestran los pasos para configurar PAT a fin de que utilice un conjunto de
direcciones. La diferencia principal entre esta configuración y la configuración para NAT dinámica
uno a uno es que se utiliza la palabra claveoverload. La palabra clave overloadhabilita PAT.
La configuración de ejemplo que se muestra en la figura 2 establece la traducción de sobrecarga

para el conjunto de NAT denominado NAT-POOL2. NAT-POOL2 contiene las direcciones de
209.165.200.226 a 209.165.200.240. Los hosts en la red 192.168.0.0/16 están sujetos a
traducción. La interfaz S0/0/0 se identifica como interfaz interna, y la interfaz S0/1/0 se identifica
como interfaz externa.
Utilice el verificador de sintaxis de la figura 3 para configurar PAT con un conjunto de direcciones
en el R2.

Configuración de PAT para una única dirección IPv4 pública
En la figura 1, se muestra la topología de una implementación de PAT para la traducción de una

única dirección IPv4 pública. En el ejemplo, todos los hosts de la red 192.168.0.0/16 (que coincide
con la ACL 1) que envían tráfico a Internet a través del router R2 se traducen a la dirección IPv4
209.165.200.225 (dirección IPv4 de la interfaz S0/1/0). Los flujos de tráfico se identifican por los
números de puerto en la tabla de NAT, ya que se utilizó la palabra clave overload.
En la figura 2, se muestran los pasos que se deben seguir para configurar PAT con una única
dirección IPv4. Si solo hay una única dirección IPv4 pública disponible, la configuración de
sobrecarga generalmente asigna la dirección pública a la interfaz externa que se conecta al ISP.
Todas las direcciones internas se traducen a la única dirección IPv4 cuando salen de la interfaz
externa.
Paso 1. Defina una ACL para permitir que se traduzca el tráfico.
Paso 2. Configure la traducción de origen con las palabras clave interface yoverload. La
palabra clave interface identifica la dirección IP de la interfaz que se debe utilizar en la
traducción de las direcciones internas. La palabra clave overload le indica al router que realice un
seguimiento de los números de puerto con cada entrada de NAT.

Paso 3. Identifique cuáles son las interfaces internas con respecto a NAT. Es decir, toda interfaz
que se conecte a la red interna.
Paso 4. Identifique cuál es la interfaz externa con respecto a NAT. Esta debe ser la misma interfaz
identificada en la instrucción de la traducción de origen del paso 2.
La configuración es similar a la de NAT dinámica, excepto que, en lugar de un conjunto de

direcciones, se utiliza la palabra clave interface para identificar la dirección IPv4 externa. Por lo
tanto, no se define ningún pool de NAT.
Utilice el verificador de sintaxis de la figura 3 para configurar PAT con una única dirección en el R2.
El proceso de NAT con sobrecarga es el mismo, ya sea que se utilice un conjunto de direcciones o
una única dirección. En el ejemplo anterior de PAT, la PC1 desea comunicarse con el servidor web

Svr1 por medio de una única dirección IPv4 pública. Al mismo tiempo, otro cliente, la PC2, desea
establecer una sesión similar con el servidor web Svr2. Tanto la PC1 como la PC2 se configuraron
con direcciones IPv4 privadas, con el R2 habilitado para PAT.
Proceso de la computadora al servidor
1. En la figura 1, se muestra que la PC1 y la PC2 envían paquetes a los servidores Svr1 y Svr2,
respectivamente. La PC1 tiene la dirección IPv4 de origen 192.168.10.10 y utiliza el puerto de
origen TCP 1444. La PC2 tiene la dirección IPv4 de origen 192.168.10.11 y, por casualidad, se le
asigna el mismo puerto de origen 1444.
2. El paquete de la PC1 llega primero al R2. Mediante el uso de PAT, el R2 modifica la dirección
IPv4 de origen a 209.165.200.225 (dirección global interna). En la tabla de NAT, no hay ningún otro
dispositivo que use el puerto 1444, de modo que PAT mantiene el mismo número de puerto. El
paquete luego se reenvía hacia el Svr1 en 209.165.201.1.
3. A continuación, llega el paquete de la PC2 al R2. PAT está configurada para utilizar una única
dirección IPv4 global interna para todas las traducciones, 209.165.200.225. Al igual que con el
proceso de traducción para la PC1, PAT cambia la dirección IPv4 de origen de la PC2 a la
dirección global interna 209.165.200.225. Sin embargo, la PC2 tiene el mismo número de puerto de
origen que una entrada actual de PAT, la traducción para la PC1. PAT aumenta el número de
puerto de origen hasta que sea un valor único en su tabla. En este caso, la entrada del puerto de
origen en la tabla de NAT y el paquete de la PC2 reciben el número 1445.
Si bien la PC1 y la PC2 usan la misma dirección traducida, la dirección global interna
209.165.200.225, y el mismo número de puerto de origen 1444, el número de puerto modificado
para la PC2 (1445) hace que cada entrada en la tabla de NAT sea única. Esto se torna evidente
cuando los paquetes se devuelven desde los servidores hacia los clientes.
Proceso del servidor a la computadora
4. Como se muestra en la figura 2, en un intercambio típico entre cliente y servidor, los servidores
Svr1 y Svr2 responden a las solicitudes recibidas de la PC1 y la PC2, respectivamente. Los
servidores usan el puerto de origen del paquete recibido como puerto de destino y la dirección de
origen como dirección de destino para el tráfico de retorno. Al parecer, los servidores se comunican
con el mismo host en 209.165.200.225, pero no es así.
5. A medida que llegan los paquetes, el R2 ubica una única entrada en su tabla de NAT mediante
la dirección de destino y el puerto de destino de cada paquete. En el caso del paquete del Svr1, la
dirección IPv4 de destino 209.165.200.225 tiene varias entradas, pero solo una con el puerto de
destino 1444. Mediante la entrada de su tabla, el R2 cambia la dirección IPv4 de destino del
paquete a 192.168.10.10, sin necesidad de modificar el puerto de destino. Luego, el paquete se
reenvía hacia la PC1.
6. Cuando llega el paquete del Svr2, el R2 realiza una traducción similar. La dirección IPv4 de
destino 209.165.200.225 vuelve a aparecer en varias entradas. Sin embargo, con el puerto de
destino 1445, el R2 puede identificar una única entrada de traducción. La dirección IPv4 de destino
se modifica a 192.168.10.11. En este caso, el puerto de destino también se debe volver a modificar
a su valor original de 1444, que está almacenado en la tabla de NAT. Luego, el paquete se reenvía
hacia la PC2.


El router R2 se configuró para proporcionar PAT a los clientes de 192.168.0.0/16. Cuando los hosts
internos salen del router R2 a Internet, se traducen a una dirección IPv4 del conjunto de PAT con
un único número de puerto de origen.
Para verificar PAT, se usan los mismos comandos que se usan para verificar la NAT estática y
dinámica, como se muestra en la figura 1. El comando show ip nat translations muestra
las traducciones de dos hosts distintos a servidores web distintos. Observe que se asigna la misma
dirección IPv4 209.165.200.226 (dirección global interna) a dos hosts internos distintos. Los
números de puerto de origen en la tabla de NAT distinguen las dos transacciones.
Como se muestra en la figura 2, el comando show ip nat statistics verifica que NAT-
POOL2 haya asignado una única dirección para ambas traducciones. El resultado incluye
información sobre la cantidad y el tipo de traducciones activas, los parámetros de configuración
NAT, la cantidad de direcciones en el conjunto y la cantidad que se asignó.



11.3.3 Reenvío de puertos
El reenvío de puertos (a veces, denominado “tunneling”) consiste en reenviar un puerto de red

desde un nodo de red hacia otro. Esta técnica permite que un usuario externo alcance un puerto en
una dirección IPv4 privada (dentro de una LAN) desde el exterior a través de un router con NAT
habilitada.
En general, las operaciones y los programas peer-to-peer para compartir archivos, como las
aplicaciones de servidores web y los FTP salientes, requieren que los puertos del router se
reenvíen o se abran para permitir que estas aplicaciones funcionen, como se muestra en la
figura 1. Debido a que NAT oculta las direcciones internas, la comunicación peer-to-peer solo
funciona desde adentro hacia fuera donde NAT puede asignar las solicitudes salientes a las
respuestas entrantes.
El problema es que NAT no permite las solicitudes iniciadas desde el exterior. Esta situación se
puede resolver de forma manual. El reenvío de puertos se puede configurar para identificar los
puertos específicos que se pueden reenviar a los hosts internos.
Recuerde que las aplicaciones de software de Internet interactúan con los puertos de usuario que
necesitan estar abiertos o disponibles para dichas aplicaciones. Las distintas aplicaciones usan
puertos diferentes. Esto hace que las aplicaciones y los routers identifiquen los servicios de red de
manera predecible. Por ejemplo, HTTP funciona a través del puerto bien conocido 80. Cuando
alguien introduce la dirección http://cisco.com, el explorador muestra el sitio web de Cisco
Systems, Inc. Tenga en cuenta que no es necesario especificar el número de puerto HTTP para la
solicitud de página, ya que la aplicación asume que se trata del puerto 80.
Si se requiere un número de puerto diferente, se puede agregar al URL separado por dos puntos
(:). Por ejemplo, si el servidor web escuchara en el puerto 8080, el usuario escribiría
http://www.ejemplo.com:8080.
El reenvío de puertos permite que los usuarios en Internet accedan a los servidores internos
mediante el uso de la dirección de puerto de WAN del router y del número de puerto externo que
coincida. En general, los servidores internos se configuran con direcciones IPv4 privadas definidas
en RFC 1918. Cuando se envía una solicitud a la dirección IPv4 del puerto de WAN a través de
Internet, el router reenvía la solicitud al servidor correspondiente en la LAN. Por motivos de
seguridad, los routers de banda ancha no permiten que se reenvíe ninguna solicitud de redes
externas a un host interno de manera predeterminada.
En la figura 2, se muestra al propietario de una pequeña empresa que utiliza un servidor del punto
de venta (PoS) para hacer un seguimiento de las ventas y los inventarios en la tienda. Se puede
acceder al servidor desde la tienda pero, debido a que tiene una dirección IPv4 privada, no es
posible acceder a este de manera pública desde Internet. Habilitar el router local para el reenvío de
puertos permitiría que el propietario acceda al servidor del punto de venta en cualquier lugar desde
Internet. El reenvío de puertos en el router se configura con el número de puerto de destino y la
dirección IPv4 privada del servidor del punto de venta. Para acceder al servidor, el software de
cliente utilizaría la dirección IPv4 pública del router y el puerto de destino del servidor.

En la ilustración, se muestra la ventana de configuración Single Port Forwarding (Reenvío de

puerto único) de un router SOHO Linksys EA6500. De manera predeterminada, el reenvío de
puertos no está habilitado en el router.
Si se especifica la dirección local interna a la cual se deben reenviar las solicitudes, es posible
habilitar el reenvío de puertos para las aplicaciones. En la ilustración, las solicitudes de servicio
HTTP que llegan a este router Linksys se reenvían al servidor web con la dirección local interna
192.168.1.254. Si la dirección IPv4 WAN externa del router SOHO es 209.165.200.225, el usuario
externo puede introducir http://www.ejemplo.com, y el router Linksys redirige la solicitud HTTP al
servidor web interno en la dirección IPv4 192.168.1.254, con el número de puerto predeterminado
80.

Se puede especificar un puerto distinto al puerto predeterminado 80. Sin embargo, el usuario
externo tendría que saber el número de puerto específico que debe utilizar. Para especificar un
puerto diferente, se modifica el valor del campo External Port (Puerto externo) en la ventana Single
Port Forwarding (Reenvío de puerto único).
El enfoque adoptado para configurar el reenvío de puertos depende de la marca y el modelo del
router de banda ancha en la red. No obstante, hay algunos pasos genéricos que se deben seguir.
Si las instrucciones que suministra el ISP o las que vienen con el router no proporcionan una
orientación adecuada, en el sitio webhttp://www.portforward.com se ofrecen guías para varios
routers de banda ancha. Puede seguir las instrucciones para agregar o eliminar puertos según sea
necesario para satisfacer las necesidades de todas las aplicaciones que desee permitir o denegar.
Los comandos de IOS que se usan para implementar el reenvío de puertos son similares a los que
se usan para configurar la NAT estática. Básicamente, el reenvío de puertos es una traducción de
NAT estática con un número de puerto TCP o UDP específico.
En la figura 1, se muestra el comando de NAT estática que se usa para configurar el reenvío de
puertos con IOS.
En la figura 2, se muestra un ejemplo de configuración del reenvío de puertos con comandos de

IOS en el router R2. La dirección 192.168.10.254 es la dirección IPv4 local interna del servidor web
que escucha en el puerto 80. Los usuarios acceden a este servidor web interno con la dirección IP
global 209.165.200.225, una dirección IPv4 pública globalmente única. En este caso, es la
dirección de la interfaz Serial 0/1/0 del R2. El puerto global se configura como 8080. Este es el
puerto de destino que se utiliza junto con la dirección IPv4 global 209.165.200.225 para acceder al
servidor web interno. Observe los siguientes parámetros de comando dentro de la configuración
NAT:

 ip-local = 192.168.10.254
 puerto-local = 80
 ip-global = 209.165.200.225
 puerto-global = 8080
Cuando no se utiliza un número de puerto bien conocido, el cliente debe especificar el número de
puerto de la aplicación.
Al igual que otros tipos de NAT, el reenvío de puertos requiere que se configuren las interfaces
NAT interna y externa.
Como en el caso de la NAT estática, se puede utilizar el comando show ip nat

translations para verificar el reenvío de puertos, como se muestra en la figura 3.
En el ejemplo, cuando el router recibe el paquete con la dirección IPv4 global interna
209.165.200.225 y un puerto TCP de destino 8080, el router realiza una búsqueda en la tabla de
NAT con la dirección IPv4 de destino y el puerto de destino como claves. A continuación, el router
traduce la dirección a la dirección local interna del host 192.168.10.254 y el puerto de destino 80.
Luego, el R2 reenvía el paquete al servidor web. En el caso de los paquetes de retorno del servidor
web al cliente, este proceso se invierte.


11.3.4 Configuración de NAT e IPv6
La cuestión del agotamiento del espacio de direcciones IPv4 es una prioridad para el IETF desde
principios de la década de los noventa. La combinación de las direcciones IPv4 privadas definidas
en RFC 1918 y de NAT cumple un papel decisivo para retrasar este agotamiento. NAT presenta
desventajas considerables, y en enero de 2011, la IANA asignó sus últimas direcciones IPv4 a los
RIR.
Uno de los beneficios de NAT para IPv4 que no fueron intencionales es que oculta la red privada
de Internet pública. NAT tiene la ventaja de que ofrece un nivel de seguridad considerable al
denegar el acceso de las computadoras que se encuentran en Internet pública a los hosts internos.
Sin embargo, no debe considerarse como un sustituto de la seguridad de red adecuada, como la
que proporciona un firewall.
En RFC 5902, el Consejo de Arquitectura de Internet (IAB) incluyó la siguiente cita sobre la
traducción de direcciones de red IPv6:
“En general, se cree que una caja NAT proporciona un nivel de protección porque los hosts
externos no pueden iniciar directamente una comunicación con los hosts detrás de una NAT. No
obstante, no se deben confundir las cajas NAT con los firewalls. Como se analizó en [RFC4864],
sección 2.2, el acto de traducción en sí mismo no proporciona seguridad. La función de filtrado con
estado puede proporcionar el mismo nivel de protección sin requerir una función de traducción”.
Con una dirección de 128 bits, IPv6 proporciona 340 sextillones de direcciones. Por lo tanto, el
espacio de direcciones no es un problema. IPv6 se desarrolló con la intención de que la NAT para
IPv4 con su traducción entre direcciones IPv4 públicas y privadas resulte innecesaria. Sin
embargo, IPv6 implementa una forma de NAT. IPv6 incluye su propio espacio de direcciones IPv6
privadas y NAT, que se implementan de manera distinta de como se hace para IPv4.

Las direcciones IPv6 locales únicas (ULA) se asemejan a las direcciones privadas en IPv4
definidas en RFC 1918, pero también existen diferencias considerables. El objetivo de las ULA es
proporcionar espacio de direcciones IPv6 para las comunicaciones dentro de un sitio local, no
tienen el propósito de proporcionar espacio adicional de direcciones IPv6 ni un nivel de seguridad.
Como se muestra en la ilustración, las ULA tienen el prefijo FC00::/7, lo que produce un rango de
primer hexteto que va desde FC00 hasta FDFF. El bit siguiente se establece en 1 si el prefijo se
asigna localmente. Es posible que en el futuro se pueda establecer en 0. Los 40 bits siguientes
corresponden a una ID global seguida de una ID de subred de 16 bits. Estos primeros 64 bits se
combinan para crear el prefijo de la ULA. Esto permite que los 64 bits restantes se utilicen para la
ID de interfaz o, en términos de IPv4, la porción de host de la dirección.
Las direcciones locales únicas se definen en RFC 4193. Las ULA también se conocen como
“direcciones IPv6 locales” (no se deben confundir con las direcciones IPv6 link-local) y tienen varias
características, incluidas las siguientes:
 Permiten que los sitios se combinen o se interconecten de manera privada, sin generar
conflictos entre direcciones y sin necesidad de volver a numerar las interfaces que usan estos
prefijos.
 Son independientes de cualquier ISP y se pueden usar para las comunicaciones dentro de un
sitio sin tener conectividad a Internet.
 No se pueden enrutar a través de Internet; sin embargo, si se filtran por routing o DNS, no
existe conflicto con otras direcciones.

Las ULA no son tan sencillas como las direcciones definidas en RFC 1918. A diferencia de las
direcciones IPv4 privadas, el IETF no tenía la intención de utilizar una forma de NAT para traducir
entre las direcciones locales únicas y las direcciones IPv6 de unidifusión global.
La comunidad de Internet continúa analizando la implementación y los posibles usos de las

direcciones IPv6 locales únicas. Por ejemplo, el IETF considera permitir la opción de crear el prefijo
de la ULA de forma local con FC00::/8, o de que lo asigne un tercero de forma automática y que
empiece con FD00::/8.
Nota: la especificación original de IPv6 asignaba el espacio de direcciones para las direcciones
locales de sitio, definidas en RFC 3513. El IETF dejó en desuso las direcciones locales de sitio en
RFC 3879 porque el término “sitio” resultaba algo ambiguo. Las direcciones locales de sitio tenían
el rango de prefijos FEC0::/10 y todavía pueden encontrarse en documentos antiguos de IPv6.
NAT para IPv6 se usa en un contexto muy distinto al de NAT para IPv4. Las variedades de NAT
para IPv6 se usan para proporcionar acceso de manera transparente entre redes solo IPv6 y redes
solo IPv4. No se utiliza como forma de traducción de IPv6 privada a IPv6 global.
Lo ideal es que IPv6 se ejecute de forma nativa siempre que sea posible. Es decir, en dispositivos
IPv6 que se comunican entre sí a través de redes IPv6. No obstante, para colaborar en el cambio
de IPv4 a IPv6, el IETF elaboró varias técnicas de transición que admiten una variedad de
situaciones de IPv4 a IPv6, como dual-stack, tunneling y traducción.
Dual-stack es cuando los dispositivos ejecutan protocolos asociados a IPv4 y a IPv6. Tunneling
para IPv6 es el proceso de encapsulación de un paquete IPv6 dentro de un paquete IPv4. Esto
permite que el paquete IPv6 se transmita a través de una red solo IPv4.
La NAT para IPv6 no se debe usar como una estrategia a largo plazo, sino como un mecanismo
temporal para contribuir a la migración de IPv4 a IPv6. Con el correr de los años, hubo varios tipos
de NAT para IPv6, incluida la traducción de direcciones de red/traducción de protocolos (NAT-PT).
El IETF dejó en desuso NAT-PT en favor de su reemplazo, NAT64. NAT64 excede el ámbito de
este currículo.

11.4 Resolución de problemas de NAT
En la figura 1, se muestra el R2 habilitado para PAT, que usa el rango de direcciones de

209.165.200.226 a 209.165.200.240.
Cuando hay problemas de conectividad IPv4 en un entorno NAT, suele ser difícil determinar la
causa del problema. El primer paso para resolverlo es descartar que la causa sea NAT. Siga estos
pasos para verificar que NAT funcione como se espera:
Paso 1. En función de la configuración, defina claramente lo que debe lograr la NAT. Esto puede
revelar un problema con la configuración.
Paso 2. Verifique que las traducciones de la tabla sean correctas con el comando show ip nat
translations.
Paso 3. Utilice los comandos clear ydebug para verificar que NAT funcione como se espera.
Verifique si se vuelven a crear las entradas dinámicas después de borrarlas.
Paso 4. Revise en detalle lo que sucede con el paquete y verifique que los routers tengan la
información de routing correcta para trasladar el paquete.
En la figura 2, se muestra el resultado de los comandos show ip nat statistics y show ip

nat translations. Antes de utilizar los comandos show, se eliminan las estadísticas y entradas
de NAT de la tabla de NAT con los comandos clear ip nat statistics y clear ip nat
translation *. Una vez que el host en 192.168.10.10 accede mediante Telnet al servidor en
209.165.201.1, se muestran las estadísticas de NAT y la tabla de NAT para verificar que NAT
funcione como se espera.

En un entorno de red simple, es útil controlar las estadísticas de NAT con el comando show ip
nat statistics. El comando show ip nat statistics muestra información sobre la
cantidad total de traducciones activas, los parámetros de configuración NAT, la cantidad de
direcciones en el conjunto y la cantidad que se asignó. Sin embargo, en un entorno NAT más
complejo, con varias traducciones en curso, es posible que este comando no identifique el
problema de forma clara. Es posible que se deban ejecutar los comandos debug en el router.
Para verificar el funcionamiento de la característica de NAT, utilice el comandodebug ip nat,

que muestra información sobre cada paquete que traduce el router. El comando debug ip nat
detailedgenera una descripción de cada paquete que se tiene en cuenta para traducir. Este
comando también proporciona información sobre determinados errores o condiciones de
excepción, como la falla para asignar una dirección global. El comando debug ip nat
detailed genera más sobrecarga que el comando debug ip nat, pero puede proporcionar el
detalle necesario para resolver el problema de NAT. Desactive siempre la depuración al finalizar.
En la figura 1, se muestra un resultado de ejemplo de debug ip nat. Este resultado muestra que
el host interno (192.168.10.10) inició el tráfico hacia el host externo (209.165.201.1) y que la
dirección de origen se tradujo a la dirección 209.165.200.226.
Cuando decodifique el resultado de este comando, observe los significados de los siguientes
símbolos y valores:
 * (asterisco): el asterisco junto a NAT indica que la traducción se realiza en la ruta de

switching rápido. Al primer paquete en una conversación siempre se aplica el switching de
procesos, que es más lento. Si existe una entrada de caché, el resto de los paquetes
atraviesan la ruta de switching rápido.
 s=: este símbolo se refiere a la dirección IP de origen.
 a.b.c.d--->w.x.y.z: este valor indica que la dirección de origen a.b.c.d se traduce a w.x.y.z.

 d=: este símbolo se refiere a la dirección IP de destino.
 [xxxx]: el valor entre corchetes es el número de identificación IP. Esta información puede ser
útil para la depuración, ya que habilita la correlación con otros seguimientos de paquetes
realizados por los analizadores de protocolos.
Nota: verifique que la ACL mencionada en la referencia de comandos de NAT permita todas las
redes necesarias. En la figura 2, solo las direcciones 192.168.0.0/16 se pueden traducir. El R2 no
traduce los paquetes de la red interna destinados a Internet con direcciones de origen que la ACL 1
no permita de forma explícita.
Caso práctico 1
En la figura 1, se muestra que los hosts de las LAN 192.168.0.0/16, la PC1 y la PC2, no pueden
hacer ping a los servidores en la red externa, el Svr1 y el Svr2.
Para iniciar la resolución de problemas, utilice el comando show ip nat translations a fin de
verificar si actualmente hay alguna traducción en la tabla de NAT. El resultado de la figura 1
muestra que no hay traducciones en la tabla.
El comando show ip nat statisticsse utiliza para determinar si se realizaron traducciones.

También identifica las interfaces entre las que debe ocurrir la traducción. Como se muestra en el
resultado de la figura 2, los contadores de NAT están en 0, lo que verifica que no se realizó
ninguna traducción. Al comparar el resultado con la topología de la figura 1, observe que las
interfaces del router están definidas de forma incorrecta como NAT interna o NAT externa.
También es posible verificar una configuración incorrecta con el comando show running-
config.
Se debe eliminar la configuración NAT actual de las interfaces antes de aplicar la configuración
correcta.
Luego de definir correctamente las interfaces NAT interna y externa, otro ping de la PC1 al Svr1
falla. El uso de los comandos show ip nat translations y show ip nat
statistics nuevamente verifica que no hay traducciones en curso.

Como se muestra en la figura 3, el comando show access-lists se utiliza para determinar si la

ACL a la que hace referencia el comando NAT permite todas las redes necesarias. Al examinar el
resultado, se comprueba que se utilizó una máscara de bits wildcard incorrecta en la ACL que
define las direcciones que se deben traducir. La máscara wildcard solo permite la subred
192.168.0.0/24. Primero se elimina la lista de acceso y después se reconfigura con la máscara
wildcard correcta.
Una vez corregidas las configuraciones, se genera otro ping de la PC1 al Svr1, y esta vez el ping
es correcto. Como se muestra en la figura 4, los comandos show ip nat
translations y show ip nat statistics se utilizan para verificar que se produzca la
traducción NAT.


11.5 Resumen
En este capítulo, se explicó cómo se utiliza NAT para contribuir a mitigar el agotamiento del
espacio de direcciones IPv4. La NAT para IPv4 permite que los administradores de red utilicen el
espacio de direcciones privadas definido en RFC 1918, a la vez que proporciona conectividad a
Internet, mediante una única dirección pública o una cantidad limitada de estas.
NAT conserva el espacio de direcciones públicas y reduce la sobrecarga administrativa de forma

considerable al administrar las adiciones, los movimientos y las modificaciones. NAT y PAT se
pueden implementar para ahorrar espacio de direcciones públicas y armar intranets privadas
seguras sin afectar la conexión al ISP. Sin embargo, NAT presenta desventajas en términos de sus
efectos negativos en el rendimiento de los dispositivos, la seguridad, la movilidad y la conectividad
de extremo a extremo, y se debe considerar como una implementación a corto plazo para el
agotamiento de direcciones, cuya solución a largo plazo es IPv6.
En este capítulo, se analizó la NAT para IPv4, incluido lo siguiente:
 Las características, la terminología y las operaciones generales de NAT
 Los diferentes tipos de NAT, incluidas la NAT estática, la NAT dinámica y PAT
 Las ventajas y las desventajas de NAT
 La configuración, la verificación y el análisis de la NAT estática, la NAT dinámica y PAT
 La forma en que se puede usar el reenvío de puertos para acceder a los dispositivos internos
desde Internet
 La resolución de problemas de NAT mediante los comandos show ydebug


PDF Ccna2 v5-401-675

Cargado por

Copyright:

Formatos disponibles

PDF Ccna2 v5-401-675

Cargado por

Información del documento

Título original

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

PDF Ccna2 v5-401-675

Cargado por

Copyright:

Formatos disponibles

CCNA Routing and Switching.

Routing and Switching Essencials

Además de la información de estado de enlace, se incluye información adicional en el LSP, como

Nicolás Contador 401

En el ejemplo en la ilustración, se muestra el contenido de la base de datos de estado de enlace

Nicolás Contador 402

En la figura 1, el R1 identifica sus redes conectadas directamente y los costos.

Nicolás Contador 403

Nicolás Contador 404

Nicolás Contador 405

Nicolás Contador 406

7.5.3 Razones para utilizar protocolos de routing de estado de enlace

 Armado de un mapa topológico: los protocolos de routing de estado de enlace crean un

 Actualizaciones desencadenadas por eventos: después de la saturación inicial con LSP,

 Diseño jerárquico: los protocolos de routing de estado de enlace utilizan el concepto de

Nicolás Contador 407

 Requisitos de memoria: los protocolos de estado de enlace requieren memoria adicional

 Requisitos de procesamiento: los protocolos de estado de enlace también pueden requerir

 Requisitos de ancho de banda: la saturación de paquetes de estado de enlace puede

Nicolás Contador 408

Existen solamente dos protocolos de routing de estado de enlace: OSPF e IS-IS.

 OSPFv2: OSPF para redes IPv4 (RFC 1247 y RFC 2328)

 OSPFv3: OSPF para redes IPv6 (RFC 2740)

Nicolás Contador 409

7.6 La tabla de routing

El R3 también introduce una ruta de superred 192.168.0.0/16.

Nicolás Contador 410

Nicolás Contador 411

Nicolás Contador 412

 Origen de la ruta: identifica el modo en que se descubrió la ruta.

 Red de destino: identifica la dirección de la red remota.

 Distancia administrativa: identifica la confiabilidad del origen de la ruta.

Nicolás Contador 413

Nicolás Contador 414

7.6.2 Rutas IPv4 descubiertas en forma dinámica

La tabla de enrutamiento IP de Cisco no es una base de datos plana. La tabla de enrutamiento, en

Las rutas se analizan en términos de lo siguiente:

 Ruta principal de nivel 1

 Rutas secundarias de nivel 2

Nicolás Contador 415

Nicolás Contador 416

 Ruta predeterminada: una ruta estática con la dirección 0.0.0.0/0.

En la figura 2, se destacan las rutas de nivel 1.

Nicolás Contador 417

Nicolás Contador 418

Nicolás Contador 419

En la figura 3, se destacan las rutas secundarias en la tabla de routing del R1.

Nicolás Contador 420

Nicolás Contador 421

7.6.3 Proceso de búsqueda de rutas IPv4

6. Si no hay coincidencia con ninguna ruta de la tabla de enrutamiento, el router descarta el

Nicolás Contador 422

Nicolás Contador 423

7.6.4 Análisis de una tabla de routing IPv6

 El R1, el R2 y el R3 están configurados en una topología de malla completa. Todos los

 Se configuró EIGRP para IPv6 en los tres routers.

Nicolás Contador 424

 Red conectada directamente: la dirección IPv6 de la red conectada directamente.

Nicolás Contador 425