BGP, IPv6 y Redistribución

CCNP: Building Scalable Internetworks
Módulo 5: Optimización de rutas.

Descripción
A veces, el enrutamiento dinámico en pequeñas redes, implica mucho más que habilitar el funcionamiento por
defecto de un protocolo de enrutamiento. Algunos de estos comportamientos pueden llevar a un uso poco
eficiente del ancho de banda, riesgos de seguridad o enrutamiento subóptimo.
Por ejemplo, las actualizaciones de enrutamiento compiten con los datos de usuarios por ancho de banda y
recursos del router. En algunos casos, aunque no se requieran actualizaciones de rutas éstas son publicadas
por defecto, consumiendo ancho de banda e incrementando los riesgos de seguridad.
Durante la redistribución de rutas entre sistemas autónomos, el enrutamiento puede no ser el más óptimo al no
haber un afinamiento.
En una red el enrutamiento puede ser optimizado, controlando cuando el router intercambia actualizaciones de
rutas y que contienen estas actualizaciones. Para asegurar que la red opere eficientemente, se deben controlar
y optimizar las actualizaciones. La información acerca de las redes debe ser enviada donde sea necesario y
filtrada donde no lo sea.
Este módulo examina las características claves del IOS para la optimización del enrutamiento, incluyendo la
redistribución de rutas, control de actualizaciones de rutas y enrutamiento basado en políticas (policy-based
routing). Además, una descripción de DHCP y como configurarlo.
5.1 Operando una red que utiliza múltiples protocolos de enrutamiento

5.1.1 Utilizando múltiples protocolos de enrutamiento
Un protocolo de enrutamiento simple trabaja bien en una red simple, pero las redes crecen y se vuelven más
complejas. Mientras lo deseable es utilizar solo un protocolo de enrutamiento en toda nuestra red, el
enrutamiento multiprotocolo es común por múltiples razones, por ejemplo fusiones entre compañías, varios
departamentos administrados por varios administradores de red, ambientes “multivendors” o simplemente
porque el protocolo de enrutamiento original no es el más adecuado.
Por ejemplo, Routing information protocol (RIP) envía periódicamente actualizaciones de la tabla de rutas
completa. Como la red crece, el tráfico
de estas actualizaciones puede saturar
la red, indicando que puede ser
necesario utilizar un protocolo de
enrutamiento más escalable. Otra razón
podría ser, que una compañía que
utiliza EIGRP, ahora necesite de un
protocolo que soporte equipos de
múltiples fabricantes o que la compañía
implemente políticas que especifican el
uso de un protocolo de enrutamiento en
particular.
Utilizar un ambiente con múltiples

protocolos a veces es parte del diseño
de la red y los administradores deben
conducir la migración, de un protocolo a
otro con atención. En ocasiones, la
transición entre protocolos de
enrutamiento se realiza gradualmente, Figura 1 – Enrutamiento jerárquico
con lo cual, múltiples protocolos se
¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 1

encuentran operativos en la red durante lapsos de tiempo variables. Es importante para un administrador de red
comprender qué debe cambiar y crear un plan detallado antes de realizar cualquier cambio. Un mapa de la
topología exacta de la red y un inventario de todos dos dispositivos también puede ser fundamental.
Protocolos de enrutamiento de estado-enlace, como OSPF e IS-IS, requieren de una estructura de red
jerárquica. Los administradores de red necesitan decidir cuales routers pertenecerán al área de backbone y
como segmentaran los demás routers dentro de áreas. Figura 1. EIGRP no requiere una estructura jerárquica,
pero operará mucho mejor dentro de una.
Utilizar un protocolo de enrutamiento para anunciar las rutas aprendidas de alguna otra forma, como por
ejemplo, otro protocolo de enrutamiento, rutas estáticas o rutas directamente conectadas, se conoce como
redistribución de rutas. Diferencias en las características de los protocolos de enrutamiento, como métricas,
distancia administrativa, características de classful o classless, pueden afectar la redistribución.
5.1.2 Definiendo redistribución de rutas

En las siguientes situaciones pueden ser necesarios múltiples protocolos de enrutamiento:
• Cuando se esta migrando desde un antiguo IGP (Interior Gateway Protocol) a un nuevo IGP. Múltiples
fronteras de redistribución pueden existir en el nuevo protocolo hasta que se halla reemplazado por
completo el antiguo protocolo.
• Cuando se requiere utilizar otro protocolo, pero el antiguo protocolo de enrutamiento se necesita para
un sistema host. Esta situación en común en ambientes UNIX que utilizan RIP.
• Algunos departamentos podrían no querer actualizar sus routers para soportar un nuevo protocolo.
• En un ambiente de routers de varios fabricantes, se podría utilizar un protocolo de enrutamiento
específico para los equipos Cisco, como EIGRP y un protocolo de enrutamiento basado en estándares,
como OSFP, para comunicar los equipos de otros fabricantes.
Cuando están siendo utilizados

múltiples protocolos de enrutamiento en
diferentes partes de la red, puede existir
la necesidad de que un host en una
parte de la red quiera alcanzar a otro
host en otra parte de la red. Una
solución sería publicar una ruta por
defecto (default route) dentro de cada
protocolo de enrutamiento, pero esto no
es siempre la mejor alternativa. El
diseño de la red podría no permitir rutas Usando múltiples protocolos de enrutamiento
por defecto.
Si hay más de una forma para llegar a la red de destino, los routers podrían necesitar información acerca de las
rutas en otras partes de la red para determinar el mejor camino hacia el destino. Adicionalmente, si hay
múltiples caminos, un router debería contar con suficiente información para determinar una ruta libre de loops
hacia la red de destino.
Los routers Cisco permiten a las redes que utilizan diferentes protocolos de enrutamiento, también conocidos
como dominios de enrutamiento o sistemas autónomos, intercambiar información de enrutamiento a través una
característica (feature) llamada redistribución de rutas.
La redistribución es, como los routers que conectan diferentes dominios de enrutamiento pueden intercambiar y
publicar información de enrutamiento entre diferentes sistemas autónomos.
NOTA: El término “sistema autónomo” es utilizado para referirse a redes que utilizan diferentes protocolos de
enrutamiento. Estos protocolos pueden ser IGP‘s o EGP‘s (Exterior Gateways Protocols), lo que es diferente a
utilizar el término “sistema autónomo” cuando se refiere a BGP (Border Gateway Protocol).

5.1.3 Redistribuyendo información de rutas

Dentro de cada sistema autónomo, los routers mantienen un completo conocimiento de su red. El router que
interconecta los sistemas autónomos se conoce como router de borde. El router de borde debe correr todos los
protocolos de enrutamiento que se están utilizando para intercambiar rutas.
Cuando un router redistribuye rutas, permite que un protocolo de enrutamiento publique rutas que no son
conocidas a través del protocolo de enrutamiento. Estas rutas redistribuidas podrían haber sido aprendidas por
medio de diferentes protocolos, como por ejemplo, cuando se redistribuye entre EIGRP y OSPF, desde rutas
estáticas o mediante una conexión directa a la red.
Los routers pueden redistribuir rutas estáticas, rutas directamente conectadas y rutas de otros protocolos de
enrutamiento.
La redistribución siempre es realizada “outbound”(de salida). El router que realiza la redistribución no cambia su
tabla de enrutamiento. Cuando se configura la redistribución entre OSPF y EIGRP, el proceso OSPF en el
router de borde toma las rutas de EIGRP de la tabla de enrutamiento y las publica como rutas de OSPF a sus
vecinos OSPF.
Asimismo, el proceso EIGRP en el

router de borde toma las rutas OSPF y
las publica como rutas EIGRP a sus
vecinos de sistema autónomo. Como
resultado, ambos sistemas autónomos
conocen las rutas del otro, y cada
sistema autónomo puede luego tomar
decisiones de enrutamiento conociendo
estas redes.
Los vecinos EIGRP utilizan el listado

EIGRP externo para rutear el tráfico
destinado a otros sistemas autónomos
a través del router de borde. El router
de borde debe conocer las rutas hacia
las redes de destino en su tabla de Redistribuyendo información de rutas
rutas para reenviar el tráfico.
Por esta razón, las rutas deben estar en la tabla de rutas para que puedan ser redistribuidas. Este
requerimiento puede ser evidente, pero también puede ser fuente de confusión.
Por ejemplo, si un router conoce una red vía EIGRP y OSPF, solo las rutas EIGRP son colocadas en la tabla de
enrutamiento porque tienen una distancia administrativa menor. Supongamos que RIP también esté corriendo
en este router y que se busca redistribuir rutas de OSPF dentro de RIP. La red no es redistribuida dentro de RIP
porque esta en la tabla de enrutamiento como una ruta EIGRP, no como una ruta OSPF.
Dentro de los factores que tienen impacto sobre la redistribución se incluyen:

• Métricas
• Distancia administrativa
• Capacidades de classful/classless en los protocolos
Estos factores serán discutidos en varias secciones de este módulo.
5.1.4 Utilizando métricas

Cada protocolo de enrutamiento define una métrica para cada ruta. El valor de la métrica determina que tan
corto es el camino hacia una red IP. Cuando un router redistribuye rutas desde un dominio de enrutamiento a
otro, esta información no puede ser traducida de un protocolo a otro. Por ejemplo, un salto de RIP no puede ser
dinámicamente recalculado a un costo OSPF por el router que realiza la redistribución. Sin embargo, una

métrica inicial (seed) artificialmente configura la distancia, costo, etc, para cada red externa (redistribuida)
desde el punto de redistribución.
Ejemplo de métrica inicial (seed metric).

Por ejemplo, si un router de borde recibe una ruta desde RIP, ésta utiliza la cuenta de saltos como métrica.
Para redistribuir esa ruta dentro de OSPF, el router debe traducir la cuenta de saltos en una métrica de costos
que el router OSPF pueda comprender.
Esta métrica inicial (seed metric), también conocida como métrica por defecto, es definida durante la
configuración de la redistribución. Cuando se establece una métrica inicial para una ruta redistribuida, la métrica
aumenta en incrementos normales dentro del sistema autónomo.
1
Nota: La diferencia para esta regla son las rutas OSPF E2 , las cuales permanecen con su métrica inicial a
pesar de que tan lejos sea propagadas dentro del sistema autónomo.
El comando default-metric, usado en el modo de configuración del proceso de enrutamiento, establece la

métrica inicial para todas las rutas redistribuidas. Figura 1.
Utilice el comando default-metric para

establecer la métrica por defecto para la
ruta o para especificar una métrica
cuando se esta redistribuyendo.
Una vez que la métrica es establecida,

la métrica se incrementa, como
cualquier otra ruta. Figura 1 – Usando métricas seed
Los routers Cisco también permiten que

la métrica inicial sea especificada como
parte del comando de redistribución,
con la opción metric o utilizando un
route-map.
De cualquier forma que sea hecho, la Figura 2 - Protocolos con sus métricas iniciales por defecto
métrica inicial debería ser configurada
con un valor más grande que la métrica más alta recibida dentro del sistema autónomo para ayudar a prevenir
un enrutamiento poco eficiente o loops de enrutamiento.
La figura 2 muestra los nombres de los protocolos con sus métricas iniciales por defecto.
5.1.5 Ejemplo de métricas iniciales

La figura 1 ilustra una métrica inicial de 30
implementada por OSPF en las rutas RIP
redistribuidas. El costo del enlace Ethernet
al router D es 100. Por lo tanto, el costo
para las redes 1.0.0.0, 2.0.0.0 y 3.0.0.0 en el
router D la métrica inicial es 30 más el costo
del enlace 100 = 130. Se debe tener en
cuenta, que la métrica de las tres redes en
la nube RIP son irrelevantes en la nube
OSPF, porque el objetivo es tener cada
Figura 1 – Redistribución con métricas iniciales

1
El concepto de rutas E2 en OSPF hace referencia a aquellas rutas que son redistribuidas dentro de OSPF. La métrica para estas rutas
refleja solo el costo de la ruta desde el ASBR (Autonomous System Boundary Router) hacia la red de destino y no incluye el costo de la ruta
desde el router local. A diferencia de las rutas E1, las que incluyen el costo total desde el router local hasta la red de destino.

router OSPF reenviando tráfico de las tres redes al router de borde (redistribución).
Una métrica infinita le dice al router que la ruta es inalcanzable, y por lo tanto, no debería ser publicada. Cuando
se redistribuyen rutas dentro de RIP y EIGRP se debe especificar una métrica por defecto (default-metric). Para
2
OSPF, las rutas redistribuidas tienen una métrica, tipo 2 , de 20, excepto para rutas BGP`s redistribuidas las
cuales tienen por defecto una métrica, tipo 2, de 1. Para IS-IS, las rutas redistribuidas tienen por defecto, una
métrica de 0. Pero a diferencia de RIP o EIGRP, IS-IS no trata la métrica inicial 0 como inalcanzable. Se
recomienda configurar una métrica inicial para redistribución dentro de IS-IS. Para BGP las rutas redistribuidas
mantienen las métricas del enrutamiento IGP.
5.1.6 Definiendo la distancia administrativa.

Muchos protocolos de enrutamiento tienen estructuras de métricas y algoritmos que no son compatibles con
otros protocolos. Es crítico para una red que utiliza múltiples protocolos de enrutamiento tener perfectamente
integrado el intercambio de información de rutas y la capacidad para seleccionar el mejor camino a través de
múltiples protocolos.
Los routers Cisco utilizan un valor llamado distancia administrativa para seleccionar el mejor camino cuando
aprenden dos o más rutas hacia un mismo destino desde diferentes protocolos de enrutamiento. La distancia
administrativa mide la confiabilidad de un protocolo de enrutamiento. Cisco ha asignado un valor por defecto a
la distancia administrativa para cada protocolo de enrutamiento soportado en sus routers.
Cada protocolo es priorizado en orden, desde el más confiable al menos confiable. Algunos ejemplos de
priorización son los siguientes:
• Rutas configuradas manualmente (rutas estáticas) antes que las rutas dinámicamente aprendidas.
• Protocolos con métricas sofisticadas sobre protocolos con métricas más determiniísticas.
• Preferir “External Border Gateway Protocol (EBGP)” más que otros protocolos dinámicos.
En la figura 1, se muestra una tabla con

la distancia administrativa por defecto
para los protocolos que soporta Cisco.
La distancia administrativa es un valor
entre 0 y 255. A menor valor de la
distancia administrativa, mayor es la
confiabilidad del protocolo.
Nota: IGRP no es soportado en el IOS

release 12.3.
Por ejemplo, en la figura 2, si un router

A recibe una ruta a la red 10.0.0.0
desde RIP y recibe una ruta a la misma Figura 1 – Distancia administrativa
red desde OSPF, el router compara las
distancias administrativas de RIP (120) con la
distancia administrativa de OSPF (110). El router
determina que OSPF es más confiable y agrega la
versión de la ruta de OSPF a su tabla de
enrutamiento.
Longitud de prefijos.
Modificar la longitud de los prefijos de rutas para
diferentes protocolos de enrutamiento puede afectar
las decisiones de enrutamiento. La longitud del
2
En OSPF las rutas externas se categorizar en dos tipos, tipo 1 y tipo 2. La diferencia
Figura entre ambas
2 – Ejemplo es la forma en
de distancias que se calcula el costo
administrativas
(métrica). Por esto, el costo de una ruta tipo 2 es siempre el costo externo sin considerar el costo interior para alcanzar una ruta. El tipo 1,
considera el costo interno utilizado para alcanzar la ruta. Hacia un mismo destino siempre se da preferencia a una ruta de tipo 1 sobre una
de tipo 2.
prefijo es el número de bits configurados en la máscara de subred. Prefijos largos siempre son preferidos sobre
prefijos cortos cuando se reenvía un paquete, independientemente del protocolo de enrutamiento.
Por ejemplo, un router tiene configurados

cuatro procesos de enrutamiento
(sistemas autónomos) y cada proceso ha
recibido las siguientes rutas:
• EIGRP (interno): 192.168.32.0 /26
• RIP: 192.168.32.0 /24
• OSPF: 192.168.32.0 /19
Cuál de estas rutas será instalada en la

tabla de enrutamiento? Puesto que las
rutas de EIGRP (interno) tienen la mejor Figura 3 – Prefijo de longitud variable
distancia administrativa, se debe asumir
que la primera ruta será instalada. Sin embargo, como cada una de estas rutas tiene un prefijo diferente
(máscara de subred), están considerados diferentes destinos. Por consiguiente, todas están instaladas en la
tabla de enrutamiento. Figura 3.
Si un paquete llega a la interfaz de un router con destino la red 192.168.32.1, cuál ruta debería escoger el
router? Esto depende del prefijo, o del número de bits configurados en la máscara de subred. Los prefijos largos
son preferidos sobre los prefijos cortos al momento de reenviar paquetes. En este caso, un paquete destinado a
192.168.32.1 es dirigido a la red 10.1.1.1 porque 192.168.32.1 cae dentro de la red 192.168.32.0 /26
(192.168.32.0 a 192.168.32.63). También cae dentro de otras dos rutas disponibles, pero la subred
192.168.32.0 /26 tiene un prefijo mayor dentro de la tabla de rutas (26 bits versus 24 o 19 bits).
Asimismo, si un paquete destinado para 192.168.32.100 llega a una de las interfaces de los routers, es
reenviado a 10.1.1.2 porque 192.168.32.100 no cae dentro de 192.168.32.0 /26 (192.168.32.0 a
192.168.32.63), pero no cae dentro 192.168.32.0 /24 (192.168.32.0 hasta 192.168.32.255). Otra vez, también
cae dentro del rango cubierto por 192.168.32.0 /19, pero 192.168.32.0 /24 tiene un prefijo mayor.
5.1.7 Modificando las distancias administrativas

En algunos casos, al confiar en un
protocolo de enrutamiento con una
distancia administrativa mejor un router
puede no seleccionar el camino más
óptimo, aunque el protocolo de
enrutamiento actual tenga una ruta peor.
Asignando una distancia administrativa

mayor a un protocolo de enrutamiento no
Figura 1 – Modificando distancias administrativas
deseado se asegura que el router
seleccione rutas desde un protocolo deseado.
Utilizando el comando distance se puede
cambiar la distancia administrativa por defecto
para todos los protocolos de enrutamiento,
excepto EIGRP y BGP. La figura 1 y 2
describen las opciones de éste comando.
Para EIGRP, utilice el comando distance eigrp

En la figura 3, EIGRP asigna un valor diferente
a la distancia administrativa de las rutas
aprendidas nativamente a través de EIGRP y
a las rutas redistribuidas dentro de otras
fuentes.
Por defecto, en EIGRP las rutas aprendidas

tienen una distancia administrativa de 90, pero Figura 2 – Parámetros del comando distance
las rutas externas tienen una distancia administrativa de 170.
Para BGP, utilice el comando distance

bgp. BGP asigna un valor diferente a la
distancia administrativa de las rutas
conocidas a través de IBGP y a las
rutas aprendidas a través de EBGP.
Figura 3 – Parámetros del comando distance eigrp
5.2 Configurando y verificando redistribución en el router.

5.2.1 Configurando redistribución.
Configurar la redistribución de rutas puede ser simple o complejo dependiendo de la mezcla de protocolos que
se quieran redistribuir. Los comandos utilizados para habilitar la redistribución y para asignar métricas varían
ligeramente dependiendo de los protocolos que estén siendo redistribuidos. Antes de configurar el intercambio
de información de enrutamiento entre protocolos, se debe comprender claramente los procedimientos y
requerimientos de cada uno de los protocolo de enrutamiento.
La redistribución debe ser configurada correctamente para cada protocolo de enrutamiento, para sí obtener los
resultados deseados.
Como se muestra en la figura 1, todos

los protocolos de enrutamiento
soportan la redistribución.
Adicionalmente, las rutas estáticas y
directamente conectadas pueden ser
redistribuidas para permitirle al
protocolo de enrutamiento publicar
estas rutas sin utilizar una red
declarada.
Intercambiando información de
enrutamiento entre protocolos de
enrutamiento se conoce como
redistribución de rutas. La redistribución
de rutas puede ser en uno o dos
sentidos. Las rutas en un sentido son
aquellas en donde un protocolo recibe Figura 1 – Redistribución soporta todos los protocolos
las rutas desde otro. Las rutas en dos
(ambos) sentidos son aquellas en las cuales ambos protocolos reciben las rutas del otro. La figura 2, muestra
un ejemplo de la redistribución en uno y dos sentidos.
Las rutas son redistribuidas dentro de un protocolo de enrutamiento, el comando redistribute se requiere para
configurar el proceso de enrutamiento que va a recibir las rutas. Antes de implementar la redistribución, se
deben tener cuenta los siguientes puntos:
• Solo los protocolos que soportan el mismo snack, de protocolos, son redistribuidos. Por ejemplo, se
puede redistribuir entre IP RIP y OSPF, porque ambos soportan el stack TCP/IP.
Nota: No se puede redistribuir entre IPX RIP y OSPF, porque el stack IPX de RIP (IPX/SPX) no es soportado
por OSPF. Aunque existen diferentes módulos dependiendo del protocolo (PDM`s) de EIGRP para IP, IPX y
AppleTalk, las rutas no pueden ser redistribuidas entre ellos porque cada PDM soporta diferentes stacks.

• El método utilizado para configurar la redistribución varía ligeramente entre diferentes protocolos de
enrutamiento y combinaciones de protocolos. Algunos de estos protocolos requieren que se configure
una métrica durante la redistribución, pero otras no.
Los siguientes pasos son genéricos

para aplicar en todas las combinaciones
de protocolos: sin embargo, los
comandos que son usados para
implementar estos pasos pueden variar.
Para la configuración de comandos, es
importante revisar la documentación de
Cisco IOS para un protocolo de
enrutamiento específico que necesite
ser redistribuido.
Nota: En este tópico, los términos

“core” y “Edge” son utilizados para
simplificar la aclaración.
1. Localizar los routers de borde

(edge) que requieran Figura 2 – Ejemplo de redistribución
configuraciones de redistribución.
Seleccionando solo un router para redistribución se minimiza la probabilidad de crear loops de enrutamiento
causados por la retroalimentación (feedback).
2. Determinar cual protocolo de enrutamiento es el protocolo del core o backbone. Típicamente este protocolo
es OSPF, IS-IS o EIGRP
3. Determinar cual es el protocolo de borde o de backbone (en caso de migración). Determine si todas las
rutas de un protocolo de borde deben ser propagadas dentro del Core. Se deben considerar métodos para
reducir el número de rutas.
4. Seleccionar un método para inyectar las rutas requeridas del protocolo de borde dentro del core. Un
redistribución simple utilizando redes sumarizadas en la frontera minimiza el número de nuevas entradas en
la tabla de enrutamiento de los routers del core.
Cuando se planea la redistribución desde el borde al core, se debe considerar como inyectar la información de
enrutamiento del core dentro del protocolo de borde. La elección depende de su red.
5.2.2 Redistribuyendo rutas dentro de un protocolo de enrutamiento classful.

La figura 1 muestra como configurar la
redistribución desde un proceso 1 de
OSPF dentro de RIP.
En la figura, el ejemplo utiliza el

comando router rip para acceder al
proceso de enrutamiento, dentro del
cual se encuentran las rutas que
necesitan ser redistribuidas. En este
caso, se utiliza el proceso de
enrutamiento RIP.
El ejemplo utiliza el comando

redistribute para especificar el protocolo
de enrutamiento a ser redistribuido
dentro de RIP. En este caso, es el Figura 1 – Configurando redistribución en RIP
proceso de enrutamiento número 1 de
OSPF.

Nota: La métrica por defecto es infinita,
excepto cuando se están redistribuyendo
rutas directamente conectadas o rutas
estáticas. Por defecto, una ruta
directamente conectada se le asigna una Figura 2 – Comando redistribute
métrica de 0, y a una ruta estática se le
asigna una métrica de 1. Sin embargo, si
una ruta estática es configurada para apuntar hacia una interfaz de salida en vez de la dirección del siguiente
salto, la ruta estática es considerada como una ruta directamente conectada.
La sintaxis del comando redistribute en

RIP se muestran en la figura 2. La figura 3
muestra los parámetros del comando.
Figura 3 – Parámetros del comando redistribute
5.2.3 Redistribuyendo desde protocolos classless a protocolos classful.

En la figura 1, rutas desde el proceso 1
de OSPF están siendo redistribuidas
dentro de RIP y tienen una métrica
inicial de 3. Como no se especifica el
tipo de ruta, ambas rutas de OSPF,
internas y externas, son redistribuidas
dentro de RIP.
Un problema común con la

redistribución de rutas entre RIP y
OSPF es que RIP no publica rutas
fuera de una interfaz aunque estas
rutas se encuentren en la misma red
pero tengan una máscara de red
diferente a la de la interfaz. Los Figura 1 – Redistribuyendo en RIP

siguientes son dos escenarios en que describe este problema.
OSPF tiene una máscara mayor que RIP.

En la figura 2, el router RTB esta redistribuyendo entre RIP y
OSPF. El dominio OSPF tiene una máscara de red diferente
(mayor en este caso) que el dominio RIP, y están en la misma
red. Por consiguiente, RIP no publica las rutas aprendidas
desde OSPF y redistribuidas dentro de RIP.
La máscara de subred del dominio OSPF es difícil de cambiar,

en lugar de eso, se agrega una ruta estática en el router RTB
que apunte al dominio OSPF con una máscara de
255.255.255.0 pero con un salto siguiente (next-hop) hacia
Null0. Luego, se redistribuyen las rutas estáticas dentro de
RIP, A continuación se muestra las configuraciones
necesarias para realizar esta tarea:
ip route 128.103.35.0 255.255.255.0 null0
Router rip
Redistribute static
Default metric 1
Figura 2 – Ejemplo de OSPF teniendo una máscara
Esto permite que la red 128.103.35.0 sea publicada a través más larga que RIP
de RIP fuera de la interfaz E2/0 del router RTB. Sin embargo,
el router RTB tiene rutas mas especificas aprendidas desde OSPF en su tabla de enrutamiento, con las que
realiza mejores decisiones de enrutamiento.
RIP tiene una máscara mayor que OSPF.

En la figura 3, el dominio RIP tiene una mascara de
255.255.255.248, y el dominio OSPF tiene una máscara de
255.255.255.240. RIP no publica rutas aprendidas desde OSPF
y redistribuidas dentro de RIP.
Nosotros podemos agregar una ruta estática en el router RTB

que apunte hacia el dominio OSPF con una máscara de
255.255.255.248, Sin embargo, dado que esta es una máscara
de red más especifica que la mascara original de OSPF, el
siguiente salto debe ser la interfaz actual del siguiente salto.
También necesitaremos múltiples rutas estáticas para cubrir
todas las direcciones de el dominio OSPF. De esta forma las
rutas estáticas son redistribuidas dentro de RIP.
En el código mostrado más abajo, las primeras dos rutas

estáticas cubren el rango 128.103.32.32 255.255.255.240 del
dominio OSPF. Las segundas dos rutas estáticas cubren el
rango 128.103.35.16 255.255.255.240 del dominio OSPF. Y las
últimas cuatro rutas estáticas cubren el rango 128.130.65.64 Figura 3 – Ejemplo de RIP teniendo una máscara
255.255.255.240, las cuales son conocidas a través de dos más larga que OSPF
interfaces en el dominio OSPF.
ip route 128.103.35.32 255.255.255.248 E0/0

ip route 128.103.35.40 255.255.255.248 E0/0
ip route 128.103.35.16 255.255.255.248 E1/0

ip route 128.103.35.24 255.255.255.248 E1/0
ip route 128.103.35.64 255.255.255.248 128.103.35.34

ip route 128.103.35.64 255.255.255.248 128.103.35.18

ip route 128.103.35.72 255.255.255.248 128.103.35.34
ip route 128.103.35.72 255.255.255.248 128.103.35.18
router rip
redistribute static
default metric 1
5.2.4 Redistribuyendo rutas dentro de un protocolo de enrutamiento classless.

La figura 1, muestra como configurar la
redistribución del sistema autónomo 100
de EIGRP dentro de OSPF. El comando
router ospf 1 es utilizado para introducir
en el proceso 1 de OSPF las rutas que
necesitan ser redistribuidas.
El comando redistribute le especifica al

protocolo de enrutamiento que sea
redistribuido dentro de OSPF. En este
caso, es el sistema autónomo 100 de
EIGRP.
La figura 2 muestra la sintaxis del

comando redistribute en OSPF. La
figura 3 muestra los parámetros del
comando.
La redistribución de OSPF puede ser Figura 1 – Configurando redistribución en RIP

limitada a un numero definido de
prefijos por el comando redistribute
maxium-prefix maxium {threshold} ó
{warning-only}. El parámetro threshold
(umbral) por defecto registra las
advertencias un 75% del valor máximo Figura 2 – Comando redistribute
configurado.
Después de alcanzar el numero máximo configurado, no mas rutas son redistribuidas. Si el parámetro warning-
only es configurado, no hay limite para la redistribución. El valor máximo simplemente se convierte en un
segundo punto donde otro mensaje warning es almacenado.
Este comando fue introducido en el release 12.0(25)S y fue integrado dentro del IOS release 12.2(18)S,
12.3(4)T, y posteriores.

5.2.5 Ejemplo de redistribución de rutas dentro de OSPF.

En la figura 1, la métrica por defecto de
20 esta siendo usada para OSPF y el
tipo de métrica es configurada como
externa tipo 1. Este tipo de
configuración logra que la métrica se
incremente a medida que las
actualizaciones pasen a través de la
red.
El comando contiene la opción subnet,

la cual provoca que las subredes
(subnets) sean redistribuidas.
Figura 1 – Redistribuyendo en OSPF
5.2.6 Redistribuyendo rutas dentro de EIGRP.

La figura 1 muestra como configurar la redistribución desde OSPF al sistema autónomo 100 de EIGRP. El
comando router eigrp 100 es utilizado para acceder al proceso de enrutamiento dentro del cual las rutas
El comando redistribute le especifica que el protocolo de enrutamiento sea redistribuido dentro del sistema
autónomo 100 de EIGRP. Es este caso, el proceso de enrutamiento 1 de OSPF.
Nota: Cuando se redistribuye una ruta

estática o directamente conectada dentro
de EIGRP, la métrica por defecto es igual
a la métrica de la interfaz saciada.
La figura 2 muestra la sintaxis del

comando redistribute en EIGRP.
La figura 3 muestra los parámetros del

comando.
Figura 1 – Configurando redistribución en EIGRP
Figura 2 – Comando redistribute

5.2.7 Ejemplo de redistribución de rutas dentro de EIGRP.

En la figura 1, las rutas de proceso numero 1 de OSPF son redistribuidas dentro del sistema autónomo 100 de
EIGRP. En este caso, la métrica especificada asegura que las rutas sean redistribuidas. Las rutas redistribuidas
aparecen en la tabla de enrutamiento de router B como rutas externas de EIGRP (D EX).
Las rutas eternas de EIGRP tienen una distancia administrativa mayor que la distancia administrativa de 170
que tienen las rutas internas de EIGRP (D), por esto las rutas internas de EIGRP son preferidas sobre las rutas
externas.
Figura 1 – Redistribución en EIGRP
5.2.8 Redistribuyendo rutas dentro de IS-IS

La figura 1 muestra la sintaxis y como
configurar la redistribución desde el
sistema autónomo 100 de EIGRP
dentro de IS-IS. El comando router isis
es utilizado para acceder al proceso de
enrutamiento dentro del cual las rutas
El comando redistribute específica el

protocolo de enrutamiento que va a ser
redistribuido dentro de IS-IS. En este
caso, es el sistema autónomo 100 de
EIGRP.
La figura 2 muestra los parámetros del

Figura 1 – Configurando redistribución en IS-IS
comando.
Cuando se redistribuyen rutas de IS-IS dentro de otro protocolo de enrutamiento, se pueden incluir rutas de
nivel 1, de nivel 2 o ambas. La salida, mostrada en la figura 3, muestra los parámetros disponibles para escoger
estas rutas. Si no se especifica un nivel, todas las rutas serán redistribuidas.
También se puede limitar la redistribución dentro de IS-IS definiendo un número de prefijos utilizando el
comando redistribute maxium-prefix maxium {threshold} {warning-only | withdraw}. El parámetro threshold por
defecto registra un 75% del valor máximo configurado. Después de alcanzar el porcentaje máximo configurado,
no se redistribuyen mas rutas. El parámetro opcional withdraw también provoca que IS-IS reconstruya los link-
state PDU`s. que están en los paquetes link-state sin un prefijo IP externo (redistribuido). Si el parámetro

warning-only es configurado, no hay limites en la redistribución. El valor máximo del número configurado se
convierte simplemente en un segundo punto donde otro mensaje warning es registrado. Este comando fue
introducido en el release 12.0(25)S y fue integrado dentro del release 12.2(18)S, 12.3(4)T, y posteriores.
Figura 2 – Parámetros del commando redistribute
Figura 3 – Redistribución IS-IS en otros protocolos de enrutamiento
5.2.9 Ejemplo de redistribución de rutas dentro de IS-IS.

En la figura 1, las rutas son redistribuidas desde el
sistema autónomo 100 de EIGRP dentro de IS-IS
en el router A. No se les configura una métrica,
por esto esas rutas tienen una seed metric de 0.
No se les configura un tipo de nivel, por ello las

rutas son redistribuidas como rutas de nivel 2
(como se muestra en la tabla de enrutamiento del
router B).
Figura 1 – Redistribución en IS-IS

5.2.10 Redistribuyendo rutas estáticas y conectadas.

En la redistribución de información entre IGP`s, a veces es necesario redistribuir información sobre rutas
estáticas.
Por ejemplo, en la figura 1 una ruta

estática por defecto (0.0.0.0 0.0.0.0) ha
sido configurada en el router RTX para
alcanzar al router RTA y el router RTA
ha sido configurado con una ruta
estática para alcanzar la red LAN
172.16.1.0 en el router RTX.
Para actualizar los otros routers

conectados al router RTA acerca de la
red 172.16.1.0, el router RTA debe ser
configurado para redistribuir las rutas
estáticas dentro de RIP. El comando
redistribute static le dice a RIP que
importe las rutas estáticas y las anuncie
como parte de las actualizaciones de
RIP.
Figura 1 – Redistribución de información estática
Nota: El comando passive-interface es
explicado en la siguiente lección.
Para redistribuir las rutas directamente conectadas, es necesario utilizar el comando redistribute conected.
Redistribuir redes directamente conectadas dentro del protocolo de enrutamiento no es una práctica común; sin
embargo se puede realizar.
5.2.11 Verificando la redistribución de rutas.

La figura 1 muestra la red hipotética de una
compañía. La red comienza con dos dominios
de enrutamiento, también conocidos como
sistemas autónomos, uno usando OSPF y el
otro usando RIP versión 2. El router B es el
router de borde. Éste conecta directamente a
un router dentro de cada dominio de
enrutamiento y corre ambos protocolos.
El router A esta en el dominio RIP y publica la

subred 10.1.0.0, 10.2.0.0 y 10.3.0.0 al router Figura 1 – Configuración antes de la redistribución
B. El router C esta en el dominio OSPF y
publica las subredes 10.8.0.0, 10.9.0.0,
10.10.0.0 y 10.11.0.0 al router B.
La configuración del router B se muestra en la

figura. Se requiere RIP para correr solamente
en la interfaz serial 1. Por lo tanto, el comando
passive-interface es puesto en la interfaz
serial 2. El comando passive-interface
previene que desde RIP se envíen
publicaciones de rutas fuera de la interfaz.
OSPF es configurado en la interfaz serial 2.
Figura 2 – Tabla de enrutamiento antes de la redistribución
La figura 2 muestra la tabla de enrutamiento

de los routers A, B y C. Cada dominio de enrutamiento es separado y los routers dentro de ellos reconocen solo
las rutas que son comunicadas solo desde su propio protocolo de enrutamiento.
El único router con la información de todas las rutas es el router B, el cual es el router de borde que corre
ambos protocolos de enrutamiento y conecta ambos dominios de enrutamiento.
La finalidad es que todos los routers reconozcan todas las rutas dentro de la compañía, para esto debe:
• Redistribuir rutas de RIP dentro de OSPF
• Redistribuir rutas OSPF dentro del dominio RIP
La redistribución debe ser configurada

en el router de borde. La figura 3
muestra como el router B es
configurado para cumplir con el
requerimiento de la redistribución.
RIP es redistribuido dentro OSPF. En

este ejemplo, la métrica es configurada
dentro del comando redistribute. Otras
opciones, dentro de las cuales se
incluyen especificar una métrica por
defecto (default metric) o aceptar la
métrica por defecto de OSPF la cual es Figura 3 – Configurando la redistribución de rutas
de 20.
El comando default-metric asigna una métrica seed a todas las rutas redistribuidas dentro de OSPF desde
cualquier origen. Si se le configura un valor a la métrica específicamente bajo el comando redistribute , este
valor sobrescribe el valor de la métrica por defecto. El valor seleccionado es 300 porque es la peor métrica de
cualquier ruta nativa en OSPF.
Bajo el proceso RIP, las rutas redistribuidas son redistribuidas desde el proceso 1 de OSPF. Estas rutas son
redistribuidas dentro de RIP con una métrica de 5. El valor de 5 es escogido porque es mayor que cualquier
métrica el la red RIP.
5.2.12 Ejemplo de verificación de redistribución de rutas.

La figura 1 muestra la tabla de rutas de
los tres routers después de que se
completó la redistribución. Como se
puede ver, se ha cumplido la finalidad:
Ahora todos los routers tienen rutas
hacia todas las subredes remotas.
El router A y C tiene muchas mas rutas

para mantener que antes. Cada router
también es afectado por los cambios de
la topología en el dominio de
enrutamiento de los otros routers.
Dependiendo de los requerimientos de

la red, se puede incrementar la
eficiencia sumarizando las rutas antes
de que sean redistribuidas. Recuerde Figura 1 – Tabla de enrutamiento después de la redistribución
que la sumarización de rutas oculta
información. Si los routers en los otros sistemas autónomos requieren seguir un cambio de topología dentro de
la red, la sumarización no debería ser realizada, porque oculta información que los routers necesitan.

