Professional Documents
Culture Documents
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 5
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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.
La redistribución debe ser configurada correctamente para cada protocolo de enrutamiento, para sí obtener los
resultados deseados.
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.
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.
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.
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.
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.
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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”.
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.
¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 22
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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)
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
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 16
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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.
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.
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.
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 20
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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.
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)
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.
El comando neighbor dice a BGP donde anunciar, y el comando network dice a BGP que anunciar
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 23
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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
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).
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.
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.
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.
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.
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.
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.
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.
El estado establecido es un estado deseado Figura 3 – Ejemplo: Comando show ip bgp neighbors
por las relaciones de neighbors. Figura 2.
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 28
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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
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.
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.
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
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 30
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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
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.
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
Similarmente, si dos routers tienen diferentes contraseñas configuradas, un mensaje tal como el siguiente
aparece en la pantalla
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
La segunda columna muestra “>” cuando BGP ha seleccionado la trayectoria como la mejor trayectoria a una
red.
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 33
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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 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.
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
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.
Hay tres maneras de accionar una actualización: con un hard reset, soft reset, o route refresh.
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.
Nota: La palabra soft es opcional; clear ip bgp out hace un sofá reset para las actualizaciones de salida.
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.
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.
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
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.
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
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)
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.
Las rutas con un peso más alto son preferidas Figura 1 – Atributo Weight (solo Cisco)
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.
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).
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.
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.
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 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
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.
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
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
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.
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.
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.
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 48
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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
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.
La segunda declaración del route map es una declaración de permiso con un número de secuencia de 100 para
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 50
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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
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.
La segunda declaración del route map es una declaración de permiso con un número de secuencia de 100 para
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
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.
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.
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.
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.
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.
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.
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.
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.
¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 5
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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
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.)
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.
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.
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 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.
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.
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.
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
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.
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.
¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 11
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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.
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
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
¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 14
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
• Opera como "ships in the night" con OSPFv2
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 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.
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.
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.
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 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.
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.
La Figura 2 muestra los campos de salida y descripciones del comando show ipv6 ospf neighbor.
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.
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.
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.
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.
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
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.
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.
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.
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.
¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 27
CCNP: Building Scalable Internetworks
CCNP: Building Scalable Internetworks
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.
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).
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.