43508804 BGP IPv6 y Redistribucion

120
CCNP: Building Scalable Internetworks ¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 1 CCNP: Building Scalable Internetworks Módulo 5: Optimización de rutas. Descripción A veces, el enrutamiento dinámico en pequeñas redes, implica mucho más que habilitar el funcionamiento por defecto de un protocolo de enrutamiento. Algunos de estos comportamientos pueden llevar a un uso poco eficiente del ancho de banda, riesgos de seguridad o enrutamiento subóptimo. Por ejemplo, las actualizaciones de enrutamiento compiten con los datos de usuarios por ancho de banda y recursos del router. En algunos casos, aunque no se requieran actualizaciones de rutas éstas son publicadas por defecto, consumiendo ancho de banda e incrementando los riesgos de seguridad. Durante la redistribución de rutas entre sistemas autónomos, el enrutamiento puede no ser el más óptimo al no haber un afinamiento. En una red el enrutamiento puede ser optimizado, controlando cuando el router intercambia actualizaciones de rutas y que contienen estas actualizaciones. Para asegurar que la red opere eficientemente, se deben controlar y optimizar las actualizaciones. La información acerca de las redes debe ser enviada donde sea necesario y filtrada donde no lo sea. Este módulo examina las características claves del IOS para la optimización del enrutamiento, incluyendo la redistribución de rutas, control de actualizaciones de rutas y enrutamiento basado en políticas (policy-based routing). Además, una descripción de DHCP y como configurarlo. 5.1 Operando una red que utiliza múltiples protocolos de enrutamiento 5.1.1 Utilizando múltiples protocolos de enrutamiento Un protocolo de enrutamiento simple trabaja bien en una red simple, pero las redes crecen y se vuelven más complejas. Mientras lo deseable es utilizar solo un protocolo de enrutamiento en toda nuestra red, el enrutamiento multiprotocolo es común por múltiples razones, por ejemplo fusiones entre compañías, varios departamentos administrados por varios administradores de red, ambientes “multivendors” o simplemente porque el protocolo de enrutamiento original no es el más adecuado. Por ejemplo, Routing information protocol (RIP) envía periódicamente actualizaciones de la tabla de rutas completa. Como la red crece, el tráfico de estas actualizaciones puede saturar la red, indicando que puede ser necesario utilizar un protocolo de enrutamiento más escalable. Otra razón podría ser, que una compañía que utiliza EIGRP, ahora necesite de un protocolo que soporte equipos de múltiples fabricantes o que la compañía implemente políticas que especifican el uso de un protocolo de enrutamiento en particular. Utilizar un ambiente con múltiples protocolos a veces es parte del diseño de la red y los administradores deben conducir la migración, de un protocolo a otro con atención. En ocasiones, la transición entre protocolos de enrutamiento se realiza gradualmente, con lo cual, múltiples protocolos se Figura 1 – Enrutamiento jerárquico

Transcript of 43508804 BGP IPv6 y Redistribucion

Page 1: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

Módulo 5: Optimización de rutas.

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

5.1 Operando una red que utiliza múltiples protocol os de enrutamiento

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

Figura 1 – Enrutamiento jerárquico

Page 2: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

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

5.1.2 Definiendo redistribución de rutas En las siguientes situaciones pueden ser necesarios múltiples protocolos de enrutamiento:

• Cuando se esta migrando desde un antiguo IGP (Interior Gateway Protocol) a un nuevo IGP. Múltiples fronteras de redistribución pueden existir en el nuevo protocolo hasta que se halla reemplazado por completo el antiguo protocolo.

• Cuando se requiere utilizar otro protocolo, pero el antiguo protocolo de enrutamiento se necesita para un sistema host. Esta situación en común en ambientes UNIX que utilizan RIP.

• Algunos departamentos podrían no querer actualizar sus routers para soportar un nuevo protocolo. • En un ambiente de routers de varios fabricantes, se podría utilizar un protocolo de enrutamiento

específico para los equipos Cisco, como EIGRP y un protocolo de enrutamiento basado en estándares, como OSFP, para comunicar los equipos de otros fabricantes.

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

Usando múltiples protocolos de enrutamiento

Page 3: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

5.1.3 Redistribuyendo información de rutas Dentro de cada sistema autónomo, los routers mantienen un completo conocimiento de su red. El router que interconecta los sistemas autónomos se conoce como router de borde. El router de borde debe correr todos los protocolos de enrutamiento que se están utilizando para intercambiar rutas. Cuando un router redistribuye rutas, permite que un protocolo de enrutamiento publique rutas que no son conocidas a través del protocolo de enrutamiento. Estas rutas redistribuidas podrían haber sido aprendidas por medio de diferentes protocolos, como por ejemplo, cuando se redistribuye entre EIGRP y OSPF, desde rutas estáticas o mediante una conexión directa a la red. Los routers pueden redistribuir rutas estáticas, rutas directamente conectadas y rutas de otros protocolos de enrutamiento. La redistribución siempre es realizada “outbound”(de salida). El router que realiza la redistribución no cambia su tabla de enrutamiento. Cuando se configura la redistribución entre OSPF y EIGRP, el proceso OSPF en el router de borde toma las rutas de EIGRP de la tabla de enrutamiento y las publica como rutas de OSPF a sus vecinos OSPF. Asimismo, el proceso EIGRP en el router de borde toma las rutas OSPF y las publica como rutas EIGRP a sus vecinos de sistema autónomo. Como resultado, ambos sistemas autónomos conocen las rutas del otro, y cada sistema autónomo puede luego tomar decisiones de enrutamiento conociendo estas redes. Los vecinos EIGRP utilizan el listado EIGRP externo para rutear el tráfico destinado a otros sistemas autónomos a través del router de borde. El router de borde debe conocer las rutas hacia las redes de destino en su tabla de rutas para reenviar el tráfico. Por esta razón, las rutas deben estar en la tabla de rutas para que puedan ser redistribuidas. Este requerimiento puede ser evidente, pero también puede ser fuente de confusión. Por ejemplo, si un router conoce una red vía EIGRP y OSPF, solo las rutas EIGRP son colocadas en la tabla de enrutamiento porque tienen una distancia administrativa menor. Supongamos que RIP también esté corriendo en este router y que se busca redistribuir rutas de OSPF dentro de RIP. La red no es redistribuida dentro de RIP porque esta en la tabla de enrutamiento como una ruta EIGRP, no como una ruta OSPF. Dentro de los factores que tienen impacto sobre la redistribución se incluyen:

• Métricas • Distancia administrativa • Capacidades de classful/classless en los protocolos

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

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

Redistribuyendo información de rutas

Page 4: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

métrica inicial (seed) artificialmente configura la distancia, costo, etc, para cada red externa (redistribuida) desde el punto de redistribución. Ejemplo de métrica inicial (seed metric). Por ejemplo, si un router de borde recibe una ruta desde RIP, ésta utiliza la cuenta de saltos como métrica. Para redistribuir esa ruta dentro de OSPF, el router debe traducir la cuenta de saltos en una métrica de costos que el router OSPF pueda comprender. Esta métrica inicial (seed metric), también conocida como métrica por defecto, es definida durante la configuración de la redistribución. Cuando se establece una métrica inicial para una ruta redistribuida, la métrica aumenta en incrementos normales dentro del sistema autónomo. Nota: La diferencia para esta regla son las rutas OSPF E21, las cuales permanecen con su métrica inicial a pesar de que tan lejos sea propagadas dentro del sistema autónomo. El comando default-metric, usado en el modo de configuración del proceso de enrutamiento, establece la métrica inicial para todas las rutas redistribuidas. Figura 1. Utilice el comando default-metric para establecer la métrica por defecto para la ruta o para especificar una métrica cuando se esta redistribuyendo. Una vez que la métrica es establecida, la métrica se incrementa, como cualquier otra ruta. Los routers Cisco también permiten que la métrica inicial sea especificada como parte del comando de redistribución, con la opción metric o utilizando un route-map. De cualquier forma que sea hecho, la métrica inicial debería ser configurada con un valor más grande que la métrica más alta recibida dentro del sistema autónomo para ayudar a prevenir un enrutamiento poco eficiente o loops de enrutamiento. La figura 2 muestra los nombres de los protocolos con sus métricas iniciales por defecto.

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

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

Figura 1 – Usando métricas seed

Figura 2 - Protocolos con sus métricas iniciales por defecto

Figura 1 – Redistribución con métricas iniciales

Page 5: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 5 CCNP: Building Scalable Internetworks

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

5.1.6 Definiendo la distancia administrativa. Muchos protocolos de enrutamiento tienen estructuras de métricas y algoritmos que no son compatibles con otros protocolos. Es crítico para una red que utiliza múltiples protocolos de enrutamiento tener perfectamente integrado el intercambio de información de rutas y la capacidad para seleccionar el mejor camino a través de múltiples protocolos. Los routers Cisco utilizan un valor llamado distancia administrativa para seleccionar el mejor camino cuando aprenden dos o más rutas hacia un mismo destino desde diferentes protocolos de enrutamiento. La distancia administrativa mide la confiabilidad de un protocolo de enrutamiento. Cisco ha asignado un valor por defecto a la distancia administrativa para cada protocolo de enrutamiento soportado en sus routers. Cada protocolo es priorizado en orden, desde el más confiable al menos confiable. Algunos ejemplos de priorización son los siguientes:

• Rutas configuradas manualmente (rutas estáticas) antes que las rutas dinámicamente aprendidas. • Protocolos con métricas sofisticadas sobre protocolos con métricas más determiniísticas. • Preferir “External Border Gateway Protocol (EBGP)” más que otros protocolos dinámicos.

En la figura 1, se muestra una tabla con la distancia administrativa por defecto para los protocolos que soporta Cisco. La distancia administrativa es un valor entre 0 y 255. A menor valor de la distancia administrativa, mayor es la confiabilidad del protocolo. Nota: IGRP no es soportado en el IOS release 12.3. Por ejemplo, en la figura 2, si un router A recibe una ruta a la red 10.0.0.0 desde RIP y recibe una ruta a la misma red desde OSPF, el router compara las distancias administrativas de RIP (120) con la distancia administrativa de OSPF (110). El router determina que OSPF es más confiable y agrega la versión de la ruta de OSPF a su tabla de enrutamiento. Longitud de prefijos. Modificar la longitud de los prefijos de rutas para diferentes protocolos de enrutamiento puede afectar las decisiones de enrutamiento. La longitud del