Un caso más típico es que los routers necesitan reconocer los cambios de topología solo dentro de su propio
dominio de enrutamiento.. En este caso, es apropiado realizar la sumarización de rutas. Si las rutas son
sumarizadas antes de la redistribución, las tablas de enrutamiento de cada router son significativamente más
pequeñas. La figura 2 muestra un ejemplo de las tablas de enrutamiento después de la sumarización.
El router B es el más beneficiado. Ahora tiene solo cuatro rutas que mantener en vez de nueve. El router A tiene
cinco rutas en vez de ocho y el router C tiene seis rutas en vez de ocho.
Estos comandos son utilizados para sumarizar rutas en cada protocolo:
• Router A, RIP: Para

RIPv2, el comando para
la sumarización es puesto
en la interfaz que conecta
al router B con el Router
A. Esta dirección
sumarizada es publicada
en vez de subredes
individuales. Una
limitación de RIP es que
la máscara de subred de
la dirección sumarizada
debe ser mayor o igual
que la máscara por
defecto de la mayor red
classful. Utilice el
siguiente comando para
RIPv2.
Figura 2 – Tabla de enrutamiento después del resumen de rutas y de la redistribución
RouterA(config)#
interface s0
RouterA(config-if)# ip summary-address rip 10.0.0.0 255.252.0.0
Nota: Esta sumarización incluye 10.0.0.0, la cual es aceptable en este caso porque esta directamente
conectada con una máscara mayor.
• Router C, OSPF: Se debe realizar la sumarización de OSPF en un router de borde (ABR) o en un

router de borde del sistema autónomo (ASBR). Crear otra área de OSPF que incluya las cuatro
subredes a ser sumarizadas. Colocar el comando para la sumarización bajo el proceso OSPF en el
router C, el cual se convierte en ABR. La sumarización de rutas OSPF internas en el ABR es realizada
con el comando area range:
RouterC(config)# router ospf 1
RouterC(config-router)# area 1 range 10.8.0.0 255.252.0.0
Para sumarizar rutas externas al ASBR, se debe utilizar el comando summary-addresss.

5.2.13 Problemas de distancia administrativa con la redistribución

El siguiente ejemplo describe una red utilizando
múltiples protocolos de enrutamiento. Estos
ejemplos muestran como pueden ocurrir
problemas y como se pueden solucionar.
La figura 1 ilustra una red con dominios de

enrutamiento RIP y OSPF. OSPF es más
confiable que RIP, porque OSPF tiene una
distancia administrativa de 110 y RIP tiene una
distancia administrativa de 120.
Si, por ejemplo, el router de borde (P3R1 o P3R2)

aprende acerca de la red 10.3.3.0 vía RIPv2 y
también vía OSPF, la ruta OSPF es usada e
insertada dentro de la tabla de enrutamiento
porque OSPF tiene una distancia administrativa
más baja que RIPv2, aun cuando el camino a
través de OSPF pueda ser mas largo (peor).
Figura 1 – Redistribución usando la distancia administrativa
La figura 2 muestra las configuraciones para los
routers P3R1 y P3R2. Estas configuraciones redistribuyen RIP dentro de OSPF y OSPF dentro de RIP en
ambos routers.
La redistribución dentro de OSPF

configura una métrica OSPF por defecto
para la red 10.0.0.0, ésto para hacer
que estas rutas sean menos preferidas
que las rutas nativas de OSPF y así
protegerse contra el “feedback” de
rutas. La sentencia redistribute también
configura una métrica de tipo 1 para que
la métrica de las rutas continúe
aumentando y el router redistribuya la
información de la subred.
La redistribución dentro de RIP

configura una métrica de 5 por defecto
también para protegerse contra el
“feedback” de rutas.
La figura 3 muestra la tabla de

enrutamiento en el router P3R2
Figura 2 – Redistribución usando la distancia administrativa (cont.)
después de ocurrida la redistribución. El
router P3R2 conoce las rutas de RIP y
OSPF pero lista solo las rutas de OSPF en su tabla de enrutamiento.
El primer router de borde establece la redistribución como una tabla de enrutamiento normal y retiene las rutas
RIP. El segundo router de borde escoge las rutas de OSPF sobre las rutas de RIP. El camino hacia las rutas
internas de RIP se muestra como yendo a través del core por los puntos duales de redistribución mutua.

OSPF es informado acerca de las rutas

de RIP mediante la redistribución.
OSPF luego publica las rutas RIP vía
rutas OSPF a sus routers vecinos. El
router vecino también es informado
acerca de las mismas rutas vía RIP. Sin
embargo, OSPF tiene una mejor
distancia administrativa que RIP, por lo
que las rutas de RIP no son puestas en
la tabla de enrutamiento.
OSPF fue configurado primero en el

router P3R1 y en el router P3R2 luego
de recibida la información acerca de las
rutas internas (RIP nativas) desde
ambos OSPF y RIP. El prefiere las rutas
OSPF porque OSPF tiene una distancia Figura 3 – Redistribución usando la
administrativa más baja. Sin embargo, distancia administrativa (cont.)
las rutas RIP no aparecen en la tabla de
enrutamiento.
Devuelta al diagrama de topología para trazar algunas rutas. La redistribución ha resultado en suboptimos
caminos para muchas de las redes.
Por instancia, 10.200.200.34 es una interfaz loopback en el router P3R4. P3R4 esta directamente conectado al
P3R2. Sin embargo, el camino OSPF hacia la interfaz loopback es por P3R1, luego P3R3, luego P3R4 antes de
alcanzar el destino. El camino OSPF toma actualmente el camino largo (peor) que el más directo vía RIP.
Uno de los routers de borde (P3R2 en este ejemplo) selecciona un mal camino porque OSPF tiene una mejor
distancia administrativa que RIP. Usted puedes cambiar la distancia administrativa de las rutas RIP
redistribuidas para asegurar que los routers de borde seleccionen las rutas nativas de RIP, como lo ilustra la
figura.
5.2.14 Solución de la distancia administrativa con redistribución

Hay un número de formas para corregir los problemas de selección de caminos en un ambiente de
redistribución. Este ejemplo una posible forma.
Uno de los routers de borde (P3R2 en

este ejemplo) selecciona n mal camino
puesto que OSPF tiene una mejor
distancia administrativa que RIP. Usted
puede cambiar la distancia
administrativa de las rutas para
asegurar que los routers de borde
seleccionen las rutas nativas de RIP,
como lo muestra la figura 1.
En la figura 1, el comando distance

modifica la distancia administrativa de
las rutas OSPF para las redes que
hacen match con la lista de acceso
(ACL) 64. Específicamente, el comando
distance 125 0.0.0.0 255.255.255.255
64 asigna la distancia administrativa de Figura 1 – Solución a la redistribución
125 a todas las rutas especificadas en
la ACL 64.
En este escenario, la ACL 64 es utilizada para hacer match con todas las rutas nativas de RIP. El comando
access-list 64 permit 10.3.1.0 configura una ACL estandar para permitir la red 10.3.1.0. Otras sentencias
similares de ACL`s permiten las otras redes RIP nativas (internas).
Nótese que ambos routers de redistribución son configurados para asignar una distancia administrativa de 125
a las rutas OSPF que son publicadas por las redes listadas en la ACL 64.
La ACL 64 tiene sentencias permit para las redes internas nativas de RIP de 10.3.1.0, 10.3.2.0 y 10.3.3.0 así
como las redes loopback 10.200.200.31, 10.200.200.32, 10.200.200.33 y 10.200.200.34.
Cuando cualquiera de los routers que están redistribuyendo aprende alguna de esas redes desde RIP,
selecciona la ruta aprendida desde RIP (con una menor distancia administrativa (120)) sobre la misma ruta
aprendida desde OSPF (con una distancia administrativa de 125) y coloca solo las rutas de RIP en la tabla de
enrutamiento.
El comando distance es parte de la configuración del proceso de enrutamiento porque la distancia

administrativa debería ser cambiada para estas rutas cuando ellas sean publicadas por OSPF, no por RIP.
Usted necesita configurar el comando

distance en ambos routers de
redistribución porque cualquiera puede
tener rutas suboptimas, dependiendo de
cual router de redistribución envíe
primero las actualizaciones OSPF
acerca de las redes RIP al otro router
de redistribución.
La salida en la figura 2 muestra que el

router P3R2 ahora retiene los caminos
más directos hacia las redes internas
aprendidas desde RIP. Sin embargo,
alguna información de enrutamiento se
pierde con esta configuración. Por
ejemplo, dependiendo del actual ancho
de banda, la ruta OSPF puede ser
mejor para la red 10.3.1.0. Pudo no
haberse incluido 10.3.1.0 en la lista de Figura 2 – Solución a la redistribución (cont.)
acceso.
Ese ejemplo ilustra la importancia de conocer su red antes de implementar la redistribución y examinar
detalladamente cuales rutas son seleccionadas en los routers después de que se habilita la redistribución.
Preste particular atención a los routers que pueden seleccionar desde un numero de posibles caminos
redundantes hacia una red, porque ellos pueden ser mas propensos a seleccionar caminos suboptimos.
La característica más importante de usar la distancia administrativa para controlar la preferencia de rutas es que
no se perderá información del camino. La información de OSPF permanecerá en la base de datos de OSPF. Si
es perdido el camino primario, el camino a través de OSPF puede reafirmarse el mismo, manteniendo
conectividad con esa red.
5.3 Controlando el tráfico de actualización de enrutamiento.

5.3.1 Controlando actualizaciones de rutas.
Cisco IOS ofrece varias técnicas para controlar las actualizaciones de enrutamiento. Algunos de estos métodos
incluyen los siguientes:

• Passive interfaces (Interfaces pasivas)
• Distribute list (Listas de redistribución)
• Policy routing usando route maps (Políticas de enrutamiento utilizando mapas de rutas)
No hay un tipo de filtro que sea apropiado para cada situación. Sin embargo, entre mas técnicas estén a tu
disposición, mejor será tu chance de que tu red funcione “como una seda”.
5.3.2 Passive Interfaces (Interfaces Pasivas)

En la figura 1, el comando network
10.0.0.0 en el modo d configuración del
router habilita RIP en todas las
interfaces. Por consiguiente, las
interfaces E0, E1, S0 y S1 participan
todas en el intercambio de información
de enrutamiento.
Sin embargo, enviando actualizaciones

de rutas por E0 es un gasto innecesario
de recursos, puesto que no hay otros
routers en la subred 10.4.4.0 que
puedan recibir las actualizaciones.
Mientras que, enviar actualizaciones
crea una ligera sobrecarga y puede
Figura 1 – Topología con una interface pasiva
causar un potencial riesgo de
seguridad. Un usuario malicioso podría
utilizar un sniffer de paquetes para
capturar las actualizaciones de rutas y
recopilar información clave de la red. Figura 2 – Comando passive-interface
Una interfaz pasiva esencialmente hace
a un router silencioso en una red.
Identificando una interfaz como pasiva
previene que el router envie
actualizaciones a través de esa interfaz.
Figura 3 – Parámetros del commando passive-interface
Se puede utilizar el comando passive-
interface con la mayoría de los
protocolos IP IGP`s, incluyendo RIP,
EIGRP, OSPF e IS-IS. Para configurar
una interfaz como pasiva, utilice el
siguiente procedimiento:
Paso 1.
Seleccione el router y el protocolo de
enrutamiento que requiere la passive
interface.
Paso 2.
Determine la interfaz a través de la cual
usted no quiere que sea enviado trafico Figura 4 – Topología con una interface pasiva
de actualizaciones de enrutamiento. (o
mensajes hello para protocolos de enrutamiento de estado-enlace (link-state) y EIGRP).
Paso 3.
Configure el router utilizando el comando passive-interface, la figura 2 y 3 muestran los parámetros del
comando.
La figura 4 muestra la configuración requerida en RIP para configurar la interfaz E0 como pasiva. E0 recibe
ahora actualizaciones, pero no las envía. El
comportamiento del comando passive-interface varia
entre protocolos de enrutamiento. Cuando es
configurado en RIP, las actualizaciones de
enrutamiento no son reenviadas fuera de la interfaz
especificada, pero el router aun continua recibiendo
actualizaciones por esa interfaz.
Cuando es configurado en EIGRP, los mensajes hello

no son enviados por la interfaz especificada. No se
forma una relación de vecindad con los otros routers Figura 5 – Interface pasiva en RIP
alcanzables a través de esa interfaz. Si no se
encuentra otro router en una interfaz, no se envía otro
tipo de tráfico EIGRP (como se muestra en la figura
6).
Usando el comando passive-interface en un router

corriendo un protocolo de enrutamiento estado-enlace
también se previene que el router establezca
adyacencias de vecindad con otros routers que están
conectados al enlace especificado en el comando. El
router no envía mensajes hello a la interfaz Figura 6 – Interface pasiva en EIGRP
especificada. Por lo tanto, no se pueden establecer
adyacencias con los vecinos porque el protocolo hello
verifica que exista comunicación bidireccional entre
los routers.
Específicamente, en OSPF, la dirección de la interfaz

que se especifica como pasiva aparece como red stub
en el dominio OSPF. Figura 7. Información de
enrutamiento de OSPF nunca es enviada o recibida a
través de la interfaz especificada. En IS-IS la dirección
IP especificada es anunciada sin estar actualmente Figura 7 – Interface pasiva en in OSPF
corriendo IS-IS en esa interfaz.
La figura 8 resume el comportamiento de

la característica passive-interface con los
comunes IGP`s.
Figura 8 – Resumen de interface pasiva
5.3.3 Consideraciones de interfaces pasivas.

Con proveedores de servicios de Internet (ISPs) y redes de grandes empresas, muchos de los routers de
redistribución tienen mas de 200 interfaces. Antes de la introducción del feature passive-interface por defecto en
los releases 12.0 del Cisco IOS, la solución a los problemas de numerosas interfaces era configurar el protocolo
de enrutamiento en todas las interfaces y manualmente setear el comando passive-interface en cada interfaz
donde no se requería adyacencias. En algunos casos, esto comprendía entrar 200 o más sentencias passive-
interface.
Para resolver esta escalabilidad en la configuración, el comando passive-interface default puede ser usado
para setear todas las interfaces como pasivas. Se puede habilitar el enrutamiento en una interfaz cando se
requiera utilizando el comando no passive-interface.

En la figura 1, los routers A y B corren

RIP y tienen una declaración de las
redes que comprenden todas sus
interfaces; sin embargo, se busca correr
RIP solo en el enlace entre el router A y
B.
El router A tiene varias interfaces. El

comando passive-interface default fue
usado para setear todas las interfaces
como pasivas y el comando no passive-
interface fue usado para habilitar la
interfaz en donde se deseaba RIP. El
router B tiene solo dos interfaces, así
que el comando passive-interface fue
usado en la interfaz que no participa en
RIP. Figura 1 – Comado passive-interface default
Es importante comprender como esta configuración afecta el intercambio de información entre los routers A y B,
y entre ellos y el router C. A menos que, se configure otro protocolo de enrutamiento y se redistribuya entre éste
y RIP, el router A no le dirá al router C que él tiene una forma para alcanzar las redes anunciadas por el router
B via RIP.
Asimismo, el router B no le dice al router C que él tiene una forma de alcanzar las redes anunciadas por el
router A vía RIP.
La redundancia se construye dentro de esta red. Sin embargo, los tres routers no son capaces de utilizar esta
redundancia eficientemente. Por ejemplo, si el enlace entre el router C y el router A falla, el router C no conoce
que existe una ruta alternativa a través del router B. En est situación, se deberían configurar filtros de rutas.
5.3.4 Configurando filtrado de rutas usando distribute lists.

La técnica de passive-interface previene
que todas las actualizaciones de
enrutamiento sean anunciadas por una
interfaz. Figura 1. Sin embargo, en
muchos casos no se busca prevenir que
toda esa información sea anunciada.
Si se busca bloquear solo el anuncio de

ciertas rutas especificas, por ejemplo,
se podría utilizar como solución para
prevenir loops de enrutamiento cuando
se implementa redistribución de rutas
en dos sentidos con puntos de
redistribución duales.
Algunas formas para controlar o

prevenir actualizaciones de rutas
dinámicas son las siguientes: Figura 1 – Controlando el tráfico de actualización de enrutamiento
• Interfaces pasivas: previenen
que todas las actualizaciones de enrutamiento sean enviadas por una interfaz. Para EIGRP, OSPF e
IS-IS, este método incluye los paquetes hello.
• Rutas por defecto (default routes): Instruye al router que envíe paquetes hacia la ruta por defecto si
no tiene una ruta hacia el destino. Por lo tanto, no son necesarias las actualizaciones dinámicas de
enrutamiento acerca de redes remotas.

• Rutas estáticas: Permite configurar manualmente rutas hacia destinos remotos. Por lo tanto, no son
necesarias las actualizaciones de enrutamiento acerca de redes remotas
Otra forma de controlar las actualizaciones de enrutamiento es con una distribute list, la cual permite que una
lista de control de acceso (ACL) sea aplicada a las actualizaciones de rutas. Usted tal vez este familiarizado con
las ACL asociadas con una interfaz y utilizada para controlar el trafico IP. Sin embargo, los routers puede tener
muchas interfaces y la información de enrutamiento puede ser obtenida a través de la redistribución de rutas, la
cual no involucra a una interfaz o a todas.
Adicionalmente, ACLs no afectan el tráfico que es originado por el router, aplicando una distribute list bajo el
protocolo de enrutamiento. La ACL permitiría las redes que serán anunciadas o redistribuidas y denegaría las
redes que permanecerán ocultas.
El router luego aplica la ACL a la actualización de enrutamiento del protocolo. Las opciones en el comando
distribute-list permiten que las actualizaciones sean filtradas basadas en tres factores:
• Interfaz de ingreso
• Interfaz de salida
• Redistribución desde otro protocolo de enrutamiento.
Una distribute list le da al administrador la flexibilidad para determinar cuales rutas el router distribuye.
5.3.5 Implementando Distribute list

Usted puede filtrar el tráfico de las
actualizaciones de enrutamiento en
cualquier protocolo definiendo una ACL
y aplicándola al protocolo de
enrutamiento especifico. Se puede
utilizar el comando distribute-list y
enlazarlo con una ACL para completar
el filtrado del tráfico de las
actualizaciones de enrutamiento. (El
comando distribute-list aplicado de
entrada, permite utilizar un route map
en lugar de una ACL). Figura 1.
Una distribute list habilita el filtrado de

actualizaciones de enrutamiento de
Figura 1 – Configurando distribute-list
entrada en una interfaz específica
desde los routers vecinos que utilizan el
mismo protocolo de enrutamiento o de
salida en la interfaz hacia dichos
routers. Una distribute list permite
también filtrar las rutas redistribuidas
desde otros protocolos de enrutamiento
o fuentes.
Para configurar una distribute list

utilizando una ACL, utilice el siguiente
procedimiento: Figura 2 – Parámetros del comando distribute-list
Paso 1.
Identifique la dirección de red que se quiera filtrar y cree una ACL.
Paso 2.
Determine si se quiere filtrar el tráfico de entrada en una interfaz o de salida, o las rutas que están siendo
redistribuidas desde otra fuente.

Paso 3.
Use el comando distribute-list out para
asignar la ACL con el objeto de filtrar las
actualizaciones de enrutamiento
salientes o para asignarla a las rutas
redistribuidas dentro del protocolo. La
figura 2 muestra los parámetros del
comando.
Nota: El comando distribute-list out no

puede ser utilizado con un protocolo de Figura 3 – Parámetros del comando distribute-list in
enrutamiento de estado-enlace para
bloquear los link-state advertisements
(LSAs) en una interfaz.
Paso 4.
Utilice el comando distribute-list in para
asignar una ACL que filtre de entrada
las actualizaciones de enrutamiento en
una interfaz. Este comando previene
que muchos protocolos de enrutamiento
coloquen rutas filtradas en sus bases de
datos. Cuando este comando es
utilizado con OSPF, las rutas están
colocadas en una base de datos pero
no en la tabla de enrutamiento. La figura
3 muestra los parámetros del comando.
La figura 4 muestra un ejemplo de una

distribute-list aplicada de salida. La
distribute list denegará la publicación de
la red 10.1.1.0 por la interfaz serial 2 en Figura 4 – Usando filtros de salida
el router RTA.
La figura 5 muestra un ejemplo de una

distribute list de entrada. Esta distribute
list bloqueará, de entrada, el anuncio de
la red 10.1.1.0 que ingresa por la
interfaz serial 0 del router RTZ.
Figura 5 – Usando filtros de entrada

5.3.6 Filtrando actualizaciones de enrutamiento con una distribute list.

El comando distribute-list 7 out s0 en la
figura 1, aplica la ACL 7 como filtro de
rutas para las actualizaciones que
EIGRP envía por la interfaz serial 0 a
otros routers que corren EIGRP. La ACL
7 es una ACL estándar que le permite a
la información de enrutamiento solo ver
la red 172.16.0.0.
La sentencia implícita deny any en el

final de la ACL previene que sean
publicadas actualizaciones de
enrutamiento acerca de cualquier otra
red. Como resultado, la red 10.0.0.0
permanece oculta del resto de la red.
Figura 1 – Filtrando actualizaciones de enrutamiento con una lista de
distribución
5.3.7 Controlando la redistribución con distribute lists.

Con redistribución mutua, usar una distribute list ayuda a prevenir el feedback de rutas, lo cual también ayuda a
prevenir loops de enrutamiento. El feedback de rutas ocurre cuando las rutas que originalmente son aprendidas
desde un protocolo de enrutamiento son redistribuidas de vuelta dentro al protocolo original.
Como se muestra en la figura 1, la

redistribución en dos vías es
completada entre RIP y OSPF. Las
redes 10.1.0.0 a la 10.3.0.0 son
redistribuidas desde RIP a OSPF. El
feedback de rutas podría ocurrir si fuera
configurado otro punto de redistribución
(Router D) y OSPF luego redistribuyera
estas rutas de vuelta a RIP. La ACL 2
permite las rutas originales de RIP y
deniega todas las demás. La distribute
list configurada bajo OSPF se refiere a
esta ACL.
El resultado es que las redes 10.8.0.0 a

la 10.11.0.0, originadas por OSPF, no
pueden ser redistribuidas de vuelta a
OSPF desde RIP. La redistribución
desde OSPF a RIP es referida por la Figura 1 – Controlando la redistribución con listas de distribución
ACL 3. El router D tendrá una
configuración similar al router B.
Una distribute list oculta información de red, lo cual podría ser considerado una desventaja en algunas
circunstancias. En una red con caminos redundantes, la finalidad de utilizar una distribute list podría ser
prevenir loops de enrutamiento. La distribute list permite habilitar las actualizaciones de enrutamiento solo en
los caminos deseados en donde se quiere que sean anunciadas. Sin embargo, otros routers en la red podrían
no conocer otras formas para alcanzar las redes filtradas.

5.4 Policy-based Routing (Enrutamiento basado en políticas).

5.4.1 Definiendo Route maps.
Los route maps son similares a complejas ACLs, pero mucho más poderosas. Son mucho más flexibles que las
ACLs y pueden ayudar en situaciones en que no es posible solucionarlas con ACLs.
Los route maps también pueden usar

complejas ACLs. Figura 1. Ellas
permiten que condiciones sean
probadas contra un paquete o ruta
usando el comando match. Si la
condición hace match, se toma una
acción para modificar los atributos del
paquete o ruta. Estas acciones son
especificadas por el comando set.
Una colección de sentencias de mapas

de rutas que tengan el mismo nombre Figura 1 – Route maps
es considerado como un route map.
Dentro de un route map, cada sentencia es numerada y puede ser editada manualmente.
Una sentencia en un route map es análoga a una línea en una ACL. Especificando la condición match en un
route map es similar a especificar la dirección fuente y destino, y la máscara en una ACL.
La gran diferencia entre los route maps y las ACLs, es que el route map puede usar el comando set para
modificar el paquete o la ruta.
5.4.2 Aplicaciones de los route maps.

Los administradores de red usan la herramienta de los route maps para una variedad de propósitos. Algunas de
las aplicaciones más comunes para los route maps son las siguientes:
• Filtrado de rutas durante la redistribución: La redistribución requiere casi siempre algún tipo de filtro
de ruta. Aunque una distribute list puede ser usada para este propósito, los route maps ofrecen y
agregan beneficios de manipular las métricas de enrutamiento a través del uso de los comandos set.
• Policy-based routing (PBR): los route maps pueden ser usados para coincidir con la dirección de
origen o destino, tipo de protocolo o aplicación del usuario final. Cuando ocurre una coincidencia, el
comando set describe la interfaz o dirección del siguiente salto a la cual el paquete debería ser enviado.
PBR permite al operador definir una política de enrutamiento diferente que la basada en el destino
utilizando la tabla de enrutamiento.
• BGP: los route maps son la herramienta primaria para implementar políticas en BGP. Los
administradores de redes asignan mapas de rutas para especificar sesiones BGP (Vecinos (neighbors))
para controlar que rutas son permitidas dentro y fuera del proceso BGP. Adicionalmente al filtrado, los
route maps entregan una sofisticada manipulación de los atributos para los caminos de BGP.

5.4.3 Operación de los route maps.

Los route maps operan de manera similar a las ACLs. Cuando se determinan cuales rutas serán redistribuidas
desde un protocolo al siguiente, el
router revisa cada ruta contra el route
map, comenzando desde arriba. Figura
1.
Cada línea tiene un número de

secuencia, ambos para procesarlos de
arriba hacia abajo y con el propósito de
editarlos. Las líneas pueden ser
agregadas o removidas de un route
map cuando se requiera un cambio.
Cada línea tiene una sentencia permit o
deny. Si una ruta coincide con la
sentencia y la sentencia es permit, el Figura 1 – Operación con Route map
router configura la métrica u otra
condición definida y permite la
redistribución de la ruta. El route map
detiene el procesamiento en el primer
match.
Si el paquete coincide (match) y el route

map tiene una sentencia deny, el router
detiene el procesamiento y no
redistribuye a ruta. Las rutas son
filtradas por este método.
Las rutas son revisadas línea por línea

buscando una coincidencia. Si no hay
coincidencia y el final del route map es
alcanzado, el router deniega la ruta
antes de ser redistribuida. Como en una
ACL, hay una sentencia deny any Figura 2 – Operación con Match
implícita al final del route map.
Las coincidencias de las sentencias son complejas en un route map. Figura 2. Múltiples criterios de
coincidencias en la misma línea son procesados con un OR lógico. Criterios de selección separados pueden ser
aplicados verticalmente bajo un route map. En este caso, cada match utiliza un AND lógico.
Un route map puede consistir de múltiples sentencias. Las sentencias son procesadas de arriba hacia abajo,
como en las ACL. La primera coincidencia encontrada para una ruta es aplicada. El número de secuencia es
usado para insertar o borrar una sentencia en un lugar específico del route map.
El comando match define la condición a ser revisada. El comando set define la acción a seguir si hay una
coincidencia.
Una sentencia que coincida puede contener múltiples condiciones. Por lo menos una condición de las
sentencias declaradas debe ser cierta para que la sentencia sea considerada como coincidente (OR lógico). Un
route map puede contener múltiples sentencias coincidentes. Todas las declaraciones en un route map deben
ser verdaderas para considerar que el route map hace match (AND lógico).
El número de secuencia especifíca el orden en el cual las condiciones son validadas. Por ejemplo, si hay dos
sentencias en un route map llamadas MYMAP, una con un número de secuencia 10 y otra con un número 20, la
secuencia 10 es verificada primero. Si la condición de la secuencia 10 no concuerda, se continúa con la
sentencia 20.

Como en una ACL, existe una sentencia deny any al final del route map. Las consecuencias de este deny
implícito depende de como sea utilizado el route map.
5.4.4 Usando el comando route map.

El comando route-map define las
condiciones para el filtrado de rutas y
redistribución. La figura 1 y la 2
muestran las opciones del comando.
Cuando es utilizado para filtros en la

redistribución, un route map es aplicado
al proceso de redistribución de rutas
agregando la sentencia route-map map-
tag al final del comando redistribute
protocol.
Figura 1 – Comando route-map
Figura 2 – Parámetros del comando route-map
5.4.5 El comando match.

El comando match es aplicado dentro
de un route map. Figura 1.
La figura 2 muestra algunos de los

parámetros del comando match. Los
parámetros representan una lista
general de los criterios a comparar.
Algunos criterios son utilizados por
políticas BGP, algunos por PBR, y otros
por filtros de redistribución.
Figura 1 – Comando match

Figura 2 – Parámetros del comando match
5.4.6 El comando set.

El comando set es usado dentro de un
route map para cambiar o agregar una
característica, como la métrica, a
cualquier ruta que coincida con algún
criterio. Figura 1.
La figura 2 muestra algunas de las

opciones del comando set.
Figura 1 – Comando set
No todas las opciones del comando set
listadas aquí son para propósitos de
redistribución. La tabla incluye opciones
para redistribución y PBR.
Figura 2 – Parámetros del comando set
5.4.7 Implementando route maps con redistribución.

En la figura 1, RIPv1 esta siendo redistribuido dentro de OSPF 10. Un route map llamado “redis-rip” es
atachado al comando redistribute rip.

El número de secuencia 10 del route map espera una dirección IP que haga match con la ACL 23 o la ACL 29.
Si no existe match, el router redistribuye la ruta dentro de OSPF con una métrica de 500 y configura la nueva
ruta OSPF como externa tipo 1.
Si no hay match con la línea 10, se mueve a

la línea 20. Si hay match con la ACL 37, no
permite que la ruta sea redistribuida dentro
de OSPF porque el número de secuencia
20 es un deny.
Si no hay match con el número de

secuencia 20, se mueve al 30. Dado que 30
es una sentencia permit y no hay un criterio
que coincida, todas las rutas restantes son
redistribuidas dentro de OSPF con una
métrica de 5000 y como métrica externa tipo
2.
Implementando Policy Routing. Figura 1 – Route maps con commandos de redistribución

La figura 2 presenta un escenario de policy
routing. Un route map puede ser usado en
RTA para implementar policy routing. Se
asume para este ejemplo que la política es
reforzada como sigue:
• Rutear el tráfico hacia Internet
desde la red 192.168.1.0/24 por el
ISP1
• Rutear el tráfico hacia Internet
desde la red 172.16.1.0/24 por el
ISP2
Primero, se define la lista de acceso que

será usada en el route map para que
coincida con las direcciones IP. Luego se
configura el route map utilizando la sintaxis Figura 2 – Ejemplo de política de enrutamiento
mostrada en la figura 3.
El comando en la figura tiene actualmente

configuradas dos políticas. El route map
ISP1 coincide con la ACL 1 y enruta el
tráfico saliente por la interfaz s0 hacia el
ISP1. El route map ISP2 coincide con la
ACL 2 y enruta el tráfico saliente de la
interfaz s1 hacia el ISP2.
El paso final es aplicar cada route map a la

interfaz apropiada en el RTA usando el Figura 3 – Configurando un route map
comando ip policy route-map. Figura 4. Con
el route map aplicado a la apropiada interfaz
LAN, el policy routing es implementado
satisfactoriamente.
Frecuentemente, los route maps son

usados para controlar el intercambio de
información de enrutamiento durante la
redistribución.
Figura 4 – Aplicando un route map a una interface

5.5 DHCP
5.5.1 El propósito del DHCP.
DHCP es estructurado en el protocolo
de servidor Bootstrap (BOOTP) y puerto
BOOTP también conocido como User
Datagram Protocol (UDP). Previo a
DHCP. Las direcciones IP eran
administradas manualmente, lo cual era
un proceso tedioso, propenso a errores
e intensivo.
DHCP permite que las direcciones IP

sean asignadas automáticamente a los
clientes DHCP. El servicio DHCP puede
ser implementado con un servidor
dedicado o con un dispositivo que utilice
un Cisco IOS.
La figura 1 muestra donde debería ser

implementado el DHCP en una red
empresarial. Figura 1 – DHCP
5.5.2 Comprendiendo el funcionamiento del DHCP.

Un dispositivo que utilice Cisco IOS puede actuar
como servidor DHCP, cliente, o agente relay.
La figura 1 muestra los pasos que ocurren cuando

un cliente DHCP solicita una dirección IP a un
servidor DHCP:
1. El host envía un mensaje broadcast
DHCPDISCOVER para localizar al servidor
DHCP.
2. Un servidor DHCP ofrece parámetros de
configuración como una dirección IP,
nombre de dominio, un servidor DNS,
gateway y el arriendo de una dirección IP al
cliente a través de un mensaje unicast
DHCPOFFER. También pueden ir incluidas
opciones para Telefonía IP como la opción
150, la cual es utilizada para la
configuración de teléfonos IP mediante Figura 1 – DHCP
TFTP.
3. El cliente devuelve una solicitud formal para la dirección ofrecida al servidor DHCP en un mensaje
broadcast DHCPREQUEST.
4. El servidor DHCP confirma que la dirección IP ha sido asignada al cliente devolviéndole un mensaje
unicast DHCPACK.
Un cliente DHCP puede recibir ofertas de múltiples servidores y puede aceptar una de estas ofertas. Sin
embargo, el cliente usualmente acepta la primera oferta que recibe. También, la oferta del servidor DHCP no
garantiza que la dirección IP sea asignada al cliente. El servidor usualmente reserva la dirección hasta que el
cliente tenga la opción de aceptar formalmente la dirección.
DHCP soporta tres posibles mecanismos de asignamiento:

• Manual: El administrador de red asigna una dirección IP a una dirección MAC específica. DHCP envía
la dirección asignada al host.
• Automática: La dirección IP es permanentemente asignada al host.
• Dinámica: La dirección IP es asignada al host por un tiempo limitado o hasta que expire el periodo de
arrendamiento. El mecanismo soporta la reutilización automática de direcciones cuando el host al cual
se le asignó la dirección ya no la necesita.
5.5.3 Configurando DHCP

Configurar un Cisco IOS como servidor
DHCP requiere las siguientes tareas:
• Configurar el agente de base de
datos DHCP o deshabilitar el
registro de conflictos DHCP
• Configurar un pool de direcciones
para DHCP (requerido)
• Excluir direcciones IP
• Habilitar las características de
servidor DHCP y agente relay
• Configurar arrendamiento manual
• Configurar un archivo de booteo
para en DHCP Server
• Configurar un numero de
paquetes ping y timeout Figura 1 – Configurando un servidor DHCP
• Habilitar el cliente Cisco IOS
DHCP en interfaces Ethernet
• Ejecutar la importación o auto
configuración de las opciones del
servidor DHCP
• Configurar las opciones de
información del agente relay en
mensajes BOOTREPLY
• Configurar la información de
políticas de reenvío del agente
relay
• Habilitar la característica de
DHCP smart-relay
No todas las opciones son cubiertas en

detalle. Información adicional de estas
características adicionales se encuentra
disponible en el sitio Web de Cisco.
La figura 1 identifica la mayoría de los

comandos para implementar el servidor
DHCP del Cisco IOS. La figura 2 muestra
los comandos adicionales para afinar el
arrendamiento manual de direcciones
para clientes individuales, incluyendo
dirección MAC. También existen opciones
adicionales con la implementación de la
función de DHCP relay.
Antes de configurar la característica de

DHCP server, se deberían completar las
siguientes tareas: Figura 2 – Comandos y parámetros del servidor IOS DHCP

Paso 1.
Identificar los servidores externos de FTP, TFTP, o RCP para almacenarlos en la base de datos de
arrendamientos.
Paso 2.
Identificar el rango de direcciones IP a ser asignado por el servidor DHCP y las direcciones a ser excluidas
(gateways por defecto y otras direcciones estáticas asignadas dentro del rango dinámico).
Paso 3.
Identificar las opciones DHCP necesarias para los dispositivos, incluyendo:
• Nombre de la imagen de booteo por defecto
• Routers por defecto (Defaut gateways)
• Servidores DNS
• Servidor de nombres de NetBIOS
• Opciones de telefonía IP, como opción 150
Paso 4.
Decidir un nombre de dominio DNS.
Los dispositivos que utilizan Cisco IOS pueden ser configurados también como clientes DHCP y agentes DHCP
relay.
La figura 3 muestra un ejemplo de la configuración DHCP.
En el ejemplo en la figura 4, dos pool de direcciones DHCP son creados: uno para la subred 172.16.1.0 y otro
para la subred 172.16.2.0. El host recibe la dirección desde el servidor DHCP más cercano. El router determina
como entregar la dirección basándose en la dirección IP de la interfaz del router.
Figura 3 – Ejemplo de configuración DHCP Figura 4 – Ejemplo DHCP

5.5.4 Importando DHCP y auto configuración.

En el pasado, los servidores de Cisco IOS eran configurados separadamente en cada dispositivo con todos los
parámetros y opciones especificas para
cada caso. El software IOS ha sido
revisado para permitir que servidores
DHCP de Cisco IOS puedan ser
configurados importando parámetros
desde un servidor centralizado.
La configuración mostrada en la figura 1

entrega un ejemplo de la sintaxis parcial
de los comandos para esta
característica.
Figura 1 – Ejemplo DHCP
5.5.5 Configurando el cliente DHCP.

Un dispositivo Cisco IOS puede ser
configurado para ser un cliente DHCP y
obtener dinámicamente una dirección IP
para una interfaz desde un servidor DHCP
con el comando ip address dhcp. En la
figura 1, este comando es implementado Figura 1 – Cliente DHCP
en el modo de interfaz y es específico
para una interfaz individual.
5.5.6 El IP helper address.

Un agente DHCP relay es cualquier
host que reenvía paquetes DHCP entre
clientes y servidores. Agentes de relay
reciben un mensaje DHCP y luego
generar un nuevo mensaje DHCP para
enviarlo por otra interfaz. El agente
reenvía las solicitudes y las replica entre
servidores y clientes cuando no están
en la misma subred. Figura 1.
El agente DHCP relay del Cisco IOS es

habilitado en una interfaz solo cuando el
comando ip helper-address es
Figura 1 – Helper address
configurado.
Los clientes DHCP utilizan broadcast UDPs para enviar el mensaje inicial DHCPDISCOVER, porque ellos no
tienen información acerca de la red a la cual están conectados.
Si el cliente esta en una red que no cuenta con un servidor DHCP, los mensajes UDP bradcast normalmente no
son reenviados por el router.

El comando ip helper-address provoca que los broadcast UDP cambien a un mensaje unicast y sean
reenviados por otra interfaz a una dirección IP especificada por el comando. Figura 2.
El agente de relay configura la dirección

del gateway (campo giaddr del paquete
DHCP) y, si esta configurado, agrega la
información de las opciones del agente
relay (como la opción 82) en el paquete y
lo reenvía al servidor DHCP. La respuesta
desde el servidor es reenviada de vuelta
al cliente después de remover la opción
82.
Figura 2 – ¿Por qué se usa helper address?
5.5.7 Configurando el IP helper address.

La figura 1 ilustra la utilización del
comando ip helper-address para
implementar el agente DHCP relay. El
comando habilita el reenvío de todos los
bien conocidos puertos UDP que
pueden ser incluidos en un mensaje
broadcast UDP. Usted puede usar el
comando ip forward-protocol udp para
personalizar esta característica de
acuerdo a los requerimientos de la red.
Figura 1 – Comado ip helper address
5.5.8 Personalizando los servicios de reenvío UDP.

Los siguientes son los puertos bien identificados que por defecto reenvían los servicios UDP:
• Tiempo (Time): 37
• TACACS: 49
• DNS: 53
• Servidor BOOTP/DHCP: 67
• Cliente BOOTP/DHCP: 68
• TFTP: 69
• Servicio de nombres NetBIOS:
137
• Servicio de datagramas
NetBIOS: 138
Usted puede eliminar puertos del Figura 1 – Personalizando los servicios de envio UDP
reenvío de servicios con el comando no
ip forward-protocol, y agregar puertos con el comando ip forwared-protocol.

El ejemplo de la configuración mostrado en la figura 1 no reenvía los puertos de NetBIOS y Time. Sin embargo,
es agregado el puerto 8000 en la lista de reenvíos, la cual incluye los restantes puertos bien conocidos por
ejemplo, TACACS, DNS, BOOTP cliente y servidor y TFTP.
5.5.9 Configurando el servicio de DHCP relay.

Cuando se usa el comando ip dhcp
relay information option, el relay agent
agrega un identificador del circuito de la
subopción y el ID remoto de la
subopción y se los reenvía a un servidor
DHCP.
Lo siguiente explica el proceso del

servicio DHCP relay: Figura 1.
1. El cliente DHCP genera una
solicitud DHCP y la envía como
broadcast a la red.
2. El agente DHCP relay
intercepta el paquete broadcast
con solicitud DHCP y le inserta
la información de la opción 82 al
paquete. La opción del relay
agent contiene información Figura 1 – Proceso del servicio DHCP relay
relacionada con la subopción.
3. En agente DHCP relay envía
como unicast el paquete DHCP
al servidor DHCP.
4. El servidor DHCP recibe el
paquete y usa la subopción
para asignar la dirección IP y
otros parámetros de
configuración y le reenvía el
paquete de vuelta al cliente.
5. El campo subopción es quitado
del paquete por el agente relay
mientras es reenviado al cliente
La figura 2 lista las opciones soportadas

por el comando.
Figura 2 – Opciones soportadas

5.5.10 Verificando los servicios de DHCP relay

La figura 1 lista los comandos de verificación DHCP. La figura 2 describe los comandos y parámetros.
Figura 1 – Comandos de verificación DHCP
Figura 2 – Descripción de los comandos de verificación y parámetros de

DHCP

Resumen.
Este módulo cubrió la redistribución de rutas IP y el control, y redistribución de las actualizaciones de rutas.
También fueron cubiertas las interfaces pasivas y los route maps para este control. Los route maps pueden ser
usados para implementar PBR para abaratar costos, calidad de servicio QoS, y otros propósitos definidos por
las políticas de la empresa.
Aunque DHCP no es una técnica cierta para la optimización de rutas, es una característica avanzada del Cisco
IOS. Esta puede ser configurada en un dispositivo Cisco como servidor DHCP, agente DHCP relay o cliente
DHCP. El comando ip helper-addres permite usar un dispositivo Cisco como un agente relay y numerosas
opciones adicionales que pueden ser implementadas.

Módulo 6: BGP
Descripción
Los protocolos que corren en dentro de una empresa son llamados interior gateway protocols (IGPs). Ejemplos
de IGPs incluyen RIP versión 1 y 2, EIGRP y OSPF
Los protocolos que corren fuera de una empresa, o entre sistemas autónomos son llamados exterior gateway
protocols (EGPs). Típicamente, EGPs son usados para intercambiar información de enrutamiento entre
proveedores de servicio de Internet (ISPs)
Desde 1994, Border Gateway Protocol versión 4 (BGP4) ha llegado a ser el protocolo de enrutamiento del core
de Internet. Todas las anteriores versiones son consideradas obsoletas. Más ISPs deben usar BGP para
establecer enrutamiento entre unos y otros
Las empresas típicamente emplean rutas por defecto para alcanzar a sus proveedores de servicio. Sin
embargo, en algunos casos, BGP puede ser más conveniente usar entre un sistema autónomo de un cliente y
la red del proveedor; por ejemplo en el caso de que una organización tenga múltiples conexiones hacia el
proveedor de servicio. Para ayudar a controlar selección de caminos específicos, BGP es una efectiva
alternativa a usar rutas por defecto.
Entendiendo las importantes características de BGP y la manera en la cual este se comporta diferente de los
IGPs es necesario saber cuando y cuando no utilizar BGP. Un administrador de BGP debe entender las varias
opciones para configurar correctamente BGP en redes escalables.
Este modulo discute la configuración y la verificación de BGP para la conectividad de empresas ISPs.
6.1 BGP Conceptos y Terminología

6.1.1 Usando BGP en la red de la empresa
El Internet es una colección de sistemas
autónomos que son interconectados para permitir
la comunicación entre ellos. BGP provee el
enrutamiento entre estos sistemas autónomos.
Figura 1.
Las empresas que quieren conectarse al Internet

lo hacen a través de uno o más ISPs. Si una
organización tiene únicamente una conexión a un
ISP, ellos probablemente no necesitan utilizar
BGP. En lugar de esto, ellos deberían utilizar una
ruta por defecto. Sin embargo, si ellos tienen
múltiples conexiones a un o a múltiples ISPs,
BGP es apropiado ya que este permite a ellos
manipular atributos de caminos para seleccionar
el camino optimo.
Figura 1 – Sistemas autónomos
Para entender BGP, tu primero necesitas
entender como este es diferente de los otros protocolos discutidos anteriormente. Los protocolos de
enrutamiento pueden ser clasificados como interiores o exteriores:
• IGP: Intercambia información de enrutamiento dentro de un sistema autónomo RIP, IGRP, OSPF, IS-IS,
y EIGRP son IGPs.
• EGP: intercambia información de enrutamiento entre diferentes sistemas autónomos BGP es un EGP.
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 1

BGP es un protocolo de enrutamiento entre dominios (IDPR), también conocido como EGP. BGP4 es la última
versión y es definido en el RFC 4271.
Según lo indicado en este RFC, la clásica definición de un sistema autónomo es “Un set de routers bajo una
sola administración técnica, utilizando un IGP y métricas comunes para rutear paquetes dentro del sistema
autónomo, y usando un protocolo de enrutamiento de sistemas autónomos (también llamado EGP) para
determinar como rutear paquetes a otros sistemas autónomos.”
Los sistemas autónomos también pueden utilizar más que un IGP, potencialmente con varias clases de
métricas. Desde el punto de vista de BGP, la más importante característica de un sistema autónomo es que
este aparece a otros sistemas autónomos tener un solo plan de enrutamiento interior coherente y presenta un
cuadro constante de destinos accesibles. Todas las partes de un sistema autónomo deben conectarse entre si.
Cuando BGP esta corriendo entre ruteadores de diferentes sistemas autónomos, este es llamado BGP externo
(EBGP). Cuando BGP esta corriendo entre ruteadores en el mismo sistema autónomo, este es llamada BGP
interno (IBGP)
Por ejemplo, una empresa de AS 65500 en la

figura 2 esta aprendiendo rutas del ISP-A y del
ISP-B vía EBGP, y esta también corriendo IBGP
en todos sus routers. AS 65500 aprende sobre
las rutas y escoge la mejor vía para cada uno
basado en la configuración de los ruteadores en
el sistema autónomo y las rutas BGP pasadas
de los ISPs. Si una de las conexiones hacia el
ISP se pierde, el tráfico es enviado a través del
otro ISP.
Una de las rutas que el AS 65500 aprende del

ISP-A es la 172.18.0.0/16. Si esta ruta es
pasada a través del AS 65500 usando IBGP y
es erróneamente anunciada al ISP-B, el ISP-B
puede decidir que el mejor camino para
conseguir la red 172.18.0.0/16 es a través del Figura 2 – Usando BGP para conectar a Internet
AS 65500, en lugar de ir a través del Internet.
AS 65500 debería entonces ser considerado un sistema autónomo de transito, lo cual es una muy indeseable
situación. AS 65500 quiere tener una conexión de redundancia al Internet, pero no quiere actuar como un
sistema autónomo de transito entre dos ISPs. Una cuidadosa configuración de BGP es requerida para evitar
esta situación.
6.1.2 BGP Opciones de Multihoming

Multihoming es cuando un sistema autónomo tiene más que una conexión al Internet. Las dos típicas razones
para multihoming son las siguientes: Figura 1.
• Para incrementar la confiabilidad de las conexiones al Internet: Si una conexión falla, la otra
conexión permanece disponible.
• Para incrementar el funcionamiento de la conexión: El mejor camino puede ser utilizado para
asegurar los destinos.
Los beneficios de BGP son evidentes

cuando un sistema autónomo tiene
múltiples conexiones EBGP hacia uno o
múltiples sistemas autónomos.
Múltiples conexiones permite una Figura 1 - ¿Qué es el Multihoming?

organización para tener conexiones
redundantes al Internet para poder mantener conectividad si un enlace llega a estar indisponible.

Una organización puede ser multihomed a un solo ISP o a múltiples ISPs. Una desventaja de tener todas tus
conexiones a un solo ISP es que problemas de conectividad en un solo ISPs pueden causar que tu sistema
autónomo pierda conexión hacia el Internet. Tener conexiones a múltiples ISPs, una organización gana los
siguientes beneficios:
• Redundancia con multiples conexiones
• No atarse en dentro de una política de enrutamiento de un solo ISP
• Mas caminos a una misma red para una mejor manipulación de la política
Un sistema autónomo multihomed puede correr EBGP con sus vecinos externos y debe también correr IBGP
internamente.
Si una organización desea realizar Multihoming con BGP, hay tres comunes maneras para hacerlo:
• Cada ISP pasa únicamente una ruta por defecto al sistema autónomo: La ruta por defecto es
pasada a las rutas internas.
• Cada ISP pasa únicamente una ruta por defecto y abastece rutas especificas al sistema
autónomo: Estas rutas deben ser pasadas a los routers internos, o todos los routers internos en la
trayectoria de transito pueden correr BGP y pasar estas rutas entre ellos
• Cada ISP pasa todas las rutas al sistema autónomo: Todas los routers internos en la trayectoria de
transito corren BGP y pasan estas rutas entre ellos
6.1.3 Opción 1: Ruta por defecto de todos los proveedores

Recibir únicamente una ruta por defecto de cada ISP requiere pocos recursos dentro del sistema autónomo, ya
que una ruta por defecto es usada para alcanzar cualquier destino externo. El sistema autónomo envía todas
estas rutas a los ISPs, los cuales los procesan y los pasan sobre otros sistemas autónomos.
Si un router en el sistema autónomo aprende sobre múltiples rutas por defecto, el protocolo de enrutamiento
local instala la mayor ruta en la tabla de enrutamiento, la cual es la que tiene la métrica IGP de menor costo.
Este ruta por defecto de IGP rutea los paquetes destinados a las redes externas hacia un router de borde de
este sistema autónomo, el cual esta corriendo EBGP con los ISPs. El router de borde usa la ruta por defecto de
BGP para alcanzar todas las redes externas.
La ruta que los paquetes de entrada toman para alcanzar el sistema autónomo es decidida fuera del sistema
autónomo (dentro de los ISPs y otros sistemas autónomos).
Los ISPs regionales que tienen múltiples conexiones hacia ISPs nacionales o internacionales comúnmente
implementan esta opción. Los ISPs regionales no utilizan BGP para manipulación de trayectorias. Sin embargo,
ellos requieren la habilidad de añadir nuevos clientes y redes de clientes utilizando BGP. Si el ISP regional no
usa BGP, cada vez que el ISP regional añada un nuevo set de redes, los clientes deben esperar hasta que el
ISP nacional añada esta red a sus
procesos de BGP y coloquen rutas de
señalización estática hacia el ISP regional.
Corriendo EBGP con el nacionales o
internacionales ISPs, el ISP regional
necesita añadir únicamente las nuevas
rutas de los clientes en el proceso BGP.
Estas nuevas redes automáticamente se
propagarán a través del Internet con un
mínimo de retardo.
Un cliente que escoge recibir rutas por

defecto de todos los proveedores deben
entender las siguientes limitaciones de
esta opción:
• La manipulación de la trayectoria
no puede ser ejecutada ya que
únicamente una sola ruta esta Figura 1 – Ejemplo: Rutas por defecto desde todos los proveedores

siendo recibida de cada ISP.
• La manipulación del Ancho de Banda es extremadamente difícil y puede ser cumplida únicamente con
la manipulación de la métrica del IGP de la ruta por defecto.
• Desviar algo de tráfico de un punto de salida a otro es desafiante, ya que todos los destinos están
utilizando la misma ruta por defecto para la selección de la trayectoria.
En la figura 1, AS 65000 y el AS 65250 envían rutas por defecto al AS 65500. La métrica IGP que es utilizada
para alcanzar la ruta por defecto dentro del sistema autónomo determina que ISP utiliza un router específico
dentro del AS 65500
Por ejemplo, si tú utilizas RIP dentro de AS 65500, el router C selecciona la ruta con el menor número de saltos
hacia la ruta por defecto al enviar los paquetes hacia la red 172.16.0.0
6.1.4 Opción 2: Rutas por defecto y actualizaciones parciales

En esta opción de diseño de multihoming, todos los ISPs pasan rutas por defecto y seleccionan rutas
específicas al sistema autónomo.
Una empresa corriendo EBGP con un ISP que quiere una tabla de enrutamiento parcial, generalmente recibe
las redes que el ISP y sus otros clientes poseen. La empresa puede también recibir las rutas de cualquier otro
sistema autónomo.
Grandes ISPs tienen asignados entre 2000 y 10000 bloques CIDR (classless interdomain routing) de
direcciones IP del Internet Assigned Numbers Authority (IANA), los cuales ellos reasignan a sus clientes. Si el
ISP pasa esta información a sus clientes que quieren únicamente una parcial tabla de enrutamiento de BGP, el
cliente puede redistribuir estas rutas en dentro de su IGP. Los routers internos del cliente (aquellos que no
corren BGP) pueden entonces recibir estas rutas vía redistribución. Ellos pueden tomar el punto de salida más
cercano basado en la mejor métrica de redes específicas, en vez de tomar la salida más cercana basada en la
ruta por defecto.
Adquirir una tabla parcial de BGP de cada proveedor es beneficioso ya que la selección de la trayectoria es más
predecible que cuando se utiliza una ruta por defecto.
En la figura 1, los ISPs del AS 65000 y AS

64900 envían rutas por defecto y rutas que
cada ISP posee hacia el AS 64500. La
empresa (AS 64500) pidió que ambos
proveedores también envíen rutas a las
redes en el AS 64520 debido a la cantidad
de tráfico entre el AS 64520 y el AS 64500.
Correr IBGP entre los routers internos

dentro del AS 64500, As 64500 pueden
escoger el óptimo camino para alcanzar las
redes de los clientes (As 64520, en este
caso). Las rutas para el AS 64100 y para
otros sistemas autónomos que no están
específicamente anunciados al AS 64500
por el ISP A y por el ISP B son
determinados por la métrica del IGP que es Figura 1 – Rutas por defecto desde todos los proveedores y tabla parcial
usada en cada ruta por defecto dentro del
sistema autónomo.
6.1.5 Opción 3: Full Rutas de todos los Proveedores

En la tercera opción multihoming, todos los ISPs pasan todas las rutas al sistema autónomo, y IBGP es
corriendo en todos los routers en la trayectoria de tránsito en este sistema autónomo. Esta opción permite a los
routers internos del sistema autónomo tomar la trayectoria a través del mejor ISP para cada ruta.

Esta configuración requiere muchos recursos

dentro del sistema autónomo, ya que se debe
procesar todas las rutas externas.
El sistema autónomo envía todas sus rutas a los
ISPs, los cuales procesan las rutas y las pasan a
otros sistemas autónomos.
En la figura 1, As 65000 y el AS 64900 envía

todas las rutas hacia el AS 64500. El ISP que un
router específico dentro del AS 64500 usa para
alcanzar las redes externas es determinado por el
protocolo BGP.
Los routers en el AS 64500 pueden ser

configurados para influenciar en la trayectoria
para cierta red. Por ejemplo, el router A y el B
pueden influenciar en el tráfico de salida del
AS64500. Figura 1 – Rutas completas desde todos los proveedores
6.1.6 Enrutamiento BGP entre sistemas autónomos

El principal objetivo de BGP es proveer un sistema de enrutamiento entre dominios que garantice un
intercambio de información de enrutamiento libre de lazos entre sistemas autónomos. Los routers intercambian
información entre paths hacia redes destino.
BGP es un sucesor del Exterior Gateway Protocol, el cual fue desarrollado para aislar redes de uno con el otro
así como el crecido Internet. Es importante no confundir el Exterior Gateway Protocol con la categoría de EGP.
Hay muchos RFCs relacionados a BGP4, la actual versión de BGP, incluyendo 1772, 1773, 1774, 1930, 1966,
1997, 1998, 2042, 2385, 2439, 2545, 2547, 2796, 2858, 2918, 3065, 3107, 3392, 4223, y el 4271.
BGP4 tiene muchas mejoras de sus anteriores realces. El Internet usa BGP4 exclusivamente para conectar
empresas a ISPs y para conectar ISPs entre ellos.
BGP4 y sus extensiones son las únicas versiones aceptables de BGP disponibles para utilizar en el public-
based Internet. BGP4 lleva una máscara
de red para cada red anunciada y soporta
variable-length subnet masking (VLSM) y
CIDR. Los antecesores de BGP4 no
soportan estas capacidades, las cuales
son actualmente mandatorias en el
Internet.
Cuando CIDR es utilizado en un router de

core para un gran ISP, la tabla de
enrutamiento IP, la cual es compuesta en
su mayoría de rutas BGP, tiene mas de
170,000 bloques CIDR. No utilizar CIDR
en el nivel de Internet podría causar que
la tabla de enrutamiento IP tenga más de
2 millones de entradas. Utilizar BGP4 y
CIDR previene que la tabla de
enrutamiento de Internet llegue a ser
demasiada grande para interconectar
millones de usuarios. Figura 1 – Sistemas autónomos BGP

Número de sistemas autónomos
Recordar que un sistema autónomo es una colección de redes bajo una sola técnica de administración. IGPs
opera dentro de un sistema autónomo, y BGP (específicamente BGP4) es utilizado entre sistemas autónomos
en el Internet. Figura 1.
IANA es la organización que mantiene un registro de la asignación global de direcciones IP. El Regional Internet
Registry (RIR) es una organización que supervisa la asignación y registración de recursos de números de
Internet dentro de una particular región del mundo. Los recursos incluyen direcciones IP (IPv4 y IPv6) y
números de sistemas autónomos.
Hay actualmente 5 RIRs. The American Registry for Internet Numbers (ARIN) tiene la jurisdicción de asignar
numeración a las Americas y a algunas islas en el Caribe. Réseaux IP Européens Network Coordination Center
(RIPE NCC) administra los sistemas autónomos de Europa, el este medio y dentro de Asia. The Asia Pacific
Network Information Center (APNIC) administra la numeración de la región del Asia-Pacific. Latin American y
Caribbean Internet Addresses Registry (LACNIC) es responsable de América Latina y algo del Caribe. AfriNIC
es responsable para el África.
El número del sistema autónomo es de 16 bits, colocados desde el 1 al 65535. El RFC 1930 provee una línea
guía para el uso de estos números. Los números del 64512 al 65535 son reservados para uso privado, así
como las direcciones privadas de IP. Los números de sistemas autónomos utilizados en este curso son todos
en el rango privado para evitar publicar números pertenecientes a organizaciones.
Nota: Utilizar un sistema autónomo asignado por el IANA mejor que un número privado, es necesario
únicamente si tu organización planea utilizar un EGP, tal como BGP, y conectarse a redes públicas, tales como
el Internet.
Comparación con IGPs

BGP trabaja diferente que IGPs. Un protocolo de enrutamiento busca el path más rápido de un punto en una
red corporativa a otra basado en métricas seguras. RIP utiliza la cuenta de saltos para atravesar los dispositivos
de capa 3 para alcanzar las redes destino. OSPF y EIGRP buscan la mejor rapidez acorde a la declaración del
ancho de banda en la interfaz. Todos los protocolos de enrutamiento interno miran el costo del path hacia un
destino.
En contraste, BGP, un protocolo de enrutamiento externo, no busca la rapidez para el mejor camino. Sino que
BGP es un protocolo PBR (policy-based routing) que permite a un sistema autónomo controlar el flujo de tráfico
utilizando múltiples atributos en las trayectorias. BGP permite que un proveedor utilice completamente todo su
ancho de banda manipulando los atributos del path.
6.1.7 Funcionalidad del Path-Vector

Internamente los protocolos de enrutamiento anuncian una lista de redes y las métricas para conseguir a cada
red. En contraste, los routers BGP
intercambian información de confiabilidad
de las redes, llamados path vectors,
compuestos de path atributes. La
información del path-vector incluye una lista
de los full path de los números de sistemas
autónomos de BGP (hop by hop)
necesariamente para alcanzar una red
destino y las redes que son alcanzables al
final del path. Figura 1.
Otros atributos incluyen la dirección IP para

conseguir a el siguiente sistema autónomo
(the next-hop attribute) y una indicación de
cómo las redes en el final del path fueron
introducidas dentro del BGP (origin code Figura 1 – Enrutando BGP path-vector
attribute). Esta información de la trayectoria
del sistema autónomo es utilizada para construir un grafico de sistemas autónomos basados en la información
intercambiada entre BGP neighbors.
BGP mira la entera red como un grafico o árbol de sistemas autónomos. La conexión entre dos cualesquier
sistemas forman un path. La colección de información de path es expresada como una secuencia de números
de sistemas autónomos llamados AS path. Esta secuencia forma una ruta para alcanzar un destino específico.
El AS path siempre esta libre de lazos. Un router que este corriendo BGP no acepta una actualización de
enrutamiento que ya incluya el numero del sistema autónomo del router en el path list, ya que la actualización
ya ha pasado a través de este sistema autónomo, y aceptar esta otra vez, podría resultar en un lazo de
enrutamiento.
6.1.8 BGP Politicas de enrutamiento

BGP permite que las decisiones de políticas de enrutamiento en el nivel del sistema autónomo sean cumplidas.
Estas políticas pueden ser implementadas para todas las redes poseídas por el sistema autónomo, para ciertos
bloques CIDR de los números de red (prefijos), o para redes o subredes individuales
BGP específica que un router BGP puede anunciar a sistemas autónomos vecinos únicamente aquellas rutas
que utiliza el mismo. Esta regla refleja el paradigma de enrutamiento hop-by-hop que el Internet generalmente
utiliza.
El paradigma de enrutamiento hop-by-hop no soporta todas las posibles políticas. Por ejemplo, tu no puedes
influenciar como un sistema autónomo vecino enrute su trafico, pero tu puedes influenciar en como tu trafico
alcanza a un sistema autónomo vecino. BGP soporta cualquier política semejante al paradigma de enrutamiento
hop-by-hop.
Debido a que el Internet actualmente utiliza únicamente el paradigma de enrutamiento hop-by-hop, y ya que
BGP soporta cualquier política que se asemeje a este paradigma, BGP es altamente aplicable como protocolo
de enrutamiento entre sistemas autónomos.
Por ejemplo, en la figura 1, los siguientes

paths son posibles para el AS 64512 para
alcanzar redes en el AS 64700 a través del
AS 64520:
• 64520 64600 64700
• 64520 64600 64540 64550 64700
• 64520 64540 64600 64700
• 64520 64540 64550 64700
El AS 64512 no ve todas estas posibilidades
El AS 64520 anuncia al AS 64512

únicamente el mejor camino, 64520 64600 Figura 1 – Políticas de enrutamiento BGP
64700 de la misma manera que los IGPs
anuncian únicamente las mejores rutas de menor costo. Este path es la única trayectoria a través del AS 64520
que el AS 64512 ve. Todos los paquetes que son destinados para el 64700 a través del 64520 toma esta
trayectoria (path)
Aun cuando otros path existen, el AS 64512 puede únicamente usar lo que el AS 64520 anuncia para las redes
del AS 64700. El AS path que es anunciado, 64520 64600 64700, es el AS-by-AS (hop-by-hop) path que el AS
64520 utiliza para alcanzar las redes dentro del AS 64700. El AS 64520 no anunciara otro path, como el 64520
64540 64600 64700, ya que este no fue elegido como mejor path basado en la política de enrutamiento en el
AS 64520.
El AS 64512 no aprende del segundo mejor path o de cualquier otro path del AS 64520, a menos que el mejor
path del AS 64520 llegue a estar indisponible.

Aun si el AS 64512 supiera otro path a través del AS 64520 y quiera utilizarlo, el AS 64520 no ratearía los
paquetes a lo largo de esa otra trayectoria ya que el AS 64520 selecciono 64520 64600 64700 como su mejor
trayectoria, y todos los routers del AS 64520 utilizan este path como cuestión de la política del BGP. BGP no
deja que un sistema autónomo envié trafico a un sistema autónomo vecino, pretendiendo que el trafico tome
una ruta diferente de la tomada por el trafico originado en el sistema autónomo vecino
Para alcanzar las redes en el AS 64700, el AS 64512 puede escoger utilizar el AS 64520 o este puede escoger
ir a través del path que el AS 64530 esta anunciando. El AS 64512 selecciona el mejor path a tomar basado en
sus propias políticas de enrutamiento.
6.1.9 Características de BGP

BGP es utilizado por ISPs a fin de que ellos
puedan comunicar e intercambiar paquetes.
Los ISPs tienen múltiples conexiones entre
ellos y acuerdan intercambiar
actualizaciones. BGP implementa el
acuerdo entre dos o más sistemas
autónomos. Figura 1.
Figura 1 – Cuando usar BGP
El inapropiado control y filtrado de las
actualizaciones BGP pueden potencialmente permitir que un sistema autónomo de afuera afecte al flujo de
trafico de tu sistema autónomo. Es importante conocer como BGP funciona y como configurarlos correctamente
para prevenir que esto ocurra.
Por ejemplo, si tú eres un cliente conectado al ISP-A y al ISP-B (por redundancia), y tú quieres implementar una
política de enrutamiento para asegurar que el ISP-A no envíe trafico al ISP-B a través de tu sistema autónomo.
Tú no quieres gastar apreciados recursos y ancho de banda dentro de tu sistema autónomo para rutear tráfico
de tus ISPs, pero tú quieres estar capacitado para recibir tráfico destinado a tu sistema autónomo a través de
cada ISP.
BGP no es siempre es la apropiada solución

para interconectar sistemas autónomos. En
la figura 2 por ejemplo, si únicamente existe
una trayectoria de salida, una ruta por
defecto es la más apropiada solución. En
este caso, BGP innecesariamente utilizaría
recursos de CPU y memoria del router. Figura 2 – Cuando no usar BGP
Si la política de enrutamiento que tú implementas en un sistema autónomo es consistente con la política en el

sistema autónomo del ISP, no es necesario o deseable configurar BGP en ese sistema autónomo.
BGP es categorizado como un protocolo de

vector distancia avanzado, pero este es
actualmente un protocolo de vector de
trayectoria (path – vector protocol). BGP es
muy diferente del estándar de protocolos de
vector distancia, tal como RIP. Figura 3
BGP utiliza TCP como su protocolo de

transporte, el cual provee una conexión Figura 3 – Características BGP
orientada a una entrega confiable. BGP
asume que esta comunicación es confiable: por consiguiente no tiene que implementar retransmisión o
mecanismos de recuperación de errores. BGP utiliza el puerto 179 de TCP. Dos routers utilizando BGP forman
una conexión TCP entre ellos e intercambian mensajes para abrir y confirmar los parámetros de la conexión.
Estos dos routers BGP son llamados routers pares (peer routers) o vecinos (neighbors).

Después de que la conexión es hecha, los BGP peers intercambian completamente las tablas de enrutamiento.
Sin embargo, dado que la conexión es confiable, los BGP peers subsecuentemente envían únicamente cambios
(en aumento o disparos de actualizaciones) después de esta.
Los enlaces confiables no requieren actualizaciones de enrutamiento periódicas; por consiguiente, los routers
en vez de eso utilizan disparos de actualizaciones.
BGP envía mensajes de keepalive, similares a los mensajes hello enviados por OSPF, IS-IS, y EIGRP.
BGP es el único protocolo de enrutamiento que utiliza TCP como su capa transporte. OSPF y EIGRP residen
directamente arriba de la capa IP, y RIPv1 y RIPv2 utilizan User Datagram Protocol (UDP) para su capa
transporte.
OSPF y EIGRP tiene sus propias funciones internas para asegurar que los paquetes de actualizaciones sean
explícitamente acusados su recepción. Estos protocolos utilizan una ventana de uno a uno, para los múltiples
paquetes de tal manera que el siguiente paquete no pueda ser enviado hasta que un acuse de recibo del primer
paquete actualizado es recibido. Este proceso puede ser muy ineficiente y causar problemas de latencia si
miles de paquetes actualizados deben ser intercambiados sobre enlaces seriales relativamente lentos. Sin
embargo, OSPF y EIGRP rara vez tienen miles de paquetes actualizados que enviar. EIGRP puede mantener
más de 10,000 redes, y la mayoría de organizaciones no tiene 10,000 subredes en la empresa.
BGP por el otro lado, tiene mas de 170,000 redes (y creciendo) en el Internet para anunciar, y usa TCP para
manejar las funciones de acuse de recibo. TCP utiliza una ventana dinámica, la cual permite 65,576 bytes que
es una ventaja antes de que se pare y se espere por un acuse de recibo. Por ejemplo, si paquetes de 1000
bytes están siendo enviados, BGP pararía y esperaría por un acuse de recibo únicamente cuando el paquete 65
no haya sido acusado, al momento de utilizar el máximo tamaño de la ventana.
TCP es diseñado para utilizar una ventana deslizante en la cual el receptor acuse el recibo en el punto medio
de la ventana enviante. Este método permite que cualquier aplicación TCP, tal como BGP, continúe con una
cadena de paquetes sin tener que parar y esperar como OSPF y EIGRP requería.
6.1.10 Base de datos BGP

Un router que corre BGP mantiene varias
tables para almacenar información BGP que
recibe y envía a otros routers. Estas tablas
incluyen una neighbor table, una BGP table
(también llamada forwarding database o
base de datos topológica) y una tabla de
enrutamiento IP. Figura 1
Para que BGP establezca una adyacencia,

tú debes configurar explícitamente cada Figura 1 – Bases de datos BGP
neighbor. BGP utiliza TCP como su
protocolo de trasporte (puerto 179). Esto forma una conexión TCP con cada uno de los neighbors configurados
y sigue el estado de estas relaciones periódicamente enviando un mensaje BGP TCP de keepalive.
Nota: BGP envía TCP keepalives cada 60 segundos por defecto.
Los routers que corren procesos de enrutamiento BGP son frecuentemente referidos como BGP speakers. Dos
BGP speakers que conforman una conexión TCP entre ellos para propósitos de intercambio de información de
enrutamiento son referidos como neighbors o peers.
Después de estableces una adyacencia, los neighbors intercambian las rutas BGP que están en su tabla de
enrutamiento IP. Cada router recolecta estas rutas de cada neighbor que exitosamente estableció una
adyacencia y entonces las pone dentro de la forwarding database de BGP. Todas las rutas que han sido
aprendidas de cada neighbor son puestas dentro de la forwarding database. La mejor ruta para cada red son

seleccionadas de la BGP forwarding database utilizando el proceso de selección de ruta BGP y entonces la
oferta a la tabla de enrutamiento IP.
Cada router compara la ruta BGP ofertada para cualquier otro posible path para esas redes, y la mejor ruta,
basada en la distancia administrativa, es instalada en la tabla de enrutamiento IP.
Las rutas EBGP (rutas BGP aprendidas de un sistema autónomo externos) tienen una distancia administrativa
de 20. Las rutas IBGP (rutas BGP aprendidas dentro del sistema autónomo) tienen una distancia administrativa
de 200.
6.1.11 Tipos de mensajes

Los 4 tipos de mensajes BGP son de
apertura, de keepalive, de actualización, y
de notificación. Figura 1
Después de que la conexión TCP es

establecida, el primer mensaje enviado por
cada lado es un open message. Si el open
message es aceptable, el lado que recibe el
mensaje envía un mensaje keepalive
confirmando el open message. Después de
que el lado de recepción confirme el open Figura 1 – Tipos de mensajes BGP
message y establezca la conexión BGP,
BGP peers pueden intercambiar cualquier mensaje de la
actualización, keepalive, y mensajes de notificación.
Los BGP peers intercambian inicialmente sus tablas de

enrutamiento completamente. Actualizaciones
incrementadas son enviadas únicamente después de
que la topología cambia en la red. Los BGP peers
envían mensajes de keepalive para asegurarse de que Figura 2 – Como trabaja BGP
todavía existe la conexión entre los BGP peers. Ellos
envían paquetes de notificación en
respuesta a errores o a condiciones
especiales.
Aquí hay mas detalles acerca de los

diferentes tipos de mensajes BGP:
• Open message: Un mensaje de
apertura que incluye la siguiente
información :
o Número de Versión: Las
más alta versión común que
ambos routers soportan es
la utilizada. Todos las
implementaciones BGP de
hoy utilizan BGP4
o AS number: Es el numero
de AS del router local. El
peer router verifica esta
información. Si no es un
numero de AS esperado, la
sesión BGP es destruida
o Holf time: Es el número
máximo de segundos que
pueden transcurrir entre
sucesivos mensajes de Figura 3 – Códigos de errores de mesajes de notificación BGP
keepalive y de actualización del remitente. Sobre el recibo de un open message o mensaje de
apertura, el router calcula el valor del hold timer utilizando cualquiera que sea más pequeño: Su
hold timer configurado o el hold timer que fue recibido en el open message.
o BGP router ID: El campo de 32 bits indica el BGP ID del remitente. El ID del BGP es un IP
address que se asigna al router y este es determinado por el startup El ID del router BGP se
elige de la misma forma que el ID de router OSPF es escogido: Esta es la más alta dirección IP
activa, a menos que exista un interfaz de loopback con una dirección IP. En este caso, el ID del
router es la dirección IP más alta del loopback. El router ID puede también ser configurada
estáticamente.
o Parámetros opcionales: Estos parámetros son tipo, longitud, y el valor (TLV) - codificado. Un
ejemplo de un parámetro opcional es la autentificación de una sesión.
• Mensaje de Keepalive: Los mensajes keepalive de BGP se intercambian entre BGP peers
frecuentemente a menudo lo suficiente para mantener que el hold timer expire. Si la negociación del
intervalo del hold time es 0, periódicos mensajes de keepalive no son enviados. Un mensaje keepalive
consiste en solamente un mensaje de cabecera
• Mensaje de actualización: Un mensaje de actualización BGP tiene información sobre un único path;
múltiples paths requieren múltiples mensajes de actualización. Todas los atributos en un mensaje de
actualización se refieren a ese path, y las redes son las que se pueden alcanzar a través de el. Un
mensaje de actualización puede incluir siguientes campos
o Rutas retiradas: Esta lista muestra los prefijos de direcciones IP que son retiradas del servicio,
si las hubieran. Figura 2
o Atributos de la trayectoria (path): Estas cualidades incluyen el AS path, origen, preferencia
local, y así sucesivamente (según lo descrito más adelante en este módulo). Cada cualidad de
la trayectoria incluye la cualidad TLV. El tipo de atributo consiste del atributo de banderas,
seguidas por el tipo de atributo del codigo.
o Información de confiabilidad de la capa red: Este campo contiene una lista de los prefijos de
direcciones IP que son accesibles por esta trayectoria
• Mensaje de notificacion: Un mensaje de notificacion BGP es enviado cuando se detecta una
condición de error. La conexión del BGP es cerrada inmediatamente después que se envía este. Los
mensajes de notificación incluyen un código de error, un subcode de error, y los datos relacionados con
el error. La figura 3 muestra el campo para los códigos de error que se pueden utilizar para localizar
averías de conexiones BGP.
6.2 EBGP y IBGP

6.2.1 Relaciones de Vecinos BGP
Ningún router puede manejar cada conexión con todas los routers. Diez mil routers corren BGP y están
conectados con el Internet, representando más de 21.000 sistemas autónomos.
Un router BGP forma una relación vecina

directa con un número limitado de otros
routers BGP. A través de estos BGP
neighbors, un router BGP aprende las
trayectorias a través del Internet para
alcanzar cualquier red anunciada. Cualquier
router que corra BGP es conocido como
BGP speaker.
El término “BGP peer” tiene un significado

específico: un BGP speaker es configurado
para formar una relación vecina con otros
BGP speaker con el fin de directamente
intercambiar la información de enrutamiento
del BGP con cada otro de ellos. Un BGP
speaker tiene un número limitado de BGP
neighbors con quienes es peers y forma una Figura 1 – Peers = vecino

relación basada en TCP Figura 1
Los BGP peers son también conocidos como BGP neighbors y pueden ser internos o externos al Autónomos
Sistema.
Un BGP peer debe ser configurado con el comando neighbor. El administrador instruye al BGP speaker para
establecer una relación con la dirección enlistada en el comando neighbor vecino y para intercambiar las
actualizaciones del enrutamiento del BGP con ese vecino.
6.2.2 Estableciendo una conexión entre BGP Neighbors externos

Hay que recordar que cuando BGP está
corriendo entre los routers en diversos
sistemas autónomos, este es llamado
EBGP. Generalmente, los routers que
corren EBGP están directamente
conectados el uno al otro. Figura 1
Para que dos routers intercambien

actualizaciones de enrutamiento, la capa de
transporte confiable TCP en cada lado,
debe exitosamente pasar el TCP three-way
handshake antes de que la sesión del BGP
pueda ser establecida. Por lo tanto, la
dirección IP usada en el comando neighbor
del BGP debe ser accesible sin utilizar un
IGP, que puede ser logrado señalando en
una dirección que sea accesible a través de
una red directamente conectada o usando
rutas estáticas a esa dirección IP
Figura 1 – BGP Externo
6.2.3 Estableciendo una conexión entre BGP Neighbors internos

Cuando el BGP funciona entre routers dentro
del mismo sistema autónomo, se llama IBGP.
IBGP intercambian información BGP de modo
que todos los BGP speakers tengan la misma
información de enrutamiento de BGP sobre
sistemas autónomos del exterior.
Debido a que múltiples paths generalmente

existen dentro de un sistema autónomo para
alcanzar las otros IBGP routers, una dirección
de loopback es usualmente utilizada en el
comando neighbor de BGP para establecer
las sesiones de IBGP.
Por ejemplo, cuando múltiples routers en un

sistema autónomo están corriendo BGP,
intercambian actualizaciones de enrutamiento
BGP el uno con el otro. En la figura 1, los
routers A, C, y D aprenden las trayectorias a
los sistemas autónomos externos de sus Figura 1 – BGP Interno
vecinos respectivos de EBGP (routers Z, Y, y
X).

Si el link entre los routers D y Y se cae, el router D debe aprender las rutas nuevas a los sistemas autónomos
externos. Otros routers BGP dentro del AS 65500 que utilizaban el router D para conseguir a las redes externas
deben también ser informados que el path a través del router D no está disponible. Estos BGP routers dentro
del AS 65500 necesitan tener path alternativos a través de los routers A y C en tabla BGP forwarding database.
Tú debes instalar sesiones de IBGP entre todas los routers BGP dentro del AS 65500 de modo que cada router
dentro del sistema autónomo aprenda sobre las trayectorias a las redes externas vía IBGP
6.2.4 Sincronización dentro de un sistema autónomo

El BGP fue pensado originalmente para funcionar a lo largo de los bordes un sistema autónomo con los routers
en el medio del sistema autónomo ignorando los detalles de BGP (por ello el nombre Border Gateway Protocol).
Un sistema autónomo de tránsito, tal como el de la figura 1, es un sistema autónomo que enruta tráfico de un
sistema autónomo externo a otro sistema autónomo externo. Típicamente, los sistemas autónomos de tránsito
son los ISPs.
Todas los routers en un sistema

autónomo de transito deben tener un
completo conocimiento de las rutas
externas. Teóricamente, una manera
para alcanzar esta meta es redistribuir
las rutas del BGP dentro de un IGP en
los routers de borde. Sin embargo, hay
problemas asociados a este método.
Puesto que la tabla de enrutamiento
actual del Internet es muy grande,
redistribuir todas las rutas del BGP en
un IGP no es un método escalable para
los routers interiores dentro de un
sistema autónomo para aprender sobre
las redes externas.
Otro método que tú puedes utilizar es Figura 1 – IBGP en transito en AS (ISP)

correr IBGP dentro del sistema
autónomo
Por definición, el comportamiento por defecto de BGP requiere que este debe ser sincronizado con el IGP antes
de que el BGP pueda anunciar las rutas de tránsito a los sistemas autónomos externos. La regla de
sincronización de BGP indica que un router BGP no debe anunciar destinos a vecinos externos, aprendidas de
IBGP neighbors, a menos que estos destinos también se sepan vía un IGP. Si un router sabe sobre estos
destinos vía un IGP, este asume que la ruta se ha propagado ya dentro del Autónomos Sistema, y la
confiabilidad interna es asegurada.
6.2.5 IBGP en un No transitado sistema autónomo

Un sistema autónomo no transitado, tal como en una organización que es multihoming con dos ISPs, no pasa
las rutas entre los ISPs. Sin embargo, los BGP routers dentro del sistema autónomo aun requieren
conocimiento de todas las rutas BGP pasadas al sistema autónomo para tomar decisiones apropiadas de
enrutamiento
BGP no trabaja de la misma manera que los IGPs. Ya que los diseñadores de BGP no podrían garantizar que
un sistema autónomo podría correr BGP en todos los routers, un método tuvo que ser desarrollado para
asegurarse que los IBGP speakers puedan pasar las actualizaciones de uno a otro mientras que se aseguraban
de que no existirían lazos de enrutamiento.
Para evitar lazos de enrutamiento dentro de un Autónomos Sistema, BGP especifica que las rutas aprendidas
con IBGP nunca sean propagadas a otros IBGP peers.

El comando neighbor habilita las actualizaciones de BGP entre BGP speakears. Por defecto, cada BGP
speakear es asumido que tiene una declaración vecina para el resto de los IBGP speakers en el Autónomos
Sistema, que se conoce como acoplamiento completo IBGP (full mesh IBGP). Los routers no tienen que estar
directamente para estar en full mesh.
Si el sending IBGP neighbor no está en full mesh con cada IBGP router, los router que no son peering con este
router tienen diferentes tablas de enrutamiento de los routers que sin son peering con este. Las inconsistentes
tablas de enrutamiento pueden causar lazos de enrutamiento o un agujero negro de enrutamiento (routing black
hole), ya que la suposición por defecto de todos los routers que corren BGP dentro de un sistema autónomo es
que cada router BGP está intercambiando información IBGP directamente con todos los otros routers BGP en el
Autónomos Sistema.
Si todos los IBGP neighbors están fulmente mallados (fully mesh), cuando un cambio es recibido de un sistema
autónomo externo, el BGP router para el sistema autónomo local es responsable de informar a los otros IBGP
neighbors de el cambio. Los IBGP neighbors que reciben esta actualización no la envían a cualquier otro IBGP
neighbor, porque asumen que el sending IBGP neighbor esta fulgente mallado con el resto de los IBGP
speakers y han enviado a cada IBGP neighbor la actualización.
Example: IBGP Parcial Mesh

La Figura 1 muestra la conducta de una
actualización IBGP en un ambiente vecino
parcialmente mallado
Si todos los vecinos de IBGP están

endentados completamente, cuando un
cambio se recibe de un Autónomos Sistema
externo, la rebajadora del BGP para el Figura 2 – Parcial mesh IBGP
Autónomos Sistema local es responsable de
informar a el resto de los vecinos de IBGP el cambio. Los vecinos de IBGP que reciben esta actualización no la
envían a cualquier otro vecino de IBGP, porque asumen que el vecino de IBGP que envía está endentado
completamente con el resto de los altavoces de IBGP y han enviado cada vecino de IBGP la actualización.
El router B recibe una actualización BGP del router A. El router B tiene dos IBGP neighbors, el router C y el
router D, pero no tiene una relación vecina IBGP con el router E. El router C y el D aprenden acerca de las
redes que son añadidas o borradas detrás del router B. Aun si el router el router C y D tienen sesiones vecinas
IBGP con el router E, asumen que el sistema autónomo está fulmente mallado por IBGP y no repliegan la
actualización y no la envían al router E.
Enviar una actualización IBGP al router E es la responsabilidad del router B, porque es el router con
conocimiento de primera mano de las redes dentro y detrás del AS 65101. El router E no aprende ninguna red a
través del router B y no utiliza el router B para alcanzar ninguna red dentro del AS 65101 u otros sistemas
autónomos detrás del AS 65101.
Example: IBGP Full Mesh

La figura 2 muestra un fully mesh IBGP.
Cuando el router B recibe una actualización
del router A, este actualiza a todos sus tres
IBGP peers: routers C, D, y E.
El IGP enjuta el segmento del TCP que

contiene la actualización BGP del router A
al router E ya que los routers no están
directamente conectados. La actualización
se envía una vez a cada neighbor y no es Figura 2 – Full mesh IBGP
duplicada por ningún otro neighbor de
IBGP, lo cual reduce el tráfico innecesario.

En IBGP completamente mallado, cada router asume que cada otro router interno tiene una declaración vecina
de esos puntos a cada IBGP neighbor.
TCP y Full Mesh (full malla)

TCP fue seleccionado como la capa de transporte para el BGP ya que puede mover volúmenes de datos
grandes confiablemente. Con la muy larga tabla de enrutamiento de Internet cambiando constantemente, TCP
fue determinado para ser la mejor solución para el windowing y la confiabilidad, contrariamente a desarrollar
una capacidad de BGP de windowing de uno a uno como OSPF o EIGRP.
Debido a que cada router IBGP necesita enviar las rutas a todos los otros neighbors de IBGP en el mismo
sistema autónomo (de modo que todos tengan un cuadro completo de las rutas enviadas al sistema autónomo),
deben utilizar sesiones BGP (TCP) completamente malladas. Recordar, que BGP usa TCP asegura la entrega
confiable de paquetes, por lo tanto, ellos no puede difundir o hacer multicast de las rutas a otros neighbors de
IBGP.
Cuando todos los routers que corren BGP en un sistema autónomo están completamente mallados y tienen la
misma base de datos como resultado de una política constante de enrutamiento, ellos pueden aplicar la misma
fórmula de selección de trayectoria. Los resultados de la selección de la trayectoria (path) son por lo tanto
uniformes a través del sistema autónomo, el cual asegura ningún lazo de enrutamiento y una política constante
para salir e incorporar al sistema autónomo.
6.2.6 Problemas de enrutamiento en un sistema autónomo de transito

Todas los routers en el path entre los
neighbors de IBGP, conocidos como el
camino de transito (transit path), deben
también estar corriendo BGP, como se
muestra en la figura 1.
En este ejemplo, los routers A, B, E, y F son

los únicos que están corriendo BGP. El
router B tiene una declaración vecina EBGP
para el router A y una declaración vecina
IBGP para el router E. El router E tiene una
declaración vecina EBGP para el router F y
una declaración vecina IBGP para el router
B. Los routers C y D no están corriendo
BGP. Los routers B, C, D, y E están Figura 1 – Problemas de enrutamiento con BGP
corriendo OSPF como su IGP.
La red 10.0.0.0 es poseída por el AS 65101 y es anunciada al router B vía una sesión EBGP. El router B la
anuncia al router E con una sesión IBGP. Los routers C y D nunca aprenden sobre esta red, debido a que este
no es redistribuido en el protocolo de enrutamiento local (OSPF), y en los routers C y D no está corriendo BGP.
Si el router E anuncia esta red al router F en el AS 65103, y la router F comienza a enviar paquetes a la red
10.0.0.0 a través del AS 65102, el router E enviaría los paquetes a BGP peer, router B. Sin embargo para
conseguir al router B, los paquetes deben pasar a través del router C o D, pero estos routers no tienen una
entrada en sus tablas de enrutamiento para la red 10.0.0.0. De tal manera, cuando el router E envía paquetes a
una dirección destino en la red 10.0.0.0 al router C o al D, estos routers desechan los paquetes.
Aunque los routers C y D tienen un puntero a ruta por defecto a los puntos de salida del sistema autónomo
(routers B y E), hay una buena oportunidad que cuando el router E envíe un paquete para la red 10.0.0.0 al
router C o D, estos routers puedan enviarla de nuevo al router E, el cual remite otra vez al router C o D,
causando un lazo de enrutamiento. Para solucionar este problema, BGP debe ser implementado en los routers
C y D. En otras palabras, todos los routers en la trayectoria de tránsito dentro del sistema autónomo deben
estar corriendo BGP, y las sesiones IBGP deben ser completamente malladas.

6.3 Configurando BGP

6.3.1 Configuración Básica de BGP
La sintaxis de los comandos básicos de la
configuración BGP es similar a la sintaxis para
configurar protocolos de enrutamiento interno.
Sin embargo, hay diferencias significativa en
cómo funciona BGP.
Use el comando: router bgp autonomous-

system para identificar e la router de
identificar al router de cualquier subsecuente
subcomando perteneciente a este proceso de
enrutamiento. Figura 1. Este comando
también identifica el sistema autónomo local
en el cual este router pertenece. El router
necesita ser informado del sistema autónomo Figura 1 – Comandos BGP
de modo que pueda determinarse si los BGP
neighbors a ser configurados después son
IBGP neighbors o EBGP La figura 2 muestra
el parámetro para el comando router bgp
Figura 2 – Parámetro del comando router bgp
El comando router bgp solo no activa BGP en
un router. Se debe al menos ingresar un subcomando para activar el proceso BGP
6.3.2 Activar una sesión BGP

Use el comando neighbor ip-address
remote-as autonomous-system para
activar una sesión BGP para neighbors
routers externos e internos. Figura 1. Este
comando identifica un peer router con el
cual el router local establezca una sesión.
La figura 2 muestra los parámetros para
este comando.
Nota: Un peer group es un grupo de BGP

neighbors en el cual todos tienen las
mismas políticas de actualización. Peers
groups son descritos mas adelante en esta
lección Figura 1 – Comando BGP neighbor remote-as
La dirección es la dirección destino para

todos los paquetes BGP que van a este
neighbor router. La dirección debe ser
accesible, ya que el BGP procura establecer
una sesión TCP e intercambiar
actualizaciones BGP con los dispositivos en
esta dirección IP. Figura 2 – Parámetros del comando neighbor remote-as
El número del sistema autónomo identifica si este neighbor es un EBGP neighbor o IBGP. Si el número es igual
que el número del sistema autónomo para este router, el vecino es un IBGP neighbor, y la dirección IP enlistada
en el comando neighbor no tiene que estar directamente conectada. Si el número es diferente, el vecino es un
EBGP, y la dirección en el comando neighbor debe estar conectada directamente por defecto
En la figura 3, el router A en el AS 65101 tiene dos declaraciones vecinas. El router A sabe que el router C
(neighbor 192.168.1.1 remote-as 65102) es un neighbor externo, ya que el AS 65102 en la declaración vecina
para el router C no empareja el número del sistema autónomo del router A, el cual esta en el AS 65101. El
router A puede alcanzar al AS 65102 vía
192.168.1.1, el cual esta directamente
conectado al router A.
El Neighbor 10.2.2.2 (router B) está en el

mismo sistema autónomo que el router A.
La segunda declaración vecina sobre el
router A define al router B como IBGP
neighbor.
El AS 65101 corre EIGRP entre todos los

routers internos. El router A tiene una
trayectoria EIGRP para alcanzar la
dirección IP 10.2.2.2. Como un IBGP
neighbor, el router B puede estar múltiples
routers lejos del router A.
Figura 3 – Ejemplo: Comando BGP neighbor
6.3.3 Shutting Down a un BGP neighbor

Use el comando neighbor ip-address
shutdown para administrativamente bajar y
rehabilitar un BGP neighbor Figura 1
Si tú llevas a cabo cambiar mayores

políticas a un router vecino y cambias
múltiples parámetros, tú debes
administrativamente bajar el router vecino, y
después traer de regreso el router vecino
con el comando l respaldo vecino de la
router con el comando no neighbor ip- Figura 1 – Comando BGP neighbor shutdown
address shutdown
6.3.4 Consideraciones de configuración de BGP

La declaración vecina de BGP informa al router de la dirección IP destino para cada paquete de actualización.
El router debe decidir cual dirección IP usar como dirección ip origen en la actualización de enrutamiento BGP.
Figura 1
Cuando un router crea un paquete BGP

para un vecino, este comprueba la tabla de
enrutamiento para la red destino para
alcanzar a ese neighbor. La dirección IP es
de la interfaz de salida, como la tabla de
enrutamiento indica, se utiliza como
dirección IP origen del paquete BGP.
Esta dirección Ip origen debe emparejar la

dirección en la correspondiente declaración
vecina en el otro router. Si no, los routers no Figura 1 – Problemas BGP con dirección IP origen
serán BGP peers ya que no pueden
establecer una sesión BGP.

6.3.5 IBGP Peering Issue

Para establecer la sesión IBGP entre el router A y
D, como se muestra en la figura 1, ¿cual dirección ip
vecina debería ser usada?
El problema es el siguiente. Si el router D utiliza

neighbor 10.3.3.1 remote-as 65102, pero el router
A esta enviando paquetes BGP para el router D a
través del router B, la dirección IP origen es la
10.1.1.1.
Cuando el router D recibe este paquete a través del

router B, este no reconoce este paquete BGP ya
que la 10.1.1.1 no fue configurada como un
neighbor del router D. Por consiguiente la sesión
IBGP entre el router A y el D no puede ser
establecida
Una solución es establecer una sesión IBGP usando

un interfaz de loopback cuando hay trayectorias Figura 1 – Ejemplo: BGP peering issue
múltiples entre los IBGP neighbors.
6.3.6 Comando update-source de BGP neighbors

La opción update-source del comando
neighbor elimina la dirección IP de origen
por defecto utilizada para los paquetes
BGP. Es necesario decir al router qué
dirección IP utilizar como dirección origen
para todos los paquetes BGP si tu deseas
utilizar una interfaz de loopback en vez de la
interfaz física. Figura 1
Si tú no utilizas la opción update-source,

un aviso yendo a un neighbor utiliza la
dirección IP de la interfaz existente como
dirección origen para un paquete.
Cuando un router crea un paquete, si este

es una actualización de enrutamiento, un Figura 1 – Comando BGP neighbor update-source
ping, o algún otro tipo de paquete IP, el
router busca la dirección destino en la tabla de enrutamiento. La tabla de enrutamiento enumera la apropiada
interfaz para conseguir la dirección destino. La dirección de esta interfaz de salida es utilizada como la dirección
origen de estos paquetes por defecto.
Considerar qué sucedería si un router vecino utiliza la dirección del interfaz de loopback en el comando
neighbor para este router, pero el otro router vecino no utiliza el comando neighbor update-source. Cuando
el router vecino recibe un paquete de actualización y mira la dirección origen del paquete, ve que no tiene
ninguna relación vecina con esa dirección origen, así que desecha el paquete.
El BGP no acepta actualizaciones no solicitadas. Debe estar enterado de cada router vecino y tener una
declaración vecina para él.
Las trayectorias múltiples pueden existir para alcanzar a cada vecino cuando esta en peering con un router
IBGP neighbor. Si el router BGP está utilizando una dirección vecina que es asignada para un interfaz
específico en otro router, y que la interfaz se caiga, el router que señala a esta dirección pierde su sesión BGP
con ese vecino.

Si el router mira con fijeza (peers) con la interfaz de loopback en vez de otro router, la interfaz de loopback esta
siempre disponible mientras el router no falle. Este arreglo de peering agrega viveza a las sesiones IBGP ya
que los routers no se atan en una interfaz física, la cual puede caerse por un sin numero de razones.
Para mirar con fijeza con el loopback de otro vecino interno, el primer router señala la declaración vecina en la
dirección de loopback del otro vecino interno. Asegúrese de que ambos routers tengan una ruta a la dirección
de loopback del otro vecino en su tabla de enrutamiento. También asegúrese de que ambos routers estén
anunciando sus direcciones de loopback en su protocolo de enrutamiento local.
Ejemplo: Utilizando una dirección de loopback con el BGP

En la figura 2. El router B tiene
al router A como EBGP
neighbor. La única dirección
accesible para el router B a
utilizar para una dirección
vecina en BGP es la dirección
directamente conectada
172.16.1.1. El router B tiene
trayectorias múltiples para
alcanzar la router C, IBGP
neighbor
Todas las redes, incluyendo la

red IP para la interfaz de
loopback del router C, pueden
Figura 2 – Ejemplo: Usando direcciones loopback en BGP
ser alcanzadas del router B. El
router B puede alcanzar estas redes porque los routers B y C intercambian actualizaciones de EIGRP; los
routers B y A no intercambian actualizaciones de EIGRP.
La relación vecina entre los routers B y C no se ata a un interfaz físico porque el router B mira con fijeza
(peers)con la interfaz de loopback en el router C y utiliza su dirección de loopback como la dirección IP origen, y
viceversa. Si el router B hacia peer con la 10.1.1.2 en el router C y esta interfase se cayera, la relación vecina
de BGP también se caería.
El comando neighbor update-source se debe utilizar en ambos routers. Si el router B apunta a la dirección de
loopback 3.3.3.3 del router C, y el router C apunta a la dirección de loopback 2.2.2.2 del router B, y ninguna
utiliza el comando neighbor update-source, la sesión BGP entre estos routers no comienza.
El router B enviaría un paquete abierto BGP al router C con la dirección origen siendo la 10.1.1.1 o la 10.2.2.1.
El router C revisaría la dirección origen y procuraría emparejarlo contra su lista de neighbors conocidos. El
router C no encontraría un emparejamiento y no respondería al mensaje abierto (open message) del router B.
6.3.7 EBGP Peering Issue

Cuando un router EBGP es peering con un
vecino externo, la única dirección que
puede alcanzar sin la configuración
adicional es la de la interfaz que está
directamente conectada con ése router
EBGP. Recordar que la información de
enrutamiento interna no está intercambiada
con peers externos. Por lo tanto, el router
tiene que señalar a una dirección
directamente conectada para ese vecino
Figura 1 – Comando BGP neighbor ebgp-multihop
externo.

Si una interfaz de loopback se utiliza en vez del interfaz directamente conectado, se requiere la configuración
adicional. Para permitir que el router acepte y ensaye conexiones BGP a pares (peers) externos que residen en
las redes que no están directamente conectadas, tu debes configurar el comando de configuración en el router
neighbor ip-address ebgp-multihop [ttl]. La Figura 1 y la figura 2 muestran los parámetros de este comando
Los EBGP peers están usualmente

solamente a un salto lejos el uno del otro. El
comando neighbor ebgp-multihop
incremente el valor de salto por defecto
para permitir rutas a la dirección de
loopback EBGP con un valor de TTL mas Figura 2 – Parámetros del comando neighbor ebgp-multihop
grande que 1. Si un valor TTL no es
especificado, el router utiliza 255 (por
defecto).
Este comando es necesario cuando existen

trayectorias redundantes entre EBGP
neighbors.
Ejemplo: Comando ebgp-multihop

En la figura 3, el router A en el AS 65102
tiene dos trayectorias al router B en el AS
65101. Si el router A utiliza una sola
declaración vecina y apunta a la
192.168.1.18 en el router B del AS 65101 y
ese link se cae, no hay sesión BGP entre
estos sistemas autónomos.
Consecuentemente, ningún paquete pasa
de un sistema autónomo al siguiente, aun Figura 3 – Ejemplo: Comando ebgp-multihop
cuando el otro link existe. Si el router A en
lugar utiliza dos declaraciones vecinas que apuntan a la 192.168.1.18 y a la 192.168.1.34 en el router B, se
soluciona parcialmente el problema. Sin embargo, cada actualización BGP que el router A reciba es enviada al
router B doblemente ya que hay dos declaraciones vecinas.
Como se muestra en la figura, el router e la figura, el router A mas bien apunta a la dirección de loopback del
router B y viceversa, y cada router usa esta dirección de loopback como la dirección IP de origen para esta
actualizaciones BGP. Debido a que IGP no es utilizado entre los sistemas autónomos, ningún router puede
alcanzar el loopback del otro router sin asistencia.
Cada router necesita utilizar dos rutas estáticas para informar al BGP de las trayectorias disponibles para
alcanzar la dirección de loopback del otra router. Una dirección vecina de EBGP debe estar directamente
conectada por defecto. El comando neighbor ebgp-multihop se debe utilizar para cambiar el ajuste por
defecto de BGP y para informar al BGP que esta dirección IP esta a mas de un salto lejos. En la figura, el
comando utilizado en el router A informa a BGP que dirección vecina de 1.1.1.1 esta a dos saltos lejos.
Nota: BGP no esta diseñado para realizar balanceo de carga. Las trayectorias se eligen debido a la política, no
se basan en el ancho de banda. BGP elige solamente una sola mejor trayectoria. Usar las direcciones de
loopback y el comando neighbor ebgp-multihop como se muestra en este ejemplo permite balanceo de carga
y redundancia a través de las dos trayectorias entre los sistemas autónomos.
6.3.8 Comportamiento del Next Hop

La manera en la cual el BGP establece una relación de IBGP es muy diferente a la manera que los IGPs se
comportan. El método que BGP utiliza que denota su dirección del next hop es también muy diferente.
BGP informa al siguiente sistema autónomo sobre las trayectorias a otros sistemas autónomos y las redes que
esos otros sistemas autónomos poseen. BGP, como IGPs, es un protocolo de enrutamiento del salto-por-salto.
Sin embargo, diferente de IGPs, BGP rutea de sistema autónomo a sistema autónomo, y el next hop por
defecto es el siguiente sistema autónomo. Un router IBGP neighbor que aprende sobre una red fuera de su
sistema autónomo ve, como la dirección de next hop, el punto de entrada para los siguientes sistemas
autónomos a lo largo de la trayectoria para
alcanzar la red distante. Figura 1
Para EBGP, el next hop por defecto es la
dirección IP del router vecino que envía la
actualización.
Para IBGP, el protocolo BGP afirma que el

next hop anunciado por EBGP debería ser
llevado dentro del IBGP
Figura 1 – Comportamiento del Next-hop
Ejemplo: Comportamiento de Next-Hop
En la figura 2, el router A anuncia la red
172.16.0.0 al router B con un next hop de
10.10.10.3. El Router B anuncia la red
172.20.0.0 al router A con un next hop de
10.10.10.1.
Para IBGP, el estado del protocolo BGP

indica que el next hop anunciado por EBGP
debe ser llevado dentro del IBGP. Debido a
esta regla, el router B anuncia la 172.16.0.0
a su IBGP peer router C con un next hop de
10.10.10.3, la dirección del router A. El
router C sabe que el next hop para alcanzar
la 172.16.0.0 es la 10.10.10.3, y no la
172.20.10.1, como puede ser esperado.
Por lo tanto, es muy importante que el

router C sepa alcanzar la subred
10.10.10.0, a través de un IGP o de una
ruta estática. Si no, el router C elimina los Figura 2 – Ejemplo: Comportamiento del Next-hop
paquetes destinados para la red 172.16.0.0
porque no puede conseguir a la dirección del next hop para esa red.
Un router IBGP neighbor realiza operaciones de búsqueda recurrentes para descubrir cómo alcanzar una
dirección del next hop del BGP usando sus entradas de IGP en la tabla de enrutamiento. Por ejemplo, el router
C aprende en una actualización de BGP sobre la red 172.16.0.0/16 de una ruta de origen de 172.20.10.1 (router
B), con un next hop de 10.10.10.3 (router A). El router C instala la ruta a la 172.16.0.0/16 en la tabla de
enrutamiento con un next hop de 10.10.10.3. El router B debe anunciar la red 10.10.10.0/24 usando su IGP
para el router C de modo que el router C pueda instalar esa ruta en su tabla de enrutamiento con un next hop
de 172.20.10.1.
Un IGP utiliza la dirección IP de origen de una actualización de enrutamiento (ruta origen) como la dirección del
next hop, mientras que BGP utiliza un campo separado por red para registrar la dirección del next hop. Si el
router C tiene un paquete para enviar a la 172.16.100.1, este busca la red en la tabla de enrutamiento y
encuentra una ruta BGP con un next hop de 10.10.10.3. Ya que este es una entrada BGP, el router C termina
una recurrente búsqueda en la tabla de enrutamiento para una trayectoria a la red 10.10.10.3. El IGP ha
colocado una ruta a la red 10.10.10.0 en la tabla de enrutamiento con un next hop (next hop) de 172.20.10.1,
así que el router C remite el paquete destinado para la 172.16.100.1 a la 172.20.10.1.
6.3.9 Comando BGP neighbor next-hop-self

A veces es necesario eliminar el comportamiento por defecto del next - hop y forzar esto a anunciar a si mismo
como una dirección de next hop para las rutas enviadas a un router vecino.

El comando neighbor next-hop-self fuerza al BGP a utilizar su propia dirección IP como la dirección del next
hop para cada red que anuncie a su IBGP neighbor, en vez de dejar que el protocolo elija la dirección del next
hop. Figura 1.
A veces esto es necesario para pasar por

encima del funcionamiento por defecto del
next hop en el router y forzar a que este se
anuncie a si mismo como dirección de next
hop para las rutas enviadas a un router
vecino.
Un protocolo interno, tal como RIP, EIGRP,
u OSPF, utiliza siempre la dirección de la
actualización de enrutamiento como su Figura 1 – Comando BGP neighbor next-hop-self
dirección de next hop para cada red que se
ponga en la tabla de enrutamiento. El
comando neighbor next-hop-self hace que
BGP utilice la dirección IP origen como
dirección del next hop para cada red Figura 2 – Parámetros del comando neighbor next-hop-self
anunciada. La figura 2 exhibe los
parámetros del comando.
Ejemplo: Configuración de next-hop-self

En la figura 3, el router B ve la ruta
192.168.1.0 aprendida del AS 65100 que
tiene un next hop de 172.16.1.1, el cual es
la entrada al AS 65100 para el router B.
Cuando el router B anuncia esa red a sus
IBGP neighbors en el AS 65101, el ajuste
por defecto de BGP es anunciar que el next
hop para alcanzar esta red es la entrada al
AS a 65100 (172.16.1.1). Esto trabaja de
esta manera por defecto porque el BGP es
un protocolo de enrutamiento AS –by –AS
Para que cualquier router BGP alcance

redes en el o detrás del AS 65100, estos Figura 3 – Ejemplo: Configuración next-hop self
routers necesitan alcanzar la red
172.16.1.1. Por lo tanto, usted necesita
incluir la red que representa 172.16.1.1 en
el protocolo interno de enrutamiento.
En este ejemplo, sin embargo, el router B

utiliza el comando neighbor next-hop-self
para cambiar los ajustes de BGP por
defecto. Una vez que se dé este comando,
el router B anuncia un next hop de 2.2.2.2
(la dirección IP de la interfaz del loopback) a
su IBGP neighbor, ya que este es la
dirección ip origen de la actualización de
enrutamiento a su IBGP neighbor (fijar con
el comando neighbor update-source).
Cuando el router C anuncia las redes que

están en el o detrás del AS 65101 a los
EBGP neighbors, tales como el router D en
el AS 65102, el router C, por defecto, utiliza Figura 4 – Ejemplo: next hop en una red multiacceso
su dirección de interfaz de salida

192.168.1.2 como la dirección del next hop. Esta dirección es también la dirección por defecto del next hop para
el router D para alcanzar cualquier red en el o detrás del AS 65101.
Al funcionar BGP sobre una red multi acceso tal como Ethernet, un router BGP ajusta la dirección de next hop
(next-hop) para evitar insertar saltos adicionales en la red. Esta característica a veces se llama un next hop de
tercera persona (third-party next hop)
Ejemplo: Next Hop en una red multiacceso

Según lo muestra la figura 4, los routers B y C en el AS 65000 están corriendo IGP de modo que el router B
pueda alcanzar la red 172.30.0.0 vía 10.10.10.2. El router B también corre EBGP con el router A. Cuando el
router B envía una actualización BGP al router A con respecto a la 172. 30.0.0, utiliza la red 10.10.10.2 como
next hop y no su propia dirección IP (10.10.10.1). Ya que la red entre los tres routers es una red multiacceso, el
router A utiliza al router C como un next hop para alcanzar a la 172.30.0.0, en vez de que haga un salto
adicional vía la router B.
La dirección del next hop tiene más sentido cuando tú revisas esta desde la perspectiva de un ISP. Un ISP
grande en un punto de peering publico que tiene múltiples routers en peering con diversos neighbors routers.
No es posible que un router mire con fijeza a cada router vecino en los puntos de peering públicos importantes.
Por ejemplo, en la figura, el router B puede mirar con fijeza al AS 64520, y el router C puede mirar con fijeza con
el AS 64600.
El router A debe tener una trayectoria a través del AS 65000 para conseguir a las redes en el y detrás del AS
64600. El router A tiene una relación vecina solamente con el router B en el del AS 65000. Sin embargo, el
router B no maneja el tráfico que va al AS 64600. La trayectoria preferida del router B para el AS 64600 está a
través del router C, 10.10.10.2. El router B debe anunciar las redes para el AS 64600 para el router A, 10
10.10.3. El router B notifica que los routers A y C están en la misma subred, así que el router B informa al router
A para que instale las redes del AS 64600 con un next hop de 10.10.10.2 y no 10.10.10.1.
6.3.10 Inyección de Información de enrutamiento dentro de BGP

Utilice el comando network network-
number para permitir que BGP anuncie una
red si esta presente en la tabla de
enrutamiento. La figura 1 y 2 muestra los
parámetros de este comando.
El comando network determina las redes

que el router origina. Este concepto es
diferente de usar el comando network
cuando tu estás configurando un IGP.
Diferente a un IGP, el comando network
no arranca el BGP en interfaces
específicos. En lugar indica al BGP que Figura 1 – Comando BGP network
redes debería originar este router.
El parámetro de la máscara indica que

BGP4 puede dirigir subnetting y
supernetting. La lista del comando network
debe incluir todas las redes en su sistema
autónomo que usted desee anunciar, y no
solo las redes que están localmente
conectadas en el router Figura 2 – Parámetros del comando network
Antes de Cisco IOS Software Release 12.0, había un límite de 200 comandos de red por el router BGP. Se ha
quitado este límite. Los recursos del router, tales como la NVRAM o la RAM, determinan el número máximo de
redes en el comando que tú puedes utilizar.
El comando neighbor dice a BGP donde anunciar, y el comando network dice a BGP que anunciar
6.3.11 Ejemplo del comando network de BGP

El propósito único del comando network es notificar al BGP qué red anunciar. Sin la opción de la máscara, este
comando anuncia solamente el número de red de clase completa. Por lo menos una subred de la red principal
especificada debe estar presente en la tabla de enrutamiento IP para permitir que el BGP comience a anunciar
la red de clase completa como ruta BGP.
Cuando tú especificas la opción network-mask, un match exacto a la red (dirección y máscara) debe existir en la
tabla de enrutamiento antes de que BGP anuncie las rutas. El BGP comprueba si pueda alcanzarlo antes de
que comience a anunciar la red como ruta del BGP.
Los siguientes son dos ejemplos de cómo el comando network-mask puede ser mal configurado

192.168.1.1 mask 255.255.255.0 hace que
BGP cheque para la especifica ruta
192.168.1.1/24 en la tabla de enrutamiento.
Este puede encontrar la 192.168.1.0/24 o la
192.168.1.1/32. Sin embargo, si este nunca Figura 1 – Ejemplo: Comando BGP network
encuentra un match especifico para la red
192.168.1.1/24, BGP no anuncia la red
192.168.1.1/24 a ningún vecino

192.168.0.0 mask 255.255.0.0 anuncia un
bloque CIDR. Por lo tanto, BGP busca la
192.168.0.0/16 en la tabla de enrutamiento. Figura 2 – Ejemplo: Comando BGP network (cont.)
Este puede encontrar la red 192.168.1.0/24
o la 192.168.1.1/32. Si BGP nunca encuentra la 192.168.0.0/16, este no anuncia la red 192.168.0.0/16 a
ningún vecino. En este caso, usted puede configurar la siguiente ruta estática hacia el interfaz nulo, así que el
BGP puede encontrar un match exacto en la tabla de enrutamiento:
ip route 198.168.0.0 255.255.0.0 null0
Después de encontrar un match exacto en la tabla de enrutamiento, BGP anuncia la red 192.168.0.0/16 a
cualquier vecino.
Nota: El comando de configuración BGP del router auto-summary determina cómo BGP maneja la
predistribución de las rutas. Cuando BGP summarization es habilitado (con auto-summary), todos las
subredes redistribuidas son sumarizadas a su limites de classful en la tabla del BGP. Cuando este es
deshabilitado (con no auto-summary), todas las subredes redistribuidas están presentes en su forma original
en la tabla de BGP, así que únicamente las subredes son anunciadas. En Cisco IOS Software Release
12.2(8)T, por defecto al comando auto-summary fu cambiado a deshabilitado. Antes de este por defecto era
habilitado (auto-summary).
6.3.12 Sincronización BGP

La regla de sincronización del BGP indica que un router BGP no debe utilizar, o anunciar a un vecino externo,
una ruta que se aprenda de IBGP a menos que esa ruta sea local o que el router aprenda del IGP. Es decir el
BGP y el IGP deben ser sincronizados antes de que el BGP pueda utilizar las redes que se aprenden de un
IBGP neighbor. Figura 1
Si un sistema autónomo pasa tráfico a otros sistemas autónomos, el BGP no debe anunciar una ruta antes de
que todas las routers en el sistema autónomo hayan aprendido sobre la ruta vía el IGP. Un router que aprende
una ruta vía IBGP espera hasta que el IGP ha propagado la ruta dentro del sistema autónomo y después
anuncia a los pares externos. Esta regla asegura de que todas los routers en el sistema autónomo estén
sincronizados y puedan encaminar el tráfico que el sistema autónomo anuncia a otros sistemas autónomos.
Este acercamiento asegura la consistencia de la información de enrutamiento (evita "black holes") dentro del
sistema autónomo.

La sincronización del BGP es inhabilitada

por defecto en el Cisco IOS Software
Release 12.2(8)T y más adelante. Era
encendido por defecto en revisiones
anteriores del Cisco IOS Cuando la
sincronización esta deshabilitada, el BGP
puede utilizar y anunciar las rutas
aprendidas de un IBGP neighbor que no
están presentes en la tabla de
enrutamiento local a un vecino externo del
BGP.
La sincronización del BGP es innecesaria

en algunas situaciones. Por ejemplo, es
seguro tener sincronización de BGP
apagado si todas los routers en la
trayectoria de tránsito en el sistema
autónomo están corriendo IBGP en full Figura 1 – Sincronización BGP
mesh
Tener la sincronización deshabilitada permite a los routers llevar pocas rutas en el IGP y permite que el BGP
converja más rápidamente.
Use sincronización si los routers en la trayectoria de tránsito de BGP en el sistema autónomo no están
corriendo BGP (por lo tanto, los routers no están en full mesh IBGP dentro del sistema autónomo
Nota: En el pasado, la mejor práctica era redistribuir el BGP en el IGP que funcionaba en un sistema autónomo
de modo que IBGP no fuera necesitado en cada router en la trayectoria de tránsito. En este caso, la
sincronización fue necesitada para cerciorarse de que los paquetes no se pierdan; por lo tanto, la sincronización
era encendida por defecto. Mientras que el Internet creció, el número de rutas en la tabla del BGP llego a ser
demasiado para que el IGPs dirija.
La mejor práctica cambiante para no redistribuir el BGP en el IGP, en lugar de esto utilizar IBGP en todas las
routers en la trayectoria de tránsito. En este caso, la sincronización no es necesaria, así que ahora está
apagado por defecto.
6.3.13 Ejemplo de sincronización BGP

En la figura 1, los routers A, B, C, y D están todos corriendo IBGP y un IGP entre ellos. No hay matching de rutas
IGP para las rutas BGP (el router A y el router B no redistribuyen las rutas BGP en dentro del IGP). Los routers
A, B, C, y D tiene rutas IGP para las redes internas del AS 65500, pero no tienen rutas a redes externas tales
como la 172.16.0.0.
El router B anuncia la ruta a 172.16.0.0 a los otros routers dentro del AS 65500 utilizando IBGP. Si la
sincronización está encendida, los routers A, C, y D no utilizan la ruta a 172.16.0.0, ni el router A anuncia esa
ruta al router E en el AS 64520. El router B utiliza la ruta para la 172.16.0.0 y la instala en su tabla de
enrutamiento. Si el router E recibe tráfico que es destinado para la red 172.16.0.0, este no tiene una ruta para
esa red y no puede enviar el tráfico.
Si la sincronización está apagada (por defecto) en el AS 65500, los routers A, C, y D pueden utilizar la ruta a
172.16.0.0 e instalar la ruta en sus tablas de enrutamiento, aunque no hay rutas de IGP que emparejan las
rutas del BGP (se asume que los routers A, C, y D pueden alcanzar la dirección del next hop para la red
172.16.0.0). El router A anuncia la ruta al router E.

El router E después tiene una ruta a la 172.16.0.0 y puede enviar el tráfico que es destinado para esa red. El
router E envía los paquetes a el router A, y el router A los remite al router C. El router C aprende una ruta a la
172.16.0.0 vía IBGP; por lo tanto, el router C remite los paquetes al router D. El router D remite los paquetes al
router B. El router B remite los paquetes al router F para la red 172.16.0.0.
En sistemas autónomos modernos, ya

que el tamaño de la tabla de
enrutamiento del Internet es grande, la
redistribución del BGP en un IGP no es
escalable. Por lo tanto, la mayoría de
los sistemas autónomos modernos
corren IBGP en full mesh y no requieren
la sincronización. Los métodos
avanzados de configuración del BGP,
por ejemplo, con los reflectores y las
confederaciones de la ruta, reducen los
requisitos para un full mesh.
Figura 1 – Ejemplo: Sincronización BGP
6.3.14 Ejemplo de configuración de BGP

La figura 1 muestra un ejemplo de BGP. La figura
2 muestra la configuración para el router B. El
primero de los dos comandos debajo del comando
router bgp 65000 establece que el router B tiene
los siguientes dos BGP neighbors
• Router A in AS 64520
• Router C in AS 65000
Desde la perspectiva del router B, el router A es

un EBGP, y el router C es un IBGP neighbor
La declaración Vecina en el router A para el router

B esta apuntando a la dirección IP directamente
conectada para a un EBGP neighbor, router A. Sin
embargo, la declaración vecina en el router B
apunta a la interfase de loopback del router C, ya
que el router B tiene múltiples trayectorias para Figura 1 – Ejemplo: Configuración BGP
alcanzar al router C.
Si el router B apunta a la dirección IP 192.168.3.2 del router C y esta interfase se cayera, el router B no podría
restablecer la sesión BGP hasta que el enlace suba. Señalando a la interfaz de loopback del router C en lugar
del otro, el link se queda establecido mientras cualquier trayectoria al router C esté disponible. El router C debe
también señalar a la dirección de loopback del router B en su configuración.
La línea 4 se notifica que el router B utilice siempre su dirección de loopback 0, 192.168.2.1, como su dirección
IP de origen cuando envíe una actualización al router C, 192.168.2.2.

En la línea 5, el router B cambia la dirección del next–hop para las redes que son accesibles con ella. La
configuración del next-hop o next hop por defecto para las redes del AS 64520 es la dirección IP 10.1.1.2. Con
este comando next-hop-self, el router B fija la dirección del next hop a la dirección IP origen de la actualización
de la enrutamiento, la cual es la interfaz de loopback 0 del router B, como lo fijo el comando update-source
Las líneas 6 y 7 notifican al BGP sobre cuales

redes anunciar. La línea 6 contiene una subred de
dirección de clase B usando la opción mask. Las
líneas 7 y 8 tienen dos declaraciones de red para
las dos redes de clase C que conectan a los
routers B y C. La máscara por defecto es
255.255.255.0, así que no necesitas incluir esto
en el comando.
En la línea 9, la sincronización es deshabilitada. Si Figura 2 – Ejemplo de configuración BGP

el router A está anunciando la red 172.20.0.0 en
BGP, el router B recibe esa ruta y la anuncia al router C. Puesto que la sincronización está apagada, el router C
puede utilizar esta ruta.
Si el router C tuviera sus propios EBGP neighbors y el router B deseara utilizar el router C como la trayectoria a
esas redes, la sincronización en el router B también necesitaría estar apagada. En esta red, la sincronización
puede estar apagada porque todas las routers dentro del sistema autónomo están corriendo IBGP.
6.4 Configuración y verificación avanzada de BGP

6.4.1 Estados de BGP neighbors
El proceso de negociación de BGP
neighbors procede a través de varios
estados. Figura 1. Estos pasos se pueden
describir en términos de una máquina de
estado finito (FSM finite-state machine). Un
FSM es un sistema de estados posibles que
pueden ir a través, qué causan
acontecimientos a esos estados, y qué
acontecimientos resultan de esos estados.
La figura 2 presenta el BGP FSM, que Figura 1 – Estados BGP
incluye los estados y algunos de los
acontecimientos de los eventos del mensaje
que los causan
Después de que hayas incorporado el

comando neighbor, el BGP toma la
dirección IP que esta enumerada y chequea
la tabla de enrutamiento local para saber si
hay una ruta a esta dirección. A este punto,
el BGP está en el estado IDLE. Si el BGP
no encuentra una ruta a la dirección IP,
permanece en el estado IDLE. Si encuentra
una ruta, entra al estado connect cuando el
paquete TCP handshaking synchronize
acknowledge (SYN ACK) retorna.
Después de que la conexión del TCP haya

finalizado, el BGP crea un paquete abierto Figura 2 – Estados FSM BGP
BGP y lo envía al vecino. Una vez de que

BGP envíe este paquete abierto, la sesión peering de BGP cambia al estado de enviado abierto (open sent). Si
no hay respuesta por 5 segundos, el estado cambia al estado activo.
Si una respuesta se vuelve de una manera oportuna, el BGP va al estado confirmado abierto y arranca el
escaneo (evaluación) de la tabla de
enrutamiento para que las trayectorias
envíen al vecino. Cuando se encuentran
esas trayectorias, el BGP va al estado
establecido y comienza el enrutamiento
entre los neighbors.
Tu puedes utilizar el comando debug para

observar los estados que dos routers BGP
van durante el establecimiento de la sesión.
Figura 3. En el Cisco IOS Software Release
12.4, tu usas el comando debug ip bgp
ipv4 unicast. En lanzamientos anteriores
del IOS de Cisco, el comando debug ip
bgp events da una similar salida.
Nota: Debugging consume recursos del

router y debería ser encendido únicamente Figura 3 – Ejemplo: establecimiento de sesión BGP
cuando es necesario
6.4.2 Estados Established e Idle de BGP

Es estado idle indica que el router no sabe
como alcanzar la dirección IP que esta
enlistada en la declaración vecina Figura 1
El router puede estar en idle dado uno de Figura 1 – Estado idle BGP
los siguientes escenarios:
• Este esta esperando por una ruta
estática para la dirección de red o
red a ser configurada.
• Este esta esperando por un
protocolo de enrutamiento local
(IGP) para aprender acerca de esta Figura 2 – Estado establecido BGP
red a través de un anuncio de otro
router.
La mas común razón para que un router

entre al estado de idle es que el vecino no
esta anunciando la dirección IP o la red que
la declaración vecina del router esta
apuntando.
Queque estas dos condiciones primero para

corregir este problema:
• Asegúrese que el vecino anuncie la
ruta en su protocolo de
enrutamiento local.
• Verifique que tu no hayas entrado
una dirección IP incorrecta en la
declaración vecina
El estado establecido es un estado deseado Figura 3 – Ejemplo: Comando show ip bgp neighbors
por las relaciones de neighbors. Figura 2.
Este estado significa que ambas routers tienen agregado para intercambiar las actualizaciones BGP con uno y
otro y el enrutamiento ha comenzado
Utilice el comando show ip bgp neighbors para mostrar la información acerca de las conexiones BGP a los
neighbors. En la figura 3, el estado de BGP es establecido, lo cual significa que los neighbors han establecido
una conexión TCP y dos peers tienen agregado utilizar BGP para comunicarse
6.4.3 Verificación de problemas de BGP en estado Activo

Si el router está en el estado activo, ha
encontrado la dirección IP en la declaración
vecina y ha creado y ha enviado un paquete
abierto de BGP. Sin embargo, el router no
ha recibido una respuesta (paquete de
confirmación abierto). Figura 1
Un problema común en este caso es que el

neighbor puede no tener una ruta de
regreso a la dirección IP origen. Asegúrese Figura 1 – Estado activo BGP
de que la dirección IP origen o red de los
paquetes se haya anunciado al protocolo de enrutamiento local (IGP).
Otro problema común asociado al estado activo ocurre cuando un router BGP procura mirar con fijeza (peers)
con otro router BGP que no tenga una declaración vecina de peering detrás en el primer router, o cuando el otro
router está mirando con fijeza con una dirección IP incorrecta en el primer router. Cheque para asegurarse de
que el otra router tenga una declaración vecina de peering con la dirección correcta del router que está en
estado activo.
Si el estado tambalea entre el estado idle y

el activo, uno de los problemas mas
comunes es una desconfiguración del
numero de sistema autónomo
La figura 2 muestra el mensaje de consola

generado en el router con el número remoto
del sistema autónomo equivocado en la Figura 2 – Ejemplo: Estado activo BGP
declaración vecina
6.4.4 Configurando un Peer Group

En BGP, los neighbors routers son frecuentemente configurados con las mismas políticas de actualización. Por
ejemplo, los neighbors routers pueden tenerle mismo filtro aplicado. En los routers Cisco, los neighbors routers
con las mismas políticas de actualización se pueden agrupar en grupos peers (peers groups) para simplificar la
configuración y para hacer la actualización más eficiente y para mejorar funcionamiento.
Los miembros del peer group heredan todas las opciones de configuración del peer group. Tu puede configurar
el router para eliminar estas opciones para algunos miembros si estas opciones afectan los anuncios de entrada
pero no a las actualizaciones de salida.
Los peers group son más eficientes ya que las actualizaciones se generan solamente una vez por peer group
en vez de que repetidamente para cada router vecino. La actualización generada es replicada para cada
neighbor que sea parte del interno peer group. Los peer group ahorran tiempo de transformación en la
generación de las actualizaciones para todos los IBGP neighbors. El nombre de peer group es local al router en
el cual se configura, y no se pasa a ningún otra router. Los peers group hacen la configuración del router más
fácil leer y manejar.

Use el comando neighbor peer-group-
name peer-group para crear un peer group
y definir el nombre para ligar los neighbors
routers similares juntos. Figura 1
Utilice el comando neighbor ip-address

peer-group peer-group-name para linkear
la dirección de un router vecino para
especificar un nombre de peer group. Un
router vecino puede ser parte de
únicamente un peer group. Este comando
permite que tú ingreses el nombre del peer
group en lugar de ingresar la dirección IP en
otros comandos, por ejemplo, para linkear
una política al grupo de neighbors routers. Figura 1 – Usando un peer group
Tu debes ingresar el comando neighbor
peer-group-name peer-group antes de que el router acepte este comando.
Nota: Los lanzamientos recientes Cisco IOS software contienen una actualización dinámica de peer group en
BGP usando peers templates para optimizar dinámicamente las actualizaciones a grupos de neighbors para
compartir políticas de salida. Más información sobre esta característica se puede encontrar en Cisco.com
6.4.5 Configurando un ejemplo de Peer Group

En la figura 1, el AS 65100 tiene
cuatro routers corriendo IBGP. Todos
estos IBGP neighbors son peering
con cada otro utilizando la interfaz de
loopback 0 de cada uno, y están
utilizando la dirección IP de su
interfaz de loopback 0 como la
dirección IP origen para todos los
paquetes BGP. Cada router está
utilizando una de sus propias
direcciones IP como la dirección del
next hop para cada red anunciada a
través de BGP. Éstas son políticas de
salida
Además, el router C tiene una lista de

distribución de salida asociada a cada
IBGP neighbor. Este filtro de salida
realiza la misma función que el
comando distribute-list que tú usas Figura 1 – Ejemplo: Usando un peer group
para los protocolos enrutamiento
interno. Sin embargo, se liga a un
vecino específico para usar con BGP. El ISP detrás del router C puede anunciar el espacio de direcciones
privadas al router C. El router C no desea pasar estas redes a otros routers que corren BGP en el AS 65100.
Para lograr esta meta, la Access list 20 debe tener acceso a la lista 20 verse de la siguiente manera:
access-list 20 deny 10.0.0.0 0.255.255.255
access-list 20 deny 172.16.0.0 0.31.255.255
access-list 20 deny 192.168.0.0 0.0.255.255
access-list 20 permit any
Note la configuración del router C cuando no está utilizando un peer group. Todos los IBGP neighbors tienen la
lista de distribución de salida para ellos individualmente. Si el router C recibe un cambio del AS 65101, este
debe generar una actualización individual para cada IBGP neighbor y correr cada actualización contra distribuir
la lista 20. Si el router C tiene una gran cantidad de IBGP neighbors, el poder de procesamiento necesitado
para informar a los IBGP neighbors de los cambios del AS 65101 podría ser extensa.
La figura también demuestra la configuración en el router C cuando está utilizando a peer group llamado
“interno.” Los comandos update-source, next-hop-self, y distribute-list 20 out están todos linkeados a un
interno peer group, el cual es prendido para linkear a cada IBGP neighbor.
Si el router C recibe un cambio del AS 65101, crea una sola actualización y procesa esto a través de la lista
distribuida 20, lo cual ahorra tiempo de procesamiento. La actualización es replicada para cada neighbor que
sea parte peer group interno
Así, el uso de los peers groups pueden mejorar la eficacia al procesar las actualizaciones para los BGP
neighbors que tienen una política de salida común de BGP.
La adición de un nuevo neighbor al router C que usa a un peer group con las mismas políticas de los otros
IBGP neighbors requiere la adición solamente de una sola declaración vecina para ligar al nuevo neighbor al
peer group interno. Agregando este mismo neighbor al router C sin un peer group requiere cuatro declaraciones
vecinas.
Usar un peer group también hace la configuración más fácil de leer y cambiar cuando es necesario. Si necesitas
agregar una nueva política, tal como un route map, a todos los IBGP neighbors en el router C usando un peer
group, necesitas solamente hacer un link del route map al peer group interno. Para el router C sin un peer
group, necesitas agregar la nueva política a cada neighbor
6.4.6 BGP Peering

El comando show ip bgp summary es una
manera de verificar las relaciones de
neighbors. La figura 1 presenta la salida de
este comando, el cual contiene lo siguiente:
• BGP router ID: dirección IP que
todos los otros BGP speakers
reconocen como una
representación de este router
• BGP table versión: Aumenta de
incrementos cuando la tabla del
BGP cambia.
• Main routing table versión: la
última versión de la base de datos
de BGP que fue inyectada en la
tabla de enrutamiento principal.
• Neighbor: dirección IP que se
utiliza en la declaración vecina con
la cual este router tiene una Figura 1 – Ejemplo: BGP peering
relación.
• Versión (V): Versión de BGP que este router está corriendo con el neighbor mencionado.
• AS: numero del sistema autónomo del neighbor mencionado.
• Messages received (MsgRcvd): Número de los mensajes de BGP que se han recibido de este
neighbor.
• Messages sent (MsgSent): Numero de mensajes BGP enviados a este neighbor \
• Table version (TblVer): Versión de la tabla de BGP.
• In queue (InQ): Número de los mensajes que esperan para ser procesados por este neighbor.
• Out queue (OutQ): Número de mensajes encolados que esperan para ser enviados para este neighbor.
• Up/Down: Longitud de tiempo que este neighbor ha estado en el estado actual de BGP (established,
active, o idle).

• State (established, active, idle, open sent, open confirm, or idle [admin]): estados de BGP. Tu
puedes setear a un neighbor para que administrativamente este abajo (admin state) utilizando el
comando shutdown en el neighbor
• Prefix received (PfxRcd): Cuando la sesión está en el estado establecido, este valor representa el
número de las entradas de red BGP recibidas del neighbor mencionado.
6.4.7 Configurando autenticación BGP

Tú puedes configurar la autentificación vecina BGP en un router de modo que el router autentique la fuente de
cada paquete de actualización de enrutamiento que recibe. Esto es logrado intercambiando una llave de
autenticidad (designada a veces una contraseña) que es conocida por ambos router el que envía y el de
recepción.
El BGP soporta autentificación vecina MD5. MD5 envía un message digest (también llamado hash) que es
creado usando la llave y un mensaje. El
message digest entonces es enviado en
lugar de la llave para evitar que la llave sea
leída por un eavesdropper mientras que se
está transmitiendo.
Para habilitar autenticación MD5 en una

conexión TCP entre dos BGP peers, use el
comando de configuración de router
neighbor {ip-address | peer-group-name}
password string la figura 1 y 2 muestra los
Figura 1 – Autenticación de vecino BGP
parámetros:
Tu puedes configurar la autentificación MD5

entre dos BGP peers, dando a entender que
cada segmento enviado en la conexión TCP
entre los pares está verificado. La
autentificación MD5 se debe configurar con
la misma contraseña en ambos BGP peers;
si no, la conexión entre ellos no es hecha.
La autentificación de configuración MD5
hace que el software del IOS de Cisco
genere y compruebe MD5 digest de cada Figura 2 – Parámetros del comando neighbor
segmento enviado en la conexión TCP.
Precaución: Si la secuencia de autentificación se configura incorrectamente, la sesión del BGP peering no se

establece. Se recomienda que ingreses una secuencia de autentificación cuidadosamente y verifiques que la
sesión peering este establecida después de que se configure la autentificación.
Si tu especificas un BGP peer group usando el argumento peer-group-name, todos los miembros del peer
group heredan la característica configurada con este comando.
Si un router tiene una contraseña configurada para un neighbor pero el router vecino no, un mensaje tal como el
siguiente aparece en la consola cuando los routers procuran enviar mensajes BGP entre sí mismos
%TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236)
Similarmente, si dos routers tienen diferentes contraseñas configuradas, un mensaje tal como el siguiente
aparece en la pantalla
%TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179)

Si configuras o cambias la contraseña o la llave usada para la autentificación MD5 entre dos pares del BGP, el
router local no rasga abajo la sesión existente después de que configures la contraseña. El router local procura
mantener la sesión que mira con fijeza usando la nueva contraseña hasta que expira el contador de tiempo del
asentamiento del BGP. El período de defecto es 180 segundos. Si la contraseña no se incorpora ni se cambia
en el router alejada antes de que expire el contador de tiempo, los tiempos de la sesión hacia fuera.
Nota: Si cambias el valor del

mantenimiento, toma efecto solamente
después que se ha reajustado la sesión. No
puedes cambiar el contador de tiempo del
asentamiento para evitar de reajustar la
sesión del BGP.
El ejemplo en la figura 3 autentificación de

configures MD5 para la sesión que mira con
fijeza del BGP entre las routers A y B. La
misma contraseña se debe configurar en el
par alejado antes de que expire el contador Figura 3 – Ejemplo: Autenticación de vecino BGP
de tiempo del mantenimiento
6.4.8 Troubleshooting BGP

Utilizar el comando show ip bgp muestra la base de datos de la topología del BGP (tabla del BGP).
La figura 1 muestra una salida parcial de la muestra del comando del BGP del IP de la demostración. Los
códigos de estado se demuestran al principio de cada línea de la salida, y los códigos de origen se demuestran
en el extremo de cada línea
En esta salida, hay un asterisco (*) en la

mayor parte de las entradas en la primera
columna. Esto significa que la dirección
del next hop (en la quinta columna) es
válida. La dirección del next hop no es
siempre el router que está conectado
directamente con este router. Otras
opciones para la primera columna son las
siguientes:
• s: Se suprimen las rutas
especificadas (generalmente
porque se han resumido las rutas
y solamente se está enviando la
ruta sumaria).
• d: La ruta se está desalentando
(penalizado) ya que la ruta sube y
baja demasiado a menudo.
Aunque la ruta pudo estar arriba
Figura 1 – Ejemplo: Comando show ip bgp
ahora, no se anuncia hasta que
ha expirado la penalización.
• h: La ruta es inasequible y está probablemente abajo. La información histórica sobre la ruta existe, pero
una mejor ruta no existe.
• r: La ruta no fue instalada en la base de información de enrutamiento (RIB). La razón que la ruta no
está instalada se puede mostrar usando el comando show ip bgp rib-failure
• S: La ruta esta averiada o añeja (este símbolo es usado en el nonstop forwarding-aware router).
La segunda columna muestra “>” cuando BGP ha seleccionado la trayectoria como la mejor trayectoria a una
red.
La tercera columna es espacio en blanco o muestra el “i” Si está en blanco, BGP aprendió la ruta de un peer
externo. Una “i” indica que un IBGP neighbor anunció esta trayectoria al router.
La cuarta columna enumera las redes que el router aprendió.
La columna next hop enumera todas las direcciones del next hop para cada ruta. Esta columna puede contener
la entrada 0.0.0.0, que significa que este router es el autor de la ruta.
Las tres columnas a la izquierda de la columna Path lista tres atributos de trayectoria BGP que se asocian a la
trayectoria: metric (multi-exit discriminator [MED]), local preference, y weight.
La columna con la cabecera de Path puede contener una secuencia de sistemas autónomos en la trayectoria.
De izquierda a derecha, el primer sistema autónomo enumerado es el sistema autónomo adyacente que esta
red ha aprendido. El último número (el número de sistema autónomo de la derecha) es el sistema autónomo
que origina esta red. Los números de sistema autónomo entre estos dos representan la trayectoria exacta que
un paquete toma de regreso al sistema autónomo originado. Si la columna de la trayectoria está en blanco, la
ruta es el sistema autónomo actual.
La última columna significa que esta ruta

fue entrada dentro de BGP en el router
original. Si la ultima columna contiene una
“i”, el router que origen probablemente
utilizo una declaración de la red para
introducir esta red en BGP.
Si el carácter es una “e,” el router que

originaba aprendió esta red del EGP, que
es el precursor histórico de BGP. Un Figura 2 – Ejemplo: Comando show ip bgp rib-failure
signo de interrogación (?) significa que el
BGP no puede verificar absolutamente la disponibilidad de esta red porque se redistribuye de un IGP dentro del
BGP.
Utilizar el comando show ip bgp rib-failure muestra las rutas BGP que no fueron instaladas en la RIB y la
razón por la cual no fueron instaladas
El ejemplo en la figura 2 muestra que las rutas exhibidas no fueron instaladas porque una ruta o las rutas con
una distancia administrativa mejor ya existen en la RIB
6.4.9 Clearing la sesión BGP

BGP puede potencialmente manejar
volúmenes enormes de información de
enrutamiento. Cuando ocurre un cambio de
configuración de la política, el router no
puede pasar a través de la tabla enorme de
información de BGP y recalcular qué
entrada no es más válida en la tabla local.
Ni puede el router determinar cuál ruta debe
ser retirada de un neighbor. Figura 1
Hay un riesgo obvio que el primer cambio Figura 1 – Limpiando la sesión BGP
de configuración será seguido
inmediatamente por un segundo, que haría al proceso entero comenzar de nuevo. Para evitar tal problema, el
software del IOS de Cisco aplica cambios solamente a esas actualizaciones que son recibidas o transmitidas
después de que se haya realizado el cambio de configuración de la política de BGP. La nueva política,
implementada por los filtros, se aplica solamente en las rutas que se reciben o se envían después del cambio.

Un administrador de red que quisiera que el cambio de política fuera aplicado a todas las rutas, deba accionar
una actualización para forzar al router que deje que todas las rutas pasen a través del nuevo filtro. Si el filtro se
aplica en la información saliente, el router tiene que volver a enviar la tabla BGP a través del nuevo filtro. Si el
filtro se aplica en la información entrante, el router necesita a que su neighbor vuelva a enviar su tabla BGP de
modo que pase a través de los nuevos
Hay tres maneras de accionar una actualización: con un hard reset, soft reset, o route refresh.
6.4.10 Hard Reset de sesiones BGP

El reajuste de una sesión es un método de informar a los neighbors de un cambio de política. Si se reajustan las
sesiones BGP, toda la información recibida en esas sesiones se invalida y se quita de la tabla del BGP.
También, el neighbor remoto detecta una sesión BGP abajo e invalida las rutas que fueron recibidas. Después
de 30 a 60 segundos, las sesiones BGP se restablecen automáticamente, y la tabla de BGP es intercambiada
otra vez pero a través de los nuevos filtros. Sin embargo, resetear la sesión BGP interrumpe y/o desestabiliza el
envió de paquetes.
Los dos comandos mostrados en la figura 1

causan un hard reset de los BGP neighbors
que están implicados. Un hard reset
significa que el router que publica
cualquiera de estos comandos cierra las
conexiones apropiadas de TCP, restablece
esas sesiones TCP como apropiadas, y
vuelve a enviar toda la información a cada
uno de los neighbors afectados por el
particular comando que es utilizado.
El comando clear ip bgp * causa que la

tabla de BGP de forwarding en el router que
se emite este comando sea completamente Figura 1 – Hard reset de sesiones BGP
borrada, y todas las redes deben ser
reaprendidas de cada neighbor. Si un router tiene múltiples neighbors, esta acción es un acontecimiento muy
dramático. Este comando fuerza a todos los neighbors a volver a enviar sus tablas enteras simultáneamente.
Debes utilizar este comando con la precaución extrema, y no se utiliza normalmente en un ambiente en
producción.
Por ejemplo, considere una situación en qué el router A tiene ocho neighbors, y cada neighbor tiene una tabla
llena de Internet de cerca de 32 MB de tamaño. Si el router A publica el comando clear ip bgp *, todos los ocho
routers vuelven a enviar sus 32 MB de tablas al mismo tiempo. Para llevar a cabo todas estas actualizaciones,
el router A necesitaría 256 MB de RAM, y también necesitaría estar disponible para poder procesar toda esta
información. Procesando 256 MB de actualizaciones tomaría un número considerable de ciclos de CPU,
adicional retardo de enrutamiento de los datos del usuario.
Si el comando clear ip bgp [neighbor-address] es usado en su lugar, reajustan a un neighbor a la vez. El

impacto es menos severo en el router que está publicando este comando. Sin embargo, toma mas tiempo
cambiar la política de todos los neighbors, ya que cada uno debe ser dado individualmente más bien que de
una vez con el comando clear ip bgp *. El comando clear ip bgp [neighbor-address] todavía realiza un hard
reset y debe restablecer la sesión TCP con la dirección especificada, pero afecta solamente a solo neighbor a la
vez.

6.4.11 Soft Reset de sesiones BGP

El comando clear ip bgp soft out causa
que BGP haga un soft reset para las
actualizaciones de salida. En la figura 1. El
router que publica el comando no reajusta la
sesión BGP. En su lugar, el router crea una
nueva actualización y envía la tabla entera a
los vecinos especificados.
Esta actualización incluye los comandos de Figura 1 – Soft reset

retiro para las redes que el otro neighbor no
mirara mas allá basado en la nueva política de salida.
Nota: La palabra soft es opcional; clear ip bgp out hace un sofá reset para las actualizaciones de salida.
Hay dos maneras de realizar una reconfiguración suave de entrada:

• Usar información de actualización de enrutamiento almacenada
• Dinámicamente
Incorporar el comando neighbor para

informar al BGP que guarde todas las
actualizaciones que fueron aprendidas del
vecino especificado. Figura 2. El router BGP
conserva una tabla sin filtro de lo que ha
enviado ese vecino. Figura 2 – Soft reset default-metric
Cuando se cambia la política de entrada,

utilice el comando clear ip bgp. Figura 3.
La tabla sin filtro almacenada genera
nuevas actualizaciones de entrada, y los
resultados se ponen el BGP forwarding
database. Así, si tú realizas cambios, tú no Figura 3 – Soft reset dinámico
tienes que forzar al otro lado volver a enviar
todo.
Cisco IOS Software Release 12.0(2)S y 12.0(6)T introdujo un realce de las características de soft reset de BGP,
también conocida como route refresh, que proporciona la ayuda automática para el reajuste del software
dinámico de las actualizaciones de entrada de la tabla de enrutamiento de BGP, y no es dependiente sobre la
información almacenada de la actualización de la tabla de enrutamiento. El comando clear ip bgp soft in pone
esta característica en ejecución. Este método no requiere ninguna preconfiguración y necesita perceptiblemente
menos memoria que el método suave anterior para las actualizaciones de la tabla de enrutamiento de entrada.
Nota: El comando clear ip bgp soft realiza una reconfiguración suave de las actualizaciones de entrada y de
salida.
La opción soft in genera nuevas actualizaciones de entrada sin resetear la sesión BGP, pero este puede usar
la memoria intensamente. BGP no permite que un router fuerce a otro BGP speaker a volver a enviar su tabla
entera. Si usted cambia la política de entrada de BGP y tú no deseas completar un hard reset, configure el
router para realizar una reconfiguración suave.
Nota: Para determinar si un BGP router soporta esta la capacidad de route refresh, use el comando show ip
bgp neighbors. El mensaje siguiente se exhibe en la salida si el router soporta la capacidad de route refresh:
La ruta recibida restaura la capacidad del peer.
Si todos los routers BGP soportan route refresh, use el comando clear ip bgp {* | address | peer-group-name}
in. Tú no tienes que utilizar la palabra soft, porque el soft reset es automáticamente asumido.

6.4.12 El comando debug ip bgp

La figura 1 muestra la salida parcial del
comando debug ip bgp updates en el
router A después de que el comando clear
ip bgp fuera publicado para borrar las
sesiones BGP con su IBGP neighbor
10.1.0.2.
Después de que se restablezca la

adyacencia vecina, el router A crea y envía
actualizaciones a 10.1.0.2. La primera
actualización se destacó en la figura,
“10.1.1.0 /24, next 10.1.0.1,” es una
actualización sobre la red 10.1.1.0 /24, con
un next hop de 10.1.0.1, que es la dirección
del router A.
La segunda actualización destacada en la

figura, “10.97.97.0/24, next 172.31.11.4,” es
una actualización sobre la red
10.97.97.0/24, con un next hop de
172.31.11.4, el cual es la dirección de uno Figura 1 – Comando debug ip bgp updates
de los EBGP neighbors del router A. La
dirección del hop next de EBGP se está llevando dentro de IBGP.
El router A recibe más adelante actualizaciones de la 10.1.0.2. La actualización destacada en la figura contiene
una trayectoria a dos redes: 10.1.2.0 /24 y 10.1.0.0 /24. Los atributos demostrados en esta actualización se
describen en la siguiente lección.
Nota: Debbugging utiliza recursos del router y debe ser encendido solamente cuando es necesario.
6.5 Seleccionando un BGP Path

6.5.1 Características de los atributos de BGP
Los BGP routers envían mensajes de actualización BGP sobre redes destino a otros BGP routers. Los
mensajes de actualización contienen una o más rutas y un set de sistema de métricas BGP, que se llaman path
attributes, unidos a las rutas. Figura 1
Un atributo es well-known u opcional,

obligatoria o discrecional, y transitivo o no
transitivo. Un atributo puede también ser
parcial.
No todas las combinaciones de estas

características son válidas. Los atributos de
Path caen en las cuatro categorías Figura 1 – Atributos path BGP
siguientes:
• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Optional nontransitive
Solamente los atributos Optional transitive se pueden marcar como parciales.

Todas los BGP routers deben reconocer un
atributo bien conocida (well-known) y
propagarlo a los otros BGP neighbors.
Figura 2
Los atributos well-known son obligatorios o

discrecionales. Un atributo well-known
mandatory debe estar presente en todas las
actualizaciones de BGP. Un atributo well-
known discretionary no tiene que estar Figura 2 – Atributos bien conocidos
presente en todas las actualizaciones de
BGP.
Los atributos que no son well-known se

llaman opcionales. Los BGP routers no
tienen que soportar un atributo opcional.
Los atributos opcionales son transitivos o no
transitivos. Figura 3
Las siguientes declaraciones se aplican a

los atributos opcionales:
• Los BGP routers que implementan Figura 3 – Atributos opcionales
el atributo opcional pueden
propagar este a los otros BGP neighbors, basados en su significado.
• Los BGP routers que no ponen un atributo transitivo opcional en ejecución deben pasar este a otros
BGP routers sin tocar y marcan el atributo como parcial.
• Los BGP routers que no implementan un atributo no transitivo opcional deben suprimir el atributo y no
deben pasarlo a otros BGP routers
6.5.2 Atributos de BGP

Lo que sigue es una lista de los atributos
comunes de BGP según a las categorías
que ellos pertenecen figura 1
• Well-known mandatory attributes
o Sistema Autónomo path
o Next hop
o Origin
• Well-known discretionary attributes
o Local preference
o Atomic aggregate Figura 1 – Atributos BGP
• Optional transitive attribute
o Aggregator
• Optional nontransitive attribute
o Multi-exit discriminator (MED)
Nota: Además, Cisco define un atributo de peso para BGP. El weight se configura localmente en un router y no
se propaga a ningunos otros BGP routers.
Nota: Los atributos en esta lista son detallados en los siguientes tópicos, a excepción de los atributos atomic
aggregate y aggregator Estos dos atributos se relacionan con la summarization (o la agregación) de BGP, y
puedes encontrar más información sobre ellos en Cisco.com
6.5.3 Atributo AS Path

El AS path es un atributo well-known mandatory. Siempre que una actualización de ruta pase a través de un
Sistema Autónomo, el número del Sistema Autónomo es agregado a esa actualización cuando se anuncia al
siguiente EBGP neighbor.
El atributo AS path es realmente la lista de los números de Sistemas Autónomos que una ruta ha atravesado
para alcanzar un destino, con el número del Sistema Autónomo que originó la ruta al final de la lista.
En la figura 1, el router A en el AS 64520

anuncia la red 192.168.1.0. Cuando esa
ruta atraviesa el AS 65500, el router C
agrega su propio número del Sistema
Autónomo a este. Cuando la 192.168.1.0
alcanza el router B, tiene dos números de
Sistema Autónomo unidos a este. Desde la
perspectiva del router B, la trayectoria para
alcanzar la 192.168.1.0 es (65500, 64520)
Un proceso similar se aplica para las

trayectorias a las redes 192.168.2.0 y
192.168.3.0. La trayectoria o path del router
A a la 192.168.2.0 es (65500, 65000), lo
cual significa que atraviesa el AS 65500 y
luego el AS 65000. El router C debe
atravesar el path (65000) para alcanzar la
192.168.2.0, y el path (64520) para alcanzar
a la 192.168.1.0. Figura 1 – Atributo AS path
6.5.4 Atributo Next-Hop

El atributo del next hop de BGP es un
atributo well-known mandatory que indica la
dirección IP del next hop que debe ser
utilizada para alcanzar un destino.
BGP enruta Sistema Autónomo por Sistema

Autónomo, no router por router. El atributo
del next hop define la dirección IP del router
frontera que se debe utilizar como el next
hop para el destino.
Para EBGP, el next hop es la dirección IP

del vecino que envió la actualización. En la
figura 1, el router A anuncia la 172.16.0.0 al
router B, con un next hop de 10.10.10.3, y el
router B anuncia la 172.20.0.0 al router A,
con un next hop de 10.10.10.1.
Para IBGP, el protocolo indica que el next Figura 1 – Atributo Next-hop

hop que es anunciado por EBGP debe ser
llevado en IBGP. Debido a esta regla, el router B anuncia la 172.16.0.0 a su IBGP peer router C con un next
hop de 10.10.10.3 (dirección del router A). Por lo tanto, el router C sabe que el next hop para alcanzar la
172.16.0.0 es la 10.10.10.3, y no la 172.20.10.1, como pudo haber sido esperado.
Es muy importante que el router C sepa alcanzar la subred 10.10.10.0, vía un IGP o una ruta estática. Si no,
este eliminará los paquetes destinados a la red 172.16.0.0, porque no puede conseguir la dirección del next hop
para esa red.
Alternativamente, el router B puede cambiar el atributo del next hop a sí mismo si se utiliza el comando
neighbor next-hop-self

6.5.5 Atributo Origen

El atributo origen define el origen de la
información de la trayectoria. El atributo
origen puede ser uno de estos tres valores:
figura 1
• IGP La ruta es interior al Sistema
Autónomo que origina. Este valor
normalmente resulta cuando el
comando network es utilizado para
anunciar la ruta vía BGP. Un origen
de IGP se indica con una “i” en la
tabla BGP Figura 1 – Atributo origen
• EGP: La ruta se ha aprendido vía
EGP. Este valor se indica con una
“e” en la tabla BGP. El EGP se
considera un protocolo histórico de
enrutamiento y no se apoya en el
Internet porque realiza solamente el
enrutamiento classful y no soporta
classless interdomain routing
• Incompleto: El origen de la ruta es
desconocido o se ha aprendido por
algún otro medio. Este valor resulta
generalmente cuando una ruta se
redistribuye en BGP. Un origen
incompleto se indica con un signo
de interrogación (?) en la tabla BGP
La figura 2 muestra un ejemplo de la salida

del comando show ip bgp El código de
origen, refleja que el atributo origen, está en
la ultima columna al final de cada línea. En
Figura 2 – Ejemplo: Atributo origen
este ejemplo, todos los códigos de origen
son “i,” indicando un atributo origen de IGP;
las rutas son interiores al Sistema Autónomo que origina.
6.5.6 Atributo Local Preference

La preferencia local (Local preferente) es un
atributo well-known discretionary que
proporciona una indicación a los routers en
el Sistema Autónomo sobre cual trayectoria
se prefiere para salir del Sistema Autónomo.
Una trayectoria con una preferencia local
más alta se prefiere.
La preferencia local es un atributo que se

configura en el router y se intercambia entre
los routers dentro del mismo Sistema
Autónomo únicamente. El valor prefijado
para la preferencia local en un router Cisco
es 100.
En la figura 1, el AS 64520 recibe

actualizaciones sobre la red 172.16.0.0 a
partir de dos direcciones. La preferencia
local en el router A para la red 172.16.0.0 se Figura 1 – Atributo preferencia local

fija a 200, y la preferencia local en el router B para la red 172.16.0.0 se fija a 150.
Ya que la información de la local preferente es intercambiada dentro del AS 64520, todo el tráfico en el AS
64520 direccionado a la red 172.16.0.0 se envía al router A como punto de salida del Sistema Autónomo 64520
(debido a su preferencia local más alta)
6.5.7 Atributo MED

El atributo MED, también llamado la métrica, es un atributo no transitivo opcional.
El MED es una indicación a los EBGP neighbors sobre la trayectoria preferida en un Sistema Autónomo. El
atributo MED es una manera dinámica de influenciar a otro Sistema Autónomo sobre cual trayectoria este debe
elegir para alcanzar una cierta ruta en su Sistema Autónomo cuando existen múltiples puntos de entrada. Se
prefiere la métrica mas baja.
Distinto a la preferencia local, el MED se intercambia entre los sistemas autónomos. El MED se envía a los
EBGP peers. Esos routers propagan el MED dentro de su Sistema Autónomo, y los routers dentro del Sistema
Autónomo utilizan el MED pero no lo pasan encendido al siguiente Sistema Autónomo. Cuando la misma
actualización se pasa encendida a otro Sistema Autónomo, la métrica se fija de nuevo por defecto a 0.
MED influencia al tráfico de entrada de un

Sistema Autónomo, y la preferencia local
influencia al tráfico de salida.
Por defecto, un router compara el atributo

de MED solamente para las trayectorias de
vecinos en el mismo Sistema Autónomo
Nota: El atributo de MED significa que BGP

es el único protocolo que puede afectar
cómo las rutas se envían en un Sistema
Autónomo.
En la figura 1, el atributo del router B MED

se fija a 150, y el atributo del router C MED
se fija a 200. Cuando el router A recibe
actualizaciones de los routers B y C, elige al
router B como el mejor next hop ya que su
MED de 150 es menor que la del router C. Figura 1 – Atributo MED
6.5.8 Atributo Weight

El atributo weight es un atributo de Cisco para la
selección de trayectoria. El peso se configura
localmente en un router y no se propaga a
ningún otro routers. Esta cualidad se aplica
cuando estás utilizando un router con múltiples
puntos de salida en Sistema Autónomo, en
comparación con el atributo de preferencia
local, el cual es usado cuando dos o más
routers proporcionan puntos múltiples de salida.
El peso puede tener un valor a partir de 0 a

65535. Por defecto, las trayectorias que el
router origina tienen un peso de 32768, y otras
trayectorias tienen un peso de 0.
Las rutas con un peso más alto son preferidas Figura 1 – Atributo Weight (solo Cisco)

cuando las múltiples rutas existen al mismo destino
En la figura 1, los routers B y C aprenden sobre la red 172.20.0.0 del AS 65250 y propagan la actualización al
router A. El router A tiene dos maneras de alcanzar la 172.20.0.0, y tiene que decidir a qué ruta a tomar.
En el ejemplo, el router A fija el peso de actualizaciones que vienen del router B a 200 y el peso de los que
vienen del router C a 150. Debido a que el peso para el router B es más alto que el router C, el router A utiliza el
router B como next hop para alcanzar la 172.20.0.0.
6.5.9 Determinando la selección del BGP Path

Múltiples trayectorias pueden existir para
alcanzar una red dada. Como las
trayectorias para una red se evalúan, esto
determinada que las que no sean la mejor
trayectoria sean eliminadas de los criterios
de selección pero se mantienen en BGP
forwarding table (que puede ser mostrada
usando el comando show ip bgp) en caso
que la mejor trayectoria llegue a estar
inaccesible. Figura 1
BGP no se diseña para realizar balancear Figura 1 – Selección path BGP

de la carga. Las trayectorias se eligen
debido a la política, no se basan en el ancho de banda. El proceso de selección de BGP elimina cualquier
trayectoria múltiple hasta que una sola mejor trayectoria es dejada.
La mejor trayectoria se somete al proceso de administración de la tabla de enrutamiento y se evalúa contra

cualquier otro protocolo de enrutamiento que pueda también alcanzar esa red. La ruta de origen con la distancia
administrativa más baja es instalada en la tabla de enrutamiento.
El proceso de decisión es basado en los atributos descritos tempranamente
6.5.10 Seleccionando un BGP Path

Después de que el BGP recibe actualizaciones sobre diversos destinos de diversos sistemas autónomos, este
elige la mejor trayectoria para alcanzar un destino específico. El proceso de decisión se basa en los atributos de
BGP. BGP considera solamente las rutas sincronizadas sin lazos del Sistema Autónomo y un next hop válido.
El siguiente proceso resume cómo BGP elige la mejor ruta en un router Cisco: figura 1
1. Preferir la ruta con el peso más alto. (El atributo del peso es propietario a Cisco y es local a router
solamente.)
2. Si múltiples rutas tienen el mismo peso, preferir la ruta con el más alto valor de preferencia local. (La
preferencia local se utiliza dentro de un Sistema Autónomo.)
3. Si las rutas múltiples tienen la
misma preferencia local, preferir la
ruta que el router local originó. Una
ruta localmente originada tiene un
next hop de 0.0.0.0 en la tabla de
BGP.
4. Si no se originó ninguna de las
rutas localmente, preferir la ruta con
la trayectoria más corta de Sistema
Autónomo.
5. Si la longitud de trayectoria de
Sistema Autónomo es igual, preferir
el código de origen más bajo (IGP < Figura 1 – Proceso de selección de ruta
EGP < incompleto).

6. Si todos los códigos de origen son iguales, preferir la trayectoria con el MED más bajo. (El MED se
intercambia entre Sistema Autónomos.) se hace la comparación de MED solamente si el Sistema
Autónomo vecino es igual para todas las rutas consideradas, a menos que el comando bgp always-
compare-med este habilitado
Nota: La decisión más reciente del Internet Engineering Task Force (IETF) con respecto a BGP MED asigna un
valor de infinito al MED perdido, haciendo que a ruta que carece de la variable MED sea preferida lo menos
posible. El comportamiento por defecto de los BGP routers que corren Cisco IOS software es tratar las rutas sin
el atributo de MED como teniendo un MED de 0, hagan que la ruta carezca de variable de MED preferida. Para
configurar el router para conformarse con el estándar del IETF, utilizar el comando bgp bestpath missing-as-
worst
7. Si las rutas tienen el mismo MED, preferir trayectorias externas a las trayectorias internas.
8. Si la sincronización es deshabilitada y solamente permanecen las trayectorias internas, preferir la
trayectoria a través del vecino más cercano de IGP, que significa que el router prefiere la trayectoria
interna más corta dentro del Sistema Autónomo para alcanzar el destino (el Shortest-Path al next hop
del BGP).
9. Para los EBGP paths, seleccionar la ruta más vieja para reducir al mínimo el efecto de las rutas que van
hacia arriba y hacia abajo (flapping).
10. Preferir la ruta con el valor más bajo de la identificación del BGP router del vecino.
11. Si las identificaciones de los routers BGP son iguales, preferir el router con la dirección IP vecina mas
baja
Solamente la mejor trayectoria se inscribe en la tabla de enrutamiento y se propaga a los BGP neighbors del
router.
Nota: El proceso de selección de la ruta sumarizada aquí no cubre todos los casos sino es suficiente para una
comprensión básica de cómo BGP selecciona las rutas.
Por ejemplo, suponer que hay siete trayectorias para alcanzar la red 10.0.0.0. Todas las trayectorias no tienen
ningún lazo de Sistema Autónomo y tienen direcciones válidas del next hop, así que las siete trayectorias pasan
al paso 1, las cuales examinan el peso de las trayectorias.
Las siete trayectorias tienen un peso de 0, así que todas pasan al paso 2, que examina la preferencia local de
las trayectorias. Cuatro de las trayectorias tienen una preferencia local de 200, y los otros tres tienen
preferencias locales de 100, 100, y 150.
Los cuatro con una preferencia local de 200 continúan el proceso de la evaluación al paso siguiente. Los otros
tres todavía están en la BGP forwarding table, pero son actualmente descalificadas como la mejor trayectoria.
BGP continúa el proceso de evaluación hasta que solamente permanece una sola mejor trayectoria, que se
somete a la tabla de enrutamiento IP como la mejor trayectoria del BGP.
6.5.11 Selección de la trayectoria (path) con conexiones Multihomed

Un Sistema Autónomo raramente implementa BGP con una única conexión EBGP. Esta situación significa
generalmente que múltiples trayectorias existen para cada red en la base de datos de forwarding
Si existe solamente una trayectoria, y si está libre de lazos y sincronizada con el IGP para IBGP, y si el next hop
es accesible, la trayectoria se somete a la
tabla de enrutamiento IP. No hay selección
de trayectoria que ocurra porque hay
solamente una trayectoria, y la
manipulación de ella no produce ninguna
ventaja.
La figura 1 destaca las razones más Figura 1 – Proceso de selección de ruta

comunes para la selección del path. Sin la
manipulación de la ruta, la razón más común de selección de trayectoria es el paso 4, la preferencia por la
trayectoria más corta de Sistema Autónomo. Figura 2
El paso 1 mira el peso, que por defecto esta fijado a 0 para las rutas que no fueron originadas por ese router.
El paso 2 compara la preferencia local, que

por defecto es fijada a 100 para todas las
redes. Ambos pasos tienen un efecto
solamente si el administrador de la red
configura el peso o la local preference a un
valor no dado por defecto
El paso 3 mira las redes que son propias

por este Sistema Autónomo. Si una de las
rutas es inyectado dentro de la tabla BGP
por el router local, el router local prefiere
esta para cualquier ruta recibida de otros
Figure 2 – Proceso de selección de ruta
BGP routers.
El paso 4 selecciona la trayectoria que tiene el más corto Sistema Autónomos a cruzarse. Ésta es la razón más
común que una trayectoria se selecciona en BGP. Si un administrador de red no tiene gusto de la trayectoria
con el más corto Sistema Autónomos, el administrador necesita manipular el peso o la preferencia local para
cambiar que la salida de la trayectoria BGP se escoja.
El paso 5 mira cómo una red fue introducida en el BGP. Esta introducción se logra generalmente con las
declaraciones de red (i para un código de origen) o a través de redistribución (? para un código de origen).
El paso 6 mira el MED para juzgar donde el Sistema Autónomo vecino quisiera que este Sistema Autónomo
enviara los paquetes para una red dada. Cisco fija el MED a 0 por defecto; por lo tanto, MED no participa en la
selección de la trayectoria a menos que el administrador de red del Sistema Autónomo vecino manipule las
trayectorias usando MED
Si las múltiples trayectorias tienen el mismo número de Sistemas Autónomos a atravesarse, el segundo punto
de decisión mas común es el paso 7, que indica que una trayectoria externamente aprendida de un EBGP
neighbor es preferida sobre una trayectoria aprendida de un IBGP neighbor. Un router en un Sistema Autónomo
prefiere utilizar el ancho de banda del ISP para alcanzar una red en vez de usar el ancho de banda interno para
alcanzar a un IBGP neighbor en el otro lado de su propio Sistema Autónomo.
Si la trayectoria del Sistema Autónomo es igual y el router en un Sistema Autónomo no tiene ningún EBGP
neighbor para esa red (solamente IBGP neighbors), tiene sentido tomar la trayectoria más rápida al punto más
cercano de la salida. El paso 8 busca al IBGP neighbor más cercano. La métrica IGP determina que significa
“más cercanos”; por ejemplo, el RIP utiliza la cuenta de saltos, y OSPF usa el menor coste basado en el ancho
de banda.
Si la trayectoria del Sistema Autónomo es igual y los costes vía todos los IBGP neighbors son iguales, o si todos
los vecinos para esta red son EBGP, el paso 9 es la siguiente razón más común de seleccionar una trayectoria
sobre otra. Los EBGP neighbors rara vez establecen sesiones al tiempo exacto. Una sesión es probable que
sea más vieja que otra, así que las trayectorias a través de esos viejos vecinos son consideradas más estables
ya que han estado arriba anteriormente
Si todos los criterios mencionados son iguales, la siguiente decisión más común es tomar al vecino con la
identificación más baja del BGP router, que es el paso 10.
Si las identificaciones del BGP router son iguales (por ejemplo, si las trayectorias están a el mismo BGP router),
el paso 11 indica que la ruta con el la dirección IP vecino más baja es utilizada

6.6 Manipulando BGP Path Selection con Route Maps

6.6.1 Seteando Local Preference con Route Maps
Distinto a los protocolos en enrutamiento local, BGP nunca fue diseñado para elegir la trayectoria más rápida.
BGP fue diseñado para manipular la circulación para maximizar o para reducir al mínimo uso del ancho de
banda. Esta figura demuestra una situación común que puede resultar cuando estás utilizando BGP sin ninguna
manipulación de la política.
Utilizar default settings para la selección de

la trayectoria en el BGP puede causar el
uso desigual del ancho de banda. En La
figura 1, el router A en el AS 65001 está
utilizando 60 por ciento de su ancho de
banda de salida para el router X en el
65004, solamente el router B está utilizando
únicamente el 20 por ciento de su ancho de
banda de salida. Si esta utilización es Figura 1 – BGP es designado para implementar la política de
aceptable por el administrador, no hay enrutamiento
manipulación necesaria.
Pero si la carga hace un promedio del 60 por ciento y tiene explosiones temporales sobre el 100 por ciento del
ancho de banda, esta situación causa perdida de paquetes, más alta latencia, y más alto uso de CPU debido al
número de paquetes que está siendo ruteado. Cuando otro link a la misma localización está disponible y no es
muy usado, tiene sentido de dividir algo del tráfico a la otra trayectoria. Para cambiar la selección de trayectoria
de salida del AS 65001, el administrador de red debe manipular el atributo local preference.
Para determinar qué trayectoria manipular, el administrador realiza un análisis del tráfico sobre el borde de
Internet examinando las direcciones de páginas web, o los nombres de dominio visitadas y mas pesadas. Esta
información puede ser encontrada generalmente examinando expedientes de administración de la red o
información de contabilidad de un firewall.
6.6.2 Seteando Local Preference con ejemplo de Route Maps

En a figura 1, asumir que el 35 por ciento de
todo el tráfico del AS 65001 han estado
yendo a www.cisco.com. El administrador
puede obtener la dirección de Cisco o el
número de AS realizando operaciones de
búsqueda reversas del Domain Name
System (DNS) o yendo a www.arin.net y
buscando el número de AS de Cisco
Systems o del espacio de direcciones que
se asigna a la compañía. Después de que
se haya determinado esta información, el Figura 1 – BGP es designado para implementar la política de
administrador utiliza route maps para enrutamiento
manipular la selección de la trayectoria para
la red de Cisco.
Usando un route map, el router B puede anunciar todas las redes que se asocien a ese Sistema Autónomo con
una preferencia local más alta que el router A anuncia para esas redes. Otros routers en el AS65001 corren
BGP prefieren las rutas con la preferencia local más alta. Para las redes Cisco, el router B anuncia la
preferencia local más alta, así que todo el tráfico destinado para ese Sistema Autónomo sale del AS 65001 vía
el router B. La carga de salida para el router B aumenta su carga anterior de 20 por ciento para contar por el
tráfico adicional del AS 65001 destinado a las redes Cisco. La carga de salida para el router A, que era
originalmente 60 por ciento, debe disminuir, y este cambio trae a la carga de salida en ambos links en equilibrio
relativo

Así como hay problemas de carga de salida en el AS 65001, puede haber un problema similar en la entrada.
Puede ser que los sales web servers están localizados en la misma subred detrás del router B, causando que la carga
de entrada para el router B haga un promedio de una utilización más alta. Para manipular cómo el tráfico entra
en un Sistema Autónomo, utilice el atributo de BGP MED.
Por ejemplo, AS 65001 anuncia un MED más bajo para la red 192.168.25.0/24 para el AS 65004 fuera del
router A. Este MED es una recomendación al siguiente Sistema Autónomo en cómo entrar al AS 65001; sin
embargo, la MED no es considerada hasta el paso 6 del proceso de selección de trayectoria BGP. Si el AS
65004 prefiere guardar su trayectoria de Sistema Autónomo vía el router Y al router B en el AS 65001, el AS
65004 simplemente necesita tener que el router Y anuncie una preferencia local más alta a los BGP routers en
el AS 65004 para la red 192.168.25.0/24 que el router X anuncia. La preferencia local que el router Y anuncia a
otros BGP routers en el AS 65004 se evalúa antes del MED que viene del router A en el AS 65001. MED es
considerado una recomendación ya que el Sistema autónomo de recepción puede eliminarla teniendo que ese
Sistema Autónomo manipule un valor antes de que se considere la MED.
En la figura, asumir que el 55 por ciento de todo el tráfico esta yendo a la subred 192.168.25.0/24 (router A). La
utilización de entrada al router A está promediando solamente el 10 por ciento, pero la utilización de entrada al
router B está promediando un 75 por ciento. Si el AS 65001 fuese fijado para preferir que todo el tráfico yendo
a la 192.168.25.0 /24 entre a través del router A del AS 65004, la carga de entrada en el router A se
incrementará, y la carga de entrada en el router B disminuiría.
El problema es que si la carga de entrada para los puntos del router A sube más del 100 por ciento y causa que
este link aletee, todas las sesiones que cruzan por ese link podrían perderse. Si estas sesiones fueran
compradas siendo hechas en los servidores de web del AS 65001, el rédito sería perdido, lo cual es un
resultado que los administradores desean evitar.
Si la carga se promedia por debajo del 50 por ciento para el caso de salida o de entrada, la manipulación de la
trayectoria no puede ser necesaria; sin embargo, cuando un link comienza a alcanzar la capacidad del link por
un período del tiempo extendido, más ancho de banda es necesitado o la manipulación de la trayectoria debe
ser considerada
6.6.3 Cambiando la Local Preference de BGP para todas las Rutas

La preferencia local se utiliza solamente
dentro de un Sistema Autónomo entre IBGP
speakers para determinar la mejor
trayectoria para salir del Sistema Autónomo
para alcanzar una red exterior.
La preferencia local es fijada a 100 por

defecto; se prefieren valores más altos.
El comando bgp default local-preference

cambia el valor por defecto de la preferencia
local. La Figura 1 y 2 exhibe el parámetro
Figura 1 – Cambiando preferencia local para todas las rutas
del comando.
Con este comando, todas las rutas IBGP

que son anunciadas tienen la preferencia
local en un valor específico
Si un EBGP neighbor recibe un valor de
preferencia local, el EBGP neighbor no hace
caso de él Figura 2 – Parámetro del comando bgp default local-preference

6.6.4 Ejemplo de Local Preference en BGP

La figura 1 ilustra un ejemplo de red que
corre BGP para demostrar la manipulación
de la preferencia local utilizando route maps
en el AS 65001.
La mejor trayectoria para la red 172.16.0.0

en el AS 65003 del router C en el AS 65001
es determinado de la siguiente manera:
• En el paso 1 y 2 miran el weight y la
local preference y usan los default
settings del weight igual a 0 y la
local preference igual a 100 para
todos los routers que están
aprendiendo de los IBGP neighbors
de A y de B.
• El paso 3 no ayuda a decidir la
mejor trayectoria ya que las 3 rutas Figura 1 – Preferencia local
de AS no son propias u originadas
en el AS 65001.
• El paso 4 prefiere la trayectoria mas corta de Sistemas Autónomos. Las opciones son dos Sistemas
Autónomos (65002, 65003) a través del router A o tres Sistemas Autónomos a través del IBGP neighbor
router B (65005, 65004, 65003). De esta manera, las más corta trayectoria de Sistemas Autónomos del
router C al AS 65003 es a través del router A.
La mejor trayectoria del router C a las redes en el AS 65005 también es seleccionada por paso 4. El Shortest-
Path del router C al AS 65005 está a través del router B, porque este consiste en un AS (65005) comparado con
los cuatro Sistemas Autónomos (65002, 65003, 65004, 65005) a través del router A.
La mejor trayectoria del router C a las redes en el AS 65004 también es seleccionado por el paso 4. El Shortest-
Path del router C al AS 65004 está a través del router B, porque este consiste en dos Sistemas Autónomos
(65005, 65004) comparado a los tres Sistema Autónomos (65002, 65003, 65004) a través del router A.
6.6.5 Ejemplo de Local Preference en BGP (continuación)

La figura 1 muestra la BGP forwarding table en el router C en el AS 65001 con solamente los default settings
para la selección de trayectoria BGP. El diagrama muestra solamente las redes de interés a este ejemplo:
• 172.16.0.0 en el AS 65003
• 172.24.0.0 en el AS 65005
• 172.30.0.0 en el AS 65004
La mejor trayectoria es indicada con “>” en la segunda columna de la salida.
Cada red tiene dos trayectorias que son sean loop-free, sincronización-deshabilitada, y que tienen una dirección
válida. Todas las rutas tienen un peso de 0 y una preferencia local por defecto de 100; así los pasos 1 y 2 en el
proceso de selección de la trayectoria BGP son iguales.
Esta router no originó ninguna de las rutas (paso 3), así que el proceso se mueve al paso 4, y BGP elige la
trayectoria más corta de Sistemas Autónomos como sigue:
• Para la red 172.16.0.0, la trayectoria más corta de Sistema Autónomo de dos Sistema Autónomos
(65002, 65003) está a través del next hop de 192.168.28.1.
• Para la red 172.24.0.0, la trayectoria más corta de Sistema Autónomo del (65005) está a través del next
hop de 172.20.50.1.
• Para la red 172.30.0.0, la trayectoria más corta de Sistema Autónomo de (65005, 65004) está a través
del next hop de 172.20.50.1.

Ninguno de los dos ni el router A ni el router

B esta utilizando la opción next-hop-self
en este ejemplo
Un análisis de tráfico revela lo siguiente:

• El link a través del router B a la
172.20.50.1 es muy usado, y el link
a través del router A a la red
192.168.28.1 es apenas utilizado.
• Las tres redes destino de mas
grande volumen en el Internet del
AS de 65001 son 172.30.0.0,
172.24.0.0, y 172.16.0.0.
• Treinta por ciento de todo el tráfico
del Internet va a la red 172.24.0.0
(vía el router B); 20 por ciento van a
la red 172.30.0.0 (vía el router B); y
10 por ciento van a la red
172.16.0.0 (vía el router A). Los
otros 40 por ciento van a otras
destinos. Solamente 10 por ciento Figura 1 – Tabla con valores por defecto del Router C
de todo el tráfico esta utilizando el
link fuera del router A a la red 192.168.28.1, y el 50 por ciento de todo el tráfico está utilizando el link
fuera del router B a la 172.20.50.1
El administrador de red ha decidido desviar el tráfico para la red 172.30.0.0 y enviar este hacia fuera del router
A para el next hop del 192.168.28.1, de modo que el cargamento entre los routers A y B sea más equilibrado.
6.6.6 Ejemplo de Local Preference en BGP (continuación)

La figura 1 muestra que usando un route
map en el router A para alterar la
actualización BGP de la red 172.30.0.0 del
router X (192.168.28.1) para tener una alta
preferencia de 400 de modo que este sea
preferido.
La primera línea del route map es una

declaración de permiso con un número de
secuencia de 10 para un route map llamado
“local_pref”; esto define la primera
declaración del route-map. La condición de
emparejamiento para esta declaración está
comprobando todas las redes que sean
permitidas por la access list 65. La access
list 65 permite a todas las redes que
comiencen con los primeros dos octetos de
la 172.30.0.0. El route map fija esas redes Figura 1 – Route map para el router A
con una preferencia local de 400.
La segunda declaración del route map es una declaración de permiso con un número de secuencia de 20 para
el route map “local_pref”, pero no tiene ningún match o declaraciones fijadas. Esta declaración es una
declaración de permit-all para todos los route maps. Ya que no hay condiciones de match para las redes
restantes, están totalmente permitidas con sus ajustes actuales. En este caso, la preferencia local para la red
172.16.0.0 y 172.24.0.0 quedan fijadas por defecto de 100. El número de secuencia de 20 se elige para la
segunda declaración en caso de que otras políticas más adelante tengan que ser puestas en ejecución antes de
la declaración permit-all
Este route map se liga al neighbor 192.168.28.1 como un route map de entrada; por lo tanto, como el router A
recibe actualizaciones de la 192.168.28.1, las procesa a través del route map del local_pref y fija la preferencia
local según el caso mientras que las redes se ponen en la tabla de BGP forwarding del router A.
La figura 2 muestra la BGP forwarding table

del router C en el AS 65001 después de que
la sesión BGP ha sido reseteada. Esta
ilustra que el router C ha aprendido sobre el
nuevo valor de local preferente (400) que
venía del router A para la red 172.30.0.0.
La única diferencia en esta tabla comparada

al ejemplo anterior, el cual no tiene una
manipulación de la local preferente, es que
la mejor ruta a la red 172.30.0.0 ahora está
con la red 192.168.28.1 ya que su
preferencia local de 400 es más alta que la
preferencia local de 100 para el next hop de
172.20.50.1.
La trayectoria de Sistema Autónomo a

través de la 172.20.50.1 sigue siendo más
corta que la trayectoria con la 192.168.28.1,
pero la longitud de la trayectoria no se
evalúa hasta el paso 4, mientras que la
preferencia local se examina en el paso 2. Figura 2 – Tabla con preferencia locales aprendidas en el Router C
La trayectoria con la más alta preferencia
local elegida como la mejor trayectoria
6.6.7 Seteando la MED con Route Maps

Recordar que MED es utilizado para decidir
cómo entrar en un Sistema Autónomo. Se
utiliza cuando las trayectorias múltiples
existen entre dos Sistema Autónomos y un
Sistema Autónomo está intentando
influenciar en la trayectoria entrante del
otro.
Ya que MED se evalúa tarde en el proceso

de selección de trayectoria de BGP (paso
6), no tiene generalmente ninguna influencia
en el proceso de selección de BGP. Por
ejemplo, un Sistema Autónomo que recibe Figura 1 – Cambiando MED para todos los routers
un MED para una ruta puede cambiar su
preferencia local para permitir al Sistema
Autónomo eliminar lo que está anunciando
el otro Sistema Autónomo con su valor de
MED. Figura 2 – Parámetro del comando default-metric
Cuando BGP está comparando los valores de MED para la misma red destino en el proceso de selección de
trayectoria, se prefiere el valor más bajo de MED.
El valor por defecto de MED para cada red que un Sistema Autónomo posee y anuncie a un EBGP neighbor se
fija a 0. Para cambiar este valor, utilizar el comando default-metric number bajo el proceso BGP. La figura 1 y
figura 2 muestra los parámetros de este comando

6.6.8 BGP Utilizando Route Maps y un Ejemplo de MED

La figura 1 es utilizada en la siguiente configuración para demostrar cómo manipular el tráfico de entrada
utilizando route maps para cambiar el
atributo BGP MED. La intención de estos
route maps es señalar al router A como la
trayectoria preferida para alcanzar las redes
192.168.25.0/24 y 192.168.26.0/24, y para
señalar al router B como la trayectoria
preferida para alcanzar la red
192.168.24.0/24. Las otras redes deberían
aun estar accesibles a través de cada router
en caso de que un link o router falle
6.6.9 BGP Utilizando Route Figura 1 – Usando route maps y el MED

Maps y un Ejemplo de MED
(continuación)
El MED es fijado de salida cuando un router
está anunciando a un EBGP neighbor. En el
ejemplo de configuración para el router A en
la figura 1, un route map nombrado
“med_65004” se liga al neighbor
192.168.28.1 como un route map de salida
Cuando el router A envía una actualización

al neighbor 192.168.28.1 (router X), procesa
la actualización de salida a través del route
map med_65004 y utiliza una declaración
del sistema para cambiar cualquiera de
valores que son especificados, siempre y
cuando la declaración de emparejamiento
precedente se resuelva en la sección del
route map.

Figura 1 – Route map para el router A
declaración de permiso con un número de
secuencia de 10 para el route map
med_65004. Esto define la primera declaración del route-map. La condición de match para esta declaración
chequea todas las redes que son permitidas por la access list 66
La primera línea de la access list 66 permite a cualquier red que comience con los primeros tres octetos de
192.168.25.0, y la segunda línea permite las redes que comienzan con los primeros tres octetos de
192.168.26.0.
Todas las redes que son permitidas por cualquiera de estas líneas se fijan un MED de 100. El resto de las redes
son negadas por esta access list (hay un implícito deny all al final de todas las access lists), así que estas no
son seteadas con un MED de 100; su MED no es cambiado. Estas otras redes deben proceder a la siguiente
declaración de route map en el route map med_65004.
el route map med_65004. El route map no tiene ninguna declaración de match, apenas tiene el comando set
metric 200. Este es una declaración de permitir todo para los route maps.
Ya que el administrador de red no especifica una condición de match para esta porción del route map, todas las
redes que son procesadas a través de esta sección del route map (número de secuencia 100) se permiten, y
estas fijan un MED de 200. Si el administrador de red no fija el MED a 200, por defecto habría sido un MED de
0. Puesto que 0 es menos que 100, las rutas con un MED de 0 habrían sido las trayectorias preferidas a las
redes en el AS 65001.
Semejantemente, en el ejemplo de
configuración para el router B en la figura 2,
un route map nombrado “med_65004” se
liga al neighbor 172.20.50.1 (router Y) como
route map de salida
Antes de que el router B envíe una

actualización al neighbor 172.20.50.1,
procesa la actualización de salida a través
del route map med_65004 y utiliza una
declaración del sistema para cambiar
cualquier valor que este especificado,
siempre y cuando la declaración precedente
de emparejamiento se resuelva en esta
sección del route map.

declaración de permiso con un número de Figura 2 – Route map para el router B
secuencia de 10 para el route map
med_65004, el cual define la primera declaración del route-map. La condición de emparejamiento para esa
línea comprueba todas las redes que son permitidas por la access list 66. La access list 66 en el router B
permite a cualquier red que comience con los primeros tres octetos de 192.168.24.0.
Cualquier red que sea permitida por esta línea se fija un MED de 100. El resto de las redes son negadas por
esta access list, así que no fijan a 100 el valor de MED. Estas otras redes deben seguir a la siguiente
declaración en el route map med_65004.
el route map med_65004, pero no tiene ninguna declaración de match, apenas un comando set metric 200.
Este es una declaración de todo permiso para los route maps. Ya que el administrador de red no específica una
condición de match para esta porción del route map, todas las redes que son procesadas con este asunto son
permitidas, pero son fijadas con un MED de 200.
Si el administrador de red no fijara el MED a 200, por defecto habría sido fijado con un MED de 0. ya que 0 es
menos de 100, las rutas con un MED de 0 habrían sido las trayectorias preferidas a las redes en el AS 65001
6.6.10 BGP Utilizando Route Maps y un Ejemplo de MED (continuación)

La BGP forwarding table en el router Z en el AS 65004 muestra las redes que se han aprendido del AS de
65001. Se han omitido otras redes que no afectan este ejemplo.
En el router Z, hay múltiples trayectorias para alcanzar a cada red. Figura 1. Todas estas trayectorias tienen
direcciones válidas de next hop, tienen sincronización inhabilitada, y están libres de lazos. Todas las redes
tienen un peso de 0 y una preferencia local de 100, así que los pasos 1 y 2 no determinan la mejor trayectoria.
Ninguna de las rutas fue originada por este router o por o algún router en el AS 65004; todas las redes vinieron
del AS 65001, así que el paso 3 no se aplica. Todas las redes tienen un AS path de uno Sistema Autónomo
(65001) y fueron introducidas dentro del BGP con declaración de red (“i” es el código de origen), así que los
pasos 4 y 5 son iguales.
El paso 6 indica que BGP elige la MED más baja si todos los pasos precedentes son igual o no se aplican.

Para la red 192.168.24.0, el next hop de
172.20.50.2 tiene una MED más baja que el
next hop de 192.168.28.2; por lo tanto, para
la red 192.168.24.0, la trayectoria a través
de la 172.20.50.2 es la trayectoria preferida.
Para las redes 192.168.25.0 y 192.168.26.0,
el next hop de la 192.168.28.2 tiene un
MED más bajo de 100 comparado al MED
de 200 a través del next hop de
172.20.50.2; por lo tanto, 192.168.28.2 es la
trayectoria preferida para esas redes
Figura 1 – MED aprendido por el router Z
6.6.11 Implementando BGP en la Empresa

La figura 1 representa una puesta en
práctica típica de BGP en una empresa. La
empresa es multihomed a dos ISPs para
aumentar la confiabilidad y el
funcionamiento de su conexión al Internet.
El ISPs puede pasar solamente las rutas

por defecto o puede también pasar otras
rutas específicas, o aún todas las rutas, a la
empresa.
Los routers de la empresa conectados a los

ISPs corren EBGP con los routers del ISP e
IBGP entre sí mismos; así todos los routers
en la trayectoria de tránsito dentro del
Sistema Autónomo de la empresa corren Figura 1 – BGP en una empresa
IBGP. Estos routers pasan las rutas por
defecto a los otros routers en la empresa en vez de redistribuir BGP en el protocolo de enrutamiento interior.
Los atributos de BGP pueden ser manipulados, utilizando los métodos discutidos hasta ahora, con cualquier de
los routers que corren BGP para afectar la trayectoria del tráfico para y desde el Sistema Autónomos.
Resumen
El Internet ha demostrado ser una herramienta valiosa a muchas compañías, dando por resultado múltiples
conexiones redundantes a muchos Internet service providers (ISPs). El Border Gateway Protocol (BGP) es
utilizado por ISPs para mover tráfico entre los sistemas autónomos y también utilizado por las compañías
individuales que son multihomed para controlar la selección de trayectorias.

Módulo 8: IPv6
Descripción
IP version 6 (IPv6) fue desarrollado para superar las limitaciones del estándar actual, IP version 4 (IPv4). IPv4
permite que los sistemas extremos se comuniquen y formen el cimiento de Internet como la conocemos hoy.
Sin embargo, uno de los defectos principales de IPv4 es su cantidad limitada de espacio de dirección. La
explosión de nuevos dispositivos IP-enabled y el crecimiento de regiones subdesarrolladas han impulsado la
necesidad de más direcciones.
En los Estados Unidos, el Department of Defense (DoD) es un conductor principal para la adopción de IPv6.
Las otras oportunidades de mercado principales son la National Research and Education Network (NREN),
agencias gubernamentales, empresas, proveedores de servicio, home networking, electrodomésticos de
consumidor, juego en línea distribuido, y servicios wireless.
Este módulo proporciona una descripción de IPv6, direccionamiento y enrutamiento IPv6, OSPFv3, y la
traducción IPv4 a IPv6.
8.1 Explicación de IPv6

8.1.1 Introducción a IPv6
La capacidad de escalar redes para las demandas futuras requiere una fuente ilimitada de direcciones IP y
movilidad mejorada. IP version 6 (IPv6) combina el direccionamiento expandido con un encabezado más
eficiente y feature-rich para enfrentar las demandas para redes escalables en el futuro.
IPv6 satisface los requerimientos cada vez más complejos de direccionamiento jerárquico que IP version 4
(IPv4) no proporciona. Un beneficio clave es que IPv6 puede recrear comunicaciones extremo-a-extremo sin la
necesidad de la Network Address Translation (NAT) - un requerimiento para una nueva generación de
aplicaciones de experiencia-compartida y de tiempo real. Cisco Systems actualmente soporta IPv6 en Cisco
IOS Software Release 12.2(2)T y posteriores.
La Internet se transformara después de que IPv6 reemplaze por completo a IPv4. Sin embargo, IPv4 no está en
peligro de desaparecer de la noche a la mañana. Más bien, coexistirá y después será substituido gradualmente
por IPv6. Este cambio ya ha comenzado, particularmente en Europa, Japón, y Asia del Pacífico. Estas áreas
han estado agotando sus direcciones IPv4 asignadas, lo cual hace a IPv6 más atractivo a todos. Además de su
potencial técnico y de negocio, IPv6 ofrece virtualmente una fuente ilimitada de direcciones IP. IPv4 provee
actualmente aproximadamente 2 billones direcciones utilizables con su espacio de dirección de 32 bits.
Debido al abundante espacio de dirección de 128 bits de IPv6, puede generar un stock virtualmente ilimitado de
direcciones - lo suficiente para asignar a cada uno en el planeta.
Como consecuencia, algunos países, tales como Japón, están adoptando agresivamente IPv6. Otros, tales
como la Unión Europea, se están moviendo hacia IPv6, y China está considerando construir redes puras IPv6
desde el ground up.
Incluso en Norteamérica, donde las direcciones de Internet son abundantes, el U.S. Department of Defense
(DoD) dio un mandato en octubre el 1 del 2003, que todo el equipo nuevo comprado debe ser IPv6-capable. El
DoD intenta cambiar enteramente a equipos IPv6 por el 2008.
8.1.2 Características de IPv6

IPv6 es una mejora poderosa para IPv4, y varias características IPv6 ofrecen mejoras funcionales:
• Espacio de dirección más grande: Ofrece alcanzabilidad y flexibilidad globales mejoradas; la
agregación de prefijos que se anuncian en las tablas de enrutamiento; multihoming a varios Internet
¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 1

service providers (ISPs); autoconfiguración que puede incluir direcciones de capa de enlace en el
espacio de dirección; opciones plug-and-play; redireccionamiento publico a privado extremo a extremo
sin traducción de dirección; y mecanismos simplificados para renumeración y modificación de dirección.
• Encabezado más simple: Proporciona mejor eficiencia de enrutamiento; no hay broadcasts y así
ninguna amenaza potencial de tormentas de broadcast; no hay necesidad de procesar checksums;
mecanismos de encabezado de extensión más simples y más eficientes; y las etiquetas de flujo para
procesamiento por flujo sin necesidad de abrir el paquete interno de transporte para identificar varios
flujos de trafico.
• Movilidad y seguridad: Asegura conformidad con funcionalidad de estándares IP móvil y IPsec ; la
movilidad esta incorporada, por que cualquier nodo IPv6 puede usarla cuando sea necesario; y permite
a la gente desplazarse en redes con dispositivos de red móviles - con muchos que tienen conectividad
inalámbrica.
Mobile IP es un estándar de la Internet Engineering Task Force (IETF) disponible para IPv4 e IPv6. El
estándar permite a los dispositivos móviles moverse sin interrupciones en conexiones de red
establecidas. Debido a que IPv4 no proporciona automáticamente esta clase de movilidad, usted debe
agregarla con configuraciones adicionales.
IPsec es el estándar IETF para la seguridad de red IP, disponible para IPv4 e IPv6. Aunque las
funcionalidades son esencialmente idénticas en ambos ambientes, IPsec es obligatorio en IPv6. IPsec
esta habilitado en cada nodo IPv6 y está disponible para el uso. La disponibilidad de IPsec en todos los
nodos hace a la Internet IPv6 más segura. IPsec también requiere claves para cada parte, lo que
implica un despliegue y distribución claves global.
• Riqueza de transición: Usted puede incorporar capacidades IPv4 existentes en IPv6 de las siguientes
maneras:
o Configure un dual stack con IPv4 e IPv6 en el interfaz de un dispositivo de red.
o Use la técnica IPv6 sobre IPv4 (también llamada tunneling 6to4), que usa un túnel IPv4 para
llevar tráfico IPv6. Este método (RFC 3056) reemplaza al tunneling IPv4-compatible (RFC
2893). Cisco IOS Software Release 12.3(2)T (y posteriores) también permite la protocol
translation (NAT-PT) entre IPv6 e IPv4. Esta traducción permite la comunicación directa entre
los hosts que hablan protocolos diferentes.
8.1.3 Espacio de Dirección Largo

IPv6 aumenta el número de bits dirección en un factor de cuatro, de 32 a 128, lo que permite un número muy
grande de nodos direccionables. Sin embargo, como en cualquier esquema de dirección, no todas las
direcciones están utilizadas o disponibles.
El uso de la dirección de protocolo IPv4 actual se extendió al aplicar técnicas tales como NAT y asignaciones de
dirección temporales. Pero la manipulación de la carga útil de los datos por dispositivos intermedios desafía (o
complica) las ventajas de la comunicación del peer-to-peer y la calidad de servicio (QoS).
IPv6 da a cada usuario múltiples direcciones globales que se pueden usar para una variedad amplia de
dispositivos, incluyendo celulares, personal digital assistants (PDAs), y vehículos IP-enabled. Estas direcciones
son alcanzables sin usar la traducción de direcciones IP, pooling, y técnicas de asignación temporales.
El aumento del número de bits para la dirección también aumenta el tamaño del encabezado IPv6. Debido a
que cada encabezado IP contiene una dirección origen y destino, el tamaño del campo de encabezado es de
256 bits para IPv6, comparado a los 64 bits para IPv4.
Nota: Para más información IETF sobre detalles del direccionamiento IPv6, consultar RFC 3513.
Espacios de dirección más grandes dan espacio a los ISPs y a las organizaciones para asignaciones de
dirección grandes. Un ISP agrega todos los prefijos de sus clientes en un solo prefijo y anuncia el prefijo único
al Internet IPv6. El espacio de dirección incrementado es suficiente para permitir que las organizaciones definan
un prefijo único para la red entera.

La agregación de prefijos de cliente da lugar a una tabla de enrutamiento eficiente y escalable. El enrutamiento
escalable es necesario para expandir la adopción más amplia de funciones de red, permitiendo que Internet
adecuar lo siguiente:
• Número creciente de consumidores de banda ancha con de alta velocidad, conexiones always-on
• Los usuarios pasan mas tiempo online adquiriendo servicios de comunicación (tales como música) y
participando en ofertas de alto valor que se pueden encontrar
• Redes caseras con aplicaciones de red expandidas tales como Voice over IP (VoIP) inalámbricas,
vigilancia casera, y los servicios avanzados tales como vídeo on demand (VoD) en tiempo real
• Juegos escalables masivamente con participantes globales
• Media-rich e-learning, proveyendo a los principiantes con laboratorios remotos y simulaciones de
laboratorio a pedido
8.2 Direccionamiento IPv6

8.2.1 Arquitectura del Direccionamiento IPv6
El encabezado IPv4 contiene 12 campos de encabezado básicos, seguidos por un campo de opciones y una
porción de datos (generalmente el segmento de capa de transporte). El encabezado IPv4 básico tiene un
tamaño fijo de 20 octetos. El campo de opciones de longitud variable aumenta el tamaño del encabezado IP
total. IPv6 contiene cinco de los 12 campos de encabezado básicos de IPv4. El encabezado IPv6 no requiere
los otros siete campos.
Los routers manejan fragmentación en IPv4, lo que causa una variedad de problemas de procesamiento. Los
routers IPv6 no realizan la fragmentación. En su lugar, un proceso de descubrimiento determina la maximum
transmission unit (MTU) óptima a usar durante una sesión dada.
En el proceso de descubrimiento, el dispositivo IPv6 origen intenta enviar un paquete del tamaño especificado
por las capas superiores, tales como la capa del transporte o aplicación. Si el dispositivo recibe un mensaje
"ICMP packet too big", retransmite el paquete de descubrimiento MTU con un MTU más pequeño y repite el
proceso hasta que consiga una respuesta de que llegó intacto el paquete de descubrimiento. Luego fija la MTU
para la sesión.
El mensaje "ICMP packet too big" contiene el tamaño de MTU apropiado para el camino. Cada dispositivo
origen necesita hacer seguimiento del tamaño de MTU para cada sesión. Generalmente, el seguimiento se
hace creando un cache que se base en la dirección destino. Sin embargo, también puede ser hecho usando la
etiqueta de flujo. Si se realiza el enrutamiento basado en el origen, el seguimiento del tamaño de MTU puede
usar la dirección origen.
El proceso de descubrimiento es beneficioso porque, como los caminos de enrutamiento cambian, una MTU
nueva podría ser la más apropiada. Cuando un dispositivo recibe un mensaje "ICMP packet too big", éste
disminuye el tamaño de su MTU si el mensaje Internet Control Message Protocol (ICMP) contiene una MTU
recomendada que sea menor que la MTU actual del dispositivo.
Un dispositivo realiza un descubrimiento de MTU cada 5 minutos para ver si la MTU ha aumentado a lo largo
del camino. Las capas de aplicación y transporte para IPv6 aceptan notificaciones de reducción de MTU desde
la capa IPv6.
Si no aceptan las notificaciones, IPv6 tiene un mecanismo para fragmentar paquetes que son demasiado
grandes. Sin embargo, se induce a las capas superiores que eviten enviar mensajes que requieren
fragmentación.
Las tecnologías de la capa de enlace ya realizan checksum y control de error. Debido a que las tecnologías de
la capa de enlace son relativamente confiables, una checksum de encabezado IP se considera redundante. Sin
la checksum de encabezado IP, las checksums opcionales de capa superior, tales como el User Datagram
Protocol (UDP), son obligatorias ahora.

8.2.2 Comparación de los Encabezados IPv4 e IPv6

El encabezado IPv6 tiene 40 octetos, en contraste a los 20 octetos en IPv4. IPv6 tiene un menor número de
campos, y el encabezado esta alineado a 64-bit para permitir el procesamiento rápido por los procesadores
actuales. Los campos de dirección son cuatro veces más grandes que en IPv4.
El encabezado IPv6 contiene estos campos:

• Versión: Campo de 4 bits, lo mismo que en IPv4. Contiene el número 6 en vez del número 4 para IPv4.
• Clase de Tráfico: Campo de 8 bits similar al campo type of sevice (TOS) en IPv4. Etiqueta al paquete
con una clase de tráfico que use en Differentiated Services (DiffServ). Estas funcionalidades son las
mismas para IPv6 e IPv4.
• Etiqueta de Flujo: Campo de 20 bits que permite que un flujo particular de tráfico sea etiquetado. Se
puede usar para técnicas de switching multicapa y ejecucion de conmutación de paquetes más rápido.
• Longitud de Carga Util: Similar al campo Longitud Total en IPv4. Especifica la longitud de la carga útil,
en bytes, que el paquete está encapsulando.
• Encabezado Siguiente: Especifica qué encabezado sigue al encabezado del paquete IPv6. Puede ser
un paquete de capa de transporte, tal como TCP o UDP, o puede ser un encabezado de extensión.
Este campo es similar al campo Protocolo en IPv4.
• Límite de Salto: Especifica el número máximo de saltos que un paquete IP puede atravesar. Cada
salto o router disminuye a este campo en uno (similar al campo Time to Live [TTL] en IPv4). Debido a
que no hay checksum en el encabezado IPv6, el router puede disminuir el campo sin recomputar la
checksum. La recomputacion cuesta tiempo de procesamiento valioso en los routers IPv4.
• Dirección Origen: Este campo tiene 16 octetos o 128 bits. Identifica al origen del paquete.
• Dirección Destino: Este campo tiene 16 octetos o 128 bits. Identifica al destino del paquete.
• Encabezados de Extensión: Sigue a los ocho campos anteriores. El número de encabezados de
extensión no es fijo, por lo que la longitud total de la cadena del encabezado de extensión es variable.
8.2.3 Encabezados de Extensión IPv6

Hay muchos tipos de encabezados de extensión. Cuando se usan múltiples encabezados de extensión en el
mismo paquete, el orden de los encabezados debe ser como sigue:
1. Encabezado IPv6: Encabezado básico descrito en la figura anterior.
2. Encabezado de opciones salto-por-salto: Cuando se usa para la alarma del router (Resource
Reservation Protocol [RSVP] y Multicast Listener Discovery version 1 [MLDv1]) y jumbogram, este
encabezado (valor = 0) procesa todos los saltos en el camino de un paquete. Cuando se presenta,
siempre el encabezado de opciones salto-por-salto sigue inmediatamente después del encabezado del
paquete IPv6 básico.
3. Encabezado de opciones de destino (cuando se usa el encabezado de enrutamiento): Este
encabezado (valor = 60) puede seguir cualquier encabezado de opciones salto-por-salto, en cuyo caso
el encabezado de opciones de destino se procesa en el destino final y también en cada dirección
visitada especificada por un encabezado de enrutamiento. Alternativamente, el encabezado de
opciones de destino puede seguir a cualquier encabezado Encapsulating Security Payload (ESP), en
cuyo caso el encabezado de opciones de destino se procesa solamente en el destino final. Por ejemplo,
el IP móvil usa este encabezado.
4. Encabezado de enrutamiento: Usado para el enrutamiento del origen e IPv6 móvil (valor = 43).
5. Encabezado de fragmentación: Usado cuando un origen debe fragmentar un paquete que sea más
grande que la MTU para el camino entre sí mismo y un dispositivo destino. El encabezado de fragmento
se usa en cada paquete fragmentado.
6. Encabezado de autenticación y encabezado de carga útil de seguridad de encapsulamiento:
Usado dentro de IPsec para proporcionar autenticación, integridad, y confidencialidad de un paquete. El
encabezado de autenticación (valor = 51) y el encabezado ESP (valor = 50) son idénticos para IPv4 e
IPv6.
7. Encabezado de capa superior: Encabezados típicos usados dentro de un paquete para transportar los
datos. Los dos protocolos de transporte principales son TCP (valor = 6) y UDP (valor = 17).

8.2.4 Definición de la Representación de Dirección

Las direcciones IPv6 de 128 bits se representan dividiéndolas en ocho segmentos de 16 bits. Cada segmento
se escribe en hexadecimal entre 0x000 y 0xFFF, separados por dos puntos. Los dígitos hexadecimales A, B, C,
D, E, y F representados en IPv6 no son sensibles a mayúsculas.
IPv6 no requiere notación de la secuencia de la dirección de forma explícita. Use las pautas siguientes para las
notaciones de la secuencia de la dirección IPv6:
• Los ceros iniciales en un campo son opcionales, o sea 09C0 = 9C0 y 0000 = 0.
• Campos sucesivos de ceros se pueden representar como "::" solamente una vez en una dirección.
• Una dirección sin especificar se escribe como "::" porque contiene solamente ceros.
Usar la notación "::" reduce grandemente el tamaño de la mayoría de las direcciones. Por ejemplo,
FF01:0:0:0:0:0:0:1 se convierte en FF01::1.
Nota: Un analizador sintáctico de dirección identifica el número de ceros faltantes separando las dos partes e
introduciendo 0 hasta que los 128 bits estén completos. Si se colocan dos notaciones "::" en la dirección, no hay
forma de identificar el tamaño de cada bloque de ceros.
8.2.5 Tipos de Direcciones IPv6

La estructura del direccionamiento IPv6
esta definida en múltiples RFCs,
incluyendo RFC 3513 y el nuevo RFC
4291 (volviendo obsoleto a RFC 3513).
Fig.1 Cada RFC define tres tipos de
direcciones IPv6: Fig.2
• Dirección unicast
• Dirección muticast
• Dirección anycast
Dirección Unicast
Figura 1 – Direccionamiento IPv6 unicast
Una dirección unicast identifica un solo
dispositivo. Un paquete enviado a una
dirección unicast es entregado a la
interfaz identificada por esa dirección.
Hay dos tipos de direcciones unicast:

• Dirección unicast de link-
local: El alcance se configura
para enlace único. La dirección
es única solamente en este
enlace, y no es ruteable fuera
del enlace.
• Dirección unicast global:
Globalmente única, así que
puede ser enrutada
globalmente sin modificación. Figura 2 – Tipos de direcciones IPv6
Una dirección global tiene un
alcance ilimitado en la Internet mundial. Los paquetes con direcciones origen y destino globales son
enrutados hacia su destino objetivo por los routers en la Internet.
Se requieren de todas las interfaces para tener por lo menos una dirección unicast link-local. Sin embargo, una
característica fundamental del IPv6 es que una sola interfaz puede también tener múltiples direcciones IPv6 de
cualquier tipo (unicast, anycast, y multicast).
Nota: También existe una dirección unicast de site-local; sin embargo, la IETF está trabajando actualmente en
quitar o reemplazar direcciones site-local. Por lo tanto, este módulo no incluye este tipo de dirección.
Dirección Multicast
IPv6 no tiene direcciones de broadcast. El broadcasting en IPv4 da varios problemas: Genera un número de
interrupciones en cada computadora en la red y, en algunos casos, provoca malfuncionamientos que pueden
parar por completo a una red entera. Este desastroso evento de red se llama "tormenta de broadcast"
Los broadcasts son reemplazados por direcciones multicast. El multicast permite la operación eficiente de la red
al usar funcionalmente grupos multicast específicos para enviar peticiones a un número limitado de
computadoras en la red. Un paquete enviado a una dirección multicast se entrega a todas las interfaces
identificadas por esa dirección.
El rango de direcciones multicast en IPv6 es más grande que en IPv4. Para el futuro próximo, la asignación de
grupos multicast no estará limitada.
Dirección Anycast
IPv6 también define un nuevo tipo de dirección llamado anycast. Una dirección anycast identifica una lista de
dispositivos o nodos; por lo tanto, una dirección anycast identifica múltiples interfaces.
Un paquete enviado a una dirección anycast se entrega a la interfaz más cercana, según lo definido por los
protocolos de enrutamiento en uso.
Las direcciones anycast son

sintácticamente indistinguibles de
direcciones unicast globales, porque las
direcciones anycast se asignan del
espacio de dirección unicast global.
Nota: Las direcciones anycast no se
pueden usar como la dirección origen de
un paquete IPv6.
Direcciones especiales
Hay un número de direcciones con
significado especial en IPv6. Algunos de Figura 3 – Direcciones especiales IPv6
éstos se presentan en Figura 3
8.2.6 Direcciones Unicast Globales y Anycast IPv6

Las direcciones unicast globales y anycast
comparten el mismo formato. El espacio de
dirección unicast asigna direcciones
anycast. Estas direcciones aparecen como
direcciones unicast para los dispositivos
que no se configuran para anycast. Figura1.
Cuando una dirección unicast se asigna a

más de una interfaz, volviéndola asi en una
dirección anycast, los nodos a los cuales se
asigna la dirección se deben configurar
explícitamente para usar y reconocer la
dirección anycast.
Un paquete que se envía a una dirección

anycast enruta al dispositivo o interfaz más
cercana que comparte la dirección. Un
remitente crea un paquete con anycast
como la dirección destino y lo remite a su Figura 1 – Direcciones globales IPv6 unicast (y anycast) addresses
router más cercano. El origen puede usar
direcciones anycast para controlar el camino a través del cual el trafico fluye.
Un ejemplo del uso del anycast en una red multihomed Border Gateway Protocol (BGP) se da cuando un cliente
tiene múltiples ISPs con múltiples conexiones a otro. El cliente puede configurar una dirección anycast diferente
para cada ISP. Cada router para la ISP dada tiene la misma dirección anycast configurada. El dispositivo origen
puede elegir a qué ISP envía el paquete. Sin embargo, los routers a lo largo del camino determinan el router
más cercano para alcanzar a es ISP usando la dirección anycast IPv6.
Otro uso para un anycast se da cuando una LAN se une a múltiples routers. Estos routers pueden tener la
misma dirección anycast IPv6 para que los dispositivos distantes necesiten identificar solamente la dirección
anycast. Los dispositivos intermedios pueden elegir el mejor camino para alcanzar el punto de entrada más
cercano a esa subred.
La dirección unicast global IPv6 es el equivalente de la dirección unicast global IPv4. La estructura de la
dirección permite agregar prefijos de enrutamiento, de ese modo se limita el número de entradas en la tabla de
enrutamiento global. Las direcciones unicast globales usadas en enlaces se agregan hacia arriba a través de
organizaciones y eventualmente de ISPs.
Las direcciones unicast globales se definen por un prefijo de enrutamiento global, una ID de subred, y una ID de
interfaz. El espacio de dirección unicast IPv6 comprende el rango de dirección IPv6 entera, a excepción del
FF00::/8 (1111 1111), el cual se usa para las direcciones multicast. La asignación de dirección unicast global
actual por la Internet Assigned Numbers Authority (IANA) usa el rango de direcciones que comienzan con el
valor binario 001 (2000::/3), que es un octavo del espacio de dirección IPv6 total y es el bloque más grande del
bloque de direcciones asignadas.
Las direcciones con un prefijo de 2000::/3 (001) al E000::/3 (111), a excepción de las direcciones multicast
FF00::/8 (1111 1111), son requeridas para tener identificadores de interfaz de 64 bits en el formato (EUI)-64 del
identificador universal extendido.
La dirección unicast global consiste típicamente de un prefijo de enrutamiento global de 48 bits y un ID subred
de 16 bits. En la ahora obsoleta RFC 2374, el Formato de Dirección Unicast Global Agregable IPv6, el prefijo de
enrutamiento global incluyó otros dos campos estructurados jerárquicamente llamados Top Level Aggregator y
Next-Level Aggregator. Debido a que estos campos fueron basados en políticas, la IETF decidió quitarlos de los
RFCs. Sin embargo, algunas redes IPv6 existentes desplegadas al principio pudieron todavía usar redes
basadas en arquitectura más antigua. Un campo de subnet de 16 bits llamado ID de subred podría ser usada
por organizaciones individuales para crear su propia jerarquía de direccionamiento local e identificar subredes.
Este campo permite que una organización use hasta 65.535 subredes individuales. (el RFC 2374 ha sido
sustituido por el RFC 3587.)
8.3 Direcciones IPv6 Dinámicas

8.3.1 Definición de las Direcciones de Interfaz de Host
Una dirección IPv6 tiene dos partes:
• Un prefijo de subred que representa la red con la cual la interfaz está conectada. El prefijo de subred es
una longitud fija de 64 bits para todas las definiciones actuales.
• Un identificador local, a veces llamado un token, que identifica únicamente al host en la red local. El
identificador local siempre es de 64 bits y se crea dinámicamente basado en medios de capa 2 y
encapsulación. En el caso simple de un medio Ethernet, el identificador local usualmente se deriva de la
dirección MAC EUI-48.
El identificador local de 64 bits en una dirección IPv6 identifica a una interfaz única en un enlace. Un enlace es
un medio de red sobre el cual los nodos de red se comunican usando la capa de enlace. El identificador de
interfaz puede también ser único sobre un alcance más amplio. En muchos casos, un identificador de interfaz
es igual a o se basa en la dirección (MAC) de capa de enlace de una interfaz. Como en IPv4, un prefijo de
subred en IPv6 se asocia con un enlace.

8.3.2 Dirección Local de Enlace

Los identificadores de interfaz en
direcciones IPv6 identifican interfaces
en un enlace. Las direcciones link-local
también pueden ser pensadas como la
porción de host de una dirección IPv6.
La dirección es única solamente en este

enlace, y no es ruteable fuera del
enlace. Los paquetes con un destino
link-local deben permanecer en el
enlace donde fueron generados. Los
routers que podrían remitirlos a otros
enlaces no están permitidos porque no
ha habido verificación de la unicidad
fuera del contexto del enlace origen.
Fig.1
Las direcciones link-local se crean

dinámicamente usando un prefijo link- Figura 1 – Direcciones de enlace local
local de FE80::/10 y un identificador de
interfaz de 64 bits en un proceso llamado autoconfiguración stateless.
8.3.3 Autoconfiguración Stateless

La autoconfiguración stateless es una característica plug-and-play que permite a los dispositivos conectarse
automáticamente con una red IPv6 sin configuración manual y sin servidores (como servidores DHCP). DHCP y
DHCPv6 se conocen como protocolos stateful porque mantienen las tablas dentro de servidores dedicados.
El protocolo de autoconfiguración stateless no necesita ningún servidor o relevo porque no hay estado a
mantener. Cada sistema IPv6 (con excepción de los routers) puede construir su propia dirección global unicast,
lo cual permite nuevos dispositivos, tales como celulares, los dispositivos inalámbricos, electrodomésticos, y
redes caseras, se desplieguen en la Internet.
Debido a que la longitud de prefijo es fija y bien conocida, un sistema construye automáticamente una dirección
link-local durante la fase de la inicialización de los NICs IPv6. Después de la verificación de unicidad, este
sistema puede comunicarse con otros
hosts IPv6 en ese enlace sin ninguna
otra intervención manual.
Para un sistema conectado con un

enlace Ethernet, la construcción y
validación de la dirección link-local se
logra en las fases siguientes. Figura 1.
Figura 1 – Fases de autoconfiguración stateless
Fase 1
Aunque manualmente configurable, el método más común para obtener un identificador único en un enlace
Ethernet es usando la dirección MAC EUI-48 y aplicando el algoritmo estándar IEEE EUI-64 modificado.
Por ejemplo, al transformar la dirección MAC 00-0C-29-C2-52-FF usando los estándares EUI-64 conduce a 00-
0C-29-FF-FE-C2-52-FF. Si esta dirección es para permanecer local, la notación IPv6 sería
000C:29FF:FEC2:52FF. Sin embargo, si la dirección es para ser una dirección unicast global, el formato
correcto es 020C:29FF:FEC2:52FF.
Nota: Para direcciones con alcance global, la porción inicial de la dirección MAC se altera de 00-0C a 02-0C.
Este proceso se discute en el tópico siguiente.

Fase 2
El bien conocido prefijo link-local fe80::/64 se premedita al identificador de 64 bits a partir de la fase uno para
crear la dirección link-local de 128 bits, por ejemplo, fe80::20c:29ff:fec2:52ff. Esta dirección se asocia a la
interfaz y etiquetada como "tentativa”
Fase 3
Antes de la asociación final, es necesario verificar la unicidad de la dirección en el enlace, llamada duplicate
address detection (DAD). La probabilidad de tener una dirección duplicada en el mismo enlace no es nula,
porque se reconoce que algunos vendedores han enviado lotes de tarjetas con las mismas direcciones MAC.
El sistema envía paquetes ICMPv6 en el enlace donde la detección tiene que ocurrir. Esos paquetes contienen
mensajes de solicitación de vecino. Su dirección origen es la dirección indefinida "::", y la dirección objetivo es la
dirección tentativa. Un nodo que ya esta usando esta dirección tentativa contesta con un mensaje de anuncio
de vecino. En ese caso, la dirección no se puede asignar a la interfaz. Si no hay respuesta, se asume que la
dirección es única y se puede asignar a la interfaz. Si la dirección no es única debe ser manipulada
manualmente.
Fase 4
Esta fase quita la etiqueta tentativa y formalmente asigna la dirección a la interfaz de red. El sistema puede
ahora comunicarse con sus vecinos en el enlace.
Para intercambiar la información con sistemas arbitrarios en la Internet global, es necesario obtener un prefijo
global. Generalmente, pero no necesariamente, el identificador construido durante la primera fase del proceso
de autoconfiguración link-local automático se añade a este prefijo global en la fase 2.
Generalmente, los prefijos globales son distribuidos a las compañías o a los usuarios finales por los ISPs.
Nota: DHCP stateless es un concepto nuevo (febrero de 2004) que saca tierra de en medio entre la
autoconfiguración stateless y el acercamiento de thick-client de DHCP stateful. DHCP stateless para IPv6
también se llama DHCP-lite. Vea RFC 3736, Stateless Dynamic Host Configuration Protocol (DHCP) Service for
IPv6.
8.3.4 EUI-64 a Identificador IPv6

Una dirección MAC (IEEE 802) tiene 48 bits
de longitud. El espacio para el identificador
local en una dirección IPv6 es de 64 bits. El
estándar EUI-64 explica cómo estirar
direcciones IEEE 802 de 48 bits a 64 bits
insertando el 0xFFFE de 16 bits en medio del
bit 24 de la direccion MAC. Esto crea un
identificador interfaz único de 64 bits. Figura 1 – Identificador de interface EUI-64 para IPv6
Por ejemplo, transformar la dirección MAC 00-

90-27-17-FC-0C usando el estándar EUI-64
da como resultado 00-90-27-FF-FE-17-FC-
0C. Al convertir esto en notación IPv6
generaría 0090:27FF:FE17:FC0C. Fig.1
Cuando el identificador de interfaz se crea a

partir de una dirección MAC Ethernet, se
asume que la dirección MAC es
universalmente única y, por lo tanto, que el
identificador de interfaz es universalmente
único.
Universal/Local (U/L) Figura 2 – Bit universal/local EUI-64

El séptimo bit en un identificador de interfaz
IPv6 se refiere como el bit universal/local, o bit U/L. Este bit identifica si este identificador de interfaz esta
universal o localmente administrado. Fig.2
• Si el bit U/L se fija a 0, la dirección se administra localmente. El administrador de red ha eliminado la
dirección manufacturada y ha especificado una dirección diferente.
• Si el bit U/L se fija a 1, el IEEE, con la designación de una ISP, ha administrado la dirección.
Por lo tanto, para hacer a esta dirección una dirección administrada universalmente, nuestra dirección IPv6
0090:27FF:FE17:FC0C se convertiría realmente en 0290:27FF:FE17:FC0C.
Individual/Grupal (I/G)
El bit I/G es el bit de orden bajo del primer byte y determina si la dirección es una dirección individual (unicast) o
una dirección grupal (multicast). Cuando se fija a 0, es una dirección unicast. Cuando se fija a 1, es una
dirección multicast.
Para una dirección de adaptador de red 802.x típico, los bits U/L y I/G se fijan a 0, correspondiendo a una
dirección MAC unicast administrada universalmente.
Debido a ciertas preocupaciones de privacidad y seguridad, la implementación de la autoconfiguración por un

host puede también crear un identificador de interfaz aleatorio usando la dirección MAC como una base. Esto
se considera una extensión de privacidad porque, sin él, crear un identificador de interfaz a partir de una
dirección MAC proporciona la capacidad de seguir la actividad y el punto de conexión.
Microsoft Windows XP actualmente soporta la implementación de esta capacidad y prefiere usar esta dirección
para la comunicación saliente, porque la dirección tiene un tiempo de vida corto y se regenera periódicamente.
8.3.5 IPv6 sobre Capas de Enlace de Datos

Aunque el comando redistribution está disponible para todos los protocolos de enrutamiento IP, éste se
comporta diferente dependiendo de los protocolos de enrutamiento IP implicados. Sin embargo, los principios
esenciales son los mismos. Por lo tanto, los ejemplos en esta sección se pueden usar como punto de partida
para cualquier esquema de redistribución.
La capa de enlace de datos define cómo se crean los identificadores de interfaz IPv6 y cómo el descubrimiento
de vecino trata con la resolución de dirección de capa de enlace de datos.
IPv6 esta definido en la mayoría de las capas de enlace de datos actuales, incluyendo el siguiente:
• Ethernet*
• PPP*
• High-Level Data Link Control (HDLC)*
• FDDI
• Token Ring
• Attached Resource Computer Network (ARCNET)
• Nonbroadcast multiaccess (NBMA)
• ATM**
• Frame Relay***
• IEEE 1394
* Cisco soporta estas capas de enlace de datos.

** Cisco soporta sólo ATM
permanent virtual circuit (PVC) y
ATM LAN Emulation (LANE).
***Cisco soporta sólo PVC Frame
Relay.
Un RFC describe el comportamiento de

IPv6 en cada una de estas capas de Figura 1 – Capas de enlace de datos Cisco que suportan IPv6
enlace de datos específicas, pero el
software Cisco IOS no necesariamente soporta todos ellos. Figura 1.
8.3.6 Multicasting IPv6

Una dirección multicast identifica un
grupo de interfaces. El tráfico enviado a
una dirección multicast viaja a múltiples
destinos al mismo tiempo. Una interfaz
puede pertenecer a cualquier número
de grupos multicast. El multicasting es
extremadamente importante para IPv6,
porque está en la base de muchas
funciones IPv6.
El formato de la dirección multicast es

como sigue: Fig.1 Figura 1 - Multicasting
• Las direcciones multicast IPv6
se definen por el prefijo FF00::/8. El segundo octeto define el tiempo de vida (flag) y el alcance de la
dirección multicast.
o El parámetro flag es igual a 0 para una permanente, o conocida, dirección multicast. Para una
dirección multicast temporal, el flag es igual a 1.
o El parámetro de alcance es igual a 1 para el alcance de la interfaz (transmisión loopback), 2
para el alcance de enlace (similar al alcance link-local unicast), 3 para el alcance subnet-local
donde las subredes pueden abarcar múltiples enlaces, 4 para el alcance admin-local
(administrativamente configurado), 5 para el alcance de sitio, 8 para el alcance de organización
(sitios múltiples), E para el alcance global. Por ejemplo, una dirección multicast que comienza
con FF02::/16 es una dirección multicast permanente con un alcance link-local.
• La ID del grupo multicast consiste de los 112 bits siguientes de la dirección multicast.
El multicast se usa con frecuencia en IPv6 y reeplaza al broadcast. No hay broadcast en IPv6. No hay Time to
Live (TTL) en el multicast IPv6. El alcance se define dentro de la dirección.
8.3.7 Direcciones Multicast Permanentes

Las direcciones multicast, FF00:: a
FF0F::, estan reservadas. Dentro de
ese rango, las siguientes son algunos
ejemplos de direcciones asignadas. Las
asignaciones son seguidas por la IANA.
Fig.1
• FF02::1 - Todos los nodos en el
enlace (alcance link-local).
• FF02::2 - Todos los routers en
el enlace.
• FF02::9 - Todos los routers
Routing Information Protocol
(RIP) IPv6 en el enlace.
• FF02::1:FFXX:XXXX - multicast
solicited-node en el enlace,
donde XX:XXXX está 24 bits a Figura 1 – Ejemplo de direcciones multicast permanentes
la derecha de la dirección
unicast o anycast correspondiente al nodo. (Los mensajes de solicitacion de vecino se envían en un
enlace local cuando un nodo desea determinar la dirección de capa de enlace de otro nodo en el mismo
enlace local, similar al Address Resolution Protocol [ARP] en IPv4.)
• FF05::101 - Todos los servidores Network Time Protocol (NTP) en el sitio (alcance site-local).
El alcance multicast site-local tiene un radio asignado administrativamente y no tiene correlación directa al
prefijo unicast site-local (ahora menospreciado) del de FEC0::/10.
8.3.8 Direcciones Que No Son Únicas

En casos muy raros, los 24 bits a la
derecha de la dirección unicast del
objetivo no son únicos en el enlace.
Las direcciones multicast solicited-node
se usan en IPv6 para la resolución de
dirección de una dirección IPv6 a una
dirección MAC en un segmento LAN.
Fig.1
Por ejemplo, considere dos nodos con

direcciones Figura 1 – Direcciones IPv6 unicast o anycast
2001:DB8:200:300:400:500:aaaa:bbbb
y 2001:DB8:200:300:400:501:aaaa:bbbb, donde el prefijo de enlace es 2001:DB8:200:300::/64. Estos dos
nodos estarían escuchando la misma dirección multicast solicited-node. Cada uno recibiría el paquete multicast,
pero solamente el nodo cuya dirección completa coincida con la dirección objetivo completa del paquete
multicast (embedida en el campo de datos del paquete multicast) respondería con un anuncio de vecino (el cual
incluye la dirección MAC verdadera). El otro nodo recibiría el paquete multicast, pero bajo la inspección de la
dirección objetivo embedida se daría cuenta que no era el receptor previsto de la petición y no respondería.
Lo que sigue describe cómo funciona esta situación.
El nodo A tiene esta característica:

• Dirección 2001:DB8:200:300:400:500:1234:5678
El nodo B tiene estas características:

• Dirección 2001:DB8:200:300:500:AAAA:BBBB
• Dirección multicast solicited-node FF02:0:0:0:0:1:FFAA:BBBB (la misma que la del nodo C)
El nodo C tiene estas características:

• Dirección 2001:DB8:200:300:501:AAAA:BBBB
• Dirección multicast solicited-node FF02:0:0:0:0:1:FFAA:BBBB (la misma que la del nodo B)
1. El nodo A desea intercambiar paquetes con el nodo B. El nodo A envía un paquete de descubrimiento
de vecino a la dirección multicast solicited-node de B, FF02:0:0:0:0:1:AAAA:BBBB. Dentro del paquete,
además de otros datos, está la dirección IPv6 completa que el nodo A está buscando
(2001:DB8:200:300:500:AAAA:BBBB). Esta se llama la dirección objetivo.
2. El nodo B y el nodo C están escuchando la misma dirección multicast, por lo que ambos reciben y
procesan el paquete.
3. El nodo B ve que la dirección objetivo dentro del paquete es su la suya y responde.
4. El nodo C ve que la dirección objetivo dentro del paquete no es la suya y no responde.
De este manera, los nodos pueden tener la misma dirección multicast solicited-node en el enlace sin causar que
el descubrimiento de vecino, la solicitación de vecino, o el anuncio de vecino funcionen incorrectamente.
8.3.9 Anycast
Una dirección anycast IPv6 es una
dirección unicast global que se asigna a
más de una interfaz. Fig.1 Cuando un
paquete se envía a una dirección
anycast, éste es enrutado hacia la
interfaz "más cercana" que tenga esa Figura 1 – Anycast
dirección.

En un alcance WAN, la interfaz más cercana se encuentra según la medida de la distancia del protocolo de
enrutamiento. En un alcance LAN, la interfaz más cercana se encuentra según el primer vecino que se
aprendio.
Lo que sigue describe las características de una dirección anycast:

• Las direcciones anycast se asignan del espacio de dirección unicast, así que son indistinguibles de la
dirección unicast. Cuando está asignada a una interfaz del nodo, el nodo se debe configurar
explícitamente para saber que la dirección es una dirección anycast.
• La idea del anycast en IP fue propuesta en 1993. Para IPv6, el anycast se define como la manera de
enviar un paquete a la interfaz más cercana que es un miembro del grupo anycast, lo que permite un
tipo de mecanismo de descubrimiento al punto más cercano.
• Hay poca experiencia con uso extenso del anycast. Pocas direcciones anycast se asignan actualmente,
incluyendo el anycast router-subnet y el anycast de agente casero Mobile IPv6.
• Una dirección anycast no se debe usar como la dirección origen de un paquete IPv6.
8.3.10 Mobilidad IPv6

La movilidad es una característica muy importante en las redes hoy. Mobile IP es un estándar IETF disponible
para IPv4 e IPv6. Mobile IP permite que los dispositivos móviles se muevan sin interrumpir conexiones actuales.
En IPv6, la movilidad esta incorporada, lo cual significa que cualquier nodo IPv6 puede usarla según sea
necesario. Sin embargo, en IPv4, la movilidad es una función nueva que debe ser agregada.
Los encabezados de enrutamiento de IPv6 hacen a Mobile IPv6 mucho más eficiente para nodos extremos que
Mobile IPv4. La movilidad aprovecha la flexibilidad de IPv6. Por ejemplo, el binding usa algunas opciones de
encabezado (destino) que sean obligatorias para cada dispositivo IPv6. También, la movilidad IPv6 crea un
encabezado de extensión de "movilidad" nuevo. La movilidad IPv6 es diferente de la movilidad IPv4 de varias
maneras:
• El espacio de dirección IPv6 permite el despliegue Mobile IP en cualquier clase de entorno grande.
• Debido al extenso espacio de dirección IPv6, ya no se requieren de agentes exteriores. Las
infraestructuras no necesitan un upgrade para aceptar nodos Mobile IPv6, por lo que el care-of address
(CoA) puede ser una dirección ruteable IPv6 global para todos los nodos móviles.
• El modelo Mobile IPv6 aprovecha algunos beneficios del mismo protocolo IPv6. Los ejemplos incluyen
encabezados de opción, descubrimiento de vecino, y la autoconfiguración.
• En muchos casos, se elimina el enrutamiento de triángulo, porque la optimización de ruta Mobile IPv6
permite que los nodos móviles y los nodos correspondientes se comuniquen directamente. El soporte
para la optimización de ruta es una parte fundamental del protocolo, más que un conjunto no estandar
de extensiones. El soporte también se integra en Mobile IPv6 para permitir que la optimización de ruta
coexista eficientemente con los routers que realizan la filtración de ingreso. La optimización de ruta
Mobile IPv6 puede operar con seguridad incluso sin asociaciones de seguridad planeadas de
antemano. Se espera que la optimización de ruta pueda ser desplegada a una escala global entre todos
los nodos móviles y los nodos correspondientes.
• Los nodos móviles trabajan transparentemente incluso con otros nodos que no soporten movilidad (lo
mismo que en la movilidad IPv4).
• El mecanismo de descubrimiento de direcciones de agente casero dinámico en Mobile IPv6 devuelve
una sola respuesta al nodo móvil. El acercamiento al broadcast dirigido usado en IPv4 devuelve
replicas de cada agente casero.
• La mayoría de paquetes enviados a un nodo móvil mientras está ausente de hogar en Mobile IPv6 son
envíados usando un encabezado de enrutamiento IPv6 más que encapsulación IP, reduciendo la
cantidad de overhead resultante comparado a Mobile IPv4.

8.4 Enrutamiento IPv6

8.4.1 Descripción del enrutamiento IPv6
Similar al classless interdomain routing
(CIDR) IP version 4 (IPv4), IPv6 usa
enrutamiento por coincidencia de prefijo
mas largo. Recientes versiones de
protocolos manejan direcciones IPv6
más largas y diferentes estructuras de
encabezado. Actualmente, están
disponibles los protocolos de
enrutamiento actualizados mostrados
en Figura 1.
Los siguientes son resúmenes de varios

protocolos de enrutamiento usados con
IPv6.
Enrutamiento Estático
El enrutamiento estático con IPv6 se Figura 1 – Protocolos de enrutamiento con IPv6
usa y se configura de la misma manera
que IPv4. Hay un requisito especifico IPv6 para RFC 2461: Un router debe ser capaz de determinar la dirección
link-local de cada uno de sus routers vecinos para asegurar que la dirección objetivo de un mensaje redirect
identifique al router vecino por su dirección link-local.
Este requisito básicamente da a entender que no se recomienda el uso de una dirección unicast global como
una dirección de siguiente-salto con enrutamiento.
RIPng
El Routing Information Protocol next
generation (RIPng, RFC 2080) es un
protocolo de enrutamiento por vector-
distancia con un límite de 15 saltos que
usa horizonte dividido y
envenenamiento inverso para prevenir
loops de enrutamiento. Fig.2
La implementación del protocolo para

IPv6 incluye estas características:
• Basado en RIP versión 2 Figura 2 - RIPng
(RIPv2) IPv4 y similar a RIPv2
• Usa IPv6 para el transporte
• Prefijo IPv6, dirección IPv6 de siguiente-salto
• Usa el grupo multicast FF02::9, el grupo multicast de routers all-RIP, como dirección destino para
actualizaciones RIP
• Actualizaciones enviadas al
puerto 521 UDP
OSPFv3
La implementación de protocolo para
IPv6 incluye estas características:
• Basado en OSPF versión 2
(OSPFv2), con mejoras
• Distribuye prefijos IPv6
• Funciona directamente sobre Figura 3 – OSPFv3
IPv6
• Opera como "ships in the night" con OSPFv2
Esta implementacion agrega estos atributos IPv6-especificos:

• Direcciones de 128 bits
• Direcciones link-local
• Múltiples direcciones e instancias por interfaz
• Autenticación (ahora usa IPsec)
• OSPFv3 funciona sobre un enlace más que una subred
IS-IS
El soporte para dirección larga facilita la
familia de dirección IPv6. El
Intermediate System to Intermediate
System (IS-IS) es el mismo que IPv4
con las siguientes extensiones
agregadas: Fig.4
• Dos nuevos atributos Tipo,
Longitud, Valor
• Alcanzabilidad IPv6
• Dirección de interfaz IPv6 Figura 4 – IS-IS
• Nuevo IDS de protocolo
EIGRP
El Enhanced Interior Gateway Routing Protocol (EIGRP) se puede usar para enrutar prefijos IPv6. EIGRP IPv4
funciona sobre un transporte IPv4, se comunica solamente con los pares IPv4, y anuncia solamente las rutas
IPv4. EIGRP para IPv6 sigue el mismo modelo. EIGRP para IPv4 y EIGRP para IPv6 se configuran y se
administran por separado. Sin embargo, la configuración de EIGRP para IPv4 e IPv6 es similar y proporciona
familiaridad y continuidad operacionales.
BGP Multiprotocolo
Para hacer al Border Gateway Protocol
version 4 (BGP4) disponible para otros
protocolos de capa de red, RFC 2858
(que substituye al RFC 2283 obsoleto)
define las extensiones multiprotocolo
para BGP4. Fig.5
El BGP multiprotocolo se usa para

permitir a BGP4 llevar la información de
otros protocolos, por ejemplo, Figura 5 – Multiprotocolo BGP (MP-BGP)
Multiprotocol Label Switching (MPLS) e
IPv6.
8.4.2 OSPFv3 e IPv6

OSPF es un protocolo de enrutamiento IP de estado de enlace. Piense en un enlace como si fuera una interfaz
en un dispositivo de networking. Un protocolo de estado de enlace toma sus decisiones de enrutamiento
basado en los estados de los enlaces que conectan a las máquinas origen y destino.
El estado de un enlace es una descripción de esa interfaz y de su relación con sus dispositivos de networking
vecinos. La información de interfaz incluye el prefijo IPv6 de la interfaz, la máscara de red, tipo de red con el
cual está conectada, routers conectados a esa red, etcétera.
Esta información se propaga en varios tipos de link-state advertisements (LSAs). Una colección de datos LSA
en un router se almacena en una link-state database (LSDB). El contenido de la base de datos, cuando está
sujeta al algoritmo de Dijkstra, da lugar a la creación de la tabla de enrutamiento OSPF.

La diferencia entre la base de datos y la tabla de enrutamiento es que la base de datos contiene una colección
completa de informaciones en bruto. La tabla de enrutamiento contiene una lista de caminos más cercanos a
destinos conocidos vía puertos de interfaz de router específicos.
OSPFv3, que se describe en RFC 2740, soporta IPv6.
8.4.3 Similitudes entre OSPFv2 y OSPFv3

Muchas de las características OSPF
para IPv6 son las mismas a las de
OSPFv2. OSPFv3 para IPv6, el cual
esta descrito en RFC 2740, amplía
OSPFv2 para proporcionar soporte para
los prefijos de enrutamiento IPv6 y para
direcciones IPv6 de tamaño más
grande. Figura 1 – OSPFv3, similitudes con OSPFv2
Otras semejanzas a OSPFv2 incluyen lo

siguiente: Fig.1
• Los mecanismos para
descubrimiento de vecinos y
formación de adyacencia son
idénticos.
• Las operaciones de OSPFv3
sobre modos de topologia
nonbroadcast multiaccess
(NBMA) y punto-a-multipunto
RFC-compliant estan
soportadaos. OSPFv3 también
soporta otros modos de Cisco,
tal como punto-a-punto y
broadcast, incluyendo la
interfaz.
• La inundación y el Figura 2 – Mejoras del protocolo de enrutamiento
envejecimiento LSA son iguales
para OSPFv2 y OSPFv3.
• OSPFv3 usa los mismos tipos de paquete básicos que OSPFv2, tales como paquetes hello, descripción
de base de datos (también llamado paquete de descripción de base de datos), link-state request (LSR),
link-state update (LSU), y LSA. Fig.2
Todas las capacidades opcionales de OSPF para IPv4, incluyendo soporte de circuito a pedido, not-so-stubby
areas (NSSAs), y las extensiones a Multicast OSPF (MOSPF) también están soportadas en OSPF para IPv6.
8.4.4 Diferencias entre OSPFv2 y OSPFv3

Las diferencias entre OSPFv2 y OSPFv3 incluyen el siguiente:
• OSPFv3 funciona sobre un link Fig.1
o El OSPF para IPv6
funciona por enlace en
vez del comportamiento
IPv4 por subred IP.
IPv6 usa el término
"enlace" para indicar
"una facilidad de
comunicación o medio
sobre el cual los nodos
puedan comunicar en la Figura 1 – Procesos por enlace OSPv3
capa de enlace." Por lo
tanto, los términos "red" y "subnet" usados en la especificación OSPF IPv4 son substituidos por
"enlace."
o La orden network en el modo de subcomando del router OSPFv2 es reemplazado por
comando de interfaz ipv6 ospf process-id area area-id [instance instance-id].
• Se usan direcciones link-local
o OSPFv3 usa direcciones link-local IPv6 para identificar a los vecinos de adyacencia OSPFv3.
Por lo tanto, al configurar el comando ipv6 ospf neighbor, la dirección IPv6 usada debe ser la
dirección link-local del vecino.
• Soporte para multiples instancias OSPFv3 Fig.2
o Sistemas autónomos
separados, cada uno
con OSPF funcionando,
usan un enlace común.
Un enlace único podría
pertenecer a múltiples
áreas.
o OSPFv3 usa un campo Figura 2 – Soporte de instancia múltiple OSPFv3
nuevo, llamado Instante
ID, para permitir múltiples instancias por enlace. Para tener dos instancias que hablen una con
la otra, ellas deben compartir la misma instance ID. Por defecto, la instance ID esta fijada a 0.
• Direcciones multicast Fig.3
o FF02::5- Representa
todos los routers
shortest path first (SPF)
en el alcance link-local,
equivalente a 224.0.0.5
en OSPFv2.
o FF02::6- Representa
todos los designated
routers (DRs) en el
alcance link-local,
equivalente a 224.0.0.6
en OSPFv2.
Figura 3 – Otras diferencias entre OSPFv2 y OSPFv3
• Retiro de semánticas de
dirección
o Las direcciones IPv6 ya no estan presentes en el encabezado del paquete OSPF (parte de
información de la carga útil).
o Las LSAs del router y las LSAs de la red no llevan direcciones IPv6.
o La ID de router, la ID de area, y la ID de estado de enlace se mantienen en 32 bits.
o El DR y el backup designated router (BDR) son identificados por su ID de router y no por su
direccion IP.
• Seguridad
o OSPFv3 usa Authentication Header (AH) IPv6 y encabezados de extensión Encapsulating
Security Payload (ESP), en vez de la variedad de mecanismos definidos en OSPFv2.
o La autenticación ya no es parte de OSPF. Ahora es trabajo de IPv6 cerciorarse de que el nivel
correcto de autentificación este en uso.
8.4.5 Tipos de LSA para IPv6

Las características LSA OSPFv3 incluyen lo siguiente:
• La LSA se compone de una ID de router, ID de área, y ID de estado de enlace. Cada una de 32 bits.
Aunque se escriben en decimal con punto, no se derivan de una dirección IPv4.
• Las LSAs de router y la LSAs de red contienen solamente IDs de 32 bits. No contienen direcciones.
• Las LSAs tiene alcances de inundación que definen el diámetro al que podrían ser inundados:
o Enlace local: Inundan todos los routers en el enlace.
o Área: Inundan todos los routers dentro del área OSPF.
o Sistema Autónomo: Inundan todas los routerss dentro del sistema autónomo OSPF entero.

• OSPFv3 soporta el envio de LSAs desconocidas basado en el alcance de inundacion. Esto puede ser
útil en un NSSA.
• OSPFv3 aprovecha el multicasting IPv6, al usar FF02::5 para todas los routers OSPF, y FF02::6 para el
OSPF DR y el OSPF BDR.
Las dos LSAs renombradss son como sigue:

• LSAs de prefijo de Interarea para area border routers (ABRs) (tipo 3): Las LSAs tipo 3 anuncian
redes internas a los routers en otras áreas (rutas de interarea). Lss LSAs tipo 3 puede representar una
red única o un conjunto de redes sumarizadas en una publicación. Solamente los ABRs generan LSAs
de sumario. En OSPF para IPv6, las direcciones para estas LSAs se expresan como prefijo, longitud de
prefijo en vez de dirección, máscara. La ruta por defecto se expresa como prefijo con longitud 0.
• LSAs de router interarea para autonomous system boundary routers (ASBRs) (tipo 4): Las LSAs
tipo 4 publican la localización de un ASBR. Los routers que tratan de alcanzar una red externa usan
estas publicaciones para determinar el mejor camino al salto siguiente. Los ASBRs generan LSAs tipo
4.
Las dos LSAs nuevas en IPv6 son como sigue:

• LSAs de enlace (tipo 8): Las LSAs tipo 8 tiene alcance de inundación link-local y nunca están
inundadas más allá del enlace con el cual están asociadas. Las LSAs de enlace proporcionan la
dirección link-local del router al resto de routers unidos al enlace. Las LSAs de enlace también informan
a otros routers unidos al enlace de una lista de prefijos IPv6 para asociar al enlace, y permiten que el
router declare una colección de bits de opciones para asociarlos con la LSA de red que será originada
para el enlace
• LSAs de prefijo intra-area (tipo 9): Un router puede originar multiples LSAs de prefijo intra-area para
cada router o red de transito, cada uno con una ID de estado de enlace única. La ID de estado de
enlace para cada LSA de prefijo intra-area describe su asociación a la LSA de router o a la LSA de red.
La ID de estado de enlace también contiene prefijos para redes matriz o de transito
8.4.6 Prefijo de Dirección y LSAs

Un prefijo de dirección ocurre en casi todas las LSAs definidas recientemente. El prefijo se representa por tres
campos: Prefijo de Longitud, Prefijo de Opciones, y Prefijo de Dirección. En OSPF para IPv6, las direcciones
para estas LSAs se expresan como prefijo, prefijo de longitud en vez de dirección, máscara.
La ruta por defecto se expresa como un prefijo con longitud 0.
Las LSAs de tipo 3 y tipo 9 llevan toda la información de prefijo IPv6, que, en IPv4, están incluidas en las LSAs
de router y en las LSAs de red.
8.5 Implementación y Verificación OSPFv3

8.5.1 Configuración OSPFv3 en IPv6
Muchos comandos OSPFv3 son
similares a los de OSPFv2. En la
mayoría de los casos, usted
simplemente prefija o remplaza ip en el
comando OSPF por ipv6. Por ejemplo,
en vez de usar el comando ip address
para asignar una dirección IPv6, usted
usa el comando ipv6 address. Para ver
las rutas IPv6, usted da el comando Figura 1 – Configurando OSPFv3 con software Cisco IOS
show ipv6 route. Fig.1
La configuración de OSPFv3 no es un modo de subcomando del comando router ospf como lo es en la

configuración OSPFv2. Por ejemplo, en vez de usar el comando network area para identificar redes que son

parte de la red OSPFv3, las interfaces se configuran directamente para especificar que las redes IPv6 son parte
de la red OSPFv3.
Lo que sigue describe los pasos para configurar OSPF para IPv6:
Paso 1 Complete la estrategia y planeamiento OSPF para su red IPv6. Por ejemplo, debe decidir si se
requieren múltiples áreas.
Paso 2 Habilite el enrutamiento unicast

IPv6 usando el comando ipv6 unicast-
routing. Fig.2
Figura 2 – Comando ipv6 unicast-routing
Paso 3 Habilite IPv6 en la interfaz usando el comando ipv6 ospf area.
Paso 4 (Opcional) Configure los ajustes específicos de la interfaz OPSFv3, incluyendo área, prioridad de router,
y costo de camino OSPFv3.
Paso 5 (Opcional) Configure las especificaciones de enrutamiento desde el modo de la configuración de router,
incluyendo la prioridad de router, sumarización de ruta, etcétera.
8.5.2 Habilitación OSPFv3 en una interfaz

La mayoría de la configuración OSPFv3
se hace en la interfaz. La Figura 1
muestra una configuración de muestra
habilitando una dirección IP IPv6, área,
prioridad de router, y costo de camino.
La Figura 2 proporciona descripciones

de los comandos de interfaz requeridos
y de comandos opcionales incluyendo Figura 1 – Habilitando OSPFv3 en una interface
prioridad de router, y costo de camino
OSPFv3.
Figura 2 – Comandos OSPFv3 interface configuration
8.5.3 Configuración de Especificaciones de Enrutamiento OSPFv3

Las especificaciones de enrutamiento OSPFv3 se configuran desde el modo de configuración de router. Para
entrar al modo de configuración de router, use el comando ipv6 router ospf process-id. Este comando habilita
un proceso OSPF en el router. El parámetro ID de proceso identifica un proceso OSPFv3 único.

Para un router IPv6-only, un parámetro ID de router se debe definir en la configuración OSPFv3 como una
dirección IPv4 usando el comando de configuración de router router-id router-id. OSPFv3 usa un número de
32 bits para una ID de router. La ID de router OSPFv3 se puede expresar en decimal con punto, permitiendo el
fácil encubrimiento de una red OSPFv3 en una red OSPFv2 existente. La Figura 1 muestra una configuración
de muestra.
Si IPv4 esta configurado en el router,

por el defecto, la ID de router se elige
de la misma manera que OSPFv2. La
dirección IPv4 más alta configurada en
una interfaz loopback viene a ser la ID
de router. Si no se configura las
interfaces loopback, la dirección más
alta en cualquier otra interfaz vendrá a
Figura 1 – Configurando el router ID
ser la ID de router.
8.5.4 Sumarizacion de Ruta OSPFv3

La Figura 1 muestra rutas OSPFv3 de muestra antes de la sumarización.
Para consolidar y sumarizar rutas en un límite de área, use el comando de router OSPFv3 IPv6 area area-id
range ipv6-prefix/prefix-length [advertise | not-advertise] [cost cost]. La Figura 2 proporciona una
configuración de muestra.
Figura 2 – Resumen de rutas OSPFv3
Figura 1 – Rutas OSPFv3 antes del resumen

El costo de las rutas sumarizadas es el costo más
alto de las rutas que están sumarizadas. Por
ejemplo, las rutas mostradas en Figura 1 se
convierten en una ruta sumarizada como se muestra Figura 3 – Rutas OSPFv3 después del resumen
en Figura 3.
8.5.5 Ejemplo de Configuración OSPFv3

El ejemplo de la Figura 1 muestra una
red OSPF de dos routers, con un área 0
y área 1. El comando de interfaz
especifico ipv6 ospf 100 area 0 crea el
proceso " ipv6 router ospf 100 "
dinámicamente, al igual que el comando
ipv6 ospf 100 area 1.
Figura 1 – Ejemplo de configuración OSPFv3

8.5.6 Verificación OSPFv3

Hay varios comandos show OSPFv3 comúnmente
usados, incluyendo el comando show ipv6 ospf
[process-id] [area-id] interface [interface]. Este
comando genera la información de interfaz
relacionada OSPF, según lo mostrado en Figura 1.
El comando clear ipv6 ospf [process-id] {process |

force-spf | redistribution | counters [neighbor
[neighbor-interface | neighbor-id]]} provoca el
recálculo SPF y el repoblamiento de la Routing
Information Base (RIB).
El comando show ipv6 ospf [process-id] [area-id]

Figura 1 – Verificando OSPFv3
muestra información general sobre procesos OSPF,
según lo mostrado en las Figuras 2 y 3.
La Figura 4 enumera algunos de los campos de

salida y descripciones del comando show ipv6
ospf.
Figura 2 – Comando show ip ospf
Figura 3 – Comando show ip ospf (cont.)
Figura 4 – Descripciones show ipv6 ospf field

8.5.7 Verificación de vecinos OSPFv3

Para mostrar información de vecino OSPF sobre una base por interfaz, use el comando show ipv6 ospf
neighbor en modo EXEC usuario o en modo EXEC privilegiado. El comando show ipv6 ospf neighbor detail
proporciona información detallada sobre vecinos OSPF IPv6, según lo ilustrado en la Figura 1.
La Figura 2 muestra los campos de salida y descripciones del comando show ipv6 ospf neighbor.
Figura 1 – Comando show ipv6 ospf neighbor detail
Figura 2 – Descripción de los campos de show ipv6 ospf neighbot detail

8.5.8 Verificación de la Base de Datos OSPFv3

Para mostrar listas de información relacionadas con la base de datos OSPF para un router específico, use el
comando show ipv6 ospf database en modo EXEC usuario o en modo EXEC privilegiado. Varias formas de
este comando entregan información sobre distintas link-state advertisements (LSAs).
Las Figuras 1 y 2 ilustran la salida parcial de muestra del comando show ipv6 ospf database. La Figura 3
proporciona descripciones de campo de salida del comando show ipv6 ospf database.
La Figura 4 ilustra la salida de muestra del comando show ipv6 ospf database database-summary.
Figura 3 – Descripción de los campos de show ipv6 ospf database
Figura 1 – Comando show ipv6 ospf database
Figura 4 – Comando show ipv6 ospf database database-summary

Figura 2 – Comando show ipv6 ospf database (cont.)
8.6 Uso de IPv6 eIPv4

8.6.1 Mecanismo de Transición IPv6 a IPv4
La transición de IPv4 a IPv6 no requiere un upgrade en todos los nodos al mismo tiempo. Muchos mecanismos
de transición permiten la integración sin problemas de IPv4 a IPv6. Hay mecanismos disponibles que permiten
que nodos IPv4 se comuniquen con nodos IPv6. Todos estos mecanismos se pueden aplicar a distintas
situaciones.

Las dos técnicas más comunes
para la transición de IPv4 a IPv6
son como sigue:
• Dual snack
• Tuneles IPv6-over- IPv4
(6to4)
Para la comunicación entre redes

IPv4 e IPv6, las direcciones IPv4
se pueden encapsular en
direcciones IPv6.
La Figura 1 muestra un ejemplo

de un mecanismo de transición e
integración. Los routers 6to4
encapsulan automáticamente el Figura 1 – Transición IPv4-a-IPv6
tráfico IPv6 dentro de paquetes
IPv4.
8.6.2 Dual Stack de Cisco IOS

La mayoría de las más recientes versiones de software Cisco IOS son IPv6-ready. Tan pronto como las
configuraciones básicas IPv4 e IPv6 esten completas en la interfaz, la interfaz esta dual-stackeada, y remite el
tráfico IPv4 e IPv6.
Usar IPv6 en un router Cisco IOS

requiere que usted use el comando
de configuración global ipv6 unicast-
routing. Fig 1 Este comando habilita
el envió de datagramas IPv6.
Todas las interfaces que envían

tráfico IPv6 deben tener una dirección
IPv6. El comando ipv6 address
[IPv6-address] [/prefix length] Figura 1 – Dual stack de Cisco IOS
especifica una red IPv6 asignada a la
interfaz y permite procesamiento IPv6
en la interfaz.
El dual-stack es un método de
integración donde un nodo tiene la
implementación y conectividad a una
red IPv4 y a red IPv6, y así el nodo
tiene dos stacks. Fig. 2 Esta
configuración se puede llevar a cabo
en la misma interfaz o en múltiples
interfaces. Las consideraciones para
dual-stack incluyen lo siguiente:
• Un nodo dual-stack elige que
stack usar basadose en la
dirección destino. Un nodo
dual-stack prefiere IPv6 Figura 2 – Dual stack
cuando esta disponible. La
estrategia dual-stack para integración IPv6 en la cual los nodos tienen stacks IPv4 e IPv6 será uno de
los métodos de integración más comúnmente usados. Las antiguas aplicaciones IPv4-only continúan
trabajando como antes. Las aplicaciones nuevas y modificadas aprovechan de ambas capas IP.

• Una nueva application programming interface (API) se define para soportar direcciones IPv4 e IPv6 y
peticiones Domain Name System (DNS). Esta API reemplaza a las llamadas gethostbyname y
gethostbyaddr. Una aplicación convertida puede hacer uso de IPv4 e IPv6. Un aplicación puede ser
convertida a la nueva API mientras que todavía usa sólo IPv4.
• La experiencia previa de porting en aplicaciones IPv4 hacia IPv6 sugiere que para la mayoría de
aplicaciones es un cambio mínimo en algunos lugares localizados dentro de código fuente. Esta técnica
es bien conocida y se ha aplicado en el pasado para otras transiciones de protocolo. Permite mejoras
graduales de la aplicación, uno por uno, a IPv6.
8.6.3 Túneles de Encubrimiento

El networking usa a menudo túneles
para encubrir una funcionalidad
incompatible en una red existente. El
tráfico IPv6 tunneling sobre una red
IPv4 requiere un router de borde que
encapsule el paquete IPv6 dentro de un
paquete IPv4 y otro router que
desencapsule. Fig.1
Este proceso le permite conectar islas

IPv6 sin convertir la red entera a IPv6.
Figura 1 – Túneles de encubrimiento
El tunneling es un método de
integración donde un paquete IPv6 se encapsula dentro de otro protocolo, tal como IPv4. Fig. 2
Este método de encapsulación es

protocolo 41 IPv4 y tiene las siguientes
características:
• Incluye un encabezado IPv4 de
20 bytes sin opciones y un
encabezado IPv6 y una carga
útil.
• Se considera el dual-stacking,
que permite la conexión de islas
IPv6 sin convertir una red
intermediaria a IPv6.
• El tunneling presenta estos
problemas:
o La MTU es disminuida
en 20 octetos (si el
encabezado IPv4 no
contiene ningún campo Figura 2 - Tunneling
opcional).
o Difíciltad para resolver problemas.
El tunneling es una técnica integración intermedia y de transición que no seria considerada una solución final.
La arquitectura IPv6 nativa debe ser la última meta.

8.6.4 Host Dual Stack Aislado

La encapsulación puede ser hecha por
routers de borde entre hosts o entre un
host y una router. El ejemplo en Figura
1 muestra un host dual-stack aislado
usando un túnel encapsulado para
conectarse con el router de borde de la
red IPv6.
El tunneling no funciona si un nodo

intermediario entre los dos puntos
extremos del túnel, tales como un
firewall, filtra hacia fuera protocolo 41
IPv4, que es la encapsulación IPv6-
over-IPv4.
Figura 1 – Host dual stack aislado
8.6.5 Configuración de Tunneling

Si usted está configurando un túnel
manualmente, usted debería configurar
las direcciones IPv4 e IPv6
estáticamente. Debería realizar esta
configuración en los routers en cada
extremo del túnel. Fig.1
Estos routers extremos deben estar

dual stackeados, y la configuración no
puede cambiar dinámicamente como la
red y las necesidades de enrutamiento
cambian. El enrutamiento se debe
configurar correctamente para enviar un Figura 1 – Túnel configurado
paquete entre las dos redes IPv6.
Los puntos extremos del túnel pueden ser innumerables, pero los puntos extremos innumerables hacen difícil la
solución de problemas. La práctica IPv4 de ahorrar direcciones para puntos extremos del túnel no es más un
problema.
8.6.6 Ejemplo de un Túnel Configurado

El ejemplo en Figura 1 muestra cómo
configurar un túnel de encubrimiento
IPv6 manualmente. Con los túneles
configurados IPv6 manualmente, una
dirección IPv6 se configura en una
interfaz de túnel, y las direcciones IPv4
configuradas manualmente se asignan
al origen del túnel y al destino del túnel.
El host o router en cada extremo de un
túnel configurado debe soportar los
stacks de protocolo IPv4 e IPv6.
El comando que habilita el túnel de Figura 1 – Ejemplo de configuración de túnel con Cisco IOS
encubrimiento IPv6 es tunnel mode

ipv6ip. Concretamente, especifica que IPv6 es el protocolo pasajero y que IPv4 será usado como protocolo de
encapsulación y transporte.
Existen varios otros mecanismos de transición de tunneling automático, incluyendo éstos:

• 6to4: Usa el prefijo reservado 2002::/16 para permitir que un sitio conectado a Internet IPv4 cree y use
un prefijo /48 IPv6 basado en una única dirección IPv4 ruteable o alcanzable globalmente.
• Intra-Site Automatic Tunnel Addressing Protocol (ISATAP): Permite que una intranet privada IPv4
(que puede o no usar direcciones RFC 1918) implemente incrementalmente nodos IPv6 sin realizar un
upgrade la red.
Otro mecanismo de transición es Teredo (conocido antes como Shipworm). Este mecanismo tunelea los
datagramas IPv6 dentro de UDP IPv4. Este método proporciona el uso de dirección IPv4 privada y NAT
traversal IPv4.
8.6.7 Tunneling IPv6 a IPv4 y Direcciones

El método tunneling 6to4 establece automáticamente la conexión de islas IPv6 a través de una red IPv4. Aplica
un prefijo IPv6 válido a cada isla IPv6, lo cual permite el rápido despliegue de IPv6 en una red corporativa, sin la
recuperación de la dirección de ISPs o de los registros.
El método de tunneliing 6to4 requiere un código especial en los routers de borde, pero los hosts y routers IPv6
dentro del sitio 6to4 no requieren nuevas características para soportar 6to4. Cada sitio 6to4 recibe un prefijo
/48, que es la concatenación de 0x2002 y la dirección IPv4 hexadecimal de router de borde.
En la Figura 1, la dirección IPv4

del router de borde es
192.168.99.1. Como resultado, el
prefijo de su red IPv6 es
2002:c0a8:6301::/48 ya que
c0a86301 es la representación
hexadecimal de 192.168.99.1. La
red IPv6 puede sustituir cualquier
dirección IP en el espacio
después de la primera sección de
16 bits (0x2002).
Cuando un paquete IPv6 con una

dirección destino en el rango de
2002::/16 alcanza al router de
borde 6to4, el router de borde Figura 1 – Tunneling 6to4
6to4 extrae la dirección IPv4 que
esta embedida en la dirección destino 2002:: (insertada entre el tercer y sexto octetos, inclusive). El router 6to4
luego encapsula el paquete IPv6 en un paquete IPv4 con la dirección IPv4 destino que fue extraída de la
dirección destino IPv6.
Esta dirección IPv4 representa la dirección del otro router de borde 6to4 del sitio 6to4 destino. El router de
borde destino desencapsula el paquete IPv6 en el paquete IPv4 y luego envía el paquete nativo hacia su
destino final.
Nota: 2002::/16 es el rango de dirección asignada específicamente a 6to4.
8.6.8 Transición de NAT-PT

Para equipos heredados que no serán actualizados a IPv6 y para algunos escenarios de despliegue, las
técnicas que pueden conectar nodos IPv4-only a nodos IPv6-only están disponibles. La traducción es
básicamente una extensión de las técnicas NAT.
La NAT-Protocol Translation (NAT-PT) es un mecanismo de traducción que se sienta entre una red IPv6 y una
red IPv4. El traductor traduce los paquetes IPv6 en paquetes IPv4 y viceversa.
La NAT-PT estática usa reglas de traducción estáticas para mapear una dirección IPv6 a una dirección IPv4.
Los nodos de red IPv6 se comunican con nodos de red IPv4 usando un mapeo IPv6 de la dirección IPv4
configurada en el router NAT-PT.
La Figura 1 muestra cómo el nodo IPv6-

only (nodo A) puede comunicarse con el
nodo IPv4-only (nodo D) usando NAT-
PT. El dispositivo NAT-PT se configura
para mapear la dirección IPv6 origen
para el nodo A de 2001:0db8:bbbb:1::1
a la dirección IPv4 192.0.2.2. NAT-PT
también se configura para mapear la
dirección origen del nodo C IPv4,
192.0.30.1 a 2001:0db8::a. Cuando los
paquetes con una dirección IPv6 origen
del nodo A se reciben en el router NAT-
PT estos son traducidos para tener una
dirección destino que coincida con el
nodo D en la red IPv4-only. NAT-PT se
puede también configurar para coincidir Figura 1 – Transición de NAT-PT
una dirección IPv4 origen y traducir el
paquete a una dirección destino IPv6 para permitir a un host IPv4-only comunicarse con un host IPv6-only.
Desde la perspectiva del nodo A, se está estableciendo una comunicación a otro nodo IPv6. Y desde la
perspectiva del nodo D, está estableciendo comunicación IPv4 con su correspondiente. El nodo D no requiere
modificación.
Si usted tiene múltiples hosts IPv6-only o IPv4-only que necesiten comunicarse, usted puede necesitar
configurar muchos mapeos NAT-PT estáticos. La NAT-PT estática es útil cuando las aplicaciones o servidores
requieren acceso a una dirección IPv4 estable. El accesar a un servidor DNS IPv4 externo es un ejemplo donde
la NAT PT estática puede ser usada. Las traducciones NAT-PT también se pueden mapear dinámicamente
basado en preguntas de DNS, usando un DNS application level gateway (DNS ALG).
Otras posibles soluciones son como sigue:

• ALGs: Este método usa una estrategia dual-stack y permite a un host en un dominio IPv6-only enviar
datos a otro host en un dominio IPv4-only. Requiere que todos los servidores de aplicaciones en un
gateway funcionen con IPv6.
• API: Usted puede instalar un módulo específico en un stack TCP/IP de host para cada host en la red. El
módulo intercepta tráfico IP con una API y lo convierte para las contrapartes IPv6.
Resumen
Este módulo es una descripción de IP versión 6 (IPv6), comenzando con el porqué se convertirá en el protocolo
de elección en el futuro y los beneficios de esa elección. Los cambios en el formato de dirección y el formato de
encabezado de paquete fueron discutidos en detalle, incluyendo la autoconfiguración y el rol de la dirección
multicast.
Una parte importante del módulo fue dedicada a describir el enrutamiento IPv6. Se definieron todos los
protocolos de enrutamiento posibles y el Open Shortest Path First Protocol (OSPF) fue cubierto en más detalle.
También se definieron estrategias de transición para emigrar de IPv4 a IPv6.
Se mostro la configuración del Cisco IOS, la verificación, y los comandos de resolucion de problemas.


BGP, IPv6 y Redistribución

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

BGP, IPv6 y Redistribución

Hochgeladen von

Copyright:

Verfügbare Formate

CCNP: Building Scalable Internetworks

Módulo 5: Optimización de rutas.

5.1 Operando una red que utiliza múltiples protocolos de enrutamiento

Utilizar un ambiente con múltiples

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 1

5.1.2 Definiendo redistribución de rutas

Cuando están siendo utilizados

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 2

5.1.3 Redistribuyendo información de rutas

Asimismo, el proceso EIGRP en el

Los vecinos EIGRP utilizan el listado

Dentro de los factores que tienen impacto sobre la redistribución se incluyen:

Estos factores serán discutidos en varias secciones de este módulo.

5.1.4 Utilizando métricas

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 3

Ejemplo de métrica inicial (seed metric).

El comando default-metric, usado en el modo de configuración del proceso de enrutamiento, establece la

Utilice el comando default-metric para

Una vez que la métrica es establecida,

Los routers Cisco también permiten que

5.1.5 Ejemplo de métricas iniciales

Figura 1 – Redistribución con métricas iniciales

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 4

5.1.6 Definiendo la distancia administrativa.

En la figura 1, se muestra una tabla con

Nota: IGRP no es soportado en el IOS

Por ejemplo, en la figura 2, si un router

Por ejemplo, un router tiene configurados

Cuál de estas rutas será instalada en la

5.1.7 Modificando las distancias administrativas

Asignando una distancia administrativa

Para EIGRP, utilice el comando distance eigrp

Por defecto, en EIGRP las rutas aprendidas

Para BGP, utilice el comando distance

Figura 3 – Parámetros del comando distance eigrp

5.2 Configurando y verificando redistribución en el router.

Como se muestra en la figura 1, todos

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 7

Los siguientes pasos son genéricos

Nota: En este tópico, los términos

1. Localizar los routers de borde

5.2.2 Redistribuyendo rutas dentro de un protocolo de enrutamiento classful.

En la figura, el ejemplo utiliza el

El ejemplo utiliza el comando

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 8

La sintaxis del comando redistribute en

Figura 3 – Parámetros del comando redistribute

5.2.3 Redistribuyendo desde protocolos classless a protocolos classful.

Un problema común con la

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 9

OSPF tiene una máscara mayor que RIP.

La máscara de subred del dominio OSPF es difícil de cambiar,

RIP tiene una máscara mayor que OSPF.

Nosotros podemos agregar una ruta estática en el router RTB

En el código mostrado más abajo, las primeras dos rutas

ip route 128.103.35.32 255.255.255.248 E0/0

ip route 128.103.35.16 255.255.255.248 E1/0

ip route 128.103.35.64 255.255.255.248 128.103.35.34

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 10

5.2.4 Redistribuyendo rutas dentro de un protocolo de enrutamiento classless.

El comando redistribute le especifica al

La figura 2 muestra la sintaxis del

La redistribución de OSPF puede ser Figura 1 – Configurando redistribución en RIP

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 11