2 En OSPF las rutas externas se categorizar en dos tipos, tipo 1 y tipo 2. La diferencia entre ambas es la forma en que se calcula el costo (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.

Figura 1 – Distancia administrativa

Figura 2 – Ejemplo de distancias administrativas

Page 6: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 6 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. Por ejemplo, un router tiene configurados cuatro procesos de enrutamiento (sistemas autónomos) y cada proceso ha recibido las siguientes rutas:

• EIGRP (interno): 192.168.32.0 /26 • RIP: 192.168.32.0 /24 • OSPF: 192.168.32.0 /19

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

5.1.7 Modificando las distancias administrativas En algunos casos, al confiar en un protocolo de enrutamiento con una distancia administrativa mejor un router puede no seleccionar el camino más óptimo, aunque el protocolo de enrutamiento actual tenga una ruta peor. Asignando una distancia administrativa mayor a un protocolo de enrutamiento no deseado se asegura que el router seleccione rutas desde un protocolo deseado. Utilizando el comando distance se puede cambiar la distancia administrativa por defecto para todos los protocolos de enrutamiento, excepto EIGRP y BGP. La figura 1 y 2 describen las opciones de éste comando. Para EIGRP, utilice el comando distance eigrp En la figura 3, EIGRP asigna un valor diferente a la distancia administrativa de las rutas aprendidas nativamente a través de EIGRP y a las rutas redistribuidas dentro de otras fuentes. Por defecto, en EIGRP las rutas aprendidas tienen una distancia administrativa de 90, pero

Figura 3 – Prefijo de longitud variable

Figura 1 – Modificando distancias administrativas

Figura 2 – Parámetros del comando distance

Page 7: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

las rutas externas tienen una distancia administrativa de 170. Para BGP, utilice el comando distance bgp. BGP asigna un valor diferente a la distancia administrativa de las rutas conocidas a través de IBGP y a las rutas aprendidas a través de EBGP.

5.2 Configurando y verificando redistribución en el router.

5.2.1 Configurando redistribución. Configurar la redistribución de rutas puede ser simple o complejo dependiendo de la mezcla de protocolos que se quieran redistribuir. Los comandos utilizados para habilitar la redistribución y para asignar métricas varían ligeramente dependiendo de los protocolos que estén siendo redistribuidos. Antes de configurar el intercambio de información de enrutamiento entre protocolos, se debe comprender claramente los procedimientos y requerimientos de cada uno de los protocolo de enrutamiento. La redistribución debe ser configurada correctamente para cada protocolo de enrutamiento, para sí obtener los resultados deseados. Como se muestra en la figura 1, todos los protocolos de enrutamiento soportan la redistribución. Adicionalmente, las rutas estáticas y directamente conectadas pueden ser redistribuidas para permitirle al protocolo de enrutamiento publicar estas rutas sin utilizar una red declarada. Intercambiando información de enrutamiento entre protocolos de enrutamiento se conoce como redistribución de rutas. La redistribución de rutas puede ser en uno o dos sentidos. Las rutas en un sentido son aquellas en donde un protocolo recibe 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.

Figura 3 – Parámetros del comando distance eigrp

Figura 1 – Redistribución soporta todos los protocolos

Page 8: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

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

Los siguientes pasos son genéricos para aplicar en todas las combinaciones de protocolos: sin embargo, los comandos que son usados para implementar estos pasos pueden variar. Para la configuración de comandos, es importante revisar la documentación de Cisco IOS para un protocolo de enrutamiento específico que necesite ser redistribuido. Nota: En este tópico, los términos “core” y “Edge” son utilizados para simplificar la aclaración. 1. Localizar los routers de borde

(edge) que requieran configuraciones de redistribución. Seleccionando solo un router para redistribución se minimiza la probabilidad de crear loops de enrutamiento causados por la retroalimentación (feedback).

2. Determinar cual protocolo de enrutamiento es el protocolo del core o backbone. Típicamente este protocolo es OSPF, IS-IS o EIGRP

3. Determinar cual es el protocolo de borde o de backbone (en caso de migración). Determine si todas las rutas de un protocolo de borde deben ser propagadas dentro del Core. Se deben considerar métodos para reducir el número de rutas.

4. Seleccionar un método para inyectar las rutas requeridas del protocolo de borde dentro del core. Un redistribución simple utilizando redes sumarizadas en la frontera minimiza el número de nuevas entradas en la tabla de enrutamiento de los routers del core.

Cuando se planea la redistribución desde el borde al core, se debe considerar como inyectar la información de enrutamiento del core dentro del protocolo de borde. La elección depende de su red.

5.2.2 Redistribuyendo rutas dentro de un protocolo de enrutamiento classful. La figura 1 muestra como configurar la redistribución desde un proceso 1 de OSPF dentro de RIP. En la figura, el ejemplo utiliza el comando router rip para acceder al proceso de enrutamiento, dentro del cual se encuentran las rutas que necesitan ser redistribuidas. En este caso, se utiliza el proceso de enrutamiento RIP. El ejemplo utiliza el comando redistribute para especificar el protocolo de enrutamiento a ser redistribuido dentro de RIP. En este caso, es el proceso de enrutamiento número 1 de OSPF.

Figura 2 – Ejemplo de redistribución

Figura 1 – Configurando redistribución en RIP

Page 9: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

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

5.2.3 Redistribuyendo desde protocolos classless a protocolos classful. En la figura 1, rutas desde el proceso 1 de OSPF están siendo redistribuidas dentro de RIP y tienen una métrica inicial de 3. Como no se especifica el tipo de ruta, ambas rutas de OSPF, internas y externas, son redistribuidas dentro de RIP. Un problema común con la redistribución de rutas entre RIP y OSPF es que RIP no publica rutas fuera de una interfaz aunque estas rutas se encuentren en la misma red pero tengan una máscara de red diferente a la de la interfaz. Los

Figura 2 – Comando redistribute

Figura 3 – Parámetros del comando redistribute

Figura 1 – Redistribuyendo en RIP

Page 10: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

siguientes son dos escenarios en que describe este problema. OSPF tiene una máscara mayor que RIP. En la figura 2, el router RTB esta redistribuyendo entre RIP y OSPF. El dominio OSPF tiene una máscara de red diferente (mayor en este caso) que el dominio RIP, y están en la misma red. Por consiguiente, RIP no publica las rutas aprendidas desde OSPF y redistribuidas dentro de RIP. La máscara de subred del dominio OSPF es difícil de cambiar, en lugar de eso, se agrega una ruta estática en el router RTB que apunte al dominio OSPF con una máscara de 255.255.255.0 pero con un salto siguiente (next-hop) hacia Null0. Luego, se redistribuyen las rutas estáticas dentro de RIP, A continuación se muestra las configuraciones necesarias para realizar esta tarea: ip route 128.103.35.0 255.255.255.0 null0 Router rip Redistribute static Default metric 1 Esto permite que la red 128.103.35.0 sea publicada a través de RIP fuera de la interfaz E2/0 del router RTB. Sin embargo, el router RTB tiene rutas mas especificas aprendidas desde OSPF en su tabla de enrutamiento, con las que realiza mejores decisiones de enrutamiento. RIP tiene una máscara mayor que OSPF. En la figura 3, el dominio RIP tiene una mascara de 255.255.255.248, y el dominio OSPF tiene una máscara de 255.255.255.240. RIP no publica rutas aprendidas desde OSPF y redistribuidas dentro de RIP. Nosotros podemos agregar una ruta estática en el router RTB que apunte hacia el dominio OSPF con una máscara de 255.255.255.248, Sin embargo, dado que esta es una máscara de red más especifica que la mascara original de OSPF, el siguiente salto debe ser la interfaz actual del siguiente salto. También necesitaremos múltiples rutas estáticas para cubrir todas las direcciones de el dominio OSPF. De esta forma las rutas estáticas son redistribuidas dentro de RIP. En el código mostrado más abajo, las primeras dos rutas estáticas cubren el rango 128.103.32.32 255.255.255.240 del dominio OSPF. Las segundas dos rutas estáticas cubren el rango 128.103.35.16 255.255.255.240 del dominio OSPF. Y las últimas cuatro rutas estáticas cubren el rango 128.130.65.64 255.255.255.240, las cuales son conocidas a través de dos interfaces en el dominio OSPF. ip route 128.103.35.32 255.255.255.248 E0/0 ip route 128.103.35.40 255.255.255.248 E0/0 ip route 128.103.35.16 255.255.255.248 E1/0 ip route 128.103.35.24 255.255.255.248 E1/0 ip route 128.103.35.64 255.255.255.248 128.103.35.34 ip route 128.103.35.64 255.255.255.248 128.103.35.18

Figura 2 – Ejemplo de OSPF teniendo una máscara

más larga que RIP

Figura 3 – Ejemplo de RIP teniendo una máscara

más larga que OSPF

Page 11: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

ip route 128.103.35.72 255.255.255.248 128.103.35.34 ip route 128.103.35.72 255.255.255.248 128.103.35.18 router rip redistribute static default metric 1

5.2.4 Redistribuyendo rutas dentro de un protocolo de enrutamiento classless. La figura 1, muestra como configurar la redistribución del sistema autónomo 100 de EIGRP dentro de OSPF. El comando router ospf 1 es utilizado para introducir en el proceso 1 de OSPF las rutas que necesitan ser redistribuidas. El comando redistribute le especifica al protocolo de enrutamiento que sea redistribuido dentro de OSPF. En este caso, es el sistema autónomo 100 de EIGRP. La figura 2 muestra la sintaxis del comando redistribute en OSPF. La figura 3 muestra los parámetros del comando. La redistribución de OSPF puede ser limitada a un numero definido de prefijos por el comando redistribute maxium-prefix maxium {threshold} ó {warning-only}. El parámetro threshold (umbral) por defecto registra las advertencias un 75% del valor máximo configurado. Después de alcanzar el numero máximo configurado, no mas rutas son redistribuidas. Si el parámetro warning-only es configurado, no hay limite para la redistribución. El valor máximo simplemente se convierte en un segundo punto donde otro mensaje warning es almacenado. Este comando fue introducido en el release 12.0(25)S y fue integrado dentro del IOS release 12.2(18)S, 12.3(4)T, y posteriores.

Figura 1 – Configurando redistribución en RIP

Figura 2 – Comando redistribute

Page 12: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 12 CCNP: Building Scalable Internetworks

5.2.5 Ejemplo de redistribución de rutas dentro de OSPF. En la figura 1, la métrica por defecto de 20 esta siendo usada para OSPF y el tipo de métrica es configurada como externa tipo 1. Este tipo de configuración logra que la métrica se incremente a medida que las actualizaciones pasen a través de la red. El comando contiene la opción subnet, la cual provoca que las subredes (subnets) sean redistribuidas.

5.2.6 Redistribuyendo rutas dentro de EIGRP. La figura 1 muestra como configurar la redistribución desde OSPF al sistema autónomo 100 de EIGRP. El comando router eigrp 100 es utilizado para acceder al proceso de enrutamiento dentro del cual las rutas necesitan ser redistribuidas.

Figura 3 – Parámetros del comando redistribute

Figura 1 – Redistribuyendo en OSPF

Page 13: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 13 CCNP: Building Scalable Internetworks

El comando redistribute le especifica que el protocolo de enrutamiento sea redistribuido dentro del sistema autónomo 100 de EIGRP. Es este caso, el proceso de enrutamiento 1 de OSPF. Nota: Cuando se redistribuye una ruta estática o directamente conectada dentro de EIGRP, la métrica por defecto es igual a la métrica de la interfaz saciada. La figura 2 muestra la sintaxis del comando redistribute en EIGRP. La figura 3 muestra los parámetros del comando.

Figura 1 – Configurando redistribución en EIGRP

Figura 2 – Comando redistribute

Figura 3 – Parámetros del comando redistribute

Page 14: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 14 CCNP: Building Scalable Internetworks

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

5.2.8 Redistribuyendo rutas dentro de IS-IS La figura 1 muestra la sintaxis y como configurar la redistribución desde el sistema autónomo 100 de EIGRP dentro de IS-IS. El comando router isis es utilizado para acceder al proceso de enrutamiento dentro del cual las rutas necesitan ser redistribuidas. El comando redistribute específica el protocolo de enrutamiento que va a ser redistribuido dentro de IS-IS. En este caso, es el sistema autónomo 100 de EIGRP. La figura 2 muestra los parámetros del comando. Cuando se redistribuyen rutas de IS-IS dentro de otro protocolo de enrutamiento, se pueden incluir rutas de nivel 1, de nivel 2 o ambas. La salida, mostrada en la figura 3, muestra los parámetros disponibles para escoger estas rutas. Si no se especifica un nivel, todas las rutas serán redistribuidas. También se puede limitar la redistribución dentro de IS-IS definiendo un número de prefijos utilizando el comando redistribute maxium-prefix maxium {threshold} {warning-only | withdraw}. El parámetro threshold por defecto registra un 75% del valor máximo configurado. Después de alcanzar el porcentaje máximo configurado, no se redistribuyen mas rutas. El parámetro opcional withdraw también provoca que IS-IS reconstruya los link-state PDU`s. que están en los paquetes link-state sin un prefijo IP externo (redistribuido). Si el parámetro

Figura 1 – Redistribución en EIGRP

Figura 1 – Configurando redistribución en IS-IS

Page 15: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 15 CCNP: Building Scalable Internetworks

warning-only es configurado, no hay limites en la redistribución. El valor máximo del número configurado se convierte simplemente en un segundo punto donde otro mensaje warning es registrado. Este comando fue introducido en el release 12.0(25)S y fue integrado dentro del release 12.2(18)S, 12.3(4)T, y posteriores.

5.2.9 Ejemplo de redistribución de rutas dentro de IS-IS. En la figura 1, las rutas son redistribuidas desde el sistema autónomo 100 de EIGRP dentro de IS-IS en el router A. No se les configura una métrica, por esto esas rutas tienen una seed metric de 0. No se les configura un tipo de nivel, por ello las rutas son redistribuidas como rutas de nivel 2 (como se muestra en la tabla de enrutamiento del router B).

Figura 2 – Parámetros del commando redistribute

Figura 3 – Redistribución IS-IS en otros protocolos de enrutamiento

Figura 1 – Redistribución en IS-IS

Page 16: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 16 CCNP: Building Scalable Internetworks

5.2.10 Redistribuyendo rutas estáticas y conectadas . En la redistribución de información entre IGP`s, a veces es necesario redistribuir información sobre rutas estáticas. Por ejemplo, en la figura 1 una ruta estática por defecto (0.0.0.0 0.0.0.0) ha sido configurada en el router RTX para alcanzar al router RTA y el router RTA ha sido configurado con una ruta estática para alcanzar la red LAN 172.16.1.0 en el router RTX. Para actualizar los otros routers conectados al router RTA acerca de la red 172.16.1.0, el router RTA debe ser configurado para redistribuir las rutas estáticas dentro de RIP. El comando redistribute static le dice a RIP que importe las rutas estáticas y las anuncie como parte de las actualizaciones de RIP. Nota: El comando passive-interface es explicado en la siguiente lección. Para redistribuir las rutas directamente conectadas, es necesario utilizar el comando redistribute conected. Redistribuir redes directamente conectadas dentro del protocolo de enrutamiento no es una práctica común; sin embargo se puede realizar.

5.2.11 Verificando la redistribución de rutas. La figura 1 muestra la red hipotética de una compañía. La red comienza con dos dominios de enrutamiento, también conocidos como sistemas autónomos, uno usando OSPF y el otro usando RIP versión 2. El router B es el router de borde. Éste conecta directamente a un router dentro de cada dominio de enrutamiento y corre ambos protocolos. El router A esta en el dominio RIP y publica la subred 10.1.0.0, 10.2.0.0 y 10.3.0.0 al router B. El router C esta en el dominio OSPF y publica las subredes 10.8.0.0, 10.9.0.0, 10.10.0.0 y 10.11.0.0 al router B. La configuración del router B se muestra en la figura. Se requiere RIP para correr solamente en la interfaz serial 1. Por lo tanto, el comando passive-interface es puesto en la interfaz serial 2. El comando passive-interface previene que desde RIP se envíen publicaciones de rutas fuera de la interfaz. OSPF es configurado en la interfaz serial 2. La figura 2 muestra la tabla de enrutamiento

Figura 1 – Redistribución de información estática

Figura 1 – Configuración antes de la redistribución

Figura 2 – Tabla de enrutamiento antes de la redistribución

Page 17: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 17 CCNP: Building Scalable Internetworks

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

• Redistribuir rutas de RIP dentro de OSPF • Redistribuir rutas OSPF dentro del dominio RIP

La redistribución debe ser configurada en el router de borde. La figura 3 muestra como el router B es configurado para cumplir con el requerimiento de la redistribución. RIP es redistribuido dentro OSPF. En este ejemplo, la métrica es configurada dentro del comando redistribute. Otras opciones, dentro de las cuales se incluyen especificar una métrica por defecto (default metric) o aceptar la métrica por defecto de OSPF la cual es de 20. El comando default-metric asigna una métrica seed a todas las rutas redistribuidas dentro de OSPF desde cualquier origen. Si se le configura un valor a la métrica específicamente bajo el comando redistribute , este valor sobrescribe el valor de la métrica por defecto. El valor seleccionado es 300 porque es la peor métrica de cualquier ruta nativa en OSPF. Bajo el proceso RIP, las rutas redistribuidas son redistribuidas desde el proceso 1 de OSPF. Estas rutas son redistribuidas dentro de RIP con una métrica de 5. El valor de 5 es escogido porque es mayor que cualquier métrica el la red RIP.

5.2.12 Ejemplo de verificación de redistribución de rutas. La figura 1 muestra la tabla de rutas de los tres routers después de que se completó la redistribución. Como se puede ver, se ha cumplido la finalidad: Ahora todos los routers tienen rutas hacia todas las subredes remotas. El router A y C tiene muchas mas rutas para mantener que antes. Cada router también es afectado por los cambios de la topología en el dominio de enrutamiento de los otros routers. Dependiendo de los requerimientos de la red, se puede incrementar la eficiencia sumarizando las rutas antes de que sean redistribuidas. Recuerde que la sumarización de rutas oculta información. Si los routers en los otros sistemas autónomos requieren seguir un cambio de topología dentro de la red, la sumarización no debería ser realizada, porque oculta información que los routers necesitan.

Figura 3 – Configurando la redistribución de rutas

Figura 1 – Tabla de enrutamiento después de la redistribución

Page 18: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 18 CCNP: Building Scalable Internetworks

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

• Router A, RIP : Para RIPv2, el comando para la sumarización es puesto en la interfaz que conecta al router B con el Router A. Esta dirección sumarizada es publicada en vez de subredes individuales. Una limitación de RIP es que la máscara de subred de la dirección sumarizada debe ser mayor o igual que la máscara por defecto de la mayor red classful. Utilice el siguiente comando para RIPv2. RouterA(config)# interface s0 RouterA(config-if)# ip summary-address rip 10.0.0.0 255.252.0.0

Nota: Esta sumarización incluye 10.0.0.0, la cual es aceptable en este caso porque esta directamente conectada con una máscara mayor.

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

Para sumarizar rutas externas al ASBR, se debe utilizar el comando summary-addresss.

Figura 2 – Tabla de enrutamiento después del resumen de rutas y de la redistribución

Page 19: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 19 CCNP: Building Scalable Internetworks

5.2.13 Problemas de distancia administrativa con la redistribución El siguiente ejemplo describe una red utilizando múltiples protocolos de enrutamiento. Estos ejemplos muestran como pueden ocurrir problemas y como se pueden solucionar. La figura 1 ilustra una red con dominios de enrutamiento RIP y OSPF. OSPF es más confiable que RIP, porque OSPF tiene una distancia administrativa de 110 y RIP tiene una distancia administrativa de 120. Si, por ejemplo, el router de borde (P3R1 o P3R2) aprende acerca de la red 10.3.3.0 vía RIPv2 y también vía OSPF, la ruta OSPF es usada e insertada dentro de la tabla de enrutamiento porque OSPF tiene una distancia administrativa más baja que RIPv2, aun cuando el camino a través de OSPF pueda ser mas largo (peor). La figura 2 muestra las configuraciones para los routers P3R1 y P3R2. Estas configuraciones redistribuyen RIP dentro de OSPF y OSPF dentro de RIP en ambos routers. La redistribución dentro de OSPF configura una métrica OSPF por defecto para la red 10.0.0.0, ésto para hacer que estas rutas sean menos preferidas que las rutas nativas de OSPF y así protegerse contra el “feedback” de rutas. La sentencia redistribute también configura una métrica de tipo 1 para que la métrica de las rutas continúe aumentando y el router redistribuya la información de la subred. La redistribución dentro de RIP configura una métrica de 5 por defecto también para protegerse contra el “feedback” de rutas. La figura 3 muestra la tabla de enrutamiento en el router P3R2 después de ocurrida la redistribución. El router P3R2 conoce las rutas de RIP y OSPF pero lista solo las rutas de OSPF en su tabla de enrutamiento. El primer router de borde establece la redistribución como una tabla de enrutamiento normal y retiene las rutas RIP. El segundo router de borde escoge las rutas de OSPF sobre las rutas de RIP. El camino hacia las rutas internas de RIP se muestra como yendo a través del core por los puntos duales de redistribución mutua.

Figura 1 – Redistribución usando la distancia administrativa

Figura 2 – Redistribución usando la distancia administrativa (cont.)

Page 20: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 20 CCNP: Building Scalable Internetworks

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

5.2.14 Solución de la distancia administrativa con redistribución Hay un número de formas para corregir los problemas de selección de caminos en un ambiente de redistribución. Este ejemplo una posible forma. Uno de los routers de borde (P3R2 en este ejemplo) selecciona n mal camino puesto que OSPF tiene una mejor distancia administrativa que RIP. Usted puede cambiar la distancia administrativa de las rutas para asegurar que los routers de borde seleccionen las rutas nativas de RIP, como lo muestra la figura 1. En la figura 1, el comando distance modifica la distancia administrativa de las rutas OSPF para las redes que hacen match con la lista de acceso (ACL) 64. Específicamente, el comando distance 125 0.0.0.0 255.255.255.255 64 asigna la distancia administrativa de 125 a todas las rutas especificadas en la ACL 64.

Figura 3 – Redistribución usando la

distancia administrativa (cont.)

Figura 1 – Solución a la redistribución

Page 21: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 21 CCNP: Building Scalable Internetworks

En este escenario, la ACL 64 es utilizada para hacer match con todas las rutas nativas de RIP. El comando access-list 64 permit 10.3.1.0 configura una ACL estandar para permitir la red 10.3.1.0. Otras sentencias similares de ACL`s permiten las otras redes RIP nativas (internas). Nótese que ambos routers de redistribución son configurados para asignar una distancia administrativa de 125 a las rutas OSPF que son publicadas por las redes listadas en la ACL 64. La ACL 64 tiene sentencias permit para las redes internas nativas de RIP de 10.3.1.0, 10.3.2.0 y 10.3.3.0 así como las redes loopback 10.200.200.31, 10.200.200.32, 10.200.200.33 y 10.200.200.34. Cuando cualquiera de los routers que están redistribuyendo aprende alguna de esas redes desde RIP, selecciona la ruta aprendida desde RIP (con una menor distancia administrativa (120)) sobre la misma ruta aprendida desde OSPF (con una distancia administrativa de 125) y coloca solo las rutas de RIP en la tabla de enrutamiento. El comando distance es parte de la configuración del proceso de enrutamiento porque la distancia administrativa debería ser cambiada para estas rutas cuando ellas sean publicadas por OSPF, no por RIP. Usted necesita configurar el comando distance en ambos routers de redistribución porque cualquiera puede tener rutas suboptimas, dependiendo de cual router de redistribución envíe primero las actualizaciones OSPF acerca de las redes RIP al otro router de redistribución. La salida en la figura 2 muestra que el router P3R2 ahora retiene los caminos más directos hacia las redes internas aprendidas desde RIP. Sin embargo, alguna información de enrutamiento se pierde con esta configuración. Por ejemplo, dependiendo del actual ancho de banda, la ruta OSPF puede ser mejor para la red 10.3.1.0. Pudo no haberse incluido 10.3.1.0 en la lista de acceso. Ese ejemplo ilustra la importancia de conocer su red antes de implementar la redistribución y examinar detalladamente cuales rutas son seleccionadas en los routers después de que se habilita la redistribución. Preste particular atención a los routers que pueden seleccionar desde un numero de posibles caminos redundantes hacia una red, porque ellos pueden ser mas propensos a seleccionar caminos suboptimos. La característica más importante de usar la distancia administrativa para controlar la preferencia de rutas es que no se perderá información del camino. La información de OSPF permanecerá en la base de datos de OSPF. Si es perdido el camino primario, el camino a través de OSPF puede reafirmarse el mismo, manteniendo conectividad con esa red.

5.3 Controlando el tráfico de actualización de enru tamiento.

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

Figura 2 – Solución a la redistribución (cont.)

Page 22: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 22 CCNP: Building Scalable Internetworks

• Passive interfaces (Interfaces pasivas) • Distribute list (Listas de redistribución) • Policy routing usando route maps (Políticas de enrutamiento utilizando mapas de rutas)

No hay un tipo de filtro que sea apropiado para cada situación. Sin embargo, entre mas técnicas estén a tu disposición, mejor será tu chance de que tu red funcione “como una seda”.

5.3.2 Passive Interfaces (Interfaces Pasivas) En la figura 1, el comando network 10.0.0.0 en el modo d configuración del router habilita RIP en todas las interfaces. Por consiguiente, las interfaces E0, E1, S0 y S1 participan todas en el intercambio de información de enrutamiento. Sin embargo, enviando actualizaciones de rutas por E0 es un gasto innecesario de recursos, puesto que no hay otros routers en la subred 10.4.4.0 que puedan recibir las actualizaciones. Mientras que, enviar actualizaciones crea una ligera sobrecarga y puede causar un potencial riesgo de seguridad. Un usuario malicioso podría utilizar un sniffer de paquetes para capturar las actualizaciones de rutas y recopilar información clave de la red. Una interfaz pasiva esencialmente hace a un router silencioso en una red. Identificando una interfaz como pasiva previene que el router envie actualizaciones a través de esa interfaz. Se puede utilizar el comando passive-interface con la mayoría de los protocolos IP IGP`s, incluyendo RIP, EIGRP, OSPF e IS-IS. Para configurar una interfaz como pasiva, utilice el siguiente procedimiento: Paso 1. Seleccione el router y el protocolo de enrutamiento que requiere la passive interface. Paso 2. Determine la interfaz a través de la cual usted no quiere que sea enviado trafico 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.

Figura 1 – Topología con una interface pasiva

Figura 2 – Comando passive-interface

Figura 3 – Parámetros del commando passive-interface

Figura 4 – Topología con una interface pasiva

Page 23: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 23 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. Cuando es configurado en EIGRP, los mensajes hello no son enviados por la interfaz especificada. No se forma una relación de vecindad con los otros routers alcanzables a través de esa interfaz. Si no se encuentra otro router en una interfaz, no se envía otro tipo de tráfico EIGRP (como se muestra en la figura 6). Usando el comando passive-interface en un router corriendo un protocolo de enrutamiento estado-enlace también se previene que el router establezca adyacencias de vecindad con otros routers que están conectados al enlace especificado en el comando. El router no envía mensajes hello a la interfaz especificada. Por lo tanto, no se pueden establecer adyacencias con los vecinos porque el protocolo hello verifica que exista comunicación bidireccional entre los routers. Específicamente, en OSPF, la dirección de la interfaz que se especifica como pasiva aparece como red stub en el dominio OSPF. Figura 7. Información de enrutamiento de OSPF nunca es enviada o recibida a través de la interfaz especificada. En IS-IS la dirección IP especificada es anunciada sin estar actualmente corriendo IS-IS en esa interfaz. La figura 8 resume el comportamiento de la característica passive-interface con los comunes IGP`s.

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

Figura 5 – Interface pasiva en RIP

Figura 6 – Interface pasiva en EIGRP

Figura 7 – Interface pasiva en in OSPF

Figura 8 – Resumen de interface pasiva

Page 24: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 24 CCNP: Building Scalable Internetworks

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

5.3.4 Configurando filtrado de rutas usando distrib ute lists. La técnica de passive-interface previene que todas las actualizaciones de enrutamiento sean anunciadas por una interfaz. Figura 1. Sin embargo, en muchos casos no se busca prevenir que toda esa información sea anunciada. Si se busca bloquear solo el anuncio de ciertas rutas especificas, por ejemplo, se podría utilizar como solución para prevenir loops de enrutamiento cuando se implementa redistribución de rutas en dos sentidos con puntos de redistribución duales. Algunas formas para controlar o prevenir actualizaciones de rutas dinámicas son las siguientes:

• Interfaces pasivas: previenen que todas las actualizaciones de enrutamiento sean enviadas por una interfaz. Para EIGRP, OSPF e IS-IS, este método incluye los paquetes hello.

• Rutas por defecto (default routes) : Instruye al router que envíe paquetes hacia la ruta por defecto si no tiene una ruta hacia el destino. Por lo tanto, no son necesarias las actualizaciones dinámicas de enrutamiento acerca de redes remotas.

Figura 1 – Comado passive-interface default

Figura 1 – Controlando el tráfico de actualización de enrutamiento

Page 25: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 25 CCNP: Building Scalable Internetworks

• Rutas estáticas : Permite configurar manualmente rutas hacia destinos remotos. Por lo tanto, no son necesarias las actualizaciones de enrutamiento acerca de redes remotas

Otra forma de controlar las actualizaciones de enrutamiento es con una distribute list, la cual permite que una lista de control de acceso (ACL) sea aplicada a las actualizaciones de rutas. Usted tal vez este familiarizado con las ACL asociadas con una interfaz y utilizada para controlar el trafico IP. Sin embargo, los routers puede tener muchas interfaces y la información de enrutamiento puede ser obtenida a través de la redistribución de rutas, la cual no involucra a una interfaz o a todas. Adicionalmente, ACLs no afectan el tráfico que es originado por el router, aplicando una distribute list bajo el protocolo de enrutamiento. La ACL permitiría las redes que serán anunciadas o redistribuidas y denegaría las redes que permanecerán ocultas. El router luego aplica la ACL a la actualización de enrutamiento del protocolo. Las opciones en el comando distribute-list permiten que las actualizaciones sean filtradas basadas en tres factores:

• Interfaz de ingreso • Interfaz de salida • Redistribución desde otro protocolo de enrutamiento.

Una distribute list le da al administrador la flexibilidad para determinar cuales rutas el router distribuye.

5.3.5 Implementando Distribute list Usted puede filtrar el tráfico de las actualizaciones de enrutamiento en cualquier protocolo definiendo una ACL y aplicándola al protocolo de enrutamiento especifico. Se puede utilizar el comando distribute-list y enlazarlo con una ACL para completar el filtrado del tráfico de las actualizaciones de enrutamiento. (El comando distribute-list aplicado de entrada, permite utilizar un route map en lugar de una ACL). Figura 1. Una distribute list habilita el filtrado de actualizaciones de enrutamiento de entrada en una interfaz específica desde los routers vecinos que utilizan el mismo protocolo de enrutamiento o de salida en la interfaz hacia dichos routers. Una distribute list permite también filtrar las rutas redistribuidas desde otros protocolos de enrutamiento o fuentes. Para configurar una distribute list utilizando una ACL, utilice el siguiente procedimiento: Paso 1. Identifique la dirección de red que se quiera filtrar y cree una ACL. Paso 2. Determine si se quiere filtrar el tráfico de entrada en una interfaz o de salida, o las rutas que están siendo redistribuidas desde otra fuente.

Figura 1 – Configurando distribute-list

Figura 2 – Parámetros del comando distribute-list

Page 26: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 26 CCNP: Building Scalable Internetworks

Paso 3. Use el comando distribute-list out para asignar la ACL con el objeto de filtrar las actualizaciones de enrutamiento salientes o para asignarla a las rutas redistribuidas dentro del protocolo. La figura 2 muestra los parámetros del comando. Nota: El comando distribute-list out no puede ser utilizado con un protocolo de enrutamiento de estado-enlace para bloquear los link-state advertisements (LSAs) en una interfaz. Paso 4. Utilice el comando distribute-list in para asignar una ACL que filtre de entrada las actualizaciones de enrutamiento en una interfaz. Este comando previene que muchos protocolos de enrutamiento coloquen rutas filtradas en sus bases de datos. Cuando este comando es utilizado con OSPF, las rutas están colocadas en una base de datos pero no en la tabla de enrutamiento. La figura 3 muestra los parámetros del comando. La figura 4 muestra un ejemplo de una distribute-list aplicada de salida. La distribute list denegará la publicación de la red 10.1.1.0 por la interfaz serial 2 en el router RTA. La figura 5 muestra un ejemplo de una distribute list de entrada. Esta distribute list bloqueará, de entrada, el anuncio de la red 10.1.1.0 que ingresa por la interfaz serial 0 del router RTZ.

Figura 3 – Parámetros del comando distribute-list in

Figura 4 – Usando filtros de salida

Figura 5 – Usando filtros de entrada

Page 27: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 27 CCNP: Building Scalable Internetworks

5.3.6 Filtrando actualizaciones de enrutamiento con una distribute list. El comando distribute-list 7 out s0 en la figura 1, aplica la ACL 7 como filtro de rutas para las actualizaciones que EIGRP envía por la interfaz serial 0 a otros routers que corren EIGRP. La ACL 7 es una ACL estándar que le permite a la información de enrutamiento solo ver la red 172.16.0.0. La sentencia implícita deny any en el final de la ACL previene que sean publicadas actualizaciones de enrutamiento acerca de cualquier otra red. Como resultado, la red 10.0.0.0 permanece oculta del resto de la red.

5.3.7 Controlando la redistribución con distribute lists. Con redistribución mutua, usar una distribute list ayuda a prevenir el feedback de rutas, lo cual también ayuda a prevenir loops de enrutamiento. El feedback de rutas ocurre cuando las rutas que originalmente son aprendidas desde un protocolo de enrutamiento son redistribuidas de vuelta dentro al protocolo original. Como se muestra en la figura 1, la redistribución en dos vías es completada entre RIP y OSPF. Las redes 10.1.0.0 a la 10.3.0.0 son redistribuidas desde RIP a OSPF. El feedback de rutas podría ocurrir si fuera configurado otro punto de redistribución (Router D) y OSPF luego redistribuyera estas rutas de vuelta a RIP. La ACL 2 permite las rutas originales de RIP y deniega todas las demás. La distribute list configurada bajo OSPF se refiere a esta ACL. El resultado es que las redes 10.8.0.0 a la 10.11.0.0, originadas por OSPF, no pueden ser redistribuidas de vuelta a OSPF desde RIP. La redistribución desde OSPF a RIP es referida por la ACL 3. El router D tendrá una configuración similar al router B. Una distribute list oculta información de red, lo cual podría ser considerado una desventaja en algunas circunstancias. En una red con caminos redundantes, la finalidad de utilizar una distribute list podría ser prevenir loops de enrutamiento. La distribute list permite habilitar las actualizaciones de enrutamiento solo en los caminos deseados en donde se quiere que sean anunciadas. Sin embargo, otros routers en la red podrían no conocer otras formas para alcanzar las redes filtradas.

Figura 1 – Filtrando actualizaciones de enrutamiento con una lista de

distribución

Figura 1 – Controlando la redistribución con listas de distribución

Page 28: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 28 CCNP: Building Scalable Internetworks

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

5.4.1 Definiendo Route maps. Los route maps son similares a complejas ACLs, pero mucho más poderosas. Son mucho más flexibles que las ACLs y pueden ayudar en situaciones en que no es posible solucionarlas con ACLs. Los route maps también pueden usar complejas ACLs. Figura 1. Ellas permiten que condiciones sean probadas contra un paquete o ruta usando el comando match. Si la condición hace match, se toma una acción para modificar los atributos del paquete o ruta. Estas acciones son especificadas por el comando set. Una colección de sentencias de mapas de rutas que tengan el mismo nombre es considerado como un route map. Dentro de un route map, cada sentencia es numerada y puede ser editada manualmente. Una sentencia en un route map es análoga a una línea en una ACL. Especificando la condición match en un route map es similar a especificar la dirección fuente y destino, y la máscara en una ACL. La gran diferencia entre los route maps y las ACLs, es que el route map puede usar el comando set para modificar el paquete o la ruta.

5.4.2 Aplicaciones de los route maps. Los administradores de red usan la herramienta de los route maps para una variedad de propósitos. Algunas de las aplicaciones más comunes para los route maps son las siguientes:

• Filtrado de rutas durante la redistribución : La redistribución requiere casi siempre algún tipo de filtro de ruta. Aunque una distribute list puede ser usada para este propósito, los route maps ofrecen y agregan beneficios de manipular las métricas de enrutamiento a través del uso de los comandos set.

• Policy-based routing (PBR) : los route maps pueden ser usados para coincidir con la dirección de origen o destino, tipo de protocolo o aplicación del usuario final. Cuando ocurre una coincidencia, el comando set describe la interfaz o dirección del siguiente salto a la cual el paquete debería ser enviado. PBR permite al operador definir una política de enrutamiento diferente que la basada en el destino utilizando la tabla de enrutamiento.

• BGP: los route maps son la herramienta primaria para implementar políticas en BGP. Los administradores de redes asignan mapas de rutas para especificar sesiones BGP (Vecinos (neighbors)) para controlar que rutas son permitidas dentro y fuera del proceso BGP. Adicionalmente al filtrado, los route maps entregan una sofisticada manipulación de los atributos para los caminos de BGP.

Figura 1 – Route maps

Page 29: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 29 CCNP: Building Scalable Internetworks

5.4.3 Operación de los route maps. Los route maps operan de manera similar a las ACLs. Cuando se determinan cuales rutas serán redistribuidas desde un protocolo al siguiente, el router revisa cada ruta contra el route map, comenzando desde arriba. Figura 1. Cada línea tiene un número de secuencia, ambos para procesarlos de arriba hacia abajo y con el propósito de editarlos. Las líneas pueden ser agregadas o removidas de un route map cuando se requiera un cambio. Cada línea tiene una sentencia permit o deny. Si una ruta coincide con la sentencia y la sentencia es permit, el router configura la métrica u otra condición definida y permite la redistribución de la ruta. El route map detiene el procesamiento en el primer match. Si el paquete coincide (match) y el route map tiene una sentencia deny, el router detiene el procesamiento y no redistribuye a ruta. Las rutas son filtradas por este método. Las rutas son revisadas línea por línea buscando una coincidencia. Si no hay coincidencia y el final del route map es alcanzado, el router deniega la ruta antes de ser redistribuida. Como en una ACL, hay una sentencia deny any implícita al final del route map. Las coincidencias de las sentencias son complejas en un route map. Figura 2. Múltiples criterios de coincidencias en la misma línea son procesados con un OR lógico. Criterios de selección separados pueden ser aplicados verticalmente bajo un route map. En este caso, cada match utiliza un AND lógico. Un route map puede consistir de múltiples sentencias. Las sentencias son procesadas de arriba hacia abajo, como en las ACL. La primera coincidencia encontrada para una ruta es aplicada. El número de secuencia es usado para insertar o borrar una sentencia en un lugar específico del route map. El comando match define la condición a ser revisada. El comando set define la acción a seguir si hay una coincidencia. Una sentencia que coincida puede contener múltiples condiciones. Por lo menos una condición de las sentencias declaradas debe ser cierta para que la sentencia sea considerada como coincidente (OR lógico). Un route map puede contener múltiples sentencias coincidentes. Todas las declaraciones en un route map deben ser verdaderas para considerar que el route map hace match (AND lógico). El número de secuencia especifíca el orden en el cual las condiciones son validadas. Por ejemplo, si hay dos sentencias en un route map llamadas MYMAP, una con un número de secuencia 10 y otra con un número 20, la secuencia 10 es verificada primero. Si la condición de la secuencia 10 no concuerda, se continúa con la sentencia 20.

Figura 1 – Operación con Route map

Figura 2 – Operación con Match

Page 30: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 30 CCNP: Building Scalable Internetworks

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

5.4.4 Usando el comando route map. El comando route-map define las condiciones para el filtrado de rutas y redistribución. La figura 1 y la 2 muestran las opciones del comando. Cuando es utilizado para filtros en la redistribución, un route map es aplicado al proceso de redistribución de rutas agregando la sentencia route-map map-tag al final del comando redistribute protocol.

5.4.5 El comando match. El comando match es aplicado dentro de un route map. Figura 1. La figura 2 muestra algunos de los parámetros del comando match. Los parámetros representan una lista general de los criterios a comparar. Algunos criterios son utilizados por políticas BGP, algunos por PBR, y otros por filtros de redistribución.

Figura 1 – Comando route-map

Figura 2 – Parámetros del comando route-map

Figura 1 – Comando match

Page 31: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 31 CCNP: Building Scalable Internetworks

5.4.6 El comando set. El comando set es usado dentro de un route map para cambiar o agregar una característica, como la métrica, a cualquier ruta que coincida con algún criterio. Figura 1. La figura 2 muestra algunas de las opciones del comando set. No todas las opciones del comando set listadas aquí son para propósitos de redistribución. La tabla incluye opciones para redistribución y PBR.

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

Figura 2 – Parámetros del comando match

Figura 1 – Comando set

Figura 2 – Parámetros del comando set

Page 32: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 32 CCNP: Building Scalable Internetworks

El número de secuencia 10 del route map espera una dirección IP que haga match con la ACL 23 o la ACL 29. Si no existe match, el router redistribuye la ruta dentro de OSPF con una métrica de 500 y configura la nueva ruta OSPF como externa tipo 1. Si no hay match con la línea 10, se mueve a la línea 20. Si hay match con la ACL 37, no permite que la ruta sea redistribuida dentro de OSPF porque el número de secuencia 20 es un deny. Si no hay match con el número de secuencia 20, se mueve al 30. Dado que 30 es una sentencia permit y no hay un criterio que coincida, todas las rutas restantes son redistribuidas dentro de OSPF con una métrica de 5000 y como métrica externa tipo 2. Implementando Policy Routing. La figura 2 presenta un escenario de policy routing. Un route map puede ser usado en RTA para implementar policy routing. Se asume para este ejemplo que la política es reforzada como sigue:

• Rutear el tráfico hacia Internet desde la red 192.168.1.0/24 por el ISP1

• Rutear el tráfico hacia Internet desde la red 172.16.1.0/24 por el ISP2

Primero, se define la lista de acceso que será usada en el route map para que coincida con las direcciones IP. Luego se configura el route map utilizando la sintaxis mostrada en la figura 3. El comando en la figura tiene actualmente configuradas dos políticas. El route map ISP1 coincide con la ACL 1 y enruta el tráfico saliente por la interfaz s0 hacia el ISP1. El route map ISP2 coincide con la ACL 2 y enruta el tráfico saliente de la interfaz s1 hacia el ISP2. El paso final es aplicar cada route map a la interfaz apropiada en el RTA usando el comando ip policy route-map. Figura 4. Con el route map aplicado a la apropiada interfaz LAN, el policy routing es implementado satisfactoriamente. Frecuentemente, los route maps son usados para controlar el intercambio de información de enrutamiento durante la redistribución.

Figura 1 – Route maps con commandos de redistribución

Figura 2 – Ejemplo de política de enrutamiento

Figura 3 – Configurando un route map

Figura 4 – Aplicando un route map a una interface

Page 33: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 33 CCNP: Building Scalable Internetworks

5.5 DHCP

5.5.1 El propósito del DHCP. DHCP es estructurado en el protocolo de servidor Bootstrap (BOOTP) y puerto BOOTP también conocido como User Datagram Protocol (UDP). Previo a DHCP. Las direcciones IP eran administradas manualmente, lo cual era un proceso tedioso, propenso a errores e intensivo. DHCP permite que las direcciones IP sean asignadas automáticamente a los clientes DHCP. El servicio DHCP puede ser implementado con un servidor dedicado o con un dispositivo que utilice un Cisco IOS. La figura 1 muestra donde debería ser implementado el DHCP en una red empresarial.

5.5.2 Comprendiendo el funcionamiento del DHCP. Un dispositivo que utilice Cisco IOS puede actuar como servidor DHCP, cliente, o agente relay. La figura 1 muestra los pasos que ocurren cuando un cliente DHCP solicita una dirección IP a un servidor DHCP:

1. El host envía un mensaje broadcast DHCPDISCOVER para localizar al servidor DHCP.

2. Un servidor DHCP ofrece parámetros de configuración como una dirección IP, nombre de dominio, un servidor DNS, gateway y el arriendo de una dirección IP al cliente a través de un mensaje unicast DHCPOFFER. También pueden ir incluidas opciones para Telefonía IP como la opción 150, la cual es utilizada para la configuración de teléfonos IP mediante TFTP.

3. El cliente devuelve una solicitud formal para la dirección ofrecida al servidor DHCP en un mensaje broadcast DHCPREQUEST.

4. El servidor DHCP confirma que la dirección IP ha sido asignada al cliente devolviéndole un mensaje unicast DHCPACK.

Un cliente DHCP puede recibir ofertas de múltiples servidores y puede aceptar una de estas ofertas. Sin embargo, el cliente usualmente acepta la primera oferta que recibe. También, la oferta del servidor DHCP no garantiza que la dirección IP sea asignada al cliente. El servidor usualmente reserva la dirección hasta que el cliente tenga la opción de aceptar formalmente la dirección. DHCP soporta tres posibles mecanismos de asignamiento:

Figura 1 – DHCP

Figura 1 – DHCP

Page 34: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 34 CCNP: Building Scalable Internetworks

• Manual : El administrador de red asigna una dirección IP a una dirección MAC específica. DHCP envía la dirección asignada al host.

• Automática : La dirección IP es permanentemente asignada al host. • Dinámica : La dirección IP es asignada al host por un tiempo limitado o hasta que expire el periodo de

arrendamiento. El mecanismo soporta la reutilización automática de direcciones cuando el host al cual se le asignó la dirección ya no la necesita.

5.5.3 Configurando DHCP Configurar un Cisco IOS como servidor DHCP requiere las siguientes tareas:

• Configurar el agente de base de datos DHCP o deshabilitar el registro de conflictos DHCP

• Configurar un pool de direcciones para DHCP (requerido)

• Excluir direcciones IP • Habilitar las características de

servidor DHCP y agente relay • Configurar arrendamiento manual • Configurar un archivo de booteo

para en DHCP Server • Configurar un numero de

paquetes ping y timeout • Habilitar el cliente Cisco IOS

DHCP en interfaces Ethernet • Ejecutar la importación o auto

configuración de las opciones del servidor DHCP

• Configurar las opciones de información del agente relay en mensajes BOOTREPLY

• Configurar la información de políticas de reenvío del agente relay

• Habilitar la característica de DHCP smart-relay

No todas las opciones son cubiertas en detalle. Información adicional de estas características adicionales se encuentra disponible en el sitio Web de Cisco. La figura 1 identifica la mayoría de los comandos para implementar el servidor DHCP del Cisco IOS. La figura 2 muestra los comandos adicionales para afinar el arrendamiento manual de direcciones para clientes individuales, incluyendo dirección MAC. También existen opciones adicionales con la implementación de la función de DHCP relay. Antes de configurar la característica de DHCP server, se deberían completar las siguientes tareas:

Figura 1 – Configurando un servidor DHCP

Figura 2 – Comandos y parámetros del servidor IOS DHCP

Page 35: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 35 CCNP: Building Scalable Internetworks

Paso 1. Identificar los servidores externos de FTP, TFTP, o RCP para almacenarlos en la base de datos de arrendamientos. Paso 2. Identificar el rango de direcciones IP a ser asignado por el servidor DHCP y las direcciones a ser excluidas (gateways por defecto y otras direcciones estáticas asignadas dentro del rango dinámico). Paso 3. Identificar las opciones DHCP necesarias para los dispositivos, incluyendo:

• Nombre de la imagen de booteo por defecto • Routers por defecto (Defaut gateways) • Servidores DNS • Servidor de nombres de NetBIOS • Opciones de telefonía IP, como opción 150

Paso 4. Decidir un nombre de dominio DNS. Los dispositivos que utilizan Cisco IOS pueden ser configurados también como clientes DHCP y agentes DHCP relay. La figura 3 muestra un ejemplo de la configuración DHCP. En el ejemplo en la figura 4, dos pool de direcciones DHCP son creados: uno para la subred 172.16.1.0 y otro para la subred 172.16.2.0. El host recibe la dirección desde el servidor DHCP más cercano. El router determina como entregar la dirección basándose en la dirección IP de la interfaz del router.

Figura 3 – Ejemplo de configuración DHCP

Figura 4 – Ejemplo DHCP

Page 36: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 36 CCNP: Building Scalable Internetworks

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

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

5.5.6 El IP helper address. Un agente DHCP relay es cualquier host que reenvía paquetes DHCP entre clientes y servidores. Agentes de relay reciben un mensaje DHCP y luego generar un nuevo mensaje DHCP para enviarlo por otra interfaz. El agente reenvía las solicitudes y las replica entre servidores y clientes cuando no están en la misma subred. Figura 1. El agente DHCP relay del Cisco IOS es habilitado en una interfaz solo cuando el comando ip helper-address es configurado. Los clientes DHCP utilizan broadcast UDPs para enviar el mensaje inicial DHCPDISCOVER, porque ellos no tienen información acerca de la red a la cual están conectados. Si el cliente esta en una red que no cuenta con un servidor DHCP, los mensajes UDP bradcast normalmente no son reenviados por el router.

Figura 1 – Ejemplo DHCP

Figura 1 – Cliente DHCP

Figura 1 – Helper address

Page 37: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 37 CCNP: Building Scalable Internetworks

El comando ip helper-address provoca que los broadcast UDP cambien a un mensaje unicast y sean reenviados por otra interfaz a una dirección IP especificada por el comando. Figura 2. El agente de relay configura la dirección del gateway (campo giaddr del paquete DHCP) y, si esta configurado, agrega la información de las opciones del agente relay (como la opción 82) en el paquete y lo reenvía al servidor DHCP. La respuesta desde el servidor es reenviada de vuelta al cliente después de remover la opción 82.

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

5.5.8 Personalizando los servicios de reenvío UDP. Los siguientes son los puertos bien identificados que por defecto reenvían los servicios UDP:

• Tiempo (Time): 37 • TACACS: 49 • DNS: 53 • Servidor BOOTP/DHCP: 67 • Cliente BOOTP/DHCP: 68 • TFTP: 69 • Servicio de nombres NetBIOS:

137 • Servicio de datagramas

NetBIOS: 138 Usted puede eliminar puertos del reenvío de servicios con el comando no ip forward-protocol, y agregar puertos con el comando ip forwared-protocol.

Figura 2 – ¿Por qué se usa helper address?

Figura 1 – Comado ip helper address

Figura 1 – Personalizando los servicios de envio UDP

Page 38: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 38 CCNP: Building Scalable Internetworks

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

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

1. El cliente DHCP genera una solicitud DHCP y la envía como broadcast a la red.

2. El agente DHCP relay intercepta el paquete broadcast con solicitud DHCP y le inserta la información de la opción 82 al paquete. La opción del relay agent contiene información relacionada con la subopción.

3. En agente DHCP relay envía como unicast el paquete DHCP al servidor DHCP.

4. El servidor DHCP recibe el paquete y usa la subopción para asignar la dirección IP y otros parámetros de configuración y le reenvía el paquete de vuelta al cliente.

5. El campo subopción es quitado del paquete por el agente relay mientras es reenviado al cliente

La figura 2 lista las opciones soportadas por el comando.

Figura 1 – Proceso del servicio DHCP relay

Figura 2 – Opciones soportadas

Page 39: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 39 CCNP: Building Scalable Internetworks

5.5.10 Verificando los servicios de DHCP relay La figura 1 lista los comandos de verificación DHCP. La figura 2 describe los comandos y parámetros.

Figura 1 – Comandos de verificación DHCP

Figura 2 – Descripción de los comandos de verificación y parámetros de

DHCP

Page 40: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 5: Optimización de Rutas 40 CCNP: Building Scalable Internetworks

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.

Page 41: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 1 CCNP: Building Scalable Internetworks

Módulo 6: BGP

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

6.1 BGP Conceptos y Terminología

6.1.1 Usando BGP en la red de la empresa El Internet es una colección de sistemas autónomos que son interconectados para permitir la comunicación entre ellos. BGP provee el enrutamiento entre estos sistemas autónomos. Figura 1. Las empresas que quieren conectarse al Internet lo hacen a través de uno o más ISPs. Si una organización tiene únicamente una conexión a un ISP, ellos probablemente no necesitan utilizar BGP. En lugar de esto, ellos deberían utilizar una ruta por defecto. Sin embargo, si ellos tienen múltiples conexiones a un o a múltiples ISPs, BGP es apropiado ya que este permite a ellos manipular atributos de caminos para seleccionar el camino optimo. Para entender BGP, tu primero necesitas entender como este es diferente de los otros protocolos discutidos anteriormente. Los protocolos de enrutamiento pueden ser clasificados como interiores o exteriores:

• IGP: Intercambia información de enrutamiento dentro de un sistema autónomo RIP, IGRP, OSPF, IS-IS, y EIGRP son IGPs.

• EGP: intercambia información de enrutamiento entre diferentes sistemas autónomos BGP es un EGP.

Figura 1 – Sistemas autónomos

Page 42: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 2 CCNP: Building Scalable Internetworks

BGP es un protocolo de enrutamiento entre dominios (IDPR), también conocido como EGP. BGP4 es la última versión y es definido en el RFC 4271. Según lo indicado en este RFC, la clásica definición de un sistema autónomo es “Un set de routers bajo una sola administración técnica, utilizando un IGP y métricas comunes para rutear paquetes dentro del sistema autónomo, y usando un protocolo de enrutamiento de sistemas autónomos (también llamado EGP) para determinar como rutear paquetes a otros sistemas autónomos.” Los sistemas autónomos también pueden utilizar más que un IGP, potencialmente con varias clases de métricas. Desde el punto de vista de BGP, la más importante característica de un sistema autónomo es que este aparece a otros sistemas autónomos tener un solo plan de enrutamiento interior coherente y presenta un cuadro constante de destinos accesibles. Todas las partes de un sistema autónomo deben conectarse entre si. Cuando BGP esta corriendo entre ruteadores de diferentes sistemas autónomos, este es llamado BGP externo (EBGP). Cuando BGP esta corriendo entre ruteadores en el mismo sistema autónomo, este es llamada BGP interno (IBGP) Por ejemplo, una empresa de AS 65500 en la figura 2 esta aprendiendo rutas del ISP-A y del ISP-B vía EBGP, y esta también corriendo IBGP en todos sus routers. AS 65500 aprende sobre las rutas y escoge la mejor vía para cada uno basado en la configuración de los ruteadores en el sistema autónomo y las rutas BGP pasadas de los ISPs. Si una de las conexiones hacia el ISP se pierde, el tráfico es enviado a través del otro ISP. Una de las rutas que el AS 65500 aprende del ISP-A es la 172.18.0.0/16. Si esta ruta es pasada a través del AS 65500 usando IBGP y es erróneamente anunciada al ISP-B, el ISP-B puede decidir que el mejor camino para conseguir la red 172.18.0.0/16 es a través del AS 65500, en lugar de ir a través del Internet. AS 65500 debería entonces ser considerado un sistema autónomo de transito, lo cual es una muy indeseable situación. AS 65500 quiere tener una conexión de redundancia al Internet, pero no quiere actuar como un sistema autónomo de transito entre dos ISPs. Una cuidadosa configuración de BGP es requerida para evitar esta situación.

6.1.2 BGP Opciones de Multihoming Multihoming es cuando un sistema autónomo tiene más que una conexión al Internet. Las dos típicas razones para multihoming son las siguientes: Figura 1.

• Para incrementar la confiabilidad de las conexiones al Internet : Si una conexión falla, la otra conexión permanece disponible.

• Para incrementar el funcionamiento de la conexión: El mejor camino puede ser utilizado para asegurar los destinos.

Los beneficios de BGP son evidentes cuando un sistema autónomo tiene múltiples conexiones EBGP hacia uno o múltiples sistemas autónomos. Múltiples conexiones permite una organización para tener conexiones redundantes al Internet para poder mantener conectividad si un enlace llega a estar indisponible.

Figura 2 – Usando BGP para conectar a Internet

Figura 1 - ¿Qué es el Multihoming?

Page 43: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 3 CCNP: Building Scalable Internetworks

Una organización puede ser multihomed a un solo ISP o a múltiples ISPs. Una desventaja de tener todas tus conexiones a un solo ISP es que problemas de conectividad en un solo ISPs pueden causar que tu sistema autónomo pierda conexión hacia el Internet. Tener conexiones a múltiples ISPs, una organización gana los siguientes beneficios:

• Redundancia con multiples conexiones • No atarse en dentro de una política de enrutamiento de un solo ISP • Mas caminos a una misma red para una mejor manipulación de la política

Un sistema autónomo multihomed puede correr EBGP con sus vecinos externos y debe también correr IBGP internamente. Si una organización desea realizar Multihoming con BGP, hay tres comunes maneras para hacerlo:

• Cada ISP pasa únicamente una ruta por defecto al si stema autónomo : La ruta por defecto es pasada a las rutas internas.

• Cada ISP pasa únicamente una ruta por defecto y aba stece rutas especificas al sistema autónomo : Estas rutas deben ser pasadas a los routers internos, o todos los routers internos en la trayectoria de transito pueden correr BGP y pasar estas rutas entre ellos

• Cada ISP pasa todas las rutas al sistema autónomo : Todas los routers internos en la trayectoria de transito corren BGP y pasan estas rutas entre ellos

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

• La manipulación de la trayectoria no puede ser ejecutada ya que únicamente una sola ruta esta

Figura 1 – Ejemplo: Rutas por defecto desde todos los proveedores

Page 44: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 4 CCNP: Building Scalable Internetworks

siendo recibida de cada ISP. • La manipulación del Ancho de Banda es extremadamente difícil y puede ser cumplida únicamente con

la manipulación de la métrica del IGP de la ruta por defecto. • Desviar algo de tráfico de un punto de salida a otro es desafiante, ya que todos los destinos están

utilizando la misma ruta por defecto para la selección de la trayectoria. En la figura 1, AS 65000 y el AS 65250 envían rutas por defecto al AS 65500. La métrica IGP que es utilizada para alcanzar la ruta por defecto dentro del sistema autónomo determina que ISP utiliza un router específico dentro del AS 65500 Por ejemplo, si tú utilizas RIP dentro de AS 65500, el router C selecciona la ruta con el menor número de saltos hacia la ruta por defecto al enviar los paquetes hacia la red 172.16.0.0

6.1.4 Opción 2: Rutas por defecto y actualizaciones parciales En esta opción de diseño de multihoming, todos los ISPs pasan rutas por defecto y seleccionan rutas específicas al sistema autónomo. Una empresa corriendo EBGP con un ISP que quiere una tabla de enrutamiento parcial, generalmente recibe las redes que el ISP y sus otros clientes poseen. La empresa puede también recibir las rutas de cualquier otro sistema autónomo. Grandes ISPs tienen asignados entre 2000 y 10000 bloques CIDR (classless interdomain routing) de direcciones IP del Internet Assigned Numbers Authority (IANA), los cuales ellos reasignan a sus clientes. Si el ISP pasa esta información a sus clientes que quieren únicamente una parcial tabla de enrutamiento de BGP, el cliente puede redistribuir estas rutas en dentro de su IGP. Los routers internos del cliente (aquellos que no corren BGP) pueden entonces recibir estas rutas vía redistribución. Ellos pueden tomar el punto de salida más cercano basado en la mejor métrica de redes específicas, en vez de tomar la salida más cercana basada en la ruta por defecto. Adquirir una tabla parcial de BGP de cada proveedor es beneficioso ya que la selección de la trayectoria es más predecible que cuando se utiliza una ruta por defecto. En la figura 1, los ISPs del AS 65000 y AS 64900 envían rutas por defecto y rutas que cada ISP posee hacia el AS 64500. La empresa (AS 64500) pidió que ambos proveedores también envíen rutas a las redes en el AS 64520 debido a la cantidad de tráfico entre el AS 64520 y el AS 64500. Correr IBGP entre los routers internos dentro del AS 64500, As 64500 pueden escoger el óptimo camino para alcanzar las redes de los clientes (As 64520, en este caso). Las rutas para el AS 64100 y para otros sistemas autónomos que no están específicamente anunciados al AS 64500 por el ISP A y por el ISP B son determinados por la métrica del IGP que es usada en cada ruta por defecto dentro del sistema autónomo.

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

Figura 1 – Rutas por defecto desde todos los proveedores y tabla parcial

Page 45: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 5 CCNP: Building Scalable Internetworks

Esta configuración requiere muchos recursos dentro del sistema autónomo, ya que se debe procesar todas las rutas externas. El sistema autónomo envía todas sus rutas a los ISPs, los cuales procesan las rutas y las pasan a otros sistemas autónomos. En la figura 1, As 65000 y el AS 64900 envía todas las rutas hacia el AS 64500. El ISP que un router específico dentro del AS 64500 usa para alcanzar las redes externas es determinado por el protocolo BGP. Los routers en el AS 64500 pueden ser configurados para influenciar en la trayectoria para cierta red. Por ejemplo, el router A y el B pueden influenciar en el tráfico de salida del AS64500.

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

Figura 1 – Rutas completas desde todos los proveedores

Figura 1 – Sistemas autónomos BGP

Page 46: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 6 CCNP: Building Scalable Internetworks

Número de sistemas autónomos Recordar que un sistema autónomo es una colección de redes bajo una sola técnica de administración. IGPs opera dentro de un sistema autónomo, y BGP (específicamente BGP4) es utilizado entre sistemas autónomos en el Internet. Figura 1. IANA es la organización que mantiene un registro de la asignación global de direcciones IP. El Regional Internet Registry (RIR) es una organización que supervisa la asignación y registración de recursos de números de Internet dentro de una particular región del mundo. Los recursos incluyen direcciones IP (IPv4 y IPv6) y números de sistemas autónomos. Hay actualmente 5 RIRs. The American Registry for Internet Numbers (ARIN) tiene la jurisdicción de asignar numeración a las Americas y a algunas islas en el Caribe. Réseaux IP Européens Network Coordination Center (RIPE NCC) administra los sistemas autónomos de Europa, el este medio y dentro de Asia. The Asia Pacific Network Information Center (APNIC) administra la numeración de la región del Asia-Pacific. Latin American y Caribbean Internet Addresses Registry (LACNIC) es responsable de América Latina y algo del Caribe. AfriNIC es responsable para el África. El número del sistema autónomo es de 16 bits, colocados desde el 1 al 65535. El RFC 1930 provee una línea guía para el uso de estos números. Los números del 64512 al 65535 son reservados para uso privado, así como las direcciones privadas de IP. Los números de sistemas autónomos utilizados en este curso son todos en el rango privado para evitar publicar números pertenecientes a organizaciones. Nota: Utilizar un sistema autónomo asignado por el IANA mejor que un número privado, es necesario únicamente si tu organización planea utilizar un EGP, tal como BGP, y conectarse a redes públicas, tales como el Internet. Comparación con IGPs BGP trabaja diferente que IGPs. Un protocolo de enrutamiento busca el path más rápido de un punto en una red corporativa a otra basado en métricas seguras. RIP utiliza la cuenta de saltos para atravesar los dispositivos de capa 3 para alcanzar las redes destino. OSPF y EIGRP buscan la mejor rapidez acorde a la declaración del ancho de banda en la interfaz. Todos los protocolos de enrutamiento interno miran el costo del path hacia un destino. En contraste, BGP, un protocolo de enrutamiento externo, no busca la rapidez para el mejor camino. Sino que BGP es un protocolo PBR (policy-based routing) que permite a un sistema autónomo controlar el flujo de tráfico utilizando múltiples atributos en las trayectorias. BGP permite que un proveedor utilice completamente todo su ancho de banda manipulando los atributos del path.

6.1.7 Funcionalidad del Path-Vector Internamente los protocolos de enrutamiento anuncian una lista de redes y las métricas para conseguir a cada red. En contraste, los routers BGP intercambian información de confiabilidad de las redes, llamados path vectors, compuestos de path atributes. La información del path-vector incluye una lista de los full path de los números de sistemas autónomos de BGP (hop by hop) necesariamente para alcanzar una red destino y las redes que son alcanzables al final del path. Figura 1. Otros atributos incluyen la dirección IP para conseguir a el siguiente sistema autónomo (the next-hop attribute) y una indicación de cómo las redes en el final del path fueron introducidas dentro del BGP (origin code attribute). Esta información de la trayectoria

Figura 1 – Enrutando BGP path-vector

Page 47: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 7 CCNP: Building Scalable Internetworks

del sistema autónomo es utilizada para construir un grafico de sistemas autónomos basados en la información intercambiada entre BGP neighbors. BGP mira la entera red como un grafico o árbol de sistemas autónomos. La conexión entre dos cualesquier sistemas forman un path. La colección de información de path es expresada como una secuencia de números de sistemas autónomos llamados AS path. Esta secuencia forma una ruta para alcanzar un destino específico. El AS path siempre esta libre de lazos. Un router que este corriendo BGP no acepta una actualización de enrutamiento que ya incluya el numero del sistema autónomo del router en el path list, ya que la actualización ya ha pasado a través de este sistema autónomo, y aceptar esta otra vez, podría resultar en un lazo de enrutamiento.

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

• 64520 64600 64700 • 64520 64600 64540 64550 64700 • 64520 64540 64600 64700 • 64520 64540 64550 64700

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

Figura 1 – Políticas de enrutamiento BGP

Page 48: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 8 CCNP: Building Scalable Internetworks

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

6.1.9 Características de BGP BGP es utilizado por ISPs a fin de que ellos puedan comunicar e intercambiar paquetes. Los ISPs tienen múltiples conexiones entre ellos y acuerdan intercambiar actualizaciones. BGP implementa el acuerdo entre dos o más sistemas autónomos. Figura 1. El inapropiado control y filtrado de las actualizaciones BGP pueden potencialmente permitir que un sistema autónomo de afuera afecte al flujo de trafico de tu sistema autónomo. Es importante conocer como BGP funciona y como configurarlos correctamente para prevenir que esto ocurra. Por ejemplo, si tú eres un cliente conectado al ISP-A y al ISP-B (por redundancia), y tú quieres implementar una política de enrutamiento para asegurar que el ISP-A no envíe trafico al ISP-B a través de tu sistema autónomo. Tú no quieres gastar apreciados recursos y ancho de banda dentro de tu sistema autónomo para rutear tráfico de tus ISPs, pero tú quieres estar capacitado para recibir tráfico destinado a tu sistema autónomo a través de cada ISP. BGP no es siempre es la apropiada solución para interconectar sistemas autónomos. En la figura 2 por ejemplo, si únicamente existe una trayectoria de salida, una ruta por defecto es la más apropiada solución. En este caso, BGP innecesariamente utilizaría recursos de CPU y memoria del router. Si la política de enrutamiento que tú implementas en un sistema autónomo es consistente con la política en el sistema autónomo del ISP, no es necesario o deseable configurar BGP en ese sistema autónomo. BGP es categorizado como un protocolo de vector distancia avanzado, pero este es actualmente un protocolo de vector de trayectoria (path – vector protocol). BGP es muy diferente del estándar de protocolos de vector distancia, tal como RIP. Figura 3 BGP utiliza TCP como su protocolo de transporte, el cual provee una conexión orientada a una entrega confiable. BGP asume que esta comunicación es confiable: por consiguiente no tiene que implementar retransmisión o mecanismos de recuperación de errores. BGP utiliza el puerto 179 de TCP. Dos routers utilizando BGP forman una conexión TCP entre ellos e intercambian mensajes para abrir y confirmar los parámetros de la conexión. Estos dos routers BGP son llamados routers pares (peer routers) o vecinos (neighbors).

Figura 1 – Cuando usar BGP

Figura 2 – Cuando no usar BGP

Figura 3 – Características BGP

Page 49: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 9 CCNP: Building Scalable Internetworks

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

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

Figura 1 – Bases de datos BGP

Page 50: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 10 CCNP: Building Scalable Internetworks

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

6.1.11 Tipos de mensajes Los 4 tipos de mensajes BGP son de apertura, de keepalive, de actualización, y de notificación. Figura 1 Después de que la conexión TCP es establecida, el primer mensaje enviado por cada lado es un open message. Si el open message es aceptable, el lado que recibe el mensaje envía un mensaje keepalive confirmando el open message. Después de que el lado de recepción confirme el open message y establezca la conexión BGP, BGP peers pueden intercambiar cualquier mensaje de la actualización, keepalive, y mensajes de notificación. Los BGP peers intercambian inicialmente sus tablas de enrutamiento completamente. Actualizaciones incrementadas son enviadas únicamente después de que la topología cambia en la red. Los BGP peers envían mensajes de keepalive para asegurarse de que todavía existe la conexión entre los BGP peers. Ellos envían paquetes de notificación en respuesta a errores o a condiciones especiales. Aquí hay mas detalles acerca de los diferentes tipos de mensajes BGP:

• Open message : Un mensaje de apertura que incluye la siguiente información :

o Número de Versión : Las más alta versión común que ambos routers soportan es la utilizada. Todos las implementaciones BGP de hoy utilizan BGP4

o AS number : Es el numero de AS del router local. El peer router verifica esta información. Si no es un numero de AS esperado, la sesión BGP es destruida

o Holf time: Es el número máximo de segundos que pueden transcurrir entre sucesivos mensajes de

Figura 1 – Tipos de mensajes BGP

Figura 2 – Como trabaja BGP

Figura 3 – Códigos de errores de mesajes de notificación BGP

Page 51: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 11 CCNP: Building Scalable Internetworks

keepalive y de actualización del remitente. Sobre el recibo de un open message o mensaje de apertura, el router calcula el valor del hold timer utilizando cualquiera que sea más pequeño: Su hold timer configurado o el hold timer que fue recibido en el open message.

o BGP router ID : El campo de 32 bits indica el BGP ID del remitente. El ID del BGP es un IP address que se asigna al router y este es determinado por el startup El ID del router BGP se elige de la misma forma que el ID de router OSPF es escogido: Esta es la más alta dirección IP activa, a menos que exista un interfaz de loopback con una dirección IP. En este caso, el ID del router es la dirección IP más alta del loopback. El router ID puede también ser configurada estáticamente.

o Parámetros opcionales: Estos parámetros son tipo, longitud, y el valor (TLV) - codificado. Un ejemplo de un parámetro opcional es la autentificación de una sesión.

• Mensaje de Keepalive: Los mensajes keepalive de BGP se intercambian entre BGP peers frecuentemente a menudo lo suficiente para mantener que el hold timer expire. Si la negociación del intervalo del hold time es 0, periódicos mensajes de keepalive no son enviados. Un mensaje keepalive consiste en solamente un mensaje de cabecera

• Mensaje de actualización : Un mensaje de actualización BGP tiene información sobre un único path; múltiples paths requieren múltiples mensajes de actualización. Todas los atributos en un mensaje de actualización se refieren a ese path, y las redes son las que se pueden alcanzar a través de el. Un mensaje de actualización puede incluir siguientes campos

o Rutas retiradas: Esta lista muestra los prefijos de direcciones IP que son retiradas del servicio, si las hubieran. Figura 2

o Atributos de la trayectoria (path): Estas cualidades incluyen el AS path, origen, preferencia local, y así sucesivamente (según lo descrito más adelante en este módulo). Cada cualidad de la trayectoria incluye la cualidad TLV. El tipo de atributo consiste del atributo de banderas, seguidas por el tipo de atributo del codigo.

o Información de confiabilidad de la capa red: Este campo contiene una lista de los prefijos de direcciones IP que son accesibles por esta trayectoria

• Mensaje de notificacion: Un mensaje de notificacion BGP es enviado cuando se detecta una condición de error. La conexión del BGP es cerrada inmediatamente después que se envía este. Los mensajes de notificación incluyen un código de error, un subcode de error, y los datos relacionados con el error. La figura 3 muestra el campo para los códigos de error que se pueden utilizar para localizar averías de conexiones BGP.

6.2 EBGP y IBGP

6.2.1 Relaciones de Vecinos BGP Ningún router puede manejar cada conexión con todas los routers. Diez mil routers corren BGP y están conectados con el Internet, representando más de 21.000 sistemas autónomos. Un router BGP forma una relación vecina directa con un número limitado de otros routers BGP. A través de estos BGP neighbors, un router BGP aprende las trayectorias a través del Internet para alcanzar cualquier red anunciada. Cualquier router que corra BGP es conocido como BGP speaker. El término “BGP peer” tiene un significado específico: un BGP speaker es configurado para formar una relación vecina con otros BGP speaker con el fin de directamente intercambiar la información de enrutamiento del BGP con cada otro de ellos. Un BGP speaker tiene un número limitado de BGP neighbors con quienes es peers y forma una

Figura 1 – Peers = vecino

Page 52: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 12 CCNP: Building Scalable Internetworks

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

6.2.2 Estableciendo una conexión entre BGP Neighbor s externos Hay que recordar que cuando BGP está corriendo entre los routers en diversos sistemas autónomos, este es llamado EBGP. Generalmente, los routers que corren EBGP están directamente conectados el uno al otro. Figura 1 Para que dos routers intercambien actualizaciones de enrutamiento, la capa de transporte confiable TCP en cada lado, debe exitosamente pasar el TCP three-way handshake antes de que la sesión del BGP pueda ser establecida. Por lo tanto, la dirección IP usada en el comando neighbor del BGP debe ser accesible sin utilizar un IGP, que puede ser logrado señalando en una dirección que sea accesible a través de una red directamente conectada o usando rutas estáticas a esa dirección IP

6.2.3 Estableciendo una conexión entre BGP Neighbor s internos Cuando el BGP funciona entre routers dentro del mismo sistema autónomo, se llama IBGP. IBGP intercambian información BGP de modo que todos los BGP speakers tengan la misma información de enrutamiento de BGP sobre sistemas autónomos del exterior. Debido a que múltiples paths generalmente existen dentro de un sistema autónomo para alcanzar las otros IBGP routers, una dirección de loopback es usualmente utilizada en el comando neighbor de BGP para establecer las sesiones de IBGP. Por ejemplo, cuando múltiples routers en un sistema autónomo están corriendo BGP, intercambian actualizaciones de enrutamiento BGP el uno con el otro. En la figura 1, los routers A, C, y D aprenden las trayectorias a los sistemas autónomos externos de sus vecinos respectivos de EBGP (routers Z, Y, y X).

Figura 1 – BGP Externo

Figura 1 – BGP Interno

Page 53: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 13 CCNP: Building Scalable Internetworks

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

6.2.4 Sincronización dentro de un sistema autónomo El BGP fue pensado originalmente para funcionar a lo largo de los bordes un sistema autónomo con los routers en el medio del sistema autónomo ignorando los detalles de BGP (por ello el nombre Border Gateway Protocol). Un sistema autónomo de tránsito, tal como el de la figura 1, es un sistema autónomo que enruta tráfico de un sistema autónomo externo a otro sistema autónomo externo. Típicamente, los sistemas autónomos de tránsito son los ISPs. Todas los routers en un sistema autónomo de transito deben tener un completo conocimiento de las rutas externas. Teóricamente, una manera para alcanzar esta meta es redistribuir las rutas del BGP dentro de un IGP en los routers de borde. Sin embargo, hay problemas asociados a este método. Puesto que la tabla de enrutamiento actual del Internet es muy grande, redistribuir todas las rutas del BGP en un IGP no es un método escalable para los routers interiores dentro de un sistema autónomo para aprender sobre las redes externas. Otro método que tú puedes utilizar es correr IBGP dentro del sistema autónomo Por definición, el comportamiento por defecto de BGP requiere que este debe ser sincronizado con el IGP antes de que el BGP pueda anunciar las rutas de tránsito a los sistemas autónomos externos. La regla de sincronización de BGP indica que un router BGP no debe anunciar destinos a vecinos externos, aprendidas de IBGP neighbors, a menos que estos destinos también se sepan vía un IGP. Si un router sabe sobre estos destinos vía un IGP, este asume que la ruta se ha propagado ya dentro del Autónomos Sistema, y la confiabilidad interna es asegurada.

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

Figura 1 – IBGP en transito en AS (ISP)

Page 54: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 14 CCNP: Building Scalable Internetworks

El comando neighbor habilita las actualizaciones de BGP entre BGP speakears. Por defecto, cada BGP speakear es asumido que tiene una declaración vecina para el resto de los IBGP speakers en el Autónomos Sistema, que se conoce como acoplamiento completo IBGP (full mesh IBGP). Los routers no tienen que estar directamente para estar en full mesh. Si el sending IBGP neighbor no está en full mesh con cada IBGP router, los router que no son peering con este router tienen diferentes tablas de enrutamiento de los routers que sin son peering con este. Las inconsistentes tablas de enrutamiento pueden causar lazos de enrutamiento o un agujero negro de enrutamiento (routing black hole), ya que la suposición por defecto de todos los routers que corren BGP dentro de un sistema autónomo es que cada router BGP está intercambiando información IBGP directamente con todos los otros routers BGP en el Autónomos Sistema. Si todos los IBGP neighbors están fulmente mallados (fully mesh), cuando un cambio es recibido de un sistema autónomo externo, el BGP router para el sistema autónomo local es responsable de informar a los otros IBGP neighbors de el cambio. Los IBGP neighbors que reciben esta actualización no la envían a cualquier otro IBGP neighbor, porque asumen que el sending IBGP neighbor esta fulgente mallado con el resto de los IBGP speakers y han enviado a cada IBGP neighbor la actualización. Example: IBGP Parcial Mesh La Figura 1 muestra la conducta de una actualización IBGP en un ambiente vecino parcialmente mallado Si todos los vecinos de IBGP están endentados completamente, cuando un cambio se recibe de un Autónomos Sistema externo, la rebajadora del BGP para el Autónomos Sistema local es responsable de informar a el resto de los vecinos de IBGP el cambio. Los vecinos de IBGP que reciben esta actualización no la envían a cualquier otro vecino de IBGP, porque asumen que el vecino de IBGP que envía está endentado completamente con el resto de los altavoces de IBGP y han enviado cada vecino de IBGP la actualización. El router B recibe una actualización BGP del router A. El router B tiene dos IBGP neighbors, el router C y el router D, pero no tiene una relación vecina IBGP con el router E. El router C y el D aprenden acerca de las redes que son añadidas o borradas detrás del router B. Aun si el router el router C y D tienen sesiones vecinas IBGP con el router E, asumen que el sistema autónomo está fulmente mallado por IBGP y no repliegan la actualización y no la envían al router E. Enviar una actualización IBGP al router E es la responsabilidad del router B, porque es el router con conocimiento de primera mano de las redes dentro y detrás del AS 65101. El router E no aprende ninguna red a través del router B y no utiliza el router B para alcanzar ninguna red dentro del AS 65101 u otros sistemas autónomos detrás del AS 65101. Example: IBGP Full Mesh La figura 2 muestra un fully mesh IBGP. Cuando el router B recibe una actualización del router A, este actualiza a todos sus tres IBGP peers: routers C, D, y E. El IGP enjuta el segmento del TCP que contiene la actualización BGP del router A al router E ya que los routers no están directamente conectados. La actualización se envía una vez a cada neighbor y no es duplicada por ningún otro neighbor de IBGP, lo cual reduce el tráfico innecesario.

Figura 2 – Parcial mesh IBGP

Figura 2 – Full mesh IBGP

Page 55: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 15 CCNP: Building Scalable Internetworks

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

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

Figura 1 – Problemas de enrutamiento con BGP

Page 56: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 16 CCNP: Building Scalable Internetworks

6.3 Configurando BGP

6.3.1 Configuración Básica de BGP La sintaxis de los comandos básicos de la configuración BGP es similar a la sintaxis para configurar protocolos de enrutamiento interno. Sin embargo, hay diferencias significativa en cómo funciona BGP. Use el comando: router bgp autonomous-system para identificar e la router de identificar al router de cualquier subsecuente subcomando perteneciente a este proceso de enrutamiento. Figura 1. Este comando también identifica el sistema autónomo local en el cual este router pertenece. El router necesita ser informado del sistema autónomo de modo que pueda determinarse si los BGP neighbors a ser configurados después son IBGP neighbors o EBGP La figura 2 muestra el parámetro para el comando router bgp El comando router bgp solo no activa BGP en un router. Se debe al menos ingresar un subcomando para activar el proceso BGP

6.3.2 Activar una sesión BGP Use el comando neighbor ip-address remote-as autonomous-system para activar una sesión BGP para neighbors routers externos e internos. Figura 1. Este comando identifica un peer router con el cual el router local establezca una sesión. La figura 2 muestra los parámetros para este comando. Nota: Un peer group es un grupo de BGP neighbors en el cual todos tienen las mismas políticas de actualización. Peers groups son descritos mas adelante en esta lección La dirección es la dirección destino para todos los paquetes BGP que van a este neighbor router. La dirección debe ser accesible, ya que el BGP procura establecer una sesión TCP e intercambiar actualizaciones BGP con los dispositivos en esta dirección IP. El número del sistema autónomo identifica si este neighbor es un EBGP neighbor o IBGP. Si el número es igual que el número del sistema autónomo para este router, el vecino es un IBGP neighbor, y la dirección IP enlistada en el comando neighbor no tiene que estar directamente conectada. Si el número es diferente, el vecino es un EBGP, y la dirección en el comando neighbor debe estar conectada directamente por defecto En la figura 3, el router A en el AS 65101 tiene dos declaraciones vecinas. El router A sabe que el router C (neighbor 192.168.1.1 remote-as 65102) es un neighbor externo, ya que el AS 65102 en la declaración vecina

Figura 1 – Comandos BGP

Figura 2 – Parámetro del comando router bgp

Figura 1 – Comando BGP neighbor remote-as

Figura 2 – Parámetros del comando neighbor remote-as

Page 57: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 17 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. El Neighbor 10.2.2.2 (router B) está en el mismo sistema autónomo que el router A. La segunda declaración vecina sobre el router A define al router B como IBGP neighbor. El AS 65101 corre EIGRP entre todos los routers internos. El router A tiene una trayectoria EIGRP para alcanzar la dirección IP 10.2.2.2. Como un IBGP neighbor, el router B puede estar múltiples routers lejos del router A.

6.3.3 Shutting Down a un BGP neighbor Use el comando neighbor ip-address shutdown para administrativamente bajar y rehabilitar un BGP neighbor Figura 1 Si tú llevas a cabo cambiar mayores políticas a un router vecino y cambias múltiples parámetros, tú debes administrativamente bajar el router vecino, y después traer de regreso el router vecino con el comando l respaldo vecino de la router con el comando no neighbor ip-address shutdown

6.3.4 Consideraciones de configuración de BGP La declaración vecina de BGP informa al router de la dirección IP destino para cada paquete de actualización. El router debe decidir cual dirección IP usar como dirección ip origen en la actualización de enrutamiento BGP. Figura 1 Cuando un router crea un paquete BGP para un vecino, este comprueba la tabla de enrutamiento para la red destino para alcanzar a ese neighbor. La dirección IP es de la interfaz de salida, como la tabla de enrutamiento indica, se utiliza como dirección IP origen del paquete BGP. Esta dirección Ip origen debe emparejar la dirección en la correspondiente declaración vecina en el otro router. Si no, los routers no serán BGP peers ya que no pueden establecer una sesión BGP.

Figura 3 – Ejemplo: Comando BGP neighbor

Figura 1 – Comando BGP neighbor shutdown

Figura 1 – Problemas BGP con dirección IP origen

Page 58: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 18 CCNP: Building Scalable Internetworks

6.3.5 IBGP Peering Issue Para establecer la sesión IBGP entre el router A y D, como se muestra en la figura 1, ¿cual dirección ip vecina debería ser usada? El problema es el siguiente. Si el router D utiliza neighbor 10.3.3.1 remote-as 65102 , pero el router A esta enviando paquetes BGP para el router D a través del router B, la dirección IP origen es la 10.1.1.1. Cuando el router D recibe este paquete a través del router B, este no reconoce este paquete BGP ya que la 10.1.1.1 no fue configurada como un neighbor del router D. Por consiguiente la sesión IBGP entre el router A y el D no puede ser establecida Una solución es establecer una sesión IBGP usando un interfaz de loopback cuando hay trayectorias múltiples entre los IBGP neighbors.

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

Figura 1 – Ejemplo: BGP peering issue

Figura 1 – Comando BGP neighbor update-source

Page 59: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 19 CCNP: Building Scalable Internetworks

Si el router mira con fijeza (peers) con la interfaz de loopback en vez de otro router, la interfaz de loopback esta siempre disponible mientras el router no falle. Este arreglo de peering agrega viveza a las sesiones IBGP ya que los routers no se atan en una interfaz física, la cual puede caerse por un sin numero de razones. Para mirar con fijeza con el loopback de otro vecino interno, el primer router señala la declaración vecina en la dirección de loopback del otro vecino interno. Asegúrese de que ambos routers tengan una ruta a la dirección de loopback del otro vecino en su tabla de enrutamiento. También asegúrese de que ambos routers estén anunciando sus direcciones de loopback en su protocolo de enrutamiento local. Ejemplo: Utilizando una dirección de loopback con e l BGP En la figura 2. El router B tiene al router A como EBGP neighbor. La única dirección accesible para el router B a utilizar para una dirección vecina en BGP es la dirección directamente conectada 172.16.1.1. El router B tiene trayectorias múltiples para alcanzar la router C, IBGP neighbor Todas las redes, incluyendo la red IP para la interfaz de loopback del router C, pueden ser alcanzadas del router B. El router B puede alcanzar estas redes porque los routers B y C intercambian actualizaciones de EIGRP; los routers B y A no intercambian actualizaciones de EIGRP. La relación vecina entre los routers B y C no se ata a un interfaz físico porque el router B mira con fijeza (peers)con la interfaz de loopback en el router C y utiliza su dirección de loopback como la dirección IP origen, y viceversa. Si el router B hacia peer con la 10.1.1.2 en el router C y esta interfase se cayera, la relación vecina de BGP también se caería. El comando neighbor update-source se debe utilizar en ambos routers. Si el router B apunta a la dirección de loopback 3.3.3.3 del router C, y el router C apunta a la dirección de loopback 2.2.2.2 del router B, y ninguna utiliza el comando neighbor update-source , la sesión BGP entre estos routers no comienza. El router B enviaría un paquete abierto BGP al router C con la dirección origen siendo la 10.1.1.1 o la 10.2.2.1. El router C revisaría la dirección origen y procuraría emparejarlo contra su lista de neighbors conocidos. El router C no encontraría un emparejamiento y no respondería al mensaje abierto (open message) del router B.

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

Figura 2 – Ejemplo: Usando direcciones loopback en BGP

Figura 1 – Comando BGP neighbor ebgp-multihop

Page 60: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 20 CCNP: Building Scalable Internetworks

Si una interfaz de loopback se utiliza en vez del interfaz directamente conectado, se requiere la configuración adicional. Para permitir que el router acepte y ensaye conexiones BGP a pares (peers) externos que residen en las redes que no están directamente conectadas, tu debes configurar el comando de configuración en el router neighbor ip-address ebgp-multihop [ttl]. La Figura 1 y la figura 2 muestran los parámetros de este comando Los EBGP peers están usualmente solamente a un salto lejos el uno del otro. El comando neighbor ebgp-multihop incremente el valor de salto por defecto para permitir rutas a la dirección de loopback EBGP con un valor de TTL mas grande que 1. Si un valor TTL no es especificado, el router utiliza 255 (por defecto). Este comando es necesario cuando existen trayectorias redundantes entre EBGP neighbors. Ejemplo: Comando ebgp-multihop En la figura 3, el router A en el AS 65102 tiene dos trayectorias al router B en el AS 65101. Si el router A utiliza una sola declaración vecina y apunta a la 192.168.1.18 en el router B del AS 65101 y ese link se cae, no hay sesión BGP entre estos sistemas autónomos. Consecuentemente, ningún paquete pasa de un sistema autónomo al siguiente, aun cuando el otro link existe. Si el router A en lugar utiliza dos declaraciones vecinas que apuntan a la 192.168.1.18 y a la 192.168.1.34 en el router B, se soluciona parcialmente el problema. Sin embargo, cada actualización BGP que el router A reciba es enviada al router B doblemente ya que hay dos declaraciones vecinas. Como se muestra en la figura, el router e la figura, el router A mas bien apunta a la dirección de loopback del router B y viceversa, y cada router usa esta dirección de loopback como la dirección IP de origen para esta actualizaciones BGP. Debido a que IGP no es utilizado entre los sistemas autónomos, ningún router puede alcanzar el loopback del otro router sin asistencia. Cada router necesita utilizar dos rutas estáticas para informar al BGP de las trayectorias disponibles para alcanzar la dirección de loopback del otra router. Una dirección vecina de EBGP debe estar directamente conectada por defecto. El comando neighbor ebgp-multihop se debe utilizar para cambiar el ajuste por defecto de BGP y para informar al BGP que esta dirección IP esta a mas de un salto lejos. En la figura, el comando utilizado en el router A informa a BGP que dirección vecina de 1.1.1.1 esta a dos saltos lejos. Nota: BGP no esta diseñado para realizar balanceo de carga. Las trayectorias se eligen debido a la política, no se basan en el ancho de banda. BGP elige solamente una sola mejor trayectoria. Usar las direcciones de loopback y el comando neighbor ebgp-multihop como se muestra en este ejemplo permite balanceo de carga y redundancia a través de las dos trayectorias entre los sistemas autónomos.

6.3.8 Comportamiento del Next Hop La manera en la cual el BGP establece una relación de IBGP es muy diferente a la manera que los IGPs se comportan. El método que BGP utiliza que denota su dirección del next hop es también muy diferente. BGP informa al siguiente sistema autónomo sobre las trayectorias a otros sistemas autónomos y las redes que esos otros sistemas autónomos poseen. BGP, como IGPs, es un protocolo de enrutamiento del salto-por-salto. Sin embargo, diferente de IGPs, BGP rutea de sistema autónomo a sistema autónomo, y el next hop por

Figura 2 – Parámetros del comando neighbor ebgp-multihop

Figura 3 – Ejemplo: Comando ebgp-multihop

Page 61: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 21 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. Para IBGP, el protocolo BGP afirma que el next hop anunciado por EBGP debería ser llevado dentro del IBGP Ejemplo: Comportamiento de Next-Hop En la figura 2, el router A anuncia la red 172.16.0.0 al router B con un next hop de 10.10.10.3. El Router B anuncia la red 172.20.0.0 al router A con un next hop de 10.10.10.1. Para IBGP, el estado del protocolo BGP indica que el next hop anunciado por EBGP debe ser llevado dentro del IBGP. Debido a esta regla, el router B anuncia la 172.16.0.0 a su IBGP peer router C con un next hop de 10.10.10.3, la dirección del router A. El router C sabe que el next hop para alcanzar la 172.16.0.0 es la 10.10.10.3, y no la 172.20.10.1, como puede ser esperado. Por lo tanto, es muy importante que el router C sepa alcanzar la subred 10.10.10.0, a través de un IGP o de una ruta estática. Si no, el router C elimina los paquetes destinados para la red 172.16.0.0 porque no puede conseguir a la dirección del next hop para esa red. Un router IBGP neighbor realiza operaciones de búsqueda recurrentes para descubrir cómo alcanzar una dirección del next hop del BGP usando sus entradas de IGP en la tabla de enrutamiento. Por ejemplo, el router C aprende en una actualización de BGP sobre la red 172.16.0.0/16 de una ruta de origen de 172.20.10.1 (router B), con un next hop de 10.10.10.3 (router A). El router C instala la ruta a la 172.16.0.0/16 en la tabla de enrutamiento con un next hop de 10.10.10.3. El router B debe anunciar la red 10.10.10.0/24 usando su IGP para el router C de modo que el router C pueda instalar esa ruta en su tabla de enrutamiento con un next hop de 172.20.10.1. Un IGP utiliza la dirección IP de origen de una actualización de enrutamiento (ruta origen) como la dirección del next hop, mientras que BGP utiliza un campo separado por red para registrar la dirección del next hop. Si el router C tiene un paquete para enviar a la 172.16.100.1, este busca la red en la tabla de enrutamiento y encuentra una ruta BGP con un next hop de 10.10.10.3. Ya que este es una entrada BGP, el router C termina una recurrente búsqueda en la tabla de enrutamiento para una trayectoria a la red 10.10.10.3. El IGP ha colocado una ruta a la red 10.10.10.0 en la tabla de enrutamiento con un next hop (next hop) de 172.20.10.1, así que el router C remite el paquete destinado para la 172.16.100.1 a la 172.20.10.1.

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

Figura 1 – Comportamiento del Next-hop

Figura 2 – Ejemplo: Comportamiento del Next-hop

Page 62: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 22 CCNP: Building Scalable Internetworks

El comando neighbor next-hop-self fuerza al BGP a utilizar su propia dirección IP como la dirección del next hop para cada red que anuncie a su IBGP neighbor, en vez de dejar que el protocolo elija la dirección del next hop. Figura 1. A veces esto es necesario para pasar por encima del funcionamiento por defecto del next hop en el router y forzar a que este se anuncie a si mismo como dirección de next hop para las rutas enviadas a un router vecino. Un protocolo interno, tal como RIP, EIGRP, u OSPF, utiliza siempre la dirección de la actualización de enrutamiento como su dirección de next hop para cada red que se ponga en la tabla de enrutamiento. El comando neighbor next-hop-self hace que BGP utilice la dirección IP origen como dirección del next hop para cada red anunciada. La figura 2 exhibe los parámetros del comando. Ejemplo: Configuración de next-hop-self En la figura 3, el router B ve la ruta 192.168.1.0 aprendida del AS 65100 que tiene un next hop de 172.16.1.1, el cual es la entrada al AS 65100 para el router B. Cuando el router B anuncia esa red a sus IBGP neighbors en el AS 65101, el ajuste por defecto de BGP es anunciar que el next hop para alcanzar esta red es la entrada al AS a 65100 (172.16.1.1). Esto trabaja de esta manera por defecto porque el BGP es un protocolo de enrutamiento AS –by –AS Para que cualquier router BGP alcance redes en el o detrás del AS 65100, estos routers necesitan alcanzar la red 172.16.1.1. Por lo tanto, usted necesita incluir la red que representa 172.16.1.1 en el protocolo interno de enrutamiento. En este ejemplo, sin embargo, el router B utiliza el comando neighbor next-hop-self para cambiar los ajustes de BGP por defecto. Una vez que se dé este comando, el router B anuncia un next hop de 2.2.2.2 (la dirección IP de la interfaz del loopback) a su IBGP neighbor, ya que este es la dirección ip origen de la actualización de enrutamiento a su IBGP neighbor (fijar con el comando neighbor update-source ). Cuando el router C anuncia las redes que están en el o detrás del AS 65101 a los EBGP neighbors, tales como el router D en el AS 65102, el router C, por defecto, utiliza su dirección de interfaz de salida

Figura 1 – Comando BGP neighbor next-hop-self

Figura 2 – Parámetros del comando neighbor next-hop-self

Figura 3 – Ejemplo: Configuración next-hop self

Figura 4 – Ejemplo: next hop en una red multiacceso

Page 63: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 23 CCNP: Building Scalable Internetworks

192.168.1.2 como la dirección del next hop. Esta dirección es también la dirección por defecto del next hop para el router D para alcanzar cualquier red en el o detrás del AS 65101. Al funcionar BGP sobre una red multi acceso tal como Ethernet, un router BGP ajusta la dirección de next hop (next-hop) para evitar insertar saltos adicionales en la red. Esta característica a veces se llama un next hop de tercera persona (third-party next hop) Ejemplo: Next Hop en una red multiacceso Según lo muestra la figura 4, los routers B y C en el AS 65000 están corriendo IGP de modo que el router B pueda alcanzar la red 172.30.0.0 vía 10.10.10.2. El router B también corre EBGP con el router A. Cuando el router B envía una actualización BGP al router A con respecto a la 172. 30.0.0, utiliza la red 10.10.10.2 como next hop y no su propia dirección IP (10.10.10.1). Ya que la red entre los tres routers es una red multiacceso, el router A utiliza al router C como un next hop para alcanzar a la 172.30.0.0, en vez de que haga un salto adicional vía la router B. La dirección del next hop tiene más sentido cuando tú revisas esta desde la perspectiva de un ISP. Un ISP grande en un punto de peering publico que tiene múltiples routers en peering con diversos neighbors routers. No es posible que un router mire con fijeza a cada router vecino en los puntos de peering públicos importantes. Por ejemplo, en la figura, el router B puede mirar con fijeza al AS 64520, y el router C puede mirar con fijeza con el AS 64600. El router A debe tener una trayectoria a través del AS 65000 para conseguir a las redes en el y detrás del AS 64600. El router A tiene una relación vecina solamente con el router B en el del AS 65000. Sin embargo, el router B no maneja el tráfico que va al AS 64600. La trayectoria preferida del router B para el AS 64600 está a través del router C, 10.10.10.2. El router B debe anunciar las redes para el AS 64600 para el router A, 10 10.10.3. El router B notifica que los routers A y C están en la misma subred, así que el router B informa al router A para que instale las redes del AS 64600 con un next hop de 10.10.10.2 y no 10.10.10.1.

6.3.10 Inyección de Información de enrutamiento den tro de BGP Utilice el comando network network-number para permitir que BGP anuncie una red si esta presente en la tabla de enrutamiento. La figura 1 y 2 muestra los parámetros de este comando. El comando network determina las redes que el router origina. Este concepto es diferente de usar el comando network cuando tu estás configurando un IGP. Diferente a un IGP, el comando network no arranca el BGP en interfaces específicos. En lugar indica al BGP que redes debería originar este router. El parámetro de la máscara indica que BGP4 puede dirigir subnetting y supernetting. La lista del comando network debe incluir todas las redes en su sistema autónomo que usted desee anunciar, y no solo las redes que están localmente conectadas en el router Antes de Cisco IOS Software Release 12.0, había un límite de 200 comandos de red por el router BGP. Se ha quitado este límite. Los recursos del router, tales como la NVRAM o la RAM, determinan el número máximo de redes en el comando que tú puedes utilizar. El comando neighbor dice a BGP donde anunciar, y el comando network dice a BGP que anunciar

Figura 1 – Comando BGP network

Figura 2 – Parámetros del comando network

Page 64: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 24 CCNP: Building Scalable Internetworks

6.3.11 Ejemplo del comando network de BGP El propósito único del comando network es notificar al BGP qué red anunciar. Sin la opción de la máscara, este comando anuncia solamente el número de red de clase completa. Por lo menos una subred de la red principal especificada debe estar presente en la tabla de enrutamiento IP para permitir que el BGP comience a anunciar la red de clase completa como ruta BGP. Cuando tú especificas la opción network-mask, un match exacto a la red (dirección y máscara) debe existir en la tabla de enrutamiento antes de que BGP anuncie las rutas. El BGP comprueba si pueda alcanzarlo antes de que comience a anunciar la red como ruta del BGP. Los siguientes son dos ejemplos de cómo el comando network-mask puede ser mal configurado En la figura 1, el comando network 192.168.1.1 mask 255.255.255.0 hace que BGP cheque para la especifica ruta 192.168.1.1/24 en la tabla de enrutamiento. Este puede encontrar la 192.168.1.0/24 o la 192.168.1.1/32. Sin embargo, si este nunca encuentra un match especifico para la red 192.168.1.1/24, BGP no anuncia la red 192.168.1.1/24 a ningún vecino En la figura 2, el comando network 192.168.0.0 mask 255.255.0.0 anuncia un bloque CIDR. Por lo tanto, BGP busca la 192.168.0.0/16 en la tabla de enrutamiento. Este puede encontrar la red 192.168.1.0/24 o la 192.168.1.1/32. Si BGP nunca encuentra la 192.168.0.0/16, este no anuncia la red 192.168.0.0/16 a ningún vecino. En este caso, usted puede configurar la siguiente ruta estática hacia el interfaz nulo, así que el BGP puede encontrar un match exacto en la tabla de enrutamiento: ip route 198.168.0.0 255.255.0.0 null0 Después de encontrar un match exacto en la tabla de enrutamiento, BGP anuncia la red 192.168.0.0/16 a cualquier vecino. Nota: El comando de configuración BGP del router auto-summary determina cómo BGP maneja la predistribución de las rutas. Cuando BGP summarization es habilitado (con auto-summary) , todos las subredes redistribuidas son sumarizadas a su limites de classful en la tabla del BGP. Cuando este es deshabilitado (con no auto-summary ), todas las subredes redistribuidas están presentes en su forma original en la tabla de BGP, así que únicamente las subredes son anunciadas. En Cisco IOS Software Release 12.2(8)T, por defecto al comando auto-summary fu cambiado a deshabilitado. Antes de este por defecto era habilitado (auto-summary ).

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

Figura 1 – Ejemplo: Comando BGP network

Figura 2 – Ejemplo: Comando BGP network (cont.)

Page 65: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 25 CCNP: Building Scalable Internetworks

La sincronización del BGP es inhabilitada por defecto en el Cisco IOS Software Release 12.2(8)T y más adelante. Era encendido por defecto en revisiones anteriores del Cisco IOS Cuando la sincronización esta deshabilitada, el BGP puede utilizar y anunciar las rutas aprendidas de un IBGP neighbor que no están presentes en la tabla de enrutamiento local a un vecino externo del BGP. La sincronización del BGP es innecesaria en algunas situaciones. Por ejemplo, es seguro tener sincronización de BGP apagado si todas los routers en la trayectoria de tránsito en el sistema autónomo están corriendo IBGP en full mesh Tener la sincronización deshabilitada permite a los routers llevar pocas rutas en el IGP y permite que el BGP converja más rápidamente. Use sincronización si los routers en la trayectoria de tránsito de BGP en el sistema autónomo no están corriendo BGP (por lo tanto, los routers no están en full mesh IBGP dentro del sistema autónomo Nota: En el pasado, la mejor práctica era redistribuir el BGP en el IGP que funcionaba en un sistema autónomo de modo que IBGP no fuera necesitado en cada router en la trayectoria de tránsito. En este caso, la sincronización fue necesitada para cerciorarse de que los paquetes no se pierdan; por lo tanto, la sincronización era encendida por defecto. Mientras que el Internet creció, el número de rutas en la tabla del BGP llego a ser demasiado para que el IGPs dirija. La mejor práctica cambiante para no redistribuir el BGP en el IGP, en lugar de esto utilizar IBGP en todas las routers en la trayectoria de tránsito. En este caso, la sincronización no es necesaria, así que ahora está apagado por defecto.

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

Figura 1 – Sincronización BGP

Page 66: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 26 CCNP: Building Scalable Internetworks

El router E después tiene una ruta a la 172.16.0.0 y puede enviar el tráfico que es destinado para esa red. El router E envía los paquetes a el router A, y el router A los remite al router C. El router C aprende una ruta a la 172.16.0.0 vía IBGP; por lo tanto, el router C remite los paquetes al router D. El router D remite los paquetes al router B. El router B remite los paquetes al router F para la red 172.16.0.0. En sistemas autónomos modernos, ya que el tamaño de la tabla de enrutamiento del Internet es grande, la redistribución del BGP en un IGP no es escalable. Por lo tanto, la mayoría de los sistemas autónomos modernos corren IBGP en full mesh y no requieren la sincronización. Los métodos avanzados de configuración del BGP, por ejemplo, con los reflectores y las confederaciones de la ruta, reducen los requisitos para un full mesh.

6.3.14 Ejemplo de configuración de BGP La figura 1 muestra un ejemplo de BGP. La figura 2 muestra la configuración para el router B. El primero de los dos comandos debajo del comando router bgp 65000 establece que el router B tiene los siguientes dos BGP neighbors

• Router A in AS 64520 • Router C in AS 65000

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

Figura 1 – Ejemplo: Sincronización BGP

Figura 1 – Ejemplo: Configuración BGP

Page 67: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 27 CCNP: Building Scalable Internetworks

En la línea 5, el router B cambia la dirección del next–hop para las redes que son accesibles con ella. La configuración del next-hop o next hop por defecto para las redes del AS 64520 es la dirección IP 10.1.1.2. Con este comando next-hop-self , el router B fija la dirección del next hop a la dirección IP origen de la actualización de la enrutamiento, la cual es la interfaz de loopback 0 del router B, como lo fijo el comando update-source Las líneas 6 y 7 notifican al BGP sobre cuales redes anunciar. La línea 6 contiene una subred de dirección de clase B usando la opción mask . Las líneas 7 y 8 tienen dos declaraciones de red para las dos redes de clase C que conectan a los routers B y C. La máscara por defecto es 255.255.255.0, así que no necesitas incluir esto en el comando. En la línea 9, la sincronización es deshabilitada. Si el router A está anunciando la red 172.20.0.0 en BGP, el router B recibe esa ruta y la anuncia al router C. Puesto que la sincronización está apagada, el router C puede utilizar esta ruta. Si el router C tuviera sus propios EBGP neighbors y el router B deseara utilizar el router C como la trayectoria a esas redes, la sincronización en el router B también necesitaría estar apagada. En esta red, la sincronización puede estar apagada porque todas las routers dentro del sistema autónomo están corriendo IBGP.

6.4 Configuración y verificación avanzada de BGP

6.4.1 Estados de BGP neighbors El proceso de negociación de BGP neighbors procede a través de varios estados. Figura 1. Estos pasos se pueden describir en términos de una máquina de estado finito (FSM finite-state machine). Un FSM es un sistema de estados posibles que pueden ir a través, qué causan acontecimientos a esos estados, y qué acontecimientos resultan de esos estados. La figura 2 presenta el BGP FSM, que incluye los estados y algunos de los acontecimientos de los eventos del mensaje que los causan Después de que hayas incorporado el comando neighbor , el BGP toma la dirección IP que esta enumerada y chequea la tabla de enrutamiento local para saber si hay una ruta a esta dirección. A este punto, el BGP está en el estado IDLE. Si el BGP no encuentra una ruta a la dirección IP, permanece en el estado IDLE. Si encuentra una ruta, entra al estado connect cuando el paquete TCP handshaking synchronize acknowledge (SYN ACK) retorna. Después de que la conexión del TCP haya finalizado, el BGP crea un paquete abierto BGP y lo envía al vecino. Una vez de que

Figura 2 – Ejemplo de configuración BGP

Figura 1 – Estados BGP

Figura 2 – Estados FSM BGP

Page 68: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 28 CCNP: Building Scalable Internetworks

BGP envíe este paquete abierto, la sesión peering de BGP cambia al estado de enviado abierto (open sent). Si no hay respuesta por 5 segundos, el estado cambia al estado activo. Si una respuesta se vuelve de una manera oportuna, el BGP va al estado confirmado abierto y arranca el escaneo (evaluación) de la tabla de enrutamiento para que las trayectorias envíen al vecino. Cuando se encuentran esas trayectorias, el BGP va al estado establecido y comienza el enrutamiento entre los neighbors. Tu puedes utilizar el comando debug para observar los estados que dos routers BGP van durante el establecimiento de la sesión. Figura 3. En el Cisco IOS Software Release 12.4, tu usas el comando debug ip bgp ipv4 unicast . En lanzamientos anteriores del IOS de Cisco, el comando debug ip bgp events da una similar salida. Nota: Debugging consume recursos del router y debería ser encendido únicamente cuando es necesario

6.4.2 Estados Established e Idle de BGP Es estado idle indica que el router no sabe como alcanzar la dirección IP que esta enlistada en la declaración vecina Figura 1 El router puede estar en idle dado uno de 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 red a través de un anuncio de otro router.

La mas común razón para que un router entre al estado de idle es que el vecino no esta anunciando la dirección IP o la red que la declaración vecina del router esta apuntando. Queque estas dos condiciones primero para corregir este problema:

• Asegúrese que el vecino anuncie la ruta en su protocolo de enrutamiento local.

• Verifique que tu no hayas entrado una dirección IP incorrecta en la declaración vecina

El estado establecido es un estado deseado por las relaciones de neighbors. Figura 2.

Figura 3 – Ejemplo: establecimiento de sesión BGP

Figura 1 – Estado idle BGP

Figura 2 – Estado establecido BGP

Figura 3 – Ejemplo: Comando show ip bgp neighbors

Page 69: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 29 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

6.4.3 Verificación de problemas de BGP en estado Ac tivo Si el router está en el estado activo, ha encontrado la dirección IP en la declaración vecina y ha creado y ha enviado un paquete abierto de BGP. Sin embargo, el router no ha recibido una respuesta (paquete de confirmación abierto). Figura 1 Un problema común en este caso es que el neighbor puede no tener una ruta de regreso a la dirección IP origen. Asegúrese de que la dirección IP origen o red de los paquetes se haya anunciado al protocolo de enrutamiento local (IGP). Otro problema común asociado al estado activo ocurre cuando un router BGP procura mirar con fijeza (peers) con otro router BGP que no tenga una declaración vecina de peering detrás en el primer router, o cuando el otro router está mirando con fijeza con una dirección IP incorrecta en el primer router. Cheque para asegurarse de que el otra router tenga una declaración vecina de peering con la dirección correcta del router que está en estado activo. Si el estado tambalea entre el estado idle y el activo, uno de los problemas mas comunes es una desconfiguración del numero de sistema autónomo La figura 2 muestra el mensaje de consola generado en el router con el número remoto del sistema autónomo equivocado en la declaración vecina

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

Figura 1 – Estado activo BGP

Figura 2 – Ejemplo: Estado activo BGP

Page 70: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 30 CCNP: Building Scalable Internetworks

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

6.4.5 Configurando un ejemplo de Peer Group En la figura 1, el AS 65100 tiene cuatro routers corriendo IBGP. Todos estos IBGP neighbors son peering con cada otro utilizando la interfaz de loopback 0 de cada uno, y están utilizando la dirección IP de su interfaz de loopback 0 como la dirección IP origen para todos los paquetes BGP. Cada router está utilizando una de sus propias direcciones IP como la dirección del next hop para cada red anunciada a través de BGP. Éstas son políticas de salida Además, el router C tiene una lista de distribución de salida asociada a cada IBGP neighbor. Este filtro de salida realiza la misma función que el comando distribute-list que tú usas para los protocolos enrutamiento interno. Sin embargo, se liga a un vecino específico para usar con BGP. El ISP detrás del router C puede anunciar el espacio de direcciones privadas al router C. El router C no desea pasar estas redes a otros routers que corren BGP en el AS 65100. Para lograr esta meta, la Access list 20 debe tener acceso a la lista 20 verse de la siguiente manera: access-list 20 deny 10.0.0.0 0.255.255.255 access-list 20 deny 172.16.0.0 0.31.255.255 access-list 20 deny 192.168.0.0 0.0.255.255 access-list 20 permit any Note la configuración del router C cuando no está utilizando un peer group. Todos los IBGP neighbors tienen la lista de distribución de salida para ellos individualmente. Si el router C recibe un cambio del AS 65101, este debe generar una actualización individual para cada IBGP neighbor y correr cada actualización contra distribuir

Figura 1 – Usando un peer group

Figura 1 – Ejemplo: Usando un peer group

Page 71: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 31 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

6.4.6 BGP Peering El comando show ip bgp summary es una manera de verificar las relaciones de neighbors. La figura 1 presenta la salida de este comando, el cual contiene lo siguiente:

• BGP router ID : dirección IP que todos los otros BGP speakers reconocen como una representación de este router

• BGP table versión : Aumenta de incrementos cuando la tabla del BGP cambia.

• Main routing table versión : la última versión de la base de datos de BGP que fue inyectada en la tabla de enrutamiento principal.

• Neighbor : dirección IP que se utiliza en la declaración vecina con la cual este router tiene una relación.

• Versión (V) : Versión de BGP que este router está corriendo con el neighbor mencionado. • AS: numero del sistema autónomo del neighbor mencionado. • Messages received (MsgRcvd) : Número de los mensajes de BGP que se han recibido de este

neighbor. • Messages sent (MsgSent) : Numero de mensajes BGP enviados a este neighbor \ • Table version (TblVer) : Versión de la tabla de BGP. • In queue (InQ) : Número de los mensajes que esperan para ser procesados por este neighbor. • Out queue (OutQ) : Número de mensajes encolados que esperan para ser enviados para este neighbor. • Up/Down : Longitud de tiempo que este neighbor ha estado en el estado actual de BGP (established,

active, o idle).

Figura 1 – Ejemplo: BGP peering

Page 72: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 32 CCNP: Building Scalable Internetworks

• State (established, active, idle, open sent, open c onfirm, or idle [admin]) : estados de BGP. Tu puedes setear a un neighbor para que administrativamente este abajo (admin state) utilizando el comando shutdown en el neighbor

• Prefix received (PfxRcd) : Cuando la sesión está en el estado establecido, este valor representa el número de las entradas de red BGP recibidas del neighbor mencionado.

6.4.7 Configurando autenticación BGP Tú puedes configurar la autentificación vecina BGP en un router de modo que el router autentique la fuente de cada paquete de actualización de enrutamiento que recibe. Esto es logrado intercambiando una llave de autenticidad (designada a veces una contraseña) que es conocida por ambos router el que envía y el de recepción. El BGP soporta autentificación vecina MD5. MD5 envía un message digest (también llamado hash) que es creado usando la llave y un mensaje. El message digest entonces es enviado en lugar de la llave para evitar que la llave sea leída por un eavesdropper mientras que se está transmitiendo. Para habilitar autenticación MD5 en una conexión TCP entre dos BGP peers, use el comando de configuración de router neighbor {ip-address | peer-group-name} password string la figura 1 y 2 muestra los parámetros: Tu puedes configurar la autentificación MD5 entre dos BGP peers, dando a entender que cada segmento enviado en la conexión TCP entre los pares está verificado. La autentificación MD5 se debe configurar con la misma contraseña en ambos BGP peers; si no, la conexión entre ellos no es hecha. La autentificación de configuración MD5 hace que el software del IOS de Cisco genere y compruebe MD5 digest de cada segmento enviado en la conexión TCP. Precaución: Si la secuencia de autentificación se configura incorrectamente, la sesión del BGP peering no se establece. Se recomienda que ingreses una secuencia de autentificación cuidadosamente y verifiques que la sesión peering este establecida después de que se configure la autentificación. Si tu especificas un BGP peer group usando el argumento peer-group-name, todos los miembros del peer group heredan la característica configurada con este comando. Si un router tiene una contraseña configurada para un neighbor pero el router vecino no, un mensaje tal como el siguiente aparece en la consola cuando los routers procuran enviar mensajes BGP entre sí mismos %TCP-6-BADAUTH: No MD5 digest from 10.1.0.2(179) to 10.1.0.1(20236) Similarmente, si dos routers tienen diferentes contraseñas configuradas, un mensaje tal como el siguiente aparece en la pantalla %TCP-6-BADAUTH: Invalid MD5 digest from 10.1.0.1(12293) to 10.1.0.2(179)

Figura 1 – Autenticación de vecino BGP

Figura 2 – Parámetros del comando neighbor

Page 73: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 33 CCNP: Building Scalable Internetworks

Si configuras o cambias la contraseña o la llave usada para la autentificación MD5 entre dos pares del BGP, el router local no rasga abajo la sesión existente después de que configures la contraseña. El router local procura mantener la sesión que mira con fijeza usando la nueva contraseña hasta que expira el contador de tiempo del asentamiento del BGP. El período de defecto es 180 segundos. Si la contraseña no se incorpora ni se cambia en el router alejada antes de que expire el contador de tiempo, los tiempos de la sesión hacia fuera. Nota: Si cambias el valor del mantenimiento, toma efecto solamente después que se ha reajustado la sesión. No puedes cambiar el contador de tiempo del asentamiento para evitar de reajustar la sesión del BGP. El ejemplo en la figura 3 autentificación de configures MD5 para la sesión que mira con fijeza del BGP entre las routers A y B. La misma contraseña se debe configurar en el par alejado antes de que expire el contador de tiempo del mantenimiento

6.4.8 Troubleshooting BGP Utilizar el comando show ip bgp muestra la base de datos de la topología del BGP (tabla del BGP). La figura 1 muestra una salida parcial de la muestra del comando del BGP del IP de la demostración. Los códigos de estado se demuestran al principio de cada línea de la salida, y los códigos de origen se demuestran en el extremo de cada línea En esta salida, hay un asterisco (*) en la mayor parte de las entradas en la primera columna. Esto significa que la dirección del next hop (en la quinta columna) es válida. La dirección del next hop no es siempre el router que está conectado directamente con este router. Otras opciones para la primera columna son las siguientes:

• s: Se suprimen las rutas especificadas (generalmente porque se han resumido las rutas y solamente se está enviando la ruta sumaria).

• d: La ruta se está desalentando (penalizado) ya que la ruta sube y baja demasiado a menudo. Aunque la ruta pudo estar arriba ahora, no se anuncia hasta que ha expirado la penalización.

• h: La ruta es inasequible y está probablemente abajo. La información histórica sobre la ruta existe, pero una mejor ruta no existe.

• r: La ruta no fue instalada en la base de información de enrutamiento (RIB). La razón que la ruta no está instalada se puede mostrar usando el comando show ip bgp rib-failure

• S: La ruta esta averiada o añeja (este símbolo es usado en el nonstop forwarding-aware router). La segunda columna muestra “>” cuando BGP ha seleccionado la trayectoria como la mejor trayectoria a una red.

Figura 3 – Ejemplo: Autenticación de vecino BGP

Figura 1 – Ejemplo: Comando show ip bgp

Page 74: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 34 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 cuarta columna enumera las redes que el router aprendió. La columna next hop enumera todas las direcciones del next hop para cada ruta. Esta columna puede contener la entrada 0.0.0.0, que significa que este router es el autor de la ruta. Las tres columnas a la izquierda de la columna Path lista tres atributos de trayectoria BGP que se asocian a la trayectoria: metric (multi-exit discriminator [MED]), local preference, y weight. La columna con la cabecera de Path puede contener una secuencia de sistemas autónomos en la trayectoria. De izquierda a derecha, el primer sistema autónomo enumerado es el sistema autónomo adyacente que esta red ha aprendido. El último número (el número de sistema autónomo de la derecha) es el sistema autónomo que origina esta red. Los números de sistema autónomo entre estos dos representan la trayectoria exacta que un paquete toma de regreso al sistema autónomo originado. Si la columna de la trayectoria está en blanco, la ruta es el sistema autónomo actual. La última columna significa que esta ruta fue entrada dentro de BGP en el router original. Si la ultima columna contiene una “i”, el router que origen probablemente utilizo una declaración de la red para introducir esta red en BGP. Si el carácter es una “e,” el router que originaba aprendió esta red del EGP, que es el precursor histórico de BGP. Un signo de interrogación (?) significa que el BGP no puede verificar absolutamente la disponibilidad de esta red porque se redistribuye de un IGP dentro del BGP. Utilizar el comando show ip bgp rib-failure muestra las rutas BGP que no fueron instaladas en la RIB y la razón por la cual no fueron instaladas El ejemplo en la figura 2 muestra que las rutas exhibidas no fueron instaladas porque una ruta o las rutas con una distancia administrativa mejor ya existen en la RIB

6.4.9 Clearing la sesión BGP BGP puede potencialmente manejar volúmenes enormes de información de enrutamiento. Cuando ocurre un cambio de configuración de la política, el router no puede pasar a través de la tabla enorme de información de BGP y recalcular qué entrada no es más válida en la tabla local. Ni puede el router determinar cuál ruta debe ser retirada de un neighbor. Figura 1 Hay un riesgo obvio que el primer cambio 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.

Figura 2 – Ejemplo: Comando show ip bgp rib-failure

Figura 1 – Limpiando la sesión BGP

Page 75: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 35 CCNP: Building Scalable Internetworks

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

6.4.10 Hard Reset de sesiones BGP El reajuste de una sesión es un método de informar a los neighbors de un cambio de política. Si se reajustan las sesiones BGP, toda la información recibida en esas sesiones se invalida y se quita de la tabla del BGP. También, el neighbor remoto detecta una sesión BGP abajo e invalida las rutas que fueron recibidas. Después de 30 a 60 segundos, las sesiones BGP se restablecen automáticamente, y la tabla de BGP es intercambiada otra vez pero a través de los nuevos filtros. Sin embargo, resetear la sesión BGP interrumpe y/o desestabiliza el envió de paquetes. Los dos comandos mostrados en la figura 1 causan un hard reset de los BGP neighbors que están implicados. Un hard reset significa que el router que publica cualquiera de estos comandos cierra las conexiones apropiadas de TCP, restablece esas sesiones TCP como apropiadas, y vuelve a enviar toda la información a cada uno de los neighbors afectados por el particular comando que es utilizado. El comando clear ip bgp * causa que la tabla de BGP de forwarding en el router que se emite este comando sea completamente borrada, y todas las redes deben ser reaprendidas de cada neighbor. Si un router tiene múltiples neighbors, esta acción es un acontecimiento muy dramático. Este comando fuerza a todos los neighbors a volver a enviar sus tablas enteras simultáneamente. Debes utilizar este comando con la precaución extrema, y no se utiliza normalmente en un ambiente en producción. Por ejemplo, considere una situación en qué el router A tiene ocho neighbors, y cada neighbor tiene una tabla llena de Internet de cerca de 32 MB de tamaño. Si el router A publica el comando clear ip bgp * , todos los ocho routers vuelven a enviar sus 32 MB de tablas al mismo tiempo. Para llevar a cabo todas estas actualizaciones, el router A necesitaría 256 MB de RAM, y también necesitaría estar disponible para poder procesar toda esta información. Procesando 256 MB de actualizaciones tomaría un número considerable de ciclos de CPU, adicional retardo de enrutamiento de los datos del usuario. Si el comando clear ip bgp [neighbor-address] es usado en su lugar, reajustan a un neighbor a la vez. El impacto es menos severo en el router que está publicando este comando. Sin embargo, toma mas tiempo cambiar la política de todos los neighbors, ya que cada uno debe ser dado individualmente más bien que de una vez con el comando clear ip bgp * . El comando clear ip bgp [neighbor-address] todavía realiza un hard reset y debe restablecer la sesión TCP con la dirección especificada, pero afecta solamente a solo neighbor a la vez.

Figura 1 – Hard reset de sesiones BGP

Page 76: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 36 CCNP: Building Scalable Internetworks

6.4.11 Soft Reset de sesiones BGP El comando clear ip bgp soft out causa que BGP haga un soft reset para las actualizaciones de salida. En la figura 1. El router que publica el comando no reajusta la sesión BGP. En su lugar, el router crea una nueva actualización y envía la tabla entera a los vecinos especificados. Esta actualización incluye los comandos de retiro para las redes que el otro neighbor no mirara mas allá basado en la nueva política de salida. Nota: La palabra soft es opcional; clear ip bgp out hace un sofá reset para las actualizaciones de salida. Hay dos maneras de realizar una reconfiguración suave de entrada:

• Usar información de actualización de enrutamiento almacenada • Dinámicamente

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

Figura 1 – Soft reset

Figura 2 – Soft reset default-metric

Figura 3 – Soft reset dinámico

Page 77: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 37 CCNP: Building Scalable Internetworks

6.4.12 El comando debug ip bgp La figura 1 muestra la salida parcial del comando debug ip bgp updates en el router A después de que el comando clear ip bgp fuera publicado para borrar las sesiones BGP con su IBGP neighbor 10.1.0.2. Después de que se restablezca la adyacencia vecina, el router A crea y envía actualizaciones a 10.1.0.2. La primera actualización se destacó en la figura, “10.1.1.0 /24, next 10.1.0.1,” es una actualización sobre la red 10.1.1.0 /24, con un next hop de 10.1.0.1, que es la dirección del router A. La segunda actualización destacada en la figura, “10.97.97.0/24, next 172.31.11.4,” es una actualización sobre la red 10.97.97.0/24, con un next hop de 172.31.11.4, el cual es la dirección de uno de los EBGP neighbors del router A. La dirección del hop next de EBGP se está llevando dentro de IBGP. El router A recibe más adelante actualizaciones de la 10.1.0.2. La actualización destacada en la figura contiene una trayectoria a dos redes: 10.1.2.0 /24 y 10.1.0.0 /24. Los atributos demostrados en esta actualización se describen en la siguiente lección. Nota: Debbugging utiliza recursos del router y debe ser encendido solamente cuando es necesario.

6.5 Seleccionando un BGP Path

6.5.1 Características de los atributos de BGP Los BGP routers envían mensajes de actualización BGP sobre redes destino a otros BGP routers. Los mensajes de actualización contienen una o más rutas y un set de sistema de métricas BGP, que se llaman path attributes, unidos a las rutas. Figura 1 Un atributo es well-known u opcional, obligatoria o discrecional, y transitivo o no transitivo. Un atributo puede también ser parcial. No todas las combinaciones de estas características son válidas. Los atributos de Path caen en las cuatro categorías siguientes:

• Well-known mandatory • Well-known discretionary • Optional transitive • Optional nontransitive

Solamente los atributos Optional transitive se pueden marcar como parciales.

Figura 1 – Comando debug ip bgp updates

Figura 1 – Atributos path BGP

Page 78: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 38 CCNP: Building Scalable Internetworks

Todas los BGP routers deben reconocer un atributo bien conocida (well-known) y propagarlo a los otros BGP neighbors. Figura 2 Los atributos well-known son obligatorios o discrecionales. Un atributo well-known mandatory debe estar presente en todas las actualizaciones de BGP. Un atributo well-known discretionary no tiene que estar presente en todas las actualizaciones de BGP. Los atributos que no son well-known se llaman opcionales. Los BGP routers no tienen que soportar un atributo opcional. Los atributos opcionales son transitivos o no transitivos. Figura 3 Las siguientes declaraciones se aplican a los atributos opcionales:

• Los BGP routers que implementan el atributo opcional pueden propagar este a los otros BGP neighbors, basados en su significado.

• Los BGP routers que no ponen un atributo transitivo opcional en ejecución deben pasar este a otros BGP routers sin tocar y marcan el atributo como parcial.

• Los BGP routers que no implementan un atributo no transitivo opcional deben suprimir el atributo y no deben pasarlo a otros BGP routers

6.5.2 Atributos de BGP Lo que sigue es una lista de los atributos comunes de BGP según a las categorías que ellos pertenecen figura 1

• Well-known mandatory attributes o Sistema Autónomo path o Next hop o Origin

• Well-known discretionary attributes o Local preference o Atomic aggregate

• Optional transitive attribute o Aggregator

• Optional nontransitive attribute o Multi-exit discriminator (MED)

Nota: Además, Cisco define un atributo de peso para BGP. El weight se configura localmente en un router y no se propaga a ningunos otros BGP routers. Nota: Los atributos en esta lista son detallados en los siguientes tópicos, a excepción de los atributos atomic aggregate y aggregator Estos dos atributos se relacionan con la summarization (o la agregación) de BGP, y puedes encontrar más información sobre ellos en Cisco.com

6.5.3 Atributo AS Path El AS path es un atributo well-known mandatory. Siempre que una actualización de ruta pase a través de un Sistema Autónomo, el número del Sistema Autónomo es agregado a esa actualización cuando se anuncia al siguiente EBGP neighbor.

Figura 2 – Atributos bien conocidos

Figura 3 – Atributos opcionales

Figura 1 – Atributos BGP

Page 79: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 39 CCNP: Building Scalable Internetworks

El atributo AS path es realmente la lista de los números de Sistemas Autónomos que una ruta ha atravesado para alcanzar un destino, con el número del Sistema Autónomo que originó la ruta al final de la lista. En la figura 1, el router A en el AS 64520 anuncia la red 192.168.1.0. Cuando esa ruta atraviesa el AS 65500, el router C agrega su propio número del Sistema Autónomo a este. Cuando la 192.168.1.0 alcanza el router B, tiene dos números de Sistema Autónomo unidos a este. Desde la perspectiva del router B, la trayectoria para alcanzar la 192.168.1.0 es (65500, 64520) Un proceso similar se aplica para las trayectorias a las redes 192.168.2.0 y 192.168.3.0. La trayectoria o path del router A a la 192.168.2.0 es (65500, 65000), lo cual significa que atraviesa el AS 65500 y luego el AS 65000. El router C debe atravesar el path (65000) para alcanzar la 192.168.2.0, y el path (64520) para alcanzar a la 192.168.1.0.

6.5.4 Atributo Next-Hop El atributo del next hop de BGP es un atributo well-known mandatory que indica la dirección IP del next hop que debe ser utilizada para alcanzar un destino. BGP enruta Sistema Autónomo por Sistema Autónomo, no router por router. El atributo del next hop define la dirección IP del router frontera que se debe utilizar como el next hop para el destino. Para EBGP, el next hop es la dirección IP del vecino que envió la actualización. En la figura 1, el router A anuncia la 172.16.0.0 al router B, con un next hop de 10.10.10.3, y el router B anuncia la 172.20.0.0 al router A, con un next hop de 10.10.10.1. Para IBGP, el protocolo indica que el next hop que es anunciado por EBGP debe ser llevado en IBGP. Debido a esta regla, el router B anuncia la 172.16.0.0 a su IBGP peer router C con un next hop de 10.10.10.3 (dirección del router A). Por lo tanto, el router C sabe que el next hop para alcanzar la 172.16.0.0 es la 10.10.10.3, y no la 172.20.10.1, como pudo haber sido esperado. Es muy importante que el router C sepa alcanzar la subred 10.10.10.0, vía un IGP o una ruta estática. Si no, este eliminará los paquetes destinados a la red 172.16.0.0, porque no puede conseguir la dirección del next hop para esa red. Alternativamente, el router B puede cambiar el atributo del next hop a sí mismo si se utiliza el comando neighbor next-hop-self

Figura 1 – Atributo AS path

Figura 1 – Atributo Next-hop

Page 80: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 40 CCNP: Building Scalable Internetworks

6.5.5 Atributo Origen El atributo origen define el origen de la información de la trayectoria. El atributo origen puede ser uno de estos tres valores: figura 1

• IGP La ruta es interior al Sistema Autónomo que origina. Este valor normalmente resulta cuando el comando network es utilizado para anunciar la ruta vía BGP. Un origen de IGP se indica con una “i” en la tabla BGP

• EGP: La ruta se ha aprendido vía EGP. Este valor se indica con una “e” en la tabla BGP. El EGP se considera un protocolo histórico de enrutamiento y no se apoya en el Internet porque realiza solamente el enrutamiento classful y no soporta classless interdomain routing

• Incompleto: El origen de la ruta es desconocido o se ha aprendido por algún otro medio. Este valor resulta generalmente cuando una ruta se redistribuye en BGP. Un origen incompleto se indica con un signo de interrogación (?) en la tabla BGP

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

6.5.6 Atributo Local Preference La preferencia local (Local preferente) es un atributo well-known discretionary que proporciona una indicación a los routers en el Sistema Autónomo sobre cual trayectoria se prefiere para salir del Sistema Autónomo. Una trayectoria con una preferencia local más alta se prefiere. La preferencia local es un atributo que se configura en el router y se intercambia entre los routers dentro del mismo Sistema Autónomo únicamente. El valor prefijado para la preferencia local en un router Cisco es 100. En la figura 1, el AS 64520 recibe actualizaciones sobre la red 172.16.0.0 a partir de dos direcciones. La preferencia local en el router A para la red 172.16.0.0 se

Figura 1 – Atributo origen

Figura 2 – Ejemplo: Atributo origen

Figura 1 – Atributo preferencia local

Page 81: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 41 CCNP: Building Scalable Internetworks

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

6.5.7 Atributo MED El atributo MED, también llamado la métrica, es un atributo no transitivo opcional. El MED es una indicación a los EBGP neighbors sobre la trayectoria preferida en un Sistema Autónomo. El atributo MED es una manera dinámica de influenciar a otro Sistema Autónomo sobre cual trayectoria este debe elegir para alcanzar una cierta ruta en su Sistema Autónomo cuando existen múltiples puntos de entrada. Se prefiere la métrica mas baja. Distinto a la preferencia local, el MED se intercambia entre los sistemas autónomos. El MED se envía a los EBGP peers. Esos routers propagan el MED dentro de su Sistema Autónomo, y los routers dentro del Sistema Autónomo utilizan el MED pero no lo pasan encendido al siguiente Sistema Autónomo. Cuando la misma actualización se pasa encendida a otro Sistema Autónomo, la métrica se fija de nuevo por defecto a 0. MED influencia al tráfico de entrada de un Sistema Autónomo, y la preferencia local influencia al tráfico de salida. Por defecto, un router compara el atributo de MED solamente para las trayectorias de vecinos en el mismo Sistema Autónomo Nota: El atributo de MED significa que BGP es el único protocolo que puede afectar cómo las rutas se envían en un Sistema Autónomo. En la figura 1, el atributo del router B MED se fija a 150, y el atributo del router C MED se fija a 200. Cuando el router A recibe actualizaciones de los routers B y C, elige al router B como el mejor next hop ya que su MED de 150 es menor que la del router C.

6.5.8 Atributo Weight El atributo weight es un atributo de Cisco para la selección de trayectoria. El peso se configura localmente en un router y no se propaga a ningún otro routers. Esta cualidad se aplica cuando estás utilizando un router con múltiples puntos de salida en Sistema Autónomo, en comparación con el atributo de preferencia local, el cual es usado cuando dos o más routers proporcionan puntos múltiples de salida. El peso puede tener un valor a partir de 0 a 65535. Por defecto, las trayectorias que el router origina tienen un peso de 32768, y otras trayectorias tienen un peso de 0. Las rutas con un peso más alto son preferidas

Figura 1 – Atributo MED

Figura 1 – Atributo Weight (solo Cisco)

Page 82: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 42 CCNP: Building Scalable Internetworks

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

6.5.9 Determinando la selección del BGP Path Múltiples trayectorias pueden existir para alcanzar una red dada. Como las trayectorias para una red se evalúan, esto determinada que las que no sean la mejor trayectoria sean eliminadas de los criterios de selección pero se mantienen en BGP forwarding table (que puede ser mostrada usando el comando show ip bgp ) en caso que la mejor trayectoria llegue a estar inaccesible. Figura 1 BGP no se diseña para realizar balancear de la carga. Las trayectorias se eligen debido a la política, no se basan en el ancho de banda. El proceso de selección de BGP elimina cualquier trayectoria múltiple hasta que una sola mejor trayectoria es dejada. La mejor trayectoria se somete al proceso de administración de la tabla de enrutamiento y se evalúa contra cualquier otro protocolo de enrutamiento que pueda también alcanzar esa red. La ruta de origen con la distancia administrativa más baja es instalada en la tabla de enrutamiento. El proceso de decisión es basado en los atributos descritos tempranamente

6.5.10 Seleccionando un BGP Path Después de que el BGP recibe actualizaciones sobre diversos destinos de diversos sistemas autónomos, este elige la mejor trayectoria para alcanzar un destino específico. El proceso de decisión se basa en los atributos de BGP. BGP considera solamente las rutas sincronizadas sin lazos del Sistema Autónomo y un next hop válido. El siguiente proceso resume cómo BGP elige la mejor ruta en un router Cisco: figura 1

1. Preferir la ruta con el peso más alto. (El atributo del peso es propietario a Cisco y es local a router solamente.)

2. Si múltiples rutas tienen el mismo peso, preferir la ruta con el más alto valor de preferencia local. (La preferencia local se utiliza dentro de un Sistema Autónomo.)

3. Si las rutas múltiples tienen la misma preferencia local, preferir la ruta que el router local originó. Una ruta localmente originada tiene un next hop de 0.0.0.0 en la tabla de BGP.

4. Si no se originó ninguna de las rutas localmente, preferir la ruta con la trayectoria más corta de Sistema Autónomo.

5. Si la longitud de trayectoria de Sistema Autónomo es igual, preferir el código de origen más bajo (IGP < EGP < incompleto).

Figura 1 – Selección path BGP

Figura 1 – Proceso de selección de ruta

Page 83: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 43 CCNP: Building Scalable Internetworks

6. Si todos los códigos de origen son iguales, preferir la trayectoria con el MED más bajo. (El MED se intercambia entre Sistema Autónomos.) se hace la comparación de MED solamente si el Sistema Autónomo vecino es igual para todas las rutas consideradas, a menos que el comando bgp always-compare-med este habilitado

Nota: La decisión más reciente del Internet Engineering Task Force (IETF) con respecto a BGP MED asigna un valor de infinito al MED perdido, haciendo que a ruta que carece de la variable MED sea preferida lo menos posible. El comportamiento por defecto de los BGP routers que corren Cisco IOS software es tratar las rutas sin el atributo de MED como teniendo un MED de 0, hagan que la ruta carezca de variable de MED preferida. Para configurar el router para conformarse con el estándar del IETF, utilizar el comando bgp bestpath missing-as-worst

7. Si las rutas tienen el mismo MED, preferir trayectorias externas a las trayectorias internas. 8. Si la sincronización es deshabilitada y solamente permanecen las trayectorias internas, preferir la

trayectoria a través del vecino más cercano de IGP, que significa que el router prefiere la trayectoria interna más corta dentro del Sistema Autónomo para alcanzar el destino (el Shortest-Path al next hop del BGP).

9. Para los EBGP paths, seleccionar la ruta más vieja para reducir al mínimo el efecto de las rutas que van hacia arriba y hacia abajo (flapping).

10. Preferir la ruta con el valor más bajo de la identificación del BGP router del vecino. 11. Si las identificaciones de los routers BGP son iguales, preferir el router con la dirección IP vecina mas

baja Solamente la mejor trayectoria se inscribe en la tabla de enrutamiento y se propaga a los BGP neighbors del router. Nota: El proceso de selección de la ruta sumarizada aquí no cubre todos los casos sino es suficiente para una comprensión básica de cómo BGP selecciona las rutas. Por ejemplo, suponer que hay siete trayectorias para alcanzar la red 10.0.0.0. Todas las trayectorias no tienen ningún lazo de Sistema Autónomo y tienen direcciones válidas del next hop, así que las siete trayectorias pasan al paso 1, las cuales examinan el peso de las trayectorias. Las siete trayectorias tienen un peso de 0, así que todas pasan al paso 2, que examina la preferencia local de las trayectorias. Cuatro de las trayectorias tienen una preferencia local de 200, y los otros tres tienen preferencias locales de 100, 100, y 150. Los cuatro con una preferencia local de 200 continúan el proceso de la evaluación al paso siguiente. Los otros tres todavía están en la BGP forwarding table, pero son actualmente descalificadas como la mejor trayectoria. BGP continúa el proceso de evaluación hasta que solamente permanece una sola mejor trayectoria, que se somete a la tabla de enrutamiento IP como la mejor trayectoria del BGP.

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

Figura 1 – Proceso de selección de ruta

Page 84: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 44 CCNP: Building Scalable Internetworks

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

Figure 2 – Proceso de selección de ruta

Page 85: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 45 CCNP: Building Scalable Internetworks

6.6 Manipulando BGP Path Selection con Route Maps

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

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

Figura 1 – BGP es designado para implementar la política de

enrutamiento

Figura 1 – BGP es designado para implementar la política de

enrutamiento

Page 86: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 46 CCNP: Building Scalable Internetworks

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

6.6.3 Cambiando la Local Preference de BGP para tod as las Rutas La preferencia local se utiliza solamente dentro de un Sistema Autónomo entre IBGP speakers para determinar la mejor trayectoria para salir del Sistema Autónomo para alcanzar una red exterior. La preferencia local es fijada a 100 por defecto; se prefieren valores más altos. El comando bgp default local-preference cambia el valor por defecto de la preferencia local. La Figura 1 y 2 exhibe el parámetro del comando. Con este comando, todas las rutas IBGP que son anunciadas tienen la preferencia local en un valor específico Si un EBGP neighbor recibe un valor de preferencia local, el EBGP neighbor no hace caso de él

Figura 1 – Cambiando preferencia local para todas las rutas

Figura 2 – Parámetro del comando bgp default local-preference

Page 87: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 47 CCNP: Building Scalable Internetworks

6.6.4 Ejemplo de Local Preference en BGP La figura 1 ilustra un ejemplo de red que corre BGP para demostrar la manipulación de la preferencia local utilizando route maps en el AS 65001. La mejor trayectoria para la red 172.16.0.0 en el AS 65003 del router C en el AS 65001 es determinado de la siguiente manera:

• En el paso 1 y 2 miran el weight y la local preference y usan los default settings del weight igual a 0 y la local preference igual a 100 para todos los routers que están aprendiendo de los IBGP neighbors de A y de B.

• El paso 3 no ayuda a decidir la mejor trayectoria ya que las 3 rutas de AS no son propias u originadas en el AS 65001.

• El paso 4 prefiere la trayectoria mas corta de Sistemas Autónomos. Las opciones son dos Sistemas Autónomos (65002, 65003) a través del router A o tres Sistemas Autónomos a través del IBGP neighbor router B (65005, 65004, 65003). De esta manera, las más corta trayectoria de Sistemas Autónomos del router C al AS 65003 es a través del router A.

La mejor trayectoria del router C a las redes en el AS 65005 también es seleccionada por paso 4. El Shortest-Path del router C al AS 65005 está a través del router B, porque este consiste en un AS (65005) comparado con los cuatro Sistemas Autónomos (65002, 65003, 65004, 65005) a través del router A. La mejor trayectoria del router C a las redes en el AS 65004 también es seleccionado por el paso 4. El Shortest-Path del router C al AS 65004 está a través del router B, porque este consiste en dos Sistemas Autónomos (65005, 65004) comparado a los tres Sistema Autónomos (65002, 65003, 65004) a través del router A.

6.6.5 Ejemplo de Local Preference en BGP (continuac ión) La figura 1 muestra la BGP forwarding table en el router C en el AS 65001 con solamente los default settings para la selección de trayectoria BGP. El diagrama muestra solamente las redes de interés a este ejemplo:

• 172.16.0.0 en el AS 65003 • 172.24.0.0 en el AS 65005 • 172.30.0.0 en el AS 65004

La mejor trayectoria es indicada con “>” en la segunda columna de la salida. Cada red tiene dos trayectorias que son sean loop-free, sincronización-deshabilitada, y que tienen una dirección válida. Todas las rutas tienen un peso de 0 y una preferencia local por defecto de 100; así los pasos 1 y 2 en el proceso de selección de la trayectoria BGP son iguales. Esta router no originó ninguna de las rutas (paso 3), así que el proceso se mueve al paso 4, y BGP elige la trayectoria más corta de Sistemas Autónomos como sigue:

• Para la red 172.16.0.0, la trayectoria más corta de Sistema Autónomo de dos Sistema Autónomos (65002, 65003) está a través del next hop de 192.168.28.1.

• Para la red 172.24.0.0, la trayectoria más corta de Sistema Autónomo del (65005) está a través del next hop de 172.20.50.1.

• Para la red 172.30.0.0, la trayectoria más corta de Sistema Autónomo de (65005, 65004) está a través del next hop de 172.20.50.1.

Figura 1 – Preferencia local

Page 88: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 48 CCNP: Building Scalable Internetworks

Ninguno de los dos ni el router A ni el router B esta utilizando la opción next-hop-self en este ejemplo Un análisis de tráfico revela lo siguiente:

• El link a través del router B a la 172.20.50.1 es muy usado, y el link a través del router A a la red 192.168.28.1 es apenas utilizado.

• Las tres redes destino de mas grande volumen en el Internet del AS de 65001 son 172.30.0.0, 172.24.0.0, y 172.16.0.0.

• Treinta por ciento de todo el tráfico del Internet va a la red 172.24.0.0 (vía el router B); 20 por ciento van a la red 172.30.0.0 (vía el router B); y 10 por ciento van a la red 172.16.0.0 (vía el router A). Los otros 40 por ciento van a otras destinos. Solamente 10 por ciento de todo el tráfico esta utilizando el link fuera del router A a la red 192.168.28.1, y el 50 por ciento de todo el tráfico está utilizando el link fuera del router B a la 172.20.50.1

El administrador de red ha decidido desviar el tráfico para la red 172.30.0.0 y enviar este hacia fuera del router A para el next hop del 192.168.28.1, de modo que el cargamento entre los routers A y B sea más equilibrado.

6.6.6 Ejemplo de Local Preference en BGP (continuac ión) La figura 1 muestra que usando un route map en el router A para alterar la actualización BGP de la red 172.30.0.0 del router X (192.168.28.1) para tener una alta preferencia de 400 de modo que este sea preferido. La primera línea del route map es una declaración de permiso con un número de secuencia de 10 para un route map llamado “local_pref”; esto define la primera declaración del route-map. La condición de emparejamiento para esta declaración está comprobando todas las redes que sean permitidas por la access list 65. La access list 65 permite a todas las redes que comiencen con los primeros dos octetos de la 172.30.0.0. El route map fija esas redes con una preferencia local de 400. La segunda declaración del route map es una declaración de permiso con un número de secuencia de 20 para el route map “local_pref”, pero no tiene ningún match o declaraciones fijadas. Esta declaración es una declaración de permit-all para todos los route maps. Ya que no hay condiciones de match para las redes restantes, están totalmente permitidas con sus ajustes actuales. En este caso, la preferencia local para la red 172.16.0.0 y 172.24.0.0 quedan fijadas por defecto de 100. El número de secuencia de 20 se elige para la segunda declaración en caso de que otras políticas más adelante tengan que ser puestas en ejecución antes de la declaración permit-all

Figura 1 – Tabla con valores por defecto del Router C

Figura 1 – Route map para el router A

Page 89: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 49 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. La figura 2 muestra la BGP forwarding table del router C en el AS 65001 después de que la sesión BGP ha sido reseteada. Esta ilustra que el router C ha aprendido sobre el nuevo valor de local preferente (400) que venía del router A para la red 172.30.0.0. La única diferencia en esta tabla comparada al ejemplo anterior, el cual no tiene una manipulación de la local preferente, es que la mejor ruta a la red 172.30.0.0 ahora está con la red 192.168.28.1 ya que su preferencia local de 400 es más alta que la preferencia local de 100 para el next hop de 172.20.50.1. La trayectoria de Sistema Autónomo a través de la 172.20.50.1 sigue siendo más corta que la trayectoria con la 192.168.28.1, pero la longitud de la trayectoria no se evalúa hasta el paso 4, mientras que la preferencia local se examina en el paso 2. La trayectoria con la más alta preferencia local elegida como la mejor trayectoria

6.6.7 Seteando la MED con Route Maps Recordar que MED es utilizado para decidir cómo entrar en un Sistema Autónomo. Se utiliza cuando las trayectorias múltiples existen entre dos Sistema Autónomos y un Sistema Autónomo está intentando influenciar en la trayectoria entrante del otro. Ya que MED se evalúa tarde en el proceso de selección de trayectoria de BGP (paso 6), no tiene generalmente ninguna influencia en el proceso de selección de BGP. Por ejemplo, un Sistema Autónomo que recibe un MED para una ruta puede cambiar su preferencia local para permitir al Sistema Autónomo eliminar lo que está anunciando el otro Sistema Autónomo con su valor de MED. 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

Figura 2 – Tabla con preferencia locales aprendidas en el Router C

Figura 1 – Cambiando MED para todos los routers

Figura 2 – Parámetro del comando default-metric

Page 90: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 50 CCNP: Building Scalable Internetworks

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

6.6.9 BGP Utilizando Route Maps y un Ejemplo de MED (continuación) El MED es fijado de salida cuando un router está anunciando a un EBGP neighbor. En el ejemplo de configuración para el router A en la figura 1, un route map nombrado “med_65004” se liga al neighbor 192.168.28.1 como un route map de salida Cuando el router A envía una actualización al neighbor 192.168.28.1 (router X), procesa la actualización de salida a través del route map med_65004 y utiliza una declaración del sistema para cambiar cualquiera de valores que son especificados, siempre y cuando la declaración de emparejamiento precedente se resuelva en la sección del route map. La primera línea del route map es una declaración de permiso con un número de secuencia de 10 para el route map med_65004. Esto define la primera declaración del route-map. La condición de match para esta declaración chequea todas las redes que son permitidas por la access list 66 La primera línea de la access list 66 permite a cualquier red que comience con los primeros tres octetos de 192.168.25.0, y la segunda línea permite las redes que comienzan con los primeros tres octetos de 192.168.26.0. Todas las redes que son permitidas por cualquiera de estas líneas se fijan un MED de 100. El resto de las redes son negadas por esta access list (hay un implícito deny all al final de todas las access lists), así que estas no son seteadas con un MED de 100; su MED no es cambiado. Estas otras redes deben proceder a la siguiente declaración de route map en el route map med_65004. 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

Figura 1 – Usando route maps y el MED

Figura 1 – Route map para el router A

Page 91: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 51 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 Antes de que el router B envíe una actualización al neighbor 172.20.50.1, procesa la actualización de salida a través del route map med_65004 y utiliza una declaración del sistema para cambiar cualquier valor que este especificado, siempre y cuando la declaración precedente de emparejamiento se resuelva en esta sección del route map. La primera línea del route map es una declaración de permiso con un número de secuencia de 10 para el route map med_65004, el cual define la primera declaración del route-map. La condición de emparejamiento para esa línea comprueba todas las redes que son permitidas por la access list 66. La access list 66 en el router B permite a cualquier red que comience con los primeros tres octetos de 192.168.24.0. Cualquier red que sea permitida por esta línea se fija un MED de 100. El resto de las redes son negadas por esta access list, así que no fijan a 100 el valor de MED. Estas otras redes deben seguir a la siguiente declaración en el route map med_65004. 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

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

Figura 2 – Route map para el router B

Page 92: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 7: IP Multicasting 52 CCNP: Building Scalable Internetworks

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

6.6.11 Implementando BGP en la Empresa La figura 1 representa una puesta en práctica típica de BGP en una empresa. La empresa es multihomed a dos ISPs para aumentar la confiabilidad y el funcionamiento de su conexión al Internet. El ISPs puede pasar solamente las rutas por defecto o puede también pasar otras rutas específicas, o aún todas las rutas, a la empresa. Los routers de la empresa conectados a los ISPs corren EBGP con los routers del ISP e IBGP entre sí mismos; así todos los routers en la trayectoria de tránsito dentro del Sistema Autónomo de la empresa corren IBGP. Estos routers pasan las rutas por defecto a los otros routers en la empresa en vez de redistribuir BGP en el protocolo de enrutamiento interior. Los atributos de BGP pueden ser manipulados, utilizando los métodos discutidos hasta ahora, con cualquier de los routers que corren BGP para afectar la trayectoria del tráfico para y desde el Sistema Autónomos.

Resumen El Internet ha demostrado ser una herramienta valiosa a muchas compañías, dando por resultado múltiples conexiones redundantes a muchos Internet service providers (ISPs). El Border Gateway Protocol (BGP) es utilizado por ISPs para mover tráfico entre los sistemas autónomos y también utilizado por las compañías individuales que son multihomed para controlar la selección de trayectorias.

Figura 1 – MED aprendido por el router Z

Figura 1 – BGP en una empresa

Page 93: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 1 CCNP: Building Scalable Internetworks

Módulo 8: IPv6

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

8.1 Explicación de IPv6

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

8.1.2 Características de IPv6 IPv6 es una mejora poderosa para IPv4, y varias características IPv6 ofrecen mejoras funcionales:

• Espacio de dirección más grande : Ofrece alcanzabilidad y flexibilidad globales mejoradas; la agregación de prefijos que se anuncian en las tablas de enrutamiento; multihoming a varios Internet

Page 94: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 2 CCNP: Building Scalable Internetworks

service providers (ISPs); autoconfiguración que puede incluir direcciones de capa de enlace en el espacio de dirección; opciones plug-and-play; redireccionamiento publico a privado extremo a extremo sin traducción de dirección; y mecanismos simplificados para renumeración y modificación de dirección.

• Encabezado más simple : Proporciona mejor eficiencia de enrutamiento; no hay broadcasts y así ninguna amenaza potencial de tormentas de broadcast; no hay necesidad de procesar checksums; mecanismos de encabezado de extensión más simples y más eficientes; y las etiquetas de flujo para procesamiento por flujo sin necesidad de abrir el paquete interno de transporte para identificar varios flujos de trafico.

• Movilidad y seguridad : Asegura conformidad con funcionalidad de estándares IP móvil y IPsec ; la movilidad esta incorporada, por que cualquier nodo IPv6 puede usarla cuando sea necesario; y permite a la gente desplazarse en redes con dispositivos de red móviles - con muchos que tienen conectividad inalámbrica. Mobile IP es un estándar de la Internet Engineering Task Force (IETF) disponible para IPv4 e IPv6. El estándar permite a los dispositivos móviles moverse sin interrupciones en conexiones de red establecidas. Debido a que IPv4 no proporciona automáticamente esta clase de movilidad, usted debe agregarla con configuraciones adicionales. IPsec es el estándar IETF para la seguridad de red IP, disponible para IPv4 e IPv6. Aunque las funcionalidades son esencialmente idénticas en ambos ambientes, IPsec es obligatorio en IPv6. IPsec esta habilitado en cada nodo IPv6 y está disponible para el uso. La disponibilidad de IPsec en todos los nodos hace a la Internet IPv6 más segura. IPsec también requiere claves para cada parte, lo que implica un despliegue y distribución claves global.

• Riqueza de transición : Usted puede incorporar capacidades IPv4 existentes en IPv6 de las siguientes maneras:

o Configure un dual stack con IPv4 e IPv6 en el interfaz de un dispositivo de red. o Use la técnica IPv6 sobre IPv4 (también llamada tunneling 6to4), que usa un túnel IPv4 para

llevar tráfico IPv6. Este método (RFC 3056) reemplaza al tunneling IPv4-compatible (RFC 2893). Cisco IOS Software Release 12.3(2)T (y posteriores) también permite la protocol translation (NAT-PT) entre IPv6 e IPv4. Esta traducción permite la comunicación directa entre los hosts que hablan protocolos diferentes.

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

Page 95: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 3 CCNP: Building Scalable Internetworks

La agregación de prefijos de cliente da lugar a una tabla de enrutamiento eficiente y escalable. El enrutamiento escalable es necesario para expandir la adopción más amplia de funciones de red, permitiendo que Internet adecuar lo siguiente:

• Número creciente de consumidores de banda ancha con de alta velocidad, conexiones always-on • Los usuarios pasan mas tiempo online adquiriendo servicios de comunicación (tales como música) y

participando en ofertas de alto valor que se pueden encontrar • Redes caseras con aplicaciones de red expandidas tales como Voice over IP (VoIP) inalámbricas,

vigilancia casera, y los servicios avanzados tales como vídeo on demand (VoD) en tiempo real • Juegos escalables masivamente con participantes globales • Media-rich e-learning, proveyendo a los principiantes con laboratorios remotos y simulaciones de

laboratorio a pedido

8.2 Direccionamiento IPv6

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

Page 96: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 4 CCNP: Building Scalable Internetworks

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

• Versión : Campo de 4 bits, lo mismo que en IPv4. Contiene el número 6 en vez del número 4 para IPv4. • Clase de Tráfico : Campo de 8 bits similar al campo type of sevice (TOS) en IPv4. Etiqueta al paquete

con una clase de tráfico que use en Differentiated Services (DiffServ). Estas funcionalidades son las mismas para IPv6 e IPv4.

• Etiqueta de Flujo : Campo de 20 bits que permite que un flujo particular de tráfico sea etiquetado. Se puede usar para técnicas de switching multicapa y ejecucion de conmutación de paquetes más rápido.

• Longitud de Carga Util : Similar al campo Longitud Total en IPv4. Especifica la longitud de la carga útil, en bytes, que el paquete está encapsulando.

• Encabezado Siguiente : Especifica qué encabezado sigue al encabezado del paquete IPv6. Puede ser un paquete de capa de transporte, tal como TCP o UDP, o puede ser un encabezado de extensión. Este campo es similar al campo Protocolo en IPv4.

• Límite de Salto : Especifica el número máximo de saltos que un paquete IP puede atravesar. Cada salto o router disminuye a este campo en uno (similar al campo Time to Live [TTL] en IPv4). Debido a que no hay checksum en el encabezado IPv6, el router puede disminuir el campo sin recomputar la checksum. La recomputacion cuesta tiempo de procesamiento valioso en los routers IPv4.

• Dirección Origen : Este campo tiene 16 octetos o 128 bits. Identifica al origen del paquete. • Dirección Destino : Este campo tiene 16 octetos o 128 bits. Identifica al destino del paquete. • Encabezados de Extensión : Sigue a los ocho campos anteriores. El número de encabezados de

extensión no es fijo, por lo que la longitud total de la cadena del encabezado de extensión es variable.

8.2.3 Encabezados de Extensión IPv6 Hay muchos tipos de encabezados de extensión. Cuando se usan múltiples encabezados de extensión en el mismo paquete, el orden de los encabezados debe ser como sigue:

1. Encabezado IPv6 : Encabezado básico descrito en la figura anterior. 2. Encabezado de opciones salto-por-salto : Cuando se usa para la alarma del router (Resource

Reservation Protocol [RSVP] y Multicast Listener Discovery version 1 [MLDv1]) y jumbogram, este encabezado (valor = 0) procesa todos los saltos en el camino de un paquete. Cuando se presenta, siempre el encabezado de opciones salto-por-salto sigue inmediatamente después del encabezado del paquete IPv6 básico.

3. Encabezado de opciones de destino (cuando se usa el encabezado de enrutamiento) : Este encabezado (valor = 60) puede seguir cualquier encabezado de opciones salto-por-salto, en cuyo caso el encabezado de opciones de destino se procesa en el destino final y también en cada dirección visitada especificada por un encabezado de enrutamiento. Alternativamente, el encabezado de opciones de destino puede seguir a cualquier encabezado Encapsulating Security Payload (ESP), en cuyo caso el encabezado de opciones de destino se procesa solamente en el destino final. Por ejemplo, el IP móvil usa este encabezado.

4. Encabezado de enrutamiento : Usado para el enrutamiento del origen e IPv6 móvil (valor = 43). 5. Encabezado de fragmentación : Usado cuando un origen debe fragmentar un paquete que sea más

grande que la MTU para el camino entre sí mismo y un dispositivo destino. El encabezado de fragmento se usa en cada paquete fragmentado.

6. Encabezado de autenticación y encabezado de carga ú til de seguridad de encapsulamiento : Usado dentro de IPsec para proporcionar autenticación, integridad, y confidencialidad de un paquete. El encabezado de autenticación (valor = 51) y el encabezado ESP (valor = 50) son idénticos para IPv4 e IPv6.

7. Encabezado de capa superior : Encabezados típicos usados dentro de un paquete para transportar los datos. Los dos protocolos de transporte principales son TCP (valor = 6) y UDP (valor = 17).

Page 97: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 5 CCNP: Building Scalable Internetworks

8.2.4 Definición de la Representación de Dirección Las direcciones IPv6 de 128 bits se representan dividiéndolas en ocho segmentos de 16 bits. Cada segmento se escribe en hexadecimal entre 0x000 y 0xFFF, separados por dos puntos. Los dígitos hexadecimales A, B, C, D, E, y F representados en IPv6 no son sensibles a mayúsculas. IPv6 no requiere notación de la secuencia de la dirección de forma explícita. Use las pautas siguientes para las notaciones de la secuencia de la dirección IPv6:

• Los ceros iniciales en un campo son opcionales, o sea 09C0 = 9C0 y 0000 = 0. • Campos sucesivos de ceros se pueden representar como "::" solamente una vez en una dirección. • Una dirección sin especificar se escribe como "::" porque contiene solamente ceros.

Usar la notación "::" reduce grandemente el tamaño de la mayoría de las direcciones. Por ejemplo, FF01:0:0:0:0:0:0:1 se convierte en FF01::1. Nota: Un analizador sintáctico de dirección identifica el número de ceros faltantes separando las dos partes e introduciendo 0 hasta que los 128 bits estén completos. Si se colocan dos notaciones "::" en la dirección, no hay forma de identificar el tamaño de cada bloque de ceros.

8.2.5 Tipos de Direcciones IPv6 La estructura del direccionamiento IPv6 esta definida en múltiples RFCs, incluyendo RFC 3513 y el nuevo RFC 4291 (volviendo obsoleto a RFC 3513). Fig.1 Cada RFC define tres tipos de direcciones IPv6: Fig.2

• Dirección unicast • Dirección muticast • Dirección anycast

Dirección Unicast Una dirección unicast identifica un solo dispositivo. Un paquete enviado a una dirección unicast es entregado a la interfaz identificada por esa dirección. Hay dos tipos de direcciones unicast:

• Dirección unicast de link-local : El alcance se configura para enlace único. La dirección es única solamente en este enlace, y no es ruteable fuera del enlace.

• Dirección unicast global : Globalmente única, así que puede ser enrutada globalmente sin modificación. Una dirección global tiene un alcance ilimitado en la Internet mundial. Los paquetes con direcciones origen y destino globales son enrutados hacia su destino objetivo por los routers en la Internet.

Se requieren de todas las interfaces para tener por lo menos una dirección unicast link-local. Sin embargo, una característica fundamental del IPv6 es que una sola interfaz puede también tener múltiples direcciones IPv6 de cualquier tipo (unicast, anycast, y multicast). Nota: También existe una dirección unicast de site-local; sin embargo, la IETF está trabajando actualmente en quitar o reemplazar direcciones site-local. Por lo tanto, este módulo no incluye este tipo de dirección.

Figura 1 – Direccionamiento IPv6 unicast

Figura 2 – Tipos de direcciones IPv6

Page 98: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 6 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. Las direcciones anycast son sintácticamente indistinguibles de direcciones unicast globales, porque las direcciones anycast se asignan del espacio de dirección unicast global. Nota: Las direcciones anycast no se pueden usar como la dirección origen de un paquete IPv6. Direcciones especiales Hay un número de direcciones con significado especial en IPv6. Algunos de éstos se presentan en Figura 3

8.2.6 Direcciones Unicast Globales y Anycast IPv6 Las direcciones unicast globales y anycast comparten el mismo formato. El espacio de dirección unicast asigna direcciones anycast. Estas direcciones aparecen como direcciones unicast para los dispositivos que no se configuran para anycast. Figura1. Cuando una dirección unicast se asigna a más de una interfaz, volviéndola asi en una dirección anycast, los nodos a los cuales se asigna la dirección se deben configurar explícitamente para usar y reconocer la dirección anycast. Un paquete que se envía a una dirección anycast enruta al dispositivo o interfaz más cercana que comparte la dirección. Un remitente crea un paquete con anycast como la dirección destino y lo remite a su router más cercano. El origen puede usar

Figura 3 – Direcciones especiales IPv6

Figura 1 – Direcciones globales IPv6 unicast (y anycast) addresses

Page 99: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 7 CCNP: Building Scalable Internetworks

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

8.3 Direcciones IPv6 Dinámicas

8.3.1 Definición de las Direcciones de Interfaz de Host Una dirección IPv6 tiene dos partes:

• Un prefijo de subred que representa la red con la cual la interfaz está conectada. El prefijo de subred es una longitud fija de 64 bits para todas las definiciones actuales.

• Un identificador local, a veces llamado un token, que identifica únicamente al host en la red local. El identificador local siempre es de 64 bits y se crea dinámicamente basado en medios de capa 2 y encapsulación. En el caso simple de un medio Ethernet, el identificador local usualmente se deriva de la dirección MAC EUI-48.

El identificador local de 64 bits en una dirección IPv6 identifica a una interfaz única en un enlace. Un enlace es un medio de red sobre el cual los nodos de red se comunican usando la capa de enlace. El identificador de interfaz puede también ser único sobre un alcance más amplio. En muchos casos, un identificador de interfaz es igual a o se basa en la dirección (MAC) de capa de enlace de una interfaz. Como en IPv4, un prefijo de subred en IPv6 se asocia con un enlace.

Page 100: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 8 CCNP: Building Scalable Internetworks

8.3.2 Dirección Local de Enlace Los identificadores de interfaz en direcciones IPv6 identifican interfaces en un enlace. Las direcciones link-local también pueden ser pensadas como la porción de host de una dirección IPv6. La dirección es única solamente en este enlace, y no es ruteable fuera del enlace. Los paquetes con un destino link-local deben permanecer en el enlace donde fueron generados. Los routers que podrían remitirlos a otros enlaces no están permitidos porque no ha habido verificación de la unicidad fuera del contexto del enlace origen. Fig.1 Las direcciones link-local se crean dinámicamente usando un prefijo link-local de FE80::/10 y un identificador de interfaz de 64 bits en un proceso llamado autoconfiguración stateless.

8.3.3 Autoconfiguración Stateless La autoconfiguración stateless es una característica plug-and-play que permite a los dispositivos conectarse automáticamente con una red IPv6 sin configuración manual y sin servidores (como servidores DHCP). DHCP y DHCPv6 se conocen como protocolos stateful porque mantienen las tablas dentro de servidores dedicados. El protocolo de autoconfiguración stateless no necesita ningún servidor o relevo porque no hay estado a mantener. Cada sistema IPv6 (con excepción de los routers) puede construir su propia dirección global unicast, lo cual permite nuevos dispositivos, tales como celulares, los dispositivos inalámbricos, electrodomésticos, y redes caseras, se desplieguen en la Internet. Debido a que la longitud de prefijo es fija y bien conocida, un sistema construye automáticamente una dirección link-local durante la fase de la inicialización de los NICs IPv6. Después de la verificación de unicidad, este sistema puede comunicarse con otros hosts IPv6 en ese enlace sin ninguna otra intervención manual. Para un sistema conectado con un enlace Ethernet, la construcción y validación de la dirección link-local se logra en las fases siguientes. Figura 1. Fase 1 Aunque manualmente configurable, el método más común para obtener un identificador único en un enlace Ethernet es usando la dirección MAC EUI-48 y aplicando el algoritmo estándar IEEE EUI-64 modificado. Por ejemplo, al transformar la dirección MAC 00-0C-29-C2-52-FF usando los estándares EUI-64 conduce a 00-0C-29-FF-FE-C2-52-FF. Si esta dirección es para permanecer local, la notación IPv6 sería 000C:29FF:FEC2:52FF. Sin embargo, si la dirección es para ser una dirección unicast global, el formato correcto es 020C:29FF:FEC2:52FF. Nota: Para direcciones con alcance global, la porción inicial de la dirección MAC se altera de 00-0C a 02-0C. Este proceso se discute en el tópico siguiente.

Figura 1 – Direcciones de enlace local

Figura 1 – Fases de autoconfiguración stateless

Page 101: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 9 CCNP: Building Scalable Internetworks

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

8.3.4 EUI-64 a Identificador IPv6 Una dirección MAC (IEEE 802) tiene 48 bits de longitud. El espacio para el identificador local en una dirección IPv6 es de 64 bits. El estándar EUI-64 explica cómo estirar direcciones IEEE 802 de 48 bits a 64 bits insertando el 0xFFFE de 16 bits en medio del bit 24 de la direccion MAC. Esto crea un identificador interfaz único de 64 bits. Por ejemplo, transformar la dirección MAC 00-90-27-17-FC-0C usando el estándar EUI-64 da como resultado 00-90-27-FF-FE-17-FC-0C. Al convertir esto en notación IPv6 generaría 0090:27FF:FE17:FC0C. Fig.1 Cuando el identificador de interfaz se crea a partir de una dirección MAC Ethernet, se asume que la dirección MAC es universalmente única y, por lo tanto, que el identificador de interfaz es universalmente único. Universal/Local (U/L) El séptimo bit en un identificador de interfaz

Figura 1 – Identificador de interface EUI-64 para IPv6

Figura 2 – Bit universal/local EUI-64

Page 102: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 10 CCNP: Building Scalable Internetworks

IPv6 se refiere como el bit universal/local, o bit U/L. Este bit identifica si este identificador de interfaz esta universal o localmente administrado. Fig.2

• Si el bit U/L se fija a 0, la dirección se administra localmente. El administrador de red ha eliminado la dirección manufacturada y ha especificado una dirección diferente.

• Si el bit U/L se fija a 1, el IEEE, con la designación de una ISP, ha administrado la dirección. Por lo tanto, para hacer a esta dirección una dirección administrada universalmente, nuestra dirección IPv6 0090:27FF:FE17:FC0C se convertiría realmente en 0290:27FF:FE17:FC0C. Individual/Grupal (I/G) El bit I/G es el bit de orden bajo del primer byte y determina si la dirección es una dirección individual (unicast) o una dirección grupal (multicast). Cuando se fija a 0, es una dirección unicast. Cuando se fija a 1, es una dirección multicast. Para una dirección de adaptador de red 802.x típico, los bits U/L y I/G se fijan a 0, correspondiendo a una dirección MAC unicast administrada universalmente. Debido a ciertas preocupaciones de privacidad y seguridad, la implementación de la autoconfiguración por un host puede también crear un identificador de interfaz aleatorio usando la dirección MAC como una base. Esto se considera una extensión de privacidad porque, sin él, crear un identificador de interfaz a partir de una dirección MAC proporciona la capacidad de seguir la actividad y el punto de conexión. Microsoft Windows XP actualmente soporta la implementación de esta capacidad y prefiere usar esta dirección para la comunicación saliente, porque la dirección tiene un tiempo de vida corto y se regenera periódicamente.

8.3.5 IPv6 sobre Capas de Enlace de Datos Aunque el comando redistribution está disponible para todos los protocolos de enrutamiento IP, éste se comporta diferente dependiendo de los protocolos de enrutamiento IP implicados. Sin embargo, los principios esenciales son los mismos. Por lo tanto, los ejemplos en esta sección se pueden usar como punto de partida para cualquier esquema de redistribución. La capa de enlace de datos define cómo se crean los identificadores de interfaz IPv6 y cómo el descubrimiento de vecino trata con la resolución de dirección de capa de enlace de datos. IPv6 esta definido en la mayoría de las capas de enlace de datos actuales, incluyendo el siguiente:

• Ethernet* • PPP* • High-Level Data Link Control (HDLC)* • FDDI • Token Ring • Attached Resource Computer Network (ARCNET) • Nonbroadcast multiaccess (NBMA) • ATM** • Frame Relay*** • IEEE 1394

* Cisco soporta estas capas de enlace de datos. ** Cisco soporta sólo ATM permanent virtual circuit (PVC) y ATM LAN Emulation (LANE). ***Cisco soporta sólo PVC Frame Relay.

Un RFC describe el comportamiento de IPv6 en cada una de estas capas de enlace de datos específicas, pero el

Figura 1 – Capas de enlace de datos Cisco que suportan IPv6

Page 103: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 11 CCNP: Building Scalable Internetworks

software Cisco IOS no necesariamente soporta todos ellos. Figura 1.

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

• Las direcciones multicast IPv6 se definen por el prefijo FF00::/8. El segundo octeto define el tiempo de vida (flag) y el alcance de la dirección multicast.

o El parámetro flag es igual a 0 para una permanente, o conocida, dirección multicast. Para una dirección multicast temporal, el flag es igual a 1.

o El parámetro de alcance es igual a 1 para el alcance de la interfaz (transmisión loopback), 2 para el alcance de enlace (similar al alcance link-local unicast), 3 para el alcance subnet-local donde las subredes pueden abarcar múltiples enlaces, 4 para el alcance admin-local (administrativamente configurado), 5 para el alcance de sitio, 8 para el alcance de organización (sitios múltiples), E para el alcance global. Por ejemplo, una dirección multicast que comienza con FF02::/16 es una dirección multicast permanente con un alcance link-local.

• La ID del grupo multicast consiste de los 112 bits siguientes de la dirección multicast. El multicast se usa con frecuencia en IPv6 y reeplaza al broadcast. No hay broadcast en IPv6. No hay Time to Live (TTL) en el multicast IPv6. El alcance se define dentro de la dirección.

8.3.7 Direcciones Multicast Permanentes Las direcciones multicast, FF00:: a FF0F::, estan reservadas. Dentro de ese rango, las siguientes son algunos ejemplos de direcciones asignadas. Las asignaciones son seguidas por la IANA. Fig.1

• FF02::1 - Todos los nodos en el enlace (alcance link-local).

• FF02::2 - Todos los routers en el enlace.

• FF02::9 - Todos los routers Routing Information Protocol (RIP) IPv6 en el enlace.

• FF02::1:FFXX:XXXX - multicast solicited-node en el enlace, donde XX:XXXX está 24 bits a la derecha de la dirección unicast o anycast correspondiente al nodo. (Los mensajes de solicitacion de vecino se envían en un enlace local cuando un nodo desea determinar la dirección de capa de enlace de otro nodo en el mismo enlace local, similar al Address Resolution Protocol [ARP] en IPv4.)

• FF05::101 - Todos los servidores Network Time Protocol (NTP) en el sitio (alcance site-local). El alcance multicast site-local tiene un radio asignado administrativamente y no tiene correlación directa al prefijo unicast site-local (ahora menospreciado) del de FEC0::/10.

Figura 1 - Multicasting

Figura 1 – Ejemplo de direcciones multicast permanentes

Page 104: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 12 CCNP: Building Scalable Internetworks

8.3.8 Direcciones Que No Son Únicas En casos muy raros, los 24 bits a la derecha de la dirección unicast del objetivo no son únicos en el enlace. Las direcciones multicast solicited-node se usan en IPv6 para la resolución de dirección de una dirección IPv6 a una dirección MAC en un segmento LAN. Fig.1 Por ejemplo, considere dos nodos con direcciones 2001:DB8:200:300:400:500:aaaa:bbbb y 2001:DB8:200:300:400:501:aaaa:bbbb, donde el prefijo de enlace es 2001:DB8:200:300::/64. Estos dos nodos estarían escuchando la misma dirección multicast solicited-node. Cada uno recibiría el paquete multicast, pero solamente el nodo cuya dirección completa coincida con la dirección objetivo completa del paquete multicast (embedida en el campo de datos del paquete multicast) respondería con un anuncio de vecino (el cual incluye la dirección MAC verdadera). El otro nodo recibiría el paquete multicast, pero bajo la inspección de la dirección objetivo embedida se daría cuenta que no era el receptor previsto de la petición y no respondería. Lo que sigue describe cómo funciona esta situación. El nodo A tiene esta característica:

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

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

El nodo C tiene estas características:

• Dirección 2001:DB8:200:300:501:AAAA:BBBB • Dirección multicast solicited-node FF02:0:0:0:0:1:FFAA:BBBB (la misma que la del nodo B)

1. El nodo A desea intercambiar paquetes con el nodo B. El nodo A envía un paquete de descubrimiento

de vecino a la dirección multicast solicited-node de B, FF02:0:0:0:0:1:AAAA:BBBB. Dentro del paquete, además de otros datos, está la dirección IPv6 completa que el nodo A está buscando (2001:DB8:200:300:500:AAAA:BBBB). Esta se llama la dirección objetivo.

2. El nodo B y el nodo C están escuchando la misma dirección multicast, por lo que ambos reciben y procesan el paquete.

3. El nodo B ve que la dirección objetivo dentro del paquete es su la suya y responde. 4. El nodo C ve que la dirección objetivo dentro del paquete no es la suya y no responde.

De este manera, los nodos pueden tener la misma dirección multicast solicited-node en el enlace sin causar que el descubrimiento de vecino, la solicitación de vecino, o el anuncio de vecino funcionen incorrectamente.

8.3.9 Anycast Una dirección anycast IPv6 es una dirección unicast global que se asigna a más de una interfaz. Fig.1 Cuando un paquete se envía a una dirección anycast, éste es enrutado hacia la interfaz "más cercana" que tenga esa dirección.

Figura 1 – Direcciones IPv6 unicast o anycast

Figura 1 – Anycast

Page 105: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 13 CCNP: Building Scalable Internetworks

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

• Las direcciones anycast se asignan del espacio de dirección unicast, así que son indistinguibles de la dirección unicast. Cuando está asignada a una interfaz del nodo, el nodo se debe configurar explícitamente para saber que la dirección es una dirección anycast.

• La idea del anycast en IP fue propuesta en 1993. Para IPv6, el anycast se define como la manera de enviar un paquete a la interfaz más cercana que es un miembro del grupo anycast, lo que permite un tipo de mecanismo de descubrimiento al punto más cercano.

• Hay poca experiencia con uso extenso del anycast. Pocas direcciones anycast se asignan actualmente, incluyendo el anycast router-subnet y el anycast de agente casero Mobile IPv6.

• Una dirección anycast no se debe usar como la dirección origen de un paquete IPv6.

8.3.10 Mobilidad IPv6 La movilidad es una característica muy importante en las redes hoy. Mobile IP es un estándar IETF disponible para IPv4 e IPv6. Mobile IP permite que los dispositivos móviles se muevan sin interrumpir conexiones actuales. En IPv6, la movilidad esta incorporada, lo cual significa que cualquier nodo IPv6 puede usarla según sea necesario. Sin embargo, en IPv4, la movilidad es una función nueva que debe ser agregada. Los encabezados de enrutamiento de IPv6 hacen a Mobile IPv6 mucho más eficiente para nodos extremos que Mobile IPv4. La movilidad aprovecha la flexibilidad de IPv6. Por ejemplo, el binding usa algunas opciones de encabezado (destino) que sean obligatorias para cada dispositivo IPv6. También, la movilidad IPv6 crea un encabezado de extensión de "movilidad" nuevo. La movilidad IPv6 es diferente de la movilidad IPv4 de varias maneras:

• El espacio de dirección IPv6 permite el despliegue Mobile IP en cualquier clase de entorno grande. • Debido al extenso espacio de dirección IPv6, ya no se requieren de agentes exteriores. Las

infraestructuras no necesitan un upgrade para aceptar nodos Mobile IPv6, por lo que el care-of address (CoA) puede ser una dirección ruteable IPv6 global para todos los nodos móviles.

• El modelo Mobile IPv6 aprovecha algunos beneficios del mismo protocolo IPv6. Los ejemplos incluyen encabezados de opción, descubrimiento de vecino, y la autoconfiguración.

• En muchos casos, se elimina el enrutamiento de triángulo, porque la optimización de ruta Mobile IPv6 permite que los nodos móviles y los nodos correspondientes se comuniquen directamente. El soporte para la optimización de ruta es una parte fundamental del protocolo, más que un conjunto no estandar de extensiones. El soporte también se integra en Mobile IPv6 para permitir que la optimización de ruta coexista eficientemente con los routers que realizan la filtración de ingreso. La optimización de ruta Mobile IPv6 puede operar con seguridad incluso sin asociaciones de seguridad planeadas de antemano. Se espera que la optimización de ruta pueda ser desplegada a una escala global entre todos los nodos móviles y los nodos correspondientes.

• Los nodos móviles trabajan transparentemente incluso con otros nodos que no soporten movilidad (lo mismo que en la movilidad IPv4).

• El mecanismo de descubrimiento de direcciones de agente casero dinámico en Mobile IPv6 devuelve una sola respuesta al nodo móvil. El acercamiento al broadcast dirigido usado en IPv4 devuelve replicas de cada agente casero.

• La mayoría de paquetes enviados a un nodo móvil mientras está ausente de hogar en Mobile IPv6 son envíados usando un encabezado de enrutamiento IPv6 más que encapsulación IP, reduciendo la cantidad de overhead resultante comparado a Mobile IPv4.

Page 106: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 14 CCNP: Building Scalable Internetworks

8.4 Enrutamiento IPv6

8.4.1 Descripción del enrutamiento IPv6 Similar al classless interdomain routing (CIDR) IP version 4 (IPv4), IPv6 usa enrutamiento por coincidencia de prefijo mas largo. Recientes versiones de protocolos manejan direcciones IPv6 más largas y diferentes estructuras de encabezado. Actualmente, están disponibles los protocolos de enrutamiento actualizados mostrados en Figura 1. Los siguientes son resúmenes de varios protocolos de enrutamiento usados con IPv6. Enrutamiento Estático El enrutamiento estático con IPv6 se usa y se configura de la misma manera que IPv4. Hay un requisito especifico IPv6 para RFC 2461: Un router debe ser capaz de determinar la dirección link-local de cada uno de sus routers vecinos para asegurar que la dirección objetivo de un mensaje redirect identifique al router vecino por su dirección link-local. Este requisito básicamente da a entender que no se recomienda el uso de una dirección unicast global como una dirección de siguiente-salto con enrutamiento. RIPng El Routing Information Protocol next generation (RIPng, RFC 2080) es un protocolo de enrutamiento por vector-distancia con un límite de 15 saltos que usa horizonte dividido y envenenamiento inverso para prevenir loops de enrutamiento. Fig.2 La implementación del protocolo para IPv6 incluye estas características:

• Basado en RIP versión 2 (RIPv2) IPv4 y similar a RIPv2

• Usa IPv6 para el transporte • Prefijo IPv6, dirección IPv6 de siguiente-salto • Usa el grupo multicast FF02::9, el grupo multicast de routers all-RIP, como dirección destino para

actualizaciones RIP • Actualizaciones enviadas al

puerto 521 UDP OSPFv3 La implementación de protocolo para IPv6 incluye estas características:

• Basado en OSPF versión 2 (OSPFv2), con mejoras

• Distribuye prefijos IPv6 • Funciona directamente sobre

IPv6

Figura 1 – Protocolos de enrutamiento con IPv6

Figura 2 - RIPng

Figura 3 – OSPFv3

Page 107: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 15 CCNP: Building Scalable Internetworks

• Opera como "ships in the night" con OSPFv2 Esta implementacion agrega estos atributos IPv6-especificos:

• Direcciones de 128 bits • Direcciones link-local • Múltiples direcciones e instancias por interfaz • Autenticación (ahora usa IPsec) • OSPFv3 funciona sobre un enlace más que una subred

IS-IS El soporte para dirección larga facilita la familia de dirección IPv6. El Intermediate System to Intermediate System (IS-IS) es el mismo que IPv4 con las siguientes extensiones agregadas: Fig.4

• Dos nuevos atributos Tipo, Longitud, Valor

• Alcanzabilidad IPv6 • Dirección de interfaz IPv6 • Nuevo IDS de protocolo

EIGRP El Enhanced Interior Gateway Routing Protocol (EIGRP) se puede usar para enrutar prefijos IPv6. EIGRP IPv4 funciona sobre un transporte IPv4, se comunica solamente con los pares IPv4, y anuncia solamente las rutas IPv4. EIGRP para IPv6 sigue el mismo modelo. EIGRP para IPv4 y EIGRP para IPv6 se configuran y se administran por separado. Sin embargo, la configuración de EIGRP para IPv4 e IPv6 es similar y proporciona familiaridad y continuidad operacionales. BGP Multiprotocolo Para hacer al Border Gateway Protocol version 4 (BGP4) disponible para otros protocolos de capa de red, RFC 2858 (que substituye al RFC 2283 obsoleto) define las extensiones multiprotocolo para BGP4. Fig.5 El BGP multiprotocolo se usa para permitir a BGP4 llevar la información de otros protocolos, por ejemplo, Multiprotocol Label Switching (MPLS) e IPv6.

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

Figura 4 – IS-IS

Figura 5 – Multiprotocolo BGP (MP-BGP)

Page 108: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 16 CCNP: Building Scalable Internetworks

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

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

• Los mecanismos para descubrimiento de vecinos y formación de adyacencia son idénticos.

• Las operaciones de OSPFv3 sobre modos de topologia nonbroadcast multiaccess (NBMA) y punto-a-multipunto RFC-compliant estan soportadaos. OSPFv3 también soporta otros modos de Cisco, tal como punto-a-punto y broadcast, incluyendo la interfaz.

• La inundación y el envejecimiento LSA son iguales para OSPFv2 y OSPFv3.

• OSPFv3 usa los mismos tipos de paquete básicos que OSPFv2, tales como paquetes hello, descripción de base de datos (también llamado paquete de descripción de base de datos), link-state request (LSR), link-state update (LSU), y LSA. Fig.2

Todas las capacidades opcionales de OSPF para IPv4, incluyendo soporte de circuito a pedido, not-so-stubby areas (NSSAs), y las extensiones a Multicast OSPF (MOSPF) también están soportadas en OSPF para IPv6.

8.4.4 Diferencias entre OSPFv2 y OSPFv3 Las diferencias entre OSPFv2 y OSPFv3 incluyen el siguiente:

• OSPFv3 funciona sobre un link Fig.1 o El OSPF para IPv6

funciona por enlace en vez del comportamiento IPv4 por subred IP. IPv6 usa el término "enlace" para indicar "una facilidad de comunicación o medio sobre el cual los nodos puedan comunicar en la capa de enlace." Por lo

Figura 1 – OSPFv3, similitudes con OSPFv2

Figura 2 – Mejoras del protocolo de enrutamiento

Figura 1 – Procesos por enlace OSPv3

Page 109: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 17 CCNP: Building Scalable Internetworks

tanto, los términos "red" y "subnet" usados en la especificación OSPF IPv4 son substituidos por "enlace."

o La orden network en el modo de subcomando del router OSPFv2 es reemplazado por comando de interfaz ipv6 ospf process-id area area-id [instance instance-id].

• Se usan direcciones link-local o OSPFv3 usa direcciones link-local IPv6 para identificar a los vecinos de adyacencia OSPFv3.

Por lo tanto, al configurar el comando ipv6 ospf neighbor , la dirección IPv6 usada debe ser la dirección link-local del vecino.

• Soporte para multiples instancias OSPFv3 Fig.2 o Sistemas autónomos

separados, cada uno con OSPF funcionando, usan un enlace común. Un enlace único podría pertenecer a múltiples áreas.

o OSPFv3 usa un campo nuevo, llamado Instante ID, para permitir múltiples instancias por enlace. Para tener dos instancias que hablen una con la otra, ellas deben compartir la misma instance ID. Por defecto, la instance ID esta fijada a 0.

• Direcciones multicast Fig.3 o FF02::5- Representa

todos los routers shortest path first (SPF) en el alcance link-local, equivalente a 224.0.0.5 en OSPFv2.

o FF02::6- Representa todos los designated routers (DRs) en el alcance link-local, equivalente a 224.0.0.6 en OSPFv2.

• Retiro de semánticas de dirección

o Las direcciones IPv6 ya no estan presentes en el encabezado del paquete OSPF (parte de información de la carga útil).

o Las LSAs del router y las LSAs de la red no llevan direcciones IPv6. o La ID de router, la ID de area, y la ID de estado de enlace se mantienen en 32 bits. o El DR y el backup designated router (BDR) son identificados por su ID de router y no por su

direccion IP. • Seguridad

o OSPFv3 usa Authentication Header (AH) IPv6 y encabezados de extensión Encapsulating Security Payload (ESP), en vez de la variedad de mecanismos definidos en OSPFv2.

o La autenticación ya no es parte de OSPF. Ahora es trabajo de IPv6 cerciorarse de que el nivel correcto de autentificación este en uso.

8.4.5 Tipos de LSA para IPv6 Las características LSA OSPFv3 incluyen lo siguiente:

• La LSA se compone de una ID de router, ID de área, y ID de estado de enlace. Cada una de 32 bits. Aunque se escriben en decimal con punto, no se derivan de una dirección IPv4.

• Las LSAs de router y la LSAs de red contienen solamente IDs de 32 bits. No contienen direcciones. • Las LSAs tiene alcances de inundación que definen el diámetro al que podrían ser inundados:

o Enlace local : Inundan todos los routers en el enlace. o Área : Inundan todos los routers dentro del área OSPF. o Sistema Autónomo : Inundan todas los routerss dentro del sistema autónomo OSPF entero.

Figura 2 – Soporte de instancia múltiple OSPFv3

Figura 3 – Otras diferencias entre OSPFv2 y OSPFv3

Page 110: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 18 CCNP: Building Scalable Internetworks

• OSPFv3 soporta el envio de LSAs desconocidas basado en el alcance de inundacion. Esto puede ser útil en un NSSA.

• OSPFv3 aprovecha el multicasting IPv6, al usar FF02::5 para todas los routers OSPF, y FF02::6 para el OSPF DR y el OSPF BDR.

Las dos LSAs renombradss son como sigue:

• LSAs de prefijo de Interarea para area border route rs (ABRs) (tipo 3) : Las LSAs tipo 3 anuncian redes internas a los routers en otras áreas (rutas de interarea). Lss LSAs tipo 3 puede representar una red única o un conjunto de redes sumarizadas en una publicación. Solamente los ABRs generan LSAs de sumario. En OSPF para IPv6, las direcciones para estas LSAs se expresan como prefijo, longitud de prefijo en vez de dirección, máscara. La ruta por defecto se expresa como prefijo con longitud 0.

• LSAs de router interarea para autonomous system bou ndary routers (ASBRs) (tipo 4) : Las LSAs tipo 4 publican la localización de un ASBR. Los routers que tratan de alcanzar una red externa usan estas publicaciones para determinar el mejor camino al salto siguiente. Los ASBRs generan LSAs tipo 4.

Las dos LSAs nuevas en IPv6 son como sigue:

• LSAs de enlace (tipo 8) : Las LSAs tipo 8 tiene alcance de inundación link-local y nunca están inundadas más allá del enlace con el cual están asociadas. Las LSAs de enlace proporcionan la dirección link-local del router al resto de routers unidos al enlace. Las LSAs de enlace también informan a otros routers unidos al enlace de una lista de prefijos IPv6 para asociar al enlace, y permiten que el router declare una colección de bits de opciones para asociarlos con la LSA de red que será originada para el enlace

• LSAs de prefijo intra-area (tipo 9) : Un router puede originar multiples LSAs de prefijo intra-area para cada router o red de transito, cada uno con una ID de estado de enlace única. La ID de estado de enlace para cada LSA de prefijo intra-area describe su asociación a la LSA de router o a la LSA de red. La ID de estado de enlace también contiene prefijos para redes matriz o de transito

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

8.5 Implementación y Verificación OSPFv3

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

Figura 1 – Configurando OSPFv3 con software Cisco IOS

Page 111: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 19 CCNP: Building Scalable Internetworks

parte de la red OSPFv3, las interfaces se configuran directamente para especificar que las redes IPv6 son parte de la red OSPFv3. Lo que sigue describe los pasos para configurar OSPF para IPv6: Paso 1 Complete la estrategia y planeamiento OSPF para su red IPv6. Por ejemplo, debe decidir si se requieren múltiples áreas. Paso 2 Habilite el enrutamiento unicast IPv6 usando el comando ipv6 unicast-routing . Fig.2 Paso 3 Habilite IPv6 en la interfaz usando el comando ipv6 ospf area . Paso 4 (Opcional) Configure los ajustes específicos de la interfaz OPSFv3, incluyendo área, prioridad de router, y costo de camino OSPFv3. Paso 5 (Opcional) Configure las especificaciones de enrutamiento desde el modo de la configuración de router, incluyendo la prioridad de router, sumarización de ruta, etcétera.

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

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

Figura 2 – Comando ipv6 unicast-routing

Figura 1 – Habilitando OSPFv3 en una interface

Figura 2 – Comandos OSPFv3 interface configuration

Page 112: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 20 CCNP: Building Scalable Internetworks

Para un router IPv6-only, un parámetro ID de router se debe definir en la configuración OSPFv3 como una dirección IPv4 usando el comando de configuración de router router-id router-id. OSPFv3 usa un número de 32 bits para una ID de router. La ID de router OSPFv3 se puede expresar en decimal con punto, permitiendo el fácil encubrimiento de una red OSPFv3 en una red OSPFv2 existente. La Figura 1 muestra una configuración de muestra. Si IPv4 esta configurado en el router, por el defecto, la ID de router se elige de la misma manera que OSPFv2. La dirección IPv4 más alta configurada en una interfaz loopback viene a ser la ID de router. Si no se configura las interfaces loopback, la dirección más alta en cualquier otra interfaz vendrá a ser la ID de router.

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

El costo de las rutas sumarizadas es el costo más alto de las rutas que están sumarizadas. Por ejemplo, las rutas mostradas en Figura 1 se convierten en una ruta sumarizada como se muestra en Figura 3.

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

Figura 1 – Configurando el router ID

Figura 1 – Rutas OSPFv3 antes del resumen

Figura 2 – Resumen de rutas OSPFv3

Figura 3 – Rutas OSPFv3 después del resumen

Figura 1 – Ejemplo de configuración OSPFv3

Page 113: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 21 CCNP: Building Scalable Internetworks

8.5.6 Verificación OSPFv3 Hay varios comandos show OSPFv3 comúnmente usados, incluyendo el comando show ipv6 ospf [process-id] [area-id] interface [interface]. Este comando genera la información de interfaz relacionada OSPF, según lo mostrado en Figura 1. El comando clear ipv6 ospf [process-id] {process | force-spf | redistribution | counters [neighbor [neighbor-interface | neighbor-id]]} provoca el recálculo SPF y el repoblamiento de la Routing Information Base (RIB). El comando show ipv6 ospf [process-id] [area-id] muestra información general sobre procesos OSPF, según lo mostrado en las Figuras 2 y 3. La Figura 4 enumera algunos de los campos de salida y descripciones del comando show ipv6 ospf .

Figura 1 – Verificando OSPFv3

Figura 2 – Comando show ip ospf

Figura 3 – Comando show ip ospf (cont.)

Figura 4 – Descripciones show ipv6 ospf field

Page 114: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 22 CCNP: Building Scalable Internetworks

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

Figura 1 – Comando show ipv6 ospf neighbor detail

Figura 2 – Descripción de los campos de show ipv6 ospf neighbot detail

Page 115: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 23 CCNP: Building Scalable Internetworks

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

8.6 Uso de IPv6 eIPv4

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

Figura 1 – Comando show ipv6 ospf database

Figura 2 – Comando show ipv6 ospf database (cont.)

Figura 3 – Descripción de los campos de show ipv6 ospf database

Figura 4 – Comando show ipv6 ospf database database-summary

Page 116: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 24 CCNP: Building Scalable Internetworks

Las dos técnicas más comunes para la transición de IPv4 a IPv6 son como sigue:

• Dual snack • Tuneles IPv6-over- IPv4

(6to4) Para la comunicación entre redes IPv4 e IPv6, las direcciones IPv4 se pueden encapsular en direcciones IPv6. La Figura 1 muestra un ejemplo de un mecanismo de transición e integración. Los routers 6to4 encapsulan automáticamente el tráfico IPv6 dentro de paquetes IPv4.

8.6.2 Dual Stack de Cisco IOS La mayoría de las más recientes versiones de software Cisco IOS son IPv6-ready. Tan pronto como las configuraciones básicas IPv4 e IPv6 esten completas en la interfaz, la interfaz esta dual-stackeada, y remite el tráfico IPv4 e IPv6. Usar IPv6 en un router Cisco IOS requiere que usted use el comando de configuración global ipv6 unicast-routing . Fig 1 Este comando habilita el envió de datagramas IPv6. Todas las interfaces que envían tráfico IPv6 deben tener una dirección IPv6. El comando ipv6 address [IPv6-address] [/prefix length] especifica una red IPv6 asignada a la interfaz y permite procesamiento IPv6 en la interfaz. El dual-stack es un método de integración donde un nodo tiene la implementación y conectividad a una red IPv4 y a red IPv6, y así el nodo tiene dos stacks. Fig. 2 Esta configuración se puede llevar a cabo en la misma interfaz o en múltiples interfaces. Las consideraciones para dual-stack incluyen lo siguiente:

• Un nodo dual-stack elige que stack usar basadose en la dirección destino. Un nodo dual-stack prefiere IPv6 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.

Figura 1 – Transición IPv4-a-IPv6

Figura 1 – Dual stack de Cisco IOS

Figura 2 – Dual stack

Page 117: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 25 CCNP: Building Scalable Internetworks

• Una nueva application programming interface (API) se define para soportar direcciones IPv4 e IPv6 y peticiones Domain Name System (DNS). Esta API reemplaza a las llamadas gethostbyname y gethostbyaddr . Una aplicación convertida puede hacer uso de IPv4 e IPv6. Un aplicación puede ser convertida a la nueva API mientras que todavía usa sólo IPv4.

• La experiencia previa de porting en aplicaciones IPv4 hacia IPv6 sugiere que para la mayoría de aplicaciones es un cambio mínimo en algunos lugares localizados dentro de código fuente. Esta técnica es bien conocida y se ha aplicado en el pasado para otras transiciones de protocolo. Permite mejoras graduales de la aplicación, uno por uno, a IPv6.

8.6.3 Túneles de Encubrimiento El networking usa a menudo túneles para encubrir una funcionalidad incompatible en una red existente. El tráfico IPv6 tunneling sobre una red IPv4 requiere un router de borde que encapsule el paquete IPv6 dentro de un paquete IPv4 y otro router que desencapsule. Fig.1 Este proceso le permite conectar islas IPv6 sin convertir la red entera a IPv6. El tunneling es un método de integración donde un paquete IPv6 se encapsula dentro de otro protocolo, tal como IPv4. Fig. 2 Este método de encapsulación es protocolo 41 IPv4 y tiene las siguientes características:

• Incluye un encabezado IPv4 de 20 bytes sin opciones y un encabezado IPv6 y una carga útil.

• Se considera el dual-stacking, que permite la conexión de islas IPv6 sin convertir una red intermediaria a IPv6.

• El tunneling presenta estos problemas:

o La MTU es disminuida en 20 octetos (si el encabezado IPv4 no contiene ningún campo opcional).

o Difíciltad para resolver problemas. El tunneling es una técnica integración intermedia y de transición que no seria considerada una solución final. La arquitectura IPv6 nativa debe ser la última meta.

Figura 1 – Túneles de encubrimiento

Figura 2 - Tunneling

Page 118: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 26 CCNP: Building Scalable Internetworks

8.6.4 Host Dual Stack Aislado La encapsulación puede ser hecha por routers de borde entre hosts o entre un host y una router. El ejemplo en Figura 1 muestra un host dual-stack aislado usando un túnel encapsulado para conectarse con el router de borde de la red IPv6. El tunneling no funciona si un nodo intermediario entre los dos puntos extremos del túnel, tales como un firewall, filtra hacia fuera protocolo 41 IPv4, que es la encapsulación IPv6-over-IPv4.

8.6.5 Configuración de Tunneling Si usted está configurando un túnel manualmente, usted debería configurar las direcciones IPv4 e IPv6 estáticamente. Debería realizar esta configuración en los routers en cada extremo del túnel. Fig.1 Estos routers extremos deben estar dual stackeados, y la configuración no puede cambiar dinámicamente como la red y las necesidades de enrutamiento cambian. El enrutamiento se debe configurar correctamente para enviar un paquete entre las dos redes IPv6. Los puntos extremos del túnel pueden ser innumerables, pero los puntos extremos innumerables hacen difícil la solución de problemas. La práctica IPv4 de ahorrar direcciones para puntos extremos del túnel no es más un problema.

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

Figura 1 – Host dual stack aislado

Figura 1 – Túnel configurado

Figura 1 – Ejemplo de configuración de túnel con Cisco IOS

Page 119: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

¡Error! Nombre desconocido de propiedad de documento. Modulo 8: IPV6 27 CCNP: Building Scalable Internetworks

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

• 6to4 : Usa el prefijo reservado 2002::/16 para permitir que un sitio conectado a Internet IPv4 cree y use un prefijo /48 IPv6 basado en una única dirección IPv4 ruteable o alcanzable globalmente.

• Intra-Site Automatic Tunnel Addressing Protocol (IS ATAP) : Permite que una intranet privada IPv4 (que puede o no usar direcciones RFC 1918) implemente incrementalmente nodos IPv6 sin realizar un upgrade la red.

Otro mecanismo de transición es Teredo (conocido antes como Shipworm). Este mecanismo tunelea los datagramas IPv6 dentro de UDP IPv4. Este método proporciona el uso de dirección IPv4 privada y NAT traversal IPv4.

8.6.7 Tunneling IPv6 a IPv4 y Direcciones El método tunneling 6to4 establece automáticamente la conexión de islas IPv6 a través de una red IPv4. Aplica un prefijo IPv6 válido a cada isla IPv6, lo cual permite el rápido despliegue de IPv6 en una red corporativa, sin la recuperación de la dirección de ISPs o de los registros. El método de tunneliing 6to4 requiere un código especial en los routers de borde, pero los hosts y routers IPv6 dentro del sitio 6to4 no requieren nuevas características para soportar 6to4. Cada sitio 6to4 recibe un prefijo /48, que es la concatenación de 0x2002 y la dirección IPv4 hexadecimal de router de borde. En la Figura 1, la dirección IPv4 del router de borde es 192.168.99.1. Como resultado, el prefijo de su red IPv6 es 2002:c0a8:6301::/48 ya que c0a86301 es la representación hexadecimal de 192.168.99.1. La red IPv6 puede sustituir cualquier dirección IP en el espacio después de la primera sección de 16 bits (0x2002). Cuando un paquete IPv6 con una dirección destino en el rango de 2002::/16 alcanza al router de borde 6to4, el router de borde 6to4 extrae la dirección IPv4 que esta embedida en la dirección destino 2002:: (insertada entre el tercer y sexto octetos, inclusive). El router 6to4 luego encapsula el paquete IPv6 en un paquete IPv4 con la dirección IPv4 destino que fue extraída de la dirección destino IPv6. Esta dirección IPv4 representa la dirección del otro router de borde 6to4 del sitio 6to4 destino. El router de borde destino desencapsula el paquete IPv6 en el paquete IPv4 y luego envía el paquete nativo hacia su destino final. Nota: 2002::/16 es el rango de dirección asignada específicamente a 6to4.

8.6.8 Transición de NAT-PT Para equipos heredados que no serán actualizados a IPv6 y para algunos escenarios de despliegue, las técnicas que pueden conectar nodos IPv4-only a nodos IPv6-only están disponibles. La traducción es básicamente una extensión de las técnicas NAT. La NAT-Protocol Translation (NAT-PT) es un mecanismo de traducción que se sienta entre una red IPv6 y una red IPv4. El traductor traduce los paquetes IPv6 en paquetes IPv4 y viceversa.

Figura 1 – Tunneling 6to4

Page 120: 43508804 BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks

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

• ALGs : Este método usa una estrategia dual-stack y permite a un host en un dominio IPv6-only enviar datos a otro host en un dominio IPv4-only. Requiere que todos los servidores de aplicaciones en un gateway funcionen con IPv6.

• API: Usted puede instalar un módulo específico en un stack TCP/IP de host para cada host en la red. El módulo intercepta tráfico IP con una API y lo convierte para las contrapartes IPv6.

Resumen Este módulo es una descripción de IP versión 6 (IPv6), comenzando con el porqué se convertirá en el protocolo de elección en el futuro y los beneficios de esa elección. Los cambios en el formato de dirección y el formato de encabezado de paquete fueron discutidos en detalle, incluyendo la autoconfiguración y el rol de la dirección multicast. Una parte importante del módulo fue dedicada a describir el enrutamiento IPv6. Se definieron todos los protocolos de enrutamiento posibles y el Open Shortest Path First Protocol (OSPF) fue cubierto en más detalle. También se definieron estrategias de transición para emigrar de IPv4 a IPv6. Se mostro la configuración del Cisco IOS, la verificación, y los comandos de resolucion de problemas.

Figura 1 – Transición de NAT-PT