BGP IPv6 y Redistribucion

CCNP: Building Scalable Internetworks
Mdulo 5: Optimizacin de rutas.

Descripcin
A veces, el enrutamiento dinmico en pequeas redes, implica mucho ms 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 subptimo. 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 redistribucin de rutas entre sistemas autnomos, el enrutamiento puede no ser el ms 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 informacin acerca de las redes debe ser enviada donde sea necesario y filtrada donde no lo sea. Este mdulo examina las caractersticas claves del IOS para la optimizacin del enrutamiento, incluyendo la redistribucin de rutas, control de actualizaciones de rutas y enrutamiento basado en polticas (policy-based routing). Adems, una descripcin de DHCP y como configurarlo.
5.1 Operando una red que utiliza mltiples protocolos de enrutamiento

5.1.1 Utilizando mltiples protocolos de enrutamiento
Un protocolo de enrutamiento simple trabaja bien en una red simple, pero las redes crecen y se vuelven ms complejas. Mientras lo deseable es utilizar solo un protocolo de enrutamiento en toda nuestra red, el enrutamiento multiprotocolo es comn por mltiples razones, por ejemplo fusiones entre compaas, varios departamentos administrados por varios administradores de red, ambientes multivendors o simplemente porque el protocolo de enrutamiento original no es el ms adecuado. Por ejemplo, Routing information protocol (RIP) enva peridicamente actualizaciones de la tabla de rutas completa. Como la red crece, el trfico de estas actualizaciones puede saturar la red, indicando que puede ser necesario utilizar un protocolo de enrutamiento ms escalable. Otra razn podra ser, que una compaa que utiliza EIGRP, ahora necesite de un protocolo que soporte equipos de mltiples fabricantes o que la compaa implemente polticas que especifican el uso de un protocolo de enrutamiento en particular. Utilizar un ambiente con mltiples protocolos a veces es parte del diseo de la red y los administradores deben conducir la migracin, de un protocolo a otro con atencin. En ocasiones, la transicin entre protocolos de enrutamiento se realiza gradualmente, con lo cual, mltiples protocolos se
Figura 1 Enrutamiento jerrquico

1
Modulo 5: Optimizacin de Rutas Error! Nombre desconocido de propiedad de documento. 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 topologa exacta de la red y un inventario de todos dos dispositivos tambin puede ser fundamental. Protocolos de enrutamiento de estado-enlace, como OSPF e IS-IS, requieren de una estructura de red jerrquica. Los administradores de red necesitan decidir cuales routers pertenecern al rea de backbone y como segmentaran los dems routers dentro de reas. Figura 1. EIGRP no requiere una estructura jerrquica, 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 estticas o rutas directamente conectadas, se conoce como redistribucin de rutas. Diferencias en las caractersticas de los protocolos de enrutamiento, como mtricas, distancia administrativa, caractersticas de classful o classless, pueden afectar la redistribucin.
5.1.2 Definiendo redistribucin de rutas

En las siguientes situaciones pueden ser necesarios mltiples protocolos de enrutamiento: Cuando se esta migrando desde un antiguo IGP (Interior Gateway Protocol) a un nuevo IGP. Mltiples fronteras de redistribucin 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 situacin en comn en ambientes UNIX que utilizan RIP. Algunos departamentos podran no querer actualizar sus routers para soportar un nuevo protocolo. En un ambiente de routers de varios fabricantes, se podra utilizar un protocolo de enrutamiento especfico para los equipos Cisco, como EIGRP y un protocolo de enrutamiento basado en estndares, como OSFP, para comunicar los equipos de otros fabricantes. Cuando estn siendo utilizados mltiples 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 solucin sera publicar una ruta por defecto (default route) dentro de cada protocolo de enrutamiento, pero esto no es siempre la mejor alternativa. El diseo de la red podra no permitir rutas por defecto.
Usando mltiples protocolos de enrutamiento
Si hay ms de una forma para llegar a la red de destino, los routers podran necesitar informacin acerca de las rutas en otras partes de la red para determinar el mejor camino hacia el destino. Adicionalmente, si hay mltiples caminos, un router debera contar con suficiente informacin 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, tambin conocidos como dominios de enrutamiento o sistemas autnomos, intercambiar informacin de enrutamiento a travs una caracterstica (feature) llamada redistribucin de rutas. La redistribucin es, como los routers que conectan diferentes dominios de enrutamiento pueden intercambiar y publicar informacin de enrutamiento entre diferentes sistemas autnomos. NOTA: El trmino sistema autnomo es utilizado para referirse a redes que utilizan diferentes protocolos de enrutamiento. Estos protocolos pueden ser IGPs o EGPs (Exterior Gateways Protocols), lo que es diferente a utilizar el trmino sistema autnomo cuando se refiere a BGP (Border Gateway Protocol).
5.1.3 Redistribuyendo informacin de rutas

Dentro de cada sistema autnomo, los routers mantienen un completo conocimiento de su red. El router que interconecta los sistemas autnomos se conoce como router de borde. El router de borde debe correr todos los protocolos de enrutamiento que se estn utilizando para intercambiar rutas. Cuando un router redistribuye rutas, permite que un protocolo de enrutamiento publique rutas que no son conocidas a travs del protocolo de enrutamiento. Estas rutas redistribuidas podran haber sido aprendidas por medio de diferentes protocolos, como por ejemplo, cuando se redistribuye entre EIGRP y OSPF, desde rutas estticas o mediante una conexin directa a la red. Los routers pueden redistribuir rutas estticas, rutas directamente conectadas y rutas de otros protocolos de enrutamiento. La redistribucin siempre es realizada outbound(de salida). El router que realiza la redistribucin no cambia su tabla de enrutamiento. Cuando se configura la redistribucin 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 autnomo. Como resultado, ambos sistemas autnomos conocen las rutas del otro, y cada sistema autnomo puede luego tomar decisiones de enrutamiento conociendo estas redes. Los vecinos EIGRP utilizan el listado EIGRP externo para rutear el trfico destinado a otros sistemas autnomos a travs 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 trfico.
Redistribuyendo informacin de rutas
Por esta razn, las rutas deben estar en la tabla de rutas para que puedan ser redistribuidas. Este requerimiento puede ser evidente, pero tambin puede ser fuente de confusin. Por ejemplo, si un router conoce una red va EIGRP y OSPF, solo las rutas EIGRP son colocadas en la tabla de enrutamiento porque tienen una distancia administrativa menor. Supongamos que RIP tambin 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 redistribucin se incluyen: Mtricas Distancia administrativa Capacidades de classful/classless en los protocolos Estos factores sern discutidos en varias secciones de este mdulo.
5.1.4 Utilizando mtricas

Cada protocolo de enrutamiento define una mtrica para cada ruta. El valor de la mtrica determina que tan corto es el camino hacia una red IP. Cuando un router redistribuye rutas desde un dominio de enrutamiento a otro, esta informacin no puede ser traducida de un protocolo a otro. Por ejemplo, un salto de RIP no puede ser dinmicamente recalculado a un costo OSPF por el router que realiza la redistribucin. Sin embargo, una
Modulo 5: Optimizacin de Rutas Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks 3
mtrica inicial (seed) artificialmente configura la distancia, costo, etc, para cada red externa (redistribuida) desde el punto de redistribucin. Ejemplo de mtrica inicial (seed metric). Por ejemplo, si un router de borde recibe una ruta desde RIP, sta utiliza la cuenta de saltos como mtrica. Para redistribuir esa ruta dentro de OSPF, el router debe traducir la cuenta de saltos en una mtrica de costos que el router OSPF pueda comprender. Esta mtrica inicial (seed metric), tambin conocida como mtrica por defecto, es definida durante la configuracin de la redistribucin. Cuando se establece una mtrica inicial para una ruta redistribuida, la mtrica aumenta en incrementos normales dentro del sistema autnomo. Nota: La diferencia para esta regla son las rutas OSPF E2 , las cuales permanecen con su mtrica inicial a pesar de que tan lejos sea propagadas dentro del sistema autnomo. El comando default-metric, usado en el modo de configuracin del proceso de enrutamiento, establece la mtrica inicial para todas las rutas redistribuidas. Figura 1. Utilice el comando default-metric para establecer la mtrica por defecto para la ruta o para especificar una mtrica cuando se esta redistribuyendo. Una vez que la mtrica es establecida, la mtrica se incrementa, como cualquier otra ruta. Los routers Cisco tambin permiten que la mtrica inicial sea especificada como parte del comando de redistribucin, con la opcin metric o utilizando un route-map. De cualquier forma que sea hecho, la Figura 2 - Protocolos con sus mtricas iniciales por defecto mtrica inicial debera ser configurada con un valor ms grande que la mtrica ms alta recibida dentro del sistema autnomo para ayudar a prevenir un enrutamiento poco eficiente o loops de enrutamiento. La figura 2 muestra los nombres de los protocolos con sus mtricas iniciales por defecto.
1
Figura 1 Usando mtricas seed
5.1.5 Ejemplo de mtricas iniciales

La figura 1 ilustra una mtrica 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 mtrica inicial es 30 ms el costo del enlace 100 = 130. Se debe tener en cuenta, que la mtrica de las tres redes en la nube RIP son irrelevantes en la nube OSPF, porque el objetivo es tener cada Figura 1 Redistribucin con mtricas iniciales
El concepto de rutas E2 en OSPF hace referencia a aquellas rutas que son redistribuidas dentro de OSPF. La mtrica 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. Modulo 5: Optimizacin de Rutas Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks 4
1
router OSPF reenviando trfico de las tres redes al router de borde (redistribucin). Una mtrica infinita le dice al router que la ruta es inalcanzable, y por lo tanto, no debera ser publicada. Cuando se redistribuyen rutas dentro de RIP y EIGRP se debe especificar una mtrica por defecto (default-metric). Para 2 OSPF, las rutas redistribuidas tienen una mtrica, tipo 2 , de 20, excepto para rutas BGP`s redistribuidas las cuales tienen por defecto una mtrica, tipo 2, de 1. Para IS-IS, las rutas redistribuidas tienen por defecto, una mtrica de 0. Pero a diferencia de RIP o EIGRP, IS-IS no trata la mtrica inicial 0 como inalcanzable. Se recomienda configurar una mtrica inicial para redistribucin dentro de IS-IS. Para BGP las rutas redistribuidas mantienen las mtricas del enrutamiento IGP.
5.1.6 Definiendo la distancia administrativa.

Muchos protocolos de enrutamiento tienen estructuras de mtricas y algoritmos que no son compatibles con otros protocolos. Es crtico para una red que utiliza mltiples protocolos de enrutamiento tener perfectamente integrado el intercambio de informacin de rutas y la capacidad para seleccionar el mejor camino a travs de mltiples protocolos. Los routers Cisco utilizan un valor llamado distancia administrativa para seleccionar el mejor camino cuando aprenden dos o ms 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 ms confiable al menos confiable. Algunos ejemplos de priorizacin son los siguientes: Rutas configuradas manualmente (rutas estticas) antes que las rutas dinmicamente aprendidas. Protocolos con mtricas sofisticadas sobre protocolos con mtricas ms deterministicas. Preferir External Border Gateway Protocol (EBGP) ms que otros protocolos dinmicos. 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 ms confiable y agrega la versin 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
En OSPF las rutas externas se categorizar en dos tipos, tipo 1 y tipo 2. La diferencia entre ambasdistancias en que se calcula el costo Figura 2 Ejemplo de es la forma administrativas (mtrica). 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. Modulo 5: Optimizacin de Rutas Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks 5
2
Figura 1 Distancia administrativa
prefijo es el nmero de bits configurados en la mscara de subred. Prefijos largos siempre son preferidos sobre prefijos cortos cuando se reenva un paquete, independientemente del protocolo de enrutamiento. Por ejemplo, un router tiene configurados cuatro procesos de enrutamiento (sistemas autnomos) 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 Cul de estas rutas ser instalada en la tabla de enrutamiento? Puesto que las Figura 3 Prefijo de longitud variable 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 (mscara de subred), estn considerados diferentes destinos. Por consiguiente, todas estn 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, cul ruta debera escoger el router? Esto depende del prefijo, o del nmero de bits configurados en la mscara 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). Tambin 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, tambin 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 ms 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 travs de EIGRP y a las rutas redistribuidas dentro de otras fuentes. Por defecto, en EIGRP las rutas aprendidas tienen una distancia administrativa de 90, pero Figura 2 Parmetros del comando distance
6
Figura 1 Modificando distancias administrativas
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 travs de IBGP y a las rutas aprendidas a travs de EBGP.
Figura 3 Parmetros del comando distance eigrp
5.2 Configurando y verificando redistribucin en el router.

5.2.1 Configurando redistribucin.
Configurar la redistribucin de rutas puede ser simple o complejo dependiendo de la mezcla de protocolos que se quieran redistribuir. Los comandos utilizados para habilitar la redistribucin y para asignar mtricas varan ligeramente dependiendo de los protocolos que estn siendo redistribuidos. Antes de configurar el intercambio de informacin de enrutamiento entre protocolos, se debe comprender claramente los procedimientos y requerimientos de cada uno de los protocolo de enrutamiento. La redistribucin 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 redistribucin. Adicionalmente, las rutas estticas y directamente conectadas pueden ser redistribuidas para permitirle al protocolo de enrutamiento publicar estas rutas sin utilizar una red declarada. Intercambiando informacin de enrutamiento entre protocolos de enrutamiento se conoce como redistribucin de rutas. La redistribucin de rutas puede ser en uno o dos sentidos. Las rutas en un sentido son Figura 1 Redistribucin soporta todos los protocolos 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 redistribucin 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 redistribucin, 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 mdulos dependiendo del protocolo (PDM`s) de EIGRP para IP, IPX y AppleTalk, las rutas no pueden ser redistribuidas entre ellos porque cada PDM soporta diferentes stacks.
El mtodo utilizado para configurar la redistribucin vara ligeramente entre diferentes protocolos de enrutamiento y combinaciones de protocolos. Algunos de estos protocolos requieren que se configure una mtrica durante la redistribucin, pero otras no.
Los siguientes pasos son genricos para aplicar en todas las combinaciones de protocolos: sin embargo, los comandos que son usados para implementar estos pasos pueden variar. Para la configuracin de comandos, es importante revisar la documentacin de Cisco IOS para un protocolo de enrutamiento especfico que necesite ser redistribuido. Nota: En este tpico, los trminos core y Edge son utilizados para simplificar la aclaracin. 1. Localizar los routers de borde (edge) que requieran Figura 2 Ejemplo de redistribucin configuraciones de redistribucin. Seleccionando solo un router para redistribucin se minimiza la probabilidad de crear loops de enrutamiento causados por la retroalimentacin (feedback). 2. Determinar cual protocolo de enrutamiento es el protocolo del core o backbone. Tpicamente este protocolo es OSPF, IS-IS o EIGRP 3. Determinar cual es el protocolo de borde o de backbone (en caso de migracin). Determine si todas las rutas de un protocolo de borde deben ser propagadas dentro del Core. Se deben considerar mtodos para reducir el nmero de rutas. 4. Seleccionar un mtodo para inyectar las rutas requeridas del protocolo de borde dentro del core. Un redistribucin simple utilizando redes sumarizadas en la frontera minimiza el nmero de nuevas entradas en la tabla de enrutamiento de los routers del core. Cuando se planea la redistribucin desde el borde al core, se debe considerar como inyectar la informacin de enrutamiento del core dentro del protocolo de borde. La eleccin depende de su red.
5.2.2 Redistribuyendo rutas dentro de un protocolo de enrutamiento classful.

La figura 1 muestra como configurar la redistribucin 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 nmero 1 de OSPF.
Figura 1 Configurando redistribucin en RIP
Nota: La mtrica por defecto es infinita, excepto cuando se estn redistribuyendo rutas directamente conectadas o rutas estticas. Por defecto, una ruta directamente conectada se le asigna una Figura 2 Comando redistribute mtrica de 0, y a una ruta esttica se le asigna una mtrica de 1. Sin embargo, si una ruta esttica es configurada para apuntar hacia una interfaz de salida en vez de la direccin del siguiente salto, la ruta esttica 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 parmetros del comando.
Figura 3 Parmetros del comando redistribute
5.2.3 Redistribuyendo desde protocolos classless a protocolos classful.

En la figura 1, rutas desde el proceso 1 de OSPF estn siendo redistribuidas dentro de RIP y tienen una mtrica 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 comn con la redistribucin 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 mscara de red diferente a la de la interfaz. Los
Figura 1 Redistribuyendo en RIP

9
siguientes son dos escenarios en que describe este problema. OSPF tiene una mscara mayor que RIP. En la figura 2, el router RTB esta redistribuyendo entre RIP y OSPF. El dominio OSPF tiene una mscara de red diferente (mayor en este caso) que el dominio RIP, y estn en la misma red. Por consiguiente, RIP no publica las rutas aprendidas desde OSPF y redistribuidas dentro de RIP. La mscara de subred del dominio OSPF es difcil de cambiar, en lugar de eso, se agrega una ruta esttica en el router RTB que apunte al dominio OSPF con una mscara de 255.255.255.0 pero con un salto siguiente (next-hop) hacia Null0. Luego, se redistribuyen las rutas estticas dentro de RIP, A continuacin se muestra las configuraciones necesarias para realizar esta tarea: ip route 128.103.35.0 255.255.255.0 null0 Router rip Redistribute static Default metric 1
Figura 2 Ejemplo de OSPF teniendo una mscara
Esto permite que la red 128.103.35.0 sea publicada a travs ms larga que RIP de RIP fuera de la interfaz E2/0 del router RTB. Sin embargo, el router RTB tiene rutas mas especificas aprendidas desde OSPF en su tabla de enrutamiento, con las que realiza mejores decisiones de enrutamiento. RIP tiene una mscara mayor que OSPF. En la figura 3, el dominio RIP tiene una mascara de 255.255.255.248, y el dominio OSPF tiene una mscara de 255.255.255.240. RIP no publica rutas aprendidas desde OSPF y redistribuidas dentro de RIP. Nosotros podemos agregar una ruta esttica en el router RTB que apunte hacia el dominio OSPF con una mscara de 255.255.255.248, Sin embargo, dado que esta es una mscara de red ms especifica que la mascara original de OSPF, el siguiente salto debe ser la interfaz actual del siguiente salto. Tambin necesitaremos mltiples rutas estticas para cubrir todas las direcciones de el dominio OSPF. De esta forma las rutas estticas son redistribuidas dentro de RIP. En el cdigo mostrado ms abajo, las primeras dos rutas estticas cubren el rango 128.103.32.32 255.255.255.240 del dominio OSPF. Las segundas dos rutas estticas cubren el rango 128.103.35.16 255.255.255.240 del dominio OSPF. Y las ltimas cuatro rutas estticas cubren el rango 128.130.65.64 255.255.255.240, las cuales son conocidas a travs 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 3 Ejemplo de RIP teniendo una mscara ms larga que OSPF
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 redistribucin del sistema autnomo 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 autnomo 100 de EIGRP. La figura 2 muestra la sintaxis del comando redistribute en OSPF. La figura 3 muestra los parmetros del comando. La redistribucin de OSPF puede ser limitada a un numero definido de prefijos por el comando redistribute maxium-prefix maxium {threshold} {warning-only}. El parmetro threshold (umbral) por defecto registra las advertencias un 75% del valor mximo configurado. Figura 1 Configurando redistribucin en RIP
Figura 2 Comando redistribute
Despus de alcanzar el numero mximo configurado, no mas rutas son redistribuidas. Si el parmetro warningonly es configurado, no hay limite para la redistribucin. El valor mximo 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.
11
5.2.5 Ejemplo de redistribucin de rutas dentro de OSPF.

En la figura 1, la mtrica por defecto de 20 esta siendo usada para OSPF y el tipo de mtrica es configurada como externa tipo 1. Este tipo de configuracin logra que la mtrica se incremente a medida que las actualizaciones pasen a travs de la red. El comando contiene la opcin subnet, la cual provoca que las subredes (subnets) sean redistribuidas. Figura 1 Redistribuyendo en OSPF
5.2.6 Redistribuyendo rutas dentro de EIGRP.

La figura 1 muestra como configurar la redistribucin desde OSPF al sistema autnomo 100 de EIGRP. El comando router eigrp 100 es utilizado para acceder al proceso de enrutamiento dentro del cual las rutas necesitan ser redistribuidas.
El comando redistribute le especifica que el protocolo de enrutamiento sea redistribuido dentro del sistema autnomo 100 de EIGRP. Es este caso, el proceso de enrutamiento 1 de OSPF. Nota: Cuando se redistribuye una ruta esttica o directamente conectada dentro de EIGRP, la mtrica por defecto es igual a la mtrica de la interfaz saciada. La figura 2 muestra la sintaxis del comando redistribute en EIGRP. La figura 3 muestra los parmetros del comando.
Figura 1 Configurando redistribucin en EIGRP
Figura 2 Comando redistribute
13
5.2.7 Ejemplo de redistribucin de rutas dentro de EIGRP.

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

La figura 1 muestra la sintaxis y como configurar la redistribucin desde el sistema autnomo 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 especfica el protocolo de enrutamiento que va a ser redistribuido dentro de IS-IS. En este caso, es el sistema autnomo 100 de EIGRP. La figura 2 muestra los parmetros del comando.
Figura 1 Configurando redistribucin en IS-IS
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 parmetros disponibles para escoger estas rutas. Si no se especifica un nivel, todas las rutas sern redistribuidas. Tambin se puede limitar la redistribucin dentro de IS-IS definiendo un nmero de prefijos utilizando el comando redistribute maxium-prefix maxium {threshold} {warning-only | withdraw}. El parmetro threshold por defecto registra un 75% del valor mximo configurado. Despus de alcanzar el porcentaje mximo configurado, no se redistribuyen mas rutas. El parmetro opcional withdraw tambin provoca que IS-IS reconstruya los linkstate PDU`s. que estn en los paquetes link-state sin un prefijo IP externo (redistribuido). Si el parmetro
warning-only es configurado, no hay limites en la redistribucin. El valor mximo del nmero configurado se convierte simplemente en un segundo punto donde otro mensaje warning es registrado. Este comando fue introducido en el release 12.0(25)S y fue integrado dentro del release 12.2(18)S, 12.3(4)T, y posteriores.
Figura 2 Parmetros del commando redistribute
Figura 3 Redistribucin IS-IS en otros protocolos de enrutamiento
5.2.9 Ejemplo de redistribucin de rutas dentro de IS-IS.

En la figura 1, las rutas son redistribuidas desde el sistema autnomo 100 de EIGRP dentro de IS-IS en el router A. No se les configura una mtrica, por esto esas rutas tienen una seed metric de 0. No se les configura un tipo de nivel, por ello las rutas son redistribuidas como rutas de nivel 2 (como se muestra en la tabla de enrutamiento del router B).
Figura 1 Redistribucin en IS-IS

5.2.10 Redistribuyendo rutas estticas y conectadas.

En la redistribucin de informacin entre IGP`s, a veces es necesario redistribuir informacin sobre rutas estticas. Por ejemplo, en la figura 1 una ruta esttica 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 esttica 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 estticas dentro de RIP. El comando redistribute static le dice a RIP que importe las rutas estticas y las anuncie como parte de las actualizaciones de RIP. Nota: El comando passive-interface es explicado en la siguiente leccin. Figura 1 Redistribucin de informacin esttica
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 prctica comn; sin embargo se puede realizar.
5.2.11 Verificando la redistribucin de rutas.

La figura 1 muestra la red hipottica de una compaa. La red comienza con dos dominios de enrutamiento, tambin conocidos como sistemas autnomos, uno usando OSPF y el otro usando RIP versin 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 configuracin 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 enven publicaciones de rutas fuera de la interfaz. OSPF es configurado en la interfaz serial 2. La figura 2 muestra la tabla de enrutamiento Figura 2 Tabla de enrutamiento antes de la redistribucin
16
Figura 1 Configuracin antes de la redistribucin
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 informacin 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 compaa, para esto debe: Redistribuir rutas de RIP dentro de OSPF Redistribuir rutas OSPF dentro del dominio RIP La redistribucin 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 redistribucin. RIP es redistribuido dentro OSPF. En este ejemplo, la mtrica es configurada dentro del comando redistribute. Otras opciones, dentro de las cuales se incluyen especificar una mtrica por defecto (default metric) o aceptar la mtrica por defecto de OSPF la cual es de 20.
Figura 3 Configurando la redistribucin de rutas
El comando default-metric asigna una mtrica seed a todas las rutas redistribuidas dentro de OSPF desde cualquier origen. Si se le configura un valor a la mtrica especficamente bajo el comando redistribute , este valor sobrescribe el valor de la mtrica por defecto. El valor seleccionado es 300 porque es la peor mtrica 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 mtrica de 5. El valor de 5 es escogido porque es mayor que cualquier mtrica el la red RIP.
5.2.12 Ejemplo de verificacin de redistribucin de rutas.

La figura 1 muestra la tabla de rutas de los tres routers despus de que se complet la redistribucin. 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 tambin es afectado por los cambios de la topologa 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 Figura 1 Tabla de enrutamiento despus de la redistribucin de que sean redistribuidas. Recuerde que la sumarizacin de rutas oculta informacin. Si los routers en los otros sistemas autnomos requieren seguir un cambio de topologa dentro de la red, la sumarizacin no debera ser realizada, porque oculta informacin que los routers necesitan.
17
Un caso ms tpico es que los routers necesitan reconocer los cambios de topologa solo dentro de su propio dominio de enrutamiento.. En este caso, es apropiado realizar la sumarizacin de rutas. Si las rutas son sumarizadas antes de la redistribucin, las tablas de enrutamiento de cada router son significativamente ms pequeas. La figura 2 muestra un ejemplo de las tablas de enrutamiento despus de la sumarizacin. El router B es el ms 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 sumarizacin es puesto en la interfaz que conecta al router B con el Router A. Esta direccin sumarizada es publicada en vez de subredes individuales. Una limitacin de RIP es que la mscara de subred de la direccin sumarizada debe ser mayor o igual que la mscara por defecto de la mayor red classful. Utilice el siguiente comando para RIPv2. Figura 2 Tabla de enrutamiento despus del resumen de rutas y de la redistribucin RouterA(config)# interface s0 RouterA(config-if)# ip summary-address rip 10.0.0.0 255.252.0.0
Nota: Esta sumarizacin incluye 10.0.0.0, la cual es aceptable en este caso porque esta directamente conectada con una mscara mayor. Router C, OSPF: Se debe realizar la sumarizacin de OSPF en un router de borde (ABR) o en un router de borde del sistema autnomo (ASBR). Crear otra rea de OSPF que incluya las cuatro subredes a ser sumarizadas. Colocar el comando para la sumarizacin bajo el proceso OSPF en el router C, el cual se convierte en ABR. La sumarizacin 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.
18
5.2.13 Problemas de distancia administrativa con la redistribucin

El siguiente ejemplo describe una red utilizando mltiples 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 ms 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 va RIPv2 y tambin va OSPF, la ruta OSPF es usada e insertada dentro de la tabla de enrutamiento porque OSPF tiene una distancia administrativa ms baja que RIPv2, aun cuando el camino a travs de OSPF pueda ser mas largo (peor).
Figura 1 Redistribucin usando la distancia administrativa
La figura 2 muestra las configuraciones para los routers P3R1 y P3R2. Estas configuraciones redistribuyen RIP dentro de OSPF y OSPF dentro de RIP en ambos routers. La redistribucin dentro de OSPF configura una mtrica 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 tambin configura una mtrica de tipo 1 para que la mtrica de las rutas contine aumentando y el router redistribuya la informacin de la subred. La redistribucin dentro de RIP configura una mtrica de 5 por defecto tambin para protegerse contra el feedback de rutas. La figura 3 muestra la tabla de enrutamiento en el router P3R2 Figura 2 Redistribucin usando la distancia administrativa (cont.) despus de ocurrida la redistribucin. 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 redistribucin 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 travs del core por los puntos duales de redistribucin mutua.
19
OSPF es informado acerca de las rutas de RIP mediante la redistribucin. OSPF luego publica las rutas RIP va rutas OSPF a sus routers vecinos. El router vecino tambin es informado acerca de las mismas rutas va 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 informacin acerca de las rutas internas (RIP nativas) desde ambos OSPF y RIP. El prefiere las rutas OSPF porque OSPF tiene una distancia administrativa ms baja. Sin embargo, las rutas RIP no aparecen en la tabla de enrutamiento.
Figura 3 Redistribucin usando la distancia administrativa (cont.)
Devuelta al diagrama de topologa para trazar algunas rutas. La redistribucin 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 ms directo va 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 Solucin de la distancia administrativa con redistribucin

Hay un nmero de formas para corregir los problemas de seleccin de caminos en un ambiente de redistribucin. 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. Especficamente, 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 1 Solucin a la redistribucin
20
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). Ntese que ambos routers de redistribucin 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 estn 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 configuracin del proceso de enrutamiento porque la distancia administrativa debera ser cambiada para estas rutas cuando ellas sean publicadas por OSPF, no por RIP. Usted necesita configurar el comando distance en ambos routers de redistribucin porque cualquiera puede tener rutas suboptimas, dependiendo de cual router de redistribucin enve primero las actualizaciones OSPF acerca de las redes RIP al otro router de redistribucin. La salida en la figura 2 muestra que el router P3R2 ahora retiene los caminos ms directos hacia las redes internas aprendidas desde RIP. Sin embargo, alguna informacin de enrutamiento se pierde con esta configuracin. 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.
Figura 2 Solucin a la redistribucin (cont.)
Ese ejemplo ilustra la importancia de conocer su red antes de implementar la redistribucin y examinar detalladamente cuales rutas son seleccionadas en los routers despus de que se habilita la redistribucin. Preste particular atencin 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 caracterstica ms importante de usar la distancia administrativa para controlar la preferencia de rutas es que no se perder informacin del camino. La informacin de OSPF permanecer en la base de datos de OSPF. Si es perdido el camino primario, el camino a travs de OSPF puede reafirmarse el mismo, manteniendo conectividad con esa red.
5.3 Controlando el trfico de actualizacin de enrutamiento.

5.3.1 Controlando actualizaciones de rutas.
Cisco IOS ofrece varias tcnicas para controlar las actualizaciones de enrutamiento. Algunos de estos mtodos incluyen los siguientes:
Passive interfaces (Interfaces pasivas) Distribute list (Listas de redistribucin) Policy routing usando route maps (Polticas de enrutamiento utilizando mapas de rutas)
No hay un tipo de filtro que sea apropiado para cada situacin. Sin embargo, entre mas tcnicas estn a tu disposicin, 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 configuracin del router habilita RIP en todas las interfaces. Por consiguiente, las interfaces E0, E1, S0 y S1 participan todas en el intercambio de informacin 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 podra utilizar un sniffer de paquetes para capturar las actualizaciones de rutas y recopilar informacin 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 travs de esa interfaz. Figura 3 Parmetros del commando passive-interface Se puede utilizar el comando passiveinterface con la mayora 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.
Figura 1 Topologa con una interface pasiva
Figura 2 Comando passive-interface
Paso 2. Determine la interfaz a travs de la cual usted no quiere que sea enviado trafico Figura 4 Topologa con una interface pasiva de actualizaciones de enrutamiento. (o mensajes hello para protocolos de enrutamiento de estado-enlace (link-state) y EIGRP). Paso 3. Configure el router utilizando el comando passive-interface, la figura 2 y 3 muestran los parmetros del comando.
La figura 4 muestra la configuracin requerida en RIP para configurar la interfaz E0 como pasiva. E0 recibe ahora actualizaciones, pero no las enva. 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 relacin de vecindad con los otros routers alcanzables a travs de esa interfaz. Si no se encuentra otro router en una interfaz, no se enva otro tipo de trfico EIGRP (como se muestra en la figura 6). Usando el comando passive-interface en un router corriendo un protocolo de enrutamiento estado-enlace tambin se previene que el router establezca adyacencias de vecindad con otros routers que estn conectados al enlace especificado en el comando. El router no enva mensajes hello a la interfaz especificada. Por lo tanto, no se pueden establecer adyacencias con los vecinos porque el protocolo hello verifica que exista comunicacin bidireccional entre los routers. Especficamente, en OSPF, la direccin de la interfaz que se especifica como pasiva aparece como red stub en el dominio OSPF. Figura 7. Informacin de enrutamiento de OSPF nunca es enviada o recibida a travs de la interfaz especificada. En IS-IS la direccin IP especificada es anunciada sin estar actualmente corriendo IS-IS en esa interfaz. La figura 8 resume el comportamiento de la caracterstica passive-interface con los comunes IGP`s.
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
5.3.3 Consideraciones de interfaces pasivas.

Con proveedores de servicios de Internet (ISPs) y redes de grandes empresas, muchos de los routers de redistribucin tienen mas de 200 interfaces. Antes de la introduccin del feature passive-interface por defecto en los releases 12.0 del Cisco IOS, la solucin 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 requera adyacencias. En algunos casos, esto comprenda entrar 200 o ms sentencias passiveinterface. Para resolver esta escalabilidad en la configuracin, el comando passive-interface default puede ser usado para setear todas las interfaces como pasivas. Se puede habilitar el enrutamiento en una interfaz cando se requiera utilizando el comando no passive-interface.
En la figura 1, los routers A y B corren RIP y tienen una declaracin 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 passiveinterface fue usado para habilitar la interfaz en donde se deseaba RIP. El router B tiene solo dos interfaces, as que el comando passive-interface fue usado en la interfaz que no participa en RIP.
Figura 1 Comado passive-interface default
Es importante comprender como esta configuracin afecta el intercambio de informacin 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 va 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 travs del router B. En est situacin, se deberan configurar filtros de rutas.
5.3.4 Configurando filtrado de rutas usando distribute lists.

La tcnica 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 informacin sea anunciada. Si se busca bloquear solo el anuncio de ciertas rutas especificas, por ejemplo, se podra utilizar como solucin para prevenir loops de enrutamiento cuando se implementa redistribucin de rutas en dos sentidos con puntos de redistribucin duales. Algunas formas para controlar o prevenir actualizaciones de rutas dinmicas son las siguientes: Figura 1 Controlando el trfico de actualizacin de enrutamiento Interfaces pasivas: previenen que todas las actualizaciones de enrutamiento sean enviadas por una interfaz. Para EIGRP, OSPF e IS-IS, este mtodo incluye los paquetes hello. Rutas por defecto (default routes): Instruye al router que enve paquetes hacia la ruta por defecto si no tiene una ruta hacia el destino. Por lo tanto, no son necesarias las actualizaciones dinmicas de enrutamiento acerca de redes remotas.
Rutas estticas: 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 informacin de enrutamiento puede ser obtenida a travs de la redistribucin de rutas, la cual no involucra a una interfaz o a todas. Adicionalmente, ACLs no afectan el trfico que es originado por el router, aplicando una distribute list bajo el protocolo de enrutamiento. La ACL permitira las redes que sern anunciadas o redistribuidas y denegara las redes que permanecern ocultas. El router luego aplica la ACL a la actualizacin 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 Redistribucin 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 trfico de las actualizaciones de enrutamiento en cualquier protocolo definiendo una ACL y aplicndola al protocolo de enrutamiento especifico. Se puede utilizar el comando distribute-list y enlazarlo con una ACL para completar el filtrado del trfico 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 especfica desde los routers vecinos que utilizan el mismo protocolo de enrutamiento o de salida en la interfaz hacia dichos routers. Una distribute list permite tambin filtrar las rutas redistribuidas desde otros protocolos de enrutamiento o fuentes. Para configurar una distribute list utilizando una ACL, utilice el siguiente procedimiento:
Figura 1 Configurando distribute-list
Figura 2 Parmetros del comando distribute-list
Paso 1. Identifique la direccin de red que se quiera filtrar y cree una ACL. Paso 2. Determine si se quiere filtrar el trfico de entrada en una interfaz o de salida, o las rutas que estn siendo redistribuidas desde otra fuente.
Paso 3. Use el comando distribute-list out para asignar la ACL con el objeto de filtrar las actualizaciones de enrutamiento salientes o para asignarla a las rutas redistribuidas dentro del protocolo. La figura 2 muestra los parmetros 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 estn colocadas en una base de datos pero no en la tabla de enrutamiento. La figura 3 muestra los parmetros del comando. La figura 4 muestra un ejemplo de una distribute-list aplicada de salida. La distribute list denegar la publicacin 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 Parmetros del comando distribute-list in
Figura 4 Usando filtros de salida
Figura 5 Usando filtros de entrada
26
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 enva por la interfaz serial 0 a otros routers que corren EIGRP. La ACL 7 es una ACL estndar que le permite a la informacin de enrutamiento solo ver la red 172.16.0.0. La sentencia implcita deny any en el final de la ACL previene que sean publicadas actualizaciones de enrutamiento acerca de cualquier otra red. Como resultado, la red 10.0.0.0 permanece oculta del resto de la red.
Figura 1 Filtrando actualizaciones de enrutamiento con una lista de distribucin
5.3.7 Controlando la redistribucin con distribute lists.

Con redistribucin mutua, usar una distribute list ayuda a prevenir el feedback de rutas, lo cual tambin 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 redistribucin en dos vas 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 podra ocurrir si fuera configurado otro punto de redistribucin (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 dems. 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 redistribucin desde OSPF a RIP es referida por la ACL 3. El router D tendr una configuracin similar al router B.
Figura 1 Controlando la redistribucin con listas de distribucin
Una distribute list oculta informacin de red, lo cual podra ser considerado una desventaja en algunas circunstancias. En una red con caminos redundantes, la finalidad de utilizar una distribute list podra 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 podran no conocer otras formas para alcanzar las redes filtradas.
27
5.4 Policy-based Routing (Enrutamiento basado en polticas).

5.4.1 Definiendo Route maps.
Los route maps son similares a complejas ACLs, pero mucho ms poderosas. Son mucho ms flexibles que las ACLs y pueden ayudar en situaciones en que no es posible solucionarlas con ACLs. Los route maps tambin pueden usar complejas ACLs. Figura 1. Ellas permiten que condiciones sean probadas contra un paquete o ruta usando el comando match. Si la condicin hace match, se toma una accin para modificar los atributos del paquete o ruta. Estas acciones son especificadas por el comando set. Una coleccin de sentencias de mapas de rutas que tengan el mismo nombre Figura 1 Route maps es considerado como un route map. Dentro de un route map, cada sentencia es numerada y puede ser editada manualmente. Una sentencia en un route map es anloga a una lnea en una ACL. Especificando la condicin match en un route map es similar a especificar la direccin fuente y destino, y la mscara 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 propsitos. Algunas de las aplicaciones ms comunes para los route maps son las siguientes: Filtrado de rutas durante la redistribucin: La redistribucin requiere casi siempre algn tipo de filtro de ruta. Aunque una distribute list puede ser usada para este propsito, los route maps ofrecen y agregan beneficios de manipular las mtricas de enrutamiento a travs del uso de los comandos set. Policy-based routing (PBR): los route maps pueden ser usados para coincidir con la direccin de origen o destino, tipo de protocolo o aplicacin del usuario final. Cuando ocurre una coincidencia, el comando set describe la interfaz o direccin del siguiente salto a la cual el paquete debera ser enviado. PBR permite al operador definir una poltica de enrutamiento diferente que la basada en el destino utilizando la tabla de enrutamiento. BGP: los route maps son la herramienta primaria para implementar polticas 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 manipulacin de los atributos para los caminos de BGP.
28
5.4.3 Operacin de los route maps.

Los route maps operan de manera similar a las ACLs. Cuando se determinan cuales rutas sern redistribuidas desde un protocolo al siguiente, el router revisa cada ruta contra el route map, comenzando desde arriba. Figura 1. Cada lnea tiene un nmero de secuencia, ambos para procesarlos de arriba hacia abajo y con el propsito de editarlos. Las lneas pueden ser agregadas o removidas de un route map cuando se requiera un cambio. Cada lnea tiene una sentencia permit o deny. Si una ruta coincide con la sentencia y la sentencia es permit, el router configura la mtrica u otra condicin definida y permite la redistribucin 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 mtodo. Las rutas son revisadas lnea por lnea 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 implcita al final del route map.
Figura 1 Operacin con Route map
Figura 2 Operacin con Match
Las coincidencias de las sentencias son complejas en un route map. Figura 2. Mltiples criterios de coincidencias en la misma lnea son procesados con un OR lgico. Criterios de seleccin separados pueden ser aplicados verticalmente bajo un route map. En este caso, cada match utiliza un AND lgico. Un route map puede consistir de mltiples sentencias. Las sentencias son procesadas de arriba hacia abajo, como en las ACL. La primera coincidencia encontrada para una ruta es aplicada. El nmero de secuencia es usado para insertar o borrar una sentencia en un lugar especfico del route map. El comando match define la condicin a ser revisada. El comando set define la accin a seguir si hay una coincidencia. Una sentencia que coincida puede contener mltiples condiciones. Por lo menos una condicin de las sentencias declaradas debe ser cierta para que la sentencia sea considerada como coincidente (OR lgico). Un route map puede contener mltiples sentencias coincidentes. Todas las declaraciones en un route map deben ser verdaderas para considerar que el route map hace match (AND lgico). El nmero de secuencia especifca el orden en el cual las condiciones son validadas. Por ejemplo, si hay dos sentencias en un route map llamadas MYMAP, una con un nmero de secuencia 10 y otra con un nmero 20, la secuencia 10 es verificada primero. Si la condicin de la secuencia 10 no concuerda, se contina con la sentencia 20.
Como en una ACL, existe una sentencia deny any al final del route map. Las consecuencias de este deny implcito 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 redistribucin. La figura 1 y la 2 muestran las opciones del comando. Cuando es utilizado para filtros en la redistribucin, un route map es aplicado al proceso de redistribucin de rutas agregando la sentencia route-map maptag al final del comando redistribute protocol.
Figura 1 Comando route-map
Figura 2 Parmetros del comando route-map
5.4.5 El comando match.

El comando match es aplicado dentro de un route map. Figura 1. La figura 2 muestra algunos de los parmetros del comando match. Los parmetros representan una lista general de los criterios a comparar. Algunos criterios son utilizados por polticas BGP, algunos por PBR, y otros por filtros de redistribucin. Figura 1 Comando match
30
Figura 2 Parmetros del comando match
5.4.6 El comando set.

El comando set es usado dentro de un route map para cambiar o agregar una caracterstica, como la mtrica, a cualquier ruta que coincida con algn 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 propsitos de redistribucin. La tabla incluye opciones para redistribucin y PBR. Figura 1 Comando set
Figura 2 Parmetros del comando set
5.4.7 Implementando route maps con redistribucin.

En la figura 1, RIPv1 esta siendo redistribuido dentro de OSPF 10. Un route map llamado redis-rip es atachado al comando redistribute rip.
31
El nmero de secuencia 10 del route map espera una direccin 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 mtrica de 500 y configura la nueva ruta OSPF como externa tipo 1. Si no hay match con la lnea 10, se mueve a la lnea 20. Si hay match con la ACL 37, no permite que la ruta sea redistribuida dentro de OSPF porque el nmero de secuencia 20 es un deny. Si no hay match con el nmero 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 mtrica de 5000 y como mtrica 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 poltica es reforzada como sigue: Rutear el trfico hacia Internet desde la red 192.168.1.0/24 por el ISP1 Rutear el trfico 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 polticas. El route map ISP1 coincide con la ACL 1 y enruta el trfico saliente por la interfaz s0 hacia el ISP1. El route map ISP2 coincide con la ACL 2 y enruta el trfico 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 informacin de enrutamiento durante la redistribucin.
Figura 1 Route maps con commandos de redistribucin
Figura 2 Ejemplo de poltica de enrutamiento
Figura 3 Configurando un route map
Figura 4 Aplicando un route map a una interface

32
5.5 DHCP
5.5.1 El propsito del DHCP.
DHCP es estructurado en el protocolo de servidor Bootstrap (BOOTP) y puerto BOOTP tambin 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 automticamente 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 debera ser implementado el DHCP en una red empresarial.
Figura 1 DHCP
5.5.2 Comprendiendo el funcionamiento del DHCP.

Un dispositivo que utilice Cisco IOS puede actuar como servidor DHCP, cliente, o agente relay. La figura 1 muestra los pasos que ocurren cuando un cliente DHCP solicita una direccin IP a un servidor DHCP: 1. El host enva un mensaje broadcast DHCPDISCOVER para localizar al servidor DHCP. 2. Un servidor DHCP ofrece parmetros de configuracin como una direccin IP, nombre de dominio, un servidor DNS, gateway y el arriendo de una direccin IP al cliente a travs de un mensaje unicast DHCPOFFER. Tambin pueden ir incluidas opciones para Telefona IP como la opcin 150, la cual es utilizada para la Figura 1 DHCP configuracin de telfonos IP mediante TFTP. 3. El cliente devuelve una solicitud formal para la direccin ofrecida al servidor DHCP en un mensaje broadcast DHCPREQUEST. 4. El servidor DHCP confirma que la direccin IP ha sido asignada al cliente devolvindole un mensaje unicast DHCPACK. Un cliente DHCP puede recibir ofertas de mltiples servidores y puede aceptar una de estas ofertas. Sin embargo, el cliente usualmente acepta la primera oferta que recibe. Tambin, la oferta del servidor DHCP no garantiza que la direccin IP sea asignada al cliente. El servidor usualmente reserva la direccin hasta que el cliente tenga la opcin de aceptar formalmente la direccin. DHCP soporta tres posibles mecanismos de asignamiento:
Manual: El administrador de red asigna una direccin IP a una direccin MAC especfica. DHCP enva la direccin asignada al host. Automtica: La direccin IP es permanentemente asignada al host. Dinmica: La direccin IP es asignada al host por un tiempo limitado o hasta que expire el periodo de arrendamiento. El mecanismo soporta la reutilizacin automtica de direcciones cuando el host al cual se le asign la direccin 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 caractersticas 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 importacin o auto configuracin de las opciones del servidor DHCP Configurar las opciones de informacin del agente relay en mensajes BOOTREPLY Configurar la informacin de polticas de reenvo del agente relay Habilitar la caracterstica de DHCP smart-relay No todas las opciones son cubiertas en detalle. Informacin adicional de estas caractersticas adicionales se encuentra disponible en el sitio Web de Cisco. La figura 1 identifica la mayora 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 direccin MAC. Tambin existen opciones adicionales con la implementacin de la funcin de DHCP relay. Antes de configurar la caracterstica de DHCP server, se deberan completar las siguientes tareas:
Figura 1 Configurando un servidor DHCP
Figura 2 Comandos y parmetros del servidor IOS DHCP

34
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 estticas asignadas dentro del rango dinmico). 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 telefona IP, como opcin 150 Paso 4. Decidir un nombre de dominio DNS. Los dispositivos que utilizan Cisco IOS pueden ser configurados tambin como clientes DHCP y agentes DHCP relay. La figura 3 muestra un ejemplo de la configuracin 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 direccin desde el servidor DHCP ms cercano. El router determina como entregar la direccin basndose en la direccin IP de la interfaz del router.
Figura 3 Ejemplo de configuracin DHCP
Figura 4 Ejemplo DHCP
35
5.5.4 Importando DHCP y auto configuracin.

En el pasado, los servidores de Cisco IOS eran configurados separadamente en cada dispositivo con todos los parmetros y opciones especificas para cada caso. El software IOS ha sido revisado para permitir que servidores DHCP de Cisco IOS puedan ser configurados importando parmetros desde un servidor centralizado. La configuracin mostrada en la figura 1 entrega un ejemplo de la sintaxis parcial de los comandos para esta caracterstica.
Figura 1 Ejemplo DHCP
5.5.5 Configurando el cliente DHCP.

Un dispositivo Cisco IOS puede ser configurado para ser un cliente DHCP y obtener dinmicamente una direccin 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 especfico para una interfaz individual.
Figura 1 Cliente DHCP
5.5.6 El IP helper address.

Un agente DHCP relay es cualquier host que reenva 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 reenva las solicitudes y las replica entre servidores y clientes cuando no estn 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.
Figura 1 Helper address
Los clientes DHCP utilizan broadcast UDPs para enviar el mensaje inicial DHCPDISCOVER, porque ellos no tienen informacin acerca de la red a la cual estn 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.
36
El comando ip helper-address provoca que los broadcast UDP cambien a un mensaje unicast y sean reenviados por otra interfaz a una direccin IP especificada por el comando. Figura 2. El agente de relay configura la direccin del gateway (campo giaddr del paquete DHCP) y, si esta configurado, agrega la informacin de las opciones del agente relay (como la opcin 82) en el paquete y lo reenva al servidor DHCP. La respuesta desde el servidor es reenviada de vuelta al cliente despus de remover la opcin 82.
Figura 2 Por qu se usa helper address?
5.5.7 Configurando el IP helper address.

La figura 1 ilustra la utilizacin del comando ip helper-address para implementar el agente DHCP relay. El comando habilita el reenvo 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 caracterstica de acuerdo a los requerimientos de la red.
Figura 1 Comado ip helper address
5.5.8 Personalizando los servicios de reenvo UDP.

Los siguientes son los puertos bien identificados que por defecto reenvan 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 Figura 1 Personalizando los servicios de envio UDP Usted puede eliminar puertos del reenvo de servicios con el comando no ip forward-protocol, y agregar puertos con el comando ip forwared-protocol.
37
El ejemplo de la configuracin mostrado en la figura 1 no reenva los puertos de NetBIOS y Time. Sin embargo, es agregado el puerto 8000 en la lista de reenvos, 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 subopcin y el ID remoto de la subopcin y se los reenva 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 enva como broadcast a la red. 2. El agente DHCP relay intercepta el paquete broadcast con solicitud DHCP y le inserta la informacin de la opcin 82 al paquete. La opcin del relay agent contiene informacin relacionada con la subopcin. 3. En agente DHCP relay enva como unicast el paquete DHCP al servidor DHCP. 4. El servidor DHCP recibe el paquete y usa la subopcin para asignar la direccin IP y otros parmetros de configuracin y le reenva el paquete de vuelta al cliente. 5. El campo subopcin 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
38
5.5.10 Verificando los servicios de DHCP relay

La figura 1 lista los comandos de verificacin DHCP. La figura 2 describe los comandos y parmetros.
Figura 1 Comandos de verificacin DHCP
Figura 2 Descripcin de los comandos de verificacin y parmetros de DHCP
39
Resumen.
Este mdulo cubri la redistribucin de rutas IP y el control, y redistribucin de las actualizaciones de rutas. Tambin 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 propsitos definidos por las polticas de la empresa. Aunque DHCP no es una tcnica cierta para la optimizacin de rutas, es una caracterstica 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.
40
Mdulo 6: BGP
Descripcin
Los protocolos que corren en dentro de una empresa son llamados interior gateway protocols (IGPs). Ejemplos de IGPs incluyen RIP versin 1 y 2, EIGRP y OSPF Los protocolos que corren fuera de una empresa, o entre sistemas autnomos son llamados exterior gateway protocols (EGPs). Tpicamente, EGPs son usados para intercambiar informacin de enrutamiento entre proveedores de servicio de Internet (ISPs) Desde 1994, Border Gateway Protocol versin 4 (BGP4) ha llegado a ser el protocolo de enrutamiento del core de Internet. Todas las anteriores versiones son consideradas obsoletas. Ms ISPs deben usar BGP para establecer enrutamiento entre unos y otros Las empresas tpicamente emplean rutas por defecto para alcanzar a sus proveedores de servicio. Sin embargo, en algunos casos, BGP puede ser ms conveniente usar entre un sistema autnomo de un cliente y la red del proveedor; por ejemplo en el caso de que una organizacin tenga mltiples conexiones hacia el proveedor de servicio. Para ayudar a controlar seleccin de caminos especficos, BGP es una efectiva alternativa a usar rutas por defecto. Entendiendo las importantes caractersticas 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 configuracin y la verificacin de BGP para la conectividad de empresas ISPs.
6.1 BGP Conceptos y Terminologa

6.1.1 Usando BGP en la red de la empresa
El Internet es una coleccin de sistemas autnomos que son interconectados para permitir la comunicacin entre ellos. BGP provee el enrutamiento entre estos sistemas autnomos. Figura 1. Las empresas que quieren conectarse al Internet lo hacen a travs de uno o ms ISPs. Si una organizacin tiene nicamente una conexin a un ISP, ellos probablemente no necesitan utilizar BGP. En lugar de esto, ellos deberan utilizar una ruta por defecto. Sin embargo, si ellos tienen mltiples conexiones a un o a mltiples 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 informacin de enrutamiento dentro de un sistema autnomo RIP, IGRP, OSPF, IS-IS, y EIGRP son IGPs. EGP: intercambia informacin de enrutamiento entre diferentes sistemas autnomos BGP es un EGP.
Figura 1 Sistemas autnomos
Modulo 7: IP Multicasting Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks
BGP es un protocolo de enrutamiento entre dominios (IDPR), tambin conocido como EGP. BGP4 es la ltima versin y es definido en el RFC 4271. Segn lo indicado en este RFC, la clsica definicin de un sistema autnomo es Un set de routers bajo una sola administracin tcnica, utilizando un IGP y mtricas comunes para rutear paquetes dentro del sistema autnomo, y usando un protocolo de enrutamiento de sistemas autnomos (tambin llamado EGP) para determinar como rutear paquetes a otros sistemas autnomos. Los sistemas autnomos tambin pueden utilizar ms que un IGP, potencialmente con varias clases de mtricas. Desde el punto de vista de BGP, la ms importante caracterstica de un sistema autnomo es que este aparece a otros sistemas autnomos tener un solo plan de enrutamiento interior coherente y presenta un cuadro constante de destinos accesibles. Todas las partes de un sistema autnomo deben conectarse entre si. Cuando BGP esta corriendo entre ruteadores de diferentes sistemas autnomos, este es llamado BGP externo (EBGP). Cuando BGP esta corriendo entre ruteadores en el mismo sistema autnomo, 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 va EBGP, y esta tambin corriendo IBGP en todos sus routers. AS 65500 aprende sobre las rutas y escoge la mejor va para cada uno basado en la configuracin de los ruteadores en el sistema autnomo y las rutas BGP pasadas de los ISPs. Si una de las conexiones hacia el ISP se pierde, el trfico es enviado a travs 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 travs del AS 65500 usando IBGP y es errneamente anunciada al ISP-B, el ISP-B puede decidir que el mejor camino para Figura 2 Usando BGP para conectar a Internet conseguir la red 172.18.0.0/16 es a travs del AS 65500, en lugar de ir a travs del Internet. AS 65500 debera entonces ser considerado un sistema autnomo de transito, lo cual es una muy indeseable situacin. AS 65500 quiere tener una conexin de redundancia al Internet, pero no quiere actuar como un sistema autnomo de transito entre dos ISPs. Una cuidadosa configuracin de BGP es requerida para evitar esta situacin.
6.1.2 BGP Opciones de Multihoming

Multihoming es cuando un sistema autnomo tiene ms que una conexin al Internet. Las dos tpicas razones para multihoming son las siguientes: Figura 1. Para incrementar la confiabilidad de las conexiones al Internet: Si una conexin falla, la otra conexin permanece disponible. Para incrementar el funcionamiento de la conexin: El mejor camino puede ser utilizado para asegurar los destinos. Los beneficios de BGP son evidentes cuando un sistema autnomo tiene mltiples conexiones EBGP hacia uno o mltiples sistemas autnomos. Mltiples conexiones permite una Figura 1 - Qu es el Multihoming? organizacin para tener conexiones redundantes al Internet para poder mantener conectividad si un enlace llega a estar indisponible.
Modulo 7: IP Multicasting Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks 2
Una organizacin puede ser multihomed a un solo ISP o a mltiples 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 autnomo pierda conexin hacia el Internet. Tener conexiones a mltiples ISPs, una organizacin gana los siguientes beneficios: Redundancia con multiples conexiones No atarse en dentro de una poltica de enrutamiento de un solo ISP Mas caminos a una misma red para una mejor manipulacin de la poltica Un sistema autnomo multihomed puede correr EBGP con sus vecinos externos y debe tambin correr IBGP internamente. Si una organizacin desea realizar Multihoming con BGP, hay tres comunes maneras para hacerlo: Cada ISP pasa nicamente una ruta por defecto al sistema autnomo: La ruta por defecto es pasada a las rutas internas. Cada ISP pasa nicamente una ruta por defecto y abastece rutas especificas al sistema autnomo: 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 autnomo: Todas los routers internos en la trayectoria de transito corren BGP y pasan estas rutas entre ellos
6.1.3 Opcin 1: Ruta por defecto de todos los proveedores

Recibir nicamente una ruta por defecto de cada ISP requiere pocos recursos dentro del sistema autnomo, ya que una ruta por defecto es usada para alcanzar cualquier destino externo. El sistema autnomo enva todas estas rutas a los ISPs, los cuales los procesan y los pasan sobre otros sistemas autnomos. Si un router en el sistema autnomo aprende sobre mltiples rutas por defecto, el protocolo de enrutamiento local instala la mayor ruta en la tabla de enrutamiento, la cual es la que tiene la mtrica 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 autnomo, 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 autnomo es decidida fuera del sistema autnomo (dentro de los ISPs y otros sistemas autnomos). Los ISPs regionales que tienen mltiples conexiones hacia ISPs nacionales o internacionales comnmente implementan esta opcin. Los ISPs regionales no utilizan BGP para manipulacin de trayectorias. Sin embargo, ellos requieren la habilidad de aadir nuevos clientes y redes de clientes utilizando BGP. Si el ISP regional no usa BGP, cada vez que el ISP regional aada un nuevo set de redes, los clientes deben esperar hasta que el ISP nacional aada esta red a sus procesos de BGP y coloquen rutas de sealizacin esttica hacia el ISP regional. Corriendo EBGP con el nacionales o internacionales ISPs, el ISP regional necesita aadir nicamente las nuevas rutas de los clientes en el proceso BGP. Estas nuevas redes automticamente se propagarn a travs del Internet con un mnimo de retardo. Un cliente que escoge recibir rutas por defecto de todos los proveedores deben entender las siguientes limitaciones de esta opcin: La manipulacin de la trayectoria no puede ser ejecutada ya que nicamente una sola ruta esta
Figura 1 Ejemplo: Rutas por defecto desde todos los proveedores

3
siendo recibida de cada ISP. La manipulacin del Ancho de Banda es extremadamente difcil y puede ser cumplida nicamente con la manipulacin de la mtrica del IGP de la ruta por defecto. Desviar algo de trfico de un punto de salida a otro es desafiante, ya que todos los destinos estn utilizando la misma ruta por defecto para la seleccin de la trayectoria.
En la figura 1, AS 65000 y el AS 65250 envan rutas por defecto al AS 65500. La mtrica IGP que es utilizada para alcanzar la ruta por defecto dentro del sistema autnomo determina que ISP utiliza un router especfico dentro del AS 65500 Por ejemplo, si t utilizas RIP dentro de AS 65500, el router C selecciona la ruta con el menor nmero de saltos hacia la ruta por defecto al enviar los paquetes hacia la red 172.16.0.0
6.1.4 Opcin 2: Rutas por defecto y actualizaciones parciales

En esta opcin de diseo de multihoming, todos los ISPs pasan rutas por defecto y seleccionan rutas especficas al sistema autnomo. 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 tambin recibir las rutas de cualquier otro sistema autnomo. 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 informacin 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 va redistribucin. Ellos pueden tomar el punto de salida ms cercano basado en la mejor mtrica de redes especficas, en vez de tomar la salida ms cercana basada en la ruta por defecto. Adquirir una tabla parcial de BGP de cada proveedor es beneficioso ya que la seleccin de la trayectoria es ms predecible que cuando se utiliza una ruta por defecto. En la figura 1, los ISPs del AS 65000 y AS 64900 envan rutas por defecto y rutas que cada ISP posee hacia el AS 64500. La empresa (AS 64500) pidi que ambos proveedores tambin enven rutas a las redes en el AS 64520 debido a la cantidad de trfico 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 autnomos que no estn especficamente anunciados al AS 64500 por el ISP A y por el ISP B son determinados por la mtrica del IGP que es usada en cada ruta por defecto dentro del sistema autnomo.
Figura 1 Rutas por defecto desde todos los proveedores y tabla parcial
6.1.5 Opcin 3: Full Rutas de todos los Proveedores

En la tercera opcin multihoming, todos los ISPs pasan todas las rutas al sistema autnomo, y IBGP es corriendo en todos los routers en la trayectoria de trnsito en este sistema autnomo. Esta opcin permite a los routers internos del sistema autnomo tomar la trayectoria a travs del mejor ISP para cada ruta.
Esta configuracin requiere muchos recursos dentro del sistema autnomo, ya que se debe procesar todas las rutas externas. El sistema autnomo enva todas sus rutas a los ISPs, los cuales procesan las rutas y las pasan a otros sistemas autnomos. En la figura 1, As 65000 y el AS 64900 enva todas las rutas hacia el AS 64500. El ISP que un router especfico 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 trfico de salida del AS64500.
Figura 1 Rutas completas desde todos los proveedores
6.1.6 Enrutamiento BGP entre sistemas autnomos

El principal objetivo de BGP es proveer un sistema de enrutamiento entre dominios que garantice un intercambio de informacin de enrutamiento libre de lazos entre sistemas autnomos. Los routers intercambian informacin 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 categora de EGP. Hay muchos RFCs relacionados a BGP4, la actual versin 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 publicbased Internet. BGP4 lleva una mscara 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 mayora de rutas BGP, tiene mas de 170,000 bloques CIDR. No utilizar CIDR en el nivel de Internet podra causar que la tabla de enrutamiento IP tenga ms de 2 millones de entradas. Utilizar BGP4 y CIDR previene que la tabla de enrutamiento de Internet llegue a ser demasiada grande para interconectar millones de usuarios.
Figura 1 Sistemas autnomos BGP
Nmero de sistemas autnomos Recordar que un sistema autnomo es una coleccin de redes bajo una sola tcnica de administracin. IGPs opera dentro de un sistema autnomo, y BGP (especficamente BGP4) es utilizado entre sistemas autnomos en el Internet. Figura 1. IANA es la organizacin que mantiene un registro de la asignacin global de direcciones IP. El Regional Internet Registry (RIR) es una organizacin que supervisa la asignacin y registracin de recursos de nmeros de Internet dentro de una particular regin del mundo. Los recursos incluyen direcciones IP (IPv4 y IPv6) y nmeros de sistemas autnomos. Hay actualmente 5 RIRs. The American Registry for Internet Numbers (ARIN) tiene la jurisdiccin de asignar numeracin a las Americas y a algunas islas en el Caribe. Rseaux IP Europens Network Coordination Center (RIPE NCC) administra los sistemas autnomos de Europa, el este medio y dentro de Asia. The Asia Pacific Network Information Center (APNIC) administra la numeracin de la regin del Asia-Pacific. Latin American y Caribbean Internet Addresses Registry (LACNIC) es responsable de Amrica Latina y algo del Caribe. AfriNIC es responsable para el frica. El nmero del sistema autnomo es de 16 bits, colocados desde el 1 al 65535. El RFC 1930 provee una lnea gua para el uso de estos nmeros. Los nmeros del 64512 al 65535 son reservados para uso privado, as como las direcciones privadas de IP. Los nmeros de sistemas autnomos utilizados en este curso son todos en el rango privado para evitar publicar nmeros pertenecientes a organizaciones. Nota: Utilizar un sistema autnomo asignado por el IANA mejor que un nmero privado, es necesario nicamente si tu organizacin planea utilizar un EGP, tal como BGP, y conectarse a redes pblicas, tales como el Internet. Comparacin con IGPs BGP trabaja diferente que IGPs. Un protocolo de enrutamiento busca el path ms rpido de un punto en una red corporativa a otra basado en mtricas 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 declaracin 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 autnomo controlar el flujo de trfico utilizando mltiples 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 mtricas para conseguir a cada red. En contraste, los routers BGP intercambian informacin de confiabilidad de las redes, llamados path vectors, compuestos de path atributes. La informacin del path-vector incluye una lista de los full path de los nmeros de sistemas autnomos 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 direccin IP para conseguir a el siguiente sistema autnomo (the next-hop attribute) y una indicacin de cmo las redes en el final del path fueron introducidas dentro del BGP (origin code attribute). Esta informacin de la trayectoria
Figura 1 Enrutando BGP path-vector

6
del sistema autnomo es utilizada para construir un grafico de sistemas autnomos basados en la informacin intercambiada entre BGP neighbors. BGP mira la entera red como un grafico o rbol de sistemas autnomos. La conexin entre dos cualesquier sistemas forman un path. La coleccin de informacin de path es expresada como una secuencia de nmeros de sistemas autnomos llamados AS path. Esta secuencia forma una ruta para alcanzar un destino especfico. El AS path siempre esta libre de lazos. Un router que este corriendo BGP no acepta una actualizacin de enrutamiento que ya incluya el numero del sistema autnomo del router en el path list, ya que la actualizacin ya ha pasado a travs de este sistema autnomo, y aceptar esta otra vez, podra resultar en un lazo de enrutamiento.
6.1.8 BGP Politicas de enrutamiento

BGP permite que las decisiones de polticas de enrutamiento en el nivel del sistema autnomo sean cumplidas. Estas polticas pueden ser implementadas para todas las redes posedas por el sistema autnomo, para ciertos bloques CIDR de los nmeros de red (prefijos), o para redes o subredes individuales BGP especfica que un router BGP puede anunciar a sistemas autnomos 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 polticas. Por ejemplo, tu no puedes influenciar como un sistema autnomo vecino enrute su trafico, pero tu puedes influenciar en como tu trafico alcanza a un sistema autnomo vecino. BGP soporta cualquier poltica 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 poltica que se asemeje a este paradigma, BGP es altamente aplicable como protocolo de enrutamiento entre sistemas autnomos. Por ejemplo, en la figura 1, los siguientes paths son posibles para el AS 64512 para alcanzar redes en el AS 64700 a travs 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 Figura 1 Polticas de enrutamiento BGP 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 travs del AS 64520 que el AS 64512 ve. Todos los paquetes que son destinados para el 64700 a travs 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 poltica de enrutamiento en el AS 64520. El AS 64512 no aprende del segundo mejor path o de cualquier otro path del AS 64520, a menos que el mejor path del AS 64520 llegue a estar indisponible.
Aun si el AS 64512 supiera otro path a travs del AS 64520 y quiera utilizarlo, el AS 64520 no rateara 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 cuestin de la poltica del BGP. BGP no deja que un sistema autnomo envi trafico a un sistema autnomo vecino, pretendiendo que el trafico tome una ruta diferente de la tomada por el trafico originado en el sistema autnomo vecino Para alcanzar las redes en el AS 64700, el AS 64512 puede escoger utilizar el AS 64520 o este puede escoger ir a travs del path que el AS 64530 esta anunciando. El AS 64512 selecciona el mejor path a tomar basado en sus propias polticas de enrutamiento.
6.1.9 Caractersticas de BGP

BGP es utilizado por ISPs a fin de que ellos puedan comunicar e intercambiar paquetes. Los ISPs tienen mltiples conexiones entre ellos y acuerdan intercambiar actualizaciones. BGP implementa el acuerdo entre dos o ms sistemas autnomos. Figura 1.
Figura 1 Cuando usar BGP
El inapropiado control y filtrado de las actualizaciones BGP pueden potencialmente permitir que un sistema autnomo de afuera afecte al flujo de trafico de tu sistema autnomo. 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 poltica de enrutamiento para asegurar que el ISP-A no enve trafico al ISP-B a travs de tu sistema autnomo. T no quieres gastar apreciados recursos y ancho de banda dentro de tu sistema autnomo para rutear trfico de tus ISPs, pero t quieres estar capacitado para recibir trfico destinado a tu sistema autnomo a travs de cada ISP. BGP no es siempre es la apropiada solucin para interconectar sistemas autnomos. En la figura 2 por ejemplo, si nicamente existe una trayectoria de salida, una ruta por defecto es la ms apropiada solucin. En este caso, BGP innecesariamente utilizara recursos de CPU y memoria del router.
Figura 2 Cuando no usar BGP
Si la poltica de enrutamiento que t implementas en un sistema autnomo es consistente con la poltica en el sistema autnomo del ISP, no es necesario o deseable configurar BGP en ese sistema autnomo. 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 estndar de protocolos de vector distancia, tal como RIP. Figura 3 BGP utiliza TCP como su protocolo de transporte, el cual provee una conexin Figura 3 Caractersticas BGP orientada a una entrega confiable. BGP asume que esta comunicacin es confiable: por consiguiente no tiene que implementar retransmisin o mecanismos de recuperacin de errores. BGP utiliza el puerto 179 de TCP. Dos routers utilizando BGP forman una conexin TCP entre ellos e intercambian mensajes para abrir y confirmar los parmetros de la conexin. Estos dos routers BGP son llamados routers pares (peer routers) o vecinos (neighbors).
Despus de que la conexin es hecha, los BGP peers intercambian completamente las tablas de enrutamiento. Sin embargo, dado que la conexin es confiable, los BGP peers subsecuentemente envan nicamente cambios (en aumento o disparos de actualizaciones) despus de esta. Los enlaces confiables no requieren actualizaciones de enrutamiento peridicas; por consiguiente, los routers en vez de eso utilizan disparos de actualizaciones. BGP enva 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 explcitamente acusados su recepcin. Estos protocolos utilizan una ventana de uno a uno, para los mltiples 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 ms de 10,000 redes, y la mayora 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 dinmica, 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 estn siendo enviados, BGP parara y esperara por un acuse de recibo nicamente cuando el paquete 65 no haya sido acusado, al momento de utilizar el mximo tamao de la ventana. TCP es diseado para utilizar una ventana deslizante en la cual el receptor acuse el recibo en el punto medio de la ventana enviante. Este mtodo permite que cualquier aplicacin TCP, tal como BGP, contine con una cadena de paquetes sin tener que parar y esperar como OSPF y EIGRP requera.
6.1.10 Base de datos BGP

Un router que corre BGP mantiene varias tables para almacenar informacin BGP que recibe y enva a otros routers. Estas tablas incluyen una neighbor table, una BGP table (tambin llamada forwarding database o base de datos topolgica) y una tabla de enrutamiento IP. Figura 1 Para que BGP establezca una adyacencia, t debes configurar explcitamente cada Figura 1 Bases de datos BGP neighbor. BGP utiliza TCP como su protocolo de trasporte (puerto 179). Esto forma una conexin TCP con cada uno de los neighbors configurados y sigue el estado de estas relaciones peridicamente enviando un mensaje BGP TCP de keepalive. Nota: BGP enva 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 conexin TCP entre ellos para propsitos de intercambio de informacin de enrutamiento son referidos como neighbors o peers. Despus de estableces una adyacencia, los neighbors intercambian las rutas BGP que estn en su tabla de enrutamiento IP. Cada router recolecta estas rutas de cada neighbor que exitosamente estableci una adyacencia y entonces las pone dentro de la forwarding database de BGP. Todas las rutas que han sido aprendidas de cada neighbor son puestas dentro de la forwarding database. La mejor ruta para cada red son
seleccionadas de la BGP forwarding database utilizando el proceso de seleccin 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 autnomo externos) tienen una distancia administrativa de 20. Las rutas IBGP (rutas BGP aprendidas dentro del sistema autnomo) tienen una distancia administrativa de 200.
6.1.11 Tipos de mensajes

Los 4 tipos de mensajes BGP son de apertura, de keepalive, de actualizacin, y de notificacin. Figura 1 Despus de que la conexin 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 enva un mensaje keepalive confirmando el open message. Despus de que el lado de recepcin confirme el open message y establezca la conexin BGP, BGP peers pueden intercambiar cualquier mensaje de la actualizacin, keepalive, y mensajes de notificacin. Los BGP peers intercambian inicialmente sus tablas de enrutamiento completamente. Actualizaciones incrementadas son enviadas nicamente despus de que la topologa cambia en la red. Los BGP peers envan mensajes de keepalive para asegurarse de que todava existe la conexin entre los BGP peers. Ellos envan paquetes de notificacin 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 informacin : o Nmero de Versin: Las ms alta versin comn 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 informacin. Si no es un numero de AS esperado, la sesin BGP es destruida o Holf time: Es el nmero mximo de segundos que pueden transcurrir entre sucesivos mensajes de
Figura 1 Tipos de mensajes BGP
Figura 2 Como trabaja BGP
Figura 3 Cdigos de errores de mesajes de notificacin BGP

10
keepalive y de actualizacin 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 ms pequeo: 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 ms alta direccin IP activa, a menos que exista un interfaz de loopback con una direccin IP. En este caso, el ID del router es la direccin IP ms alta del loopback. El router ID puede tambin ser configurada estticamente. o Parmetros opcionales: Estos parmetros son tipo, longitud, y el valor (TLV) - codificado. Un ejemplo de un parmetro opcional es la autentificacin de una sesin. 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 negociacin del intervalo del hold time es 0, peridicos mensajes de keepalive no son enviados. Un mensaje keepalive consiste en solamente un mensaje de cabecera Mensaje de actualizacin: Un mensaje de actualizacin BGP tiene informacin sobre un nico path; mltiples paths requieren mltiples mensajes de actualizacin. Todas los atributos en un mensaje de actualizacin se refieren a ese path, y las redes son las que se pueden alcanzar a travs de el. Un mensaje de actualizacin 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 (segn lo descrito ms adelante en este mdulo). 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 Informacin 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 condicin de error. La conexin del BGP es cerrada inmediatamente despus que se enva este. Los mensajes de notificacin incluyen un cdigo de error, un subcode de error, y los datos relacionados con el error. La figura 3 muestra el campo para los cdigos de error que se pueden utilizar para localizar averas de conexiones BGP.
6.2 EBGP y IBGP

6.2.1 Relaciones de Vecinos BGP
Ningn router puede manejar cada conexin con todas los routers. Diez mil routers corren BGP y estn conectados con el Internet, representando ms de 21.000 sistemas autnomos. Un router BGP forma una relacin vecina directa con un nmero limitado de otros routers BGP. A travs de estos BGP neighbors, un router BGP aprende las trayectorias a travs del Internet para alcanzar cualquier red anunciada. Cualquier router que corra BGP es conocido como BGP speaker. El trmino BGP peer tiene un significado especfico: un BGP speaker es configurado para formar una relacin vecina con otros BGP speaker con el fin de directamente intercambiar la informacin de enrutamiento del BGP con cada otro de ellos. Un BGP speaker tiene un nmero limitado de BGP neighbors con quienes es peers y forma una
Figura 1 Peers = vecino

11
relacin basada en TCP Figura 1 Los BGP peers son tambin conocidos como BGP neighbors y pueden ser internos o externos al Autnomos Sistema. Un BGP peer debe ser configurado con el comando neighbor. El administrador instruye al BGP speaker para establecer una relacin con la direccin enlistada en el comando neighbor vecino y para intercambiar las actualizaciones del enrutamiento del BGP con ese vecino.
6.2.2 Estableciendo una conexin entre BGP Neighbors externos

Hay que recordar que cuando BGP est corriendo entre los routers en diversos sistemas autnomos, este es llamado EBGP. Generalmente, los routers que corren EBGP estn 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 sesin del BGP pueda ser establecida. Por lo tanto, la direccin IP usada en el comando neighbor del BGP debe ser accesible sin utilizar un IGP, que puede ser logrado sealando en una direccin que sea accesible a travs de una red directamente conectada o usando rutas estticas a esa direccin IP
Figura 1 BGP Externo
6.2.3 Estableciendo una conexin entre BGP Neighbors internos

Cuando el BGP funciona entre routers dentro del mismo sistema autnomo, se llama IBGP. IBGP intercambian informacin BGP de modo que todos los BGP speakers tengan la misma informacin de enrutamiento de BGP sobre sistemas autnomos del exterior. Debido a que mltiples paths generalmente existen dentro de un sistema autnomo para alcanzar las otros IBGP routers, una direccin de loopback es usualmente utilizada en el comando neighbor de BGP para establecer las sesiones de IBGP. Por ejemplo, cuando mltiples routers en un sistema autnomo estn 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 autnomos externos de sus vecinos respectivos de EBGP (routers Z, Y, y X).
Figura 1 BGP Interno
12
Si el link entre los routers D y Y se cae, el router D debe aprender las rutas nuevas a los sistemas autnomos externos. Otros routers BGP dentro del AS 65500 que utilizaban el router D para conseguir a las redes externas deben tambin ser informados que el path a travs del router D no est disponible. Estos BGP routers dentro del AS 65500 necesitan tener path alternativos a travs 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 autnomo aprenda sobre las trayectorias a las redes externas va IBGP
6.2.4 Sincronizacin dentro de un sistema autnomo

El BGP fue pensado originalmente para funcionar a lo largo de los bordes un sistema autnomo con los routers en el medio del sistema autnomo ignorando los detalles de BGP (por ello el nombre Border Gateway Protocol). Un sistema autnomo de trnsito, tal como el de la figura 1, es un sistema autnomo que enruta trfico de un sistema autnomo externo a otro sistema autnomo externo. Tpicamente, los sistemas autnomos de trnsito son los ISPs. Todas los routers en un sistema autnomo de transito deben tener un completo conocimiento de las rutas externas. Tericamente, 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 mtodo. Puesto que la tabla de enrutamiento actual del Internet es muy grande, redistribuir todas las rutas del BGP en un IGP no es un mtodo escalable para los routers interiores dentro de un sistema autnomo para aprender sobre las redes externas. Otro mtodo que t puedes utilizar es correr IBGP dentro del sistema autnomo
Figura 1 IBGP en transito en AS (ISP)
Por definicin, 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 trnsito a los sistemas autnomos externos. La regla de sincronizacin de BGP indica que un router BGP no debe anunciar destinos a vecinos externos, aprendidas de IBGP neighbors, a menos que estos destinos tambin se sepan va un IGP. Si un router sabe sobre estos destinos va un IGP, este asume que la ruta se ha propagado ya dentro del Autnomos Sistema, y la confiabilidad interna es asegurada.
6.2.5 IBGP en un No transitado sistema autnomo

Un sistema autnomo no transitado, tal como en una organizacin que es multihoming con dos ISPs, no pasa las rutas entre los ISPs. Sin embargo, los BGP routers dentro del sistema autnomo aun requieren conocimiento de todas las rutas BGP pasadas al sistema autnomo para tomar decisiones apropiadas de enrutamiento BGP no trabaja de la misma manera que los IGPs. Ya que los diseadores de BGP no podran garantizar que un sistema autnomo podra correr BGP en todos los routers, un mtodo 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 existiran lazos de enrutamiento. Para evitar lazos de enrutamiento dentro de un Autnomos Sistema, BGP especifica que las rutas aprendidas con IBGP nunca sean propagadas a otros IBGP peers.
13
El comando neighbor habilita las actualizaciones de BGP entre BGP speakears. Por defecto, cada BGP speakear es asumido que tiene una declaracin vecina para el resto de los IBGP speakers en el Autnomos 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 suposicin por defecto de todos los routers que corren BGP dentro de un sistema autnomo es que cada router BGP est intercambiando informacin IBGP directamente con todos los otros routers BGP en el Autnomos Sistema. Si todos los IBGP neighbors estn fulmente mallados (fully mesh), cuando un cambio es recibido de un sistema autnomo externo, el BGP router para el sistema autnomo local es responsable de informar a los otros IBGP neighbors de el cambio. Los IBGP neighbors que reciben esta actualizacin no la envan 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 actualizacin. Example: IBGP Parcial Mesh La Figura 1 muestra la conducta de una actualizacin IBGP en un ambiente vecino parcialmente mallado Si todos los vecinos de IBGP estn endentados completamente, cuando un cambio se recibe de un Autnomos Sistema externo, la rebajadora del BGP para el Figura 2 Parcial mesh IBGP Autnomos Sistema local es responsable de informar a el resto de los vecinos de IBGP el cambio. Los vecinos de IBGP que reciben esta actualizacin no la envan a cualquier otro vecino de IBGP, porque asumen que el vecino de IBGP que enva est endentado completamente con el resto de los altavoces de IBGP y han enviado cada vecino de IBGP la actualizacin. El router B recibe una actualizacin BGP del router A. El router B tiene dos IBGP neighbors, el router C y el router D, pero no tiene una relacin vecina IBGP con el router E. El router C y el D aprenden acerca de las redes que son aadidas o borradas detrs del router B. Aun si el router el router C y D tienen sesiones vecinas IBGP con el router E, asumen que el sistema autnomo est fulmente mallado por IBGP y no repliegan la actualizacin y no la envan al router E. Enviar una actualizacin IBGP al router E es la responsabilidad del router B, porque es el router con conocimiento de primera mano de las redes dentro y detrs del AS 65101. El router E no aprende ninguna red a travs del router B y no utiliza el router B para alcanzar ninguna red dentro del AS 65101 u otros sistemas autnomos detrs del AS 65101. Example: IBGP Full Mesh La figura 2 muestra un fully mesh IBGP. Cuando el router B recibe una actualizacin 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 actualizacin BGP del router A al router E ya que los routers no estn directamente conectados. La actualizacin se enva una vez a cada neighbor y no es duplicada por ningn otro neighbor de IBGP, lo cual reduce el trfico innecesario.
Figura 2 Full mesh IBGP
14
En IBGP completamente mallado, cada router asume que cada otro router interno tiene una declaracin 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 volmenes de datos grandes confiablemente. Con la muy larga tabla de enrutamiento de Internet cambiando constantemente, TCP fue determinado para ser la mejor solucin 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 autnomo (de modo que todos tengan un cuadro completo de las rutas enviadas al sistema autnomo), 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 autnomo estn completamente mallados y tienen la misma base de datos como resultado de una poltica constante de enrutamiento, ellos pueden aplicar la misma frmula de seleccin de trayectoria. Los resultados de la seleccin de la trayectoria (path) son por lo tanto uniformes a travs del sistema autnomo, el cual asegura ningn lazo de enrutamiento y una poltica constante para salir e incorporar al sistema autnomo.
6.2.6 Problemas de enrutamiento en un sistema autnomo de transito

Todas los routers en el path entre los neighbors de IBGP, conocidos como el camino de transito (transit path), deben tambin estar corriendo BGP, como se muestra en la figura 1. En este ejemplo, los routers A, B, E, y F son los nicos que estn corriendo BGP. El router B tiene una declaracin vecina EBGP para el router A y una declaracin vecina IBGP para el router E. El router E tiene una declaracin vecina EBGP para el router F y una declaracin vecina IBGP para el router B. Los routers C y D no estn corriendo BGP. Los routers B, C, D, y E estn corriendo OSPF como su IGP.
Figura 1 Problemas de enrutamiento con BGP
La red 10.0.0.0 es poseda por el AS 65101 y es anunciada al router B va una sesin EBGP. El router B la anuncia al router E con una sesin 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 travs del AS 65102, el router E enviara los paquetes a BGP peer, router B. Sin embargo para conseguir al router B, los paquetes deben pasar a travs 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 enva paquetes a una direccin 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 autnomo (routers B y E), hay una buena oportunidad que cuando el router E enve 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 trnsito dentro del sistema autnomo deben estar corriendo BGP, y las sesiones IBGP deben ser completamente malladas.
15
6.3 Configurando BGP

6.3.1 Configuracin Bsica de BGP
La sintaxis de los comandos bsicos de la configuracin BGP es similar a la sintaxis para configurar protocolos de enrutamiento interno. Sin embargo, hay diferencias significativa en cmo funciona BGP. Use el comando: router bgp autonomoussystem para identificar e la router de identificar al router de cualquier subsecuente subcomando perteneciente a este proceso de enrutamiento. Figura 1. Este comando tambin identifica el sistema autnomo local en el cual este router pertenece. El router necesita ser informado del sistema autnomo de modo que pueda determinarse si los BGP neighbors a ser configurados despus son IBGP neighbors o EBGP La figura 2 muestra el parmetro para el comando router bgp
Figura 1 Comandos BGP
El comando router bgp solo no activa BGP en un router. Se debe al menos ingresar un subcomando para activar el proceso BGP
Figura 2 Parmetro del comando router bgp
6.3.2 Activar una sesin BGP

Use el comando neighbor ip-address remote-as autonomous-system para activar una sesin BGP para neighbors routers externos e internos. Figura 1. Este comando identifica un peer router con el cual el router local establezca una sesin. La figura 2 muestra los parmetros para este comando. Nota: Un peer group es un grupo de BGP neighbors en el cual todos tienen las mismas polticas de actualizacin. Peers groups son descritos mas adelante en esta leccin La direccin es la direccin destino para todos los paquetes BGP que van a este neighbor router. La direccin debe ser accesible, ya que el BGP procura establecer una sesin TCP e intercambiar actualizaciones BGP con los dispositivos en esta direccin IP.
Figura 1 Comando BGP neighbor remote-as
Figura 2 Parmetros del comando neighbor remote-as
El nmero del sistema autnomo identifica si este neighbor es un EBGP neighbor o IBGP. Si el nmero es igual que el nmero del sistema autnomo para este router, el vecino es un IBGP neighbor, y la direccin IP enlistada en el comando neighbor no tiene que estar directamente conectada. Si el nmero es diferente, el vecino es un EBGP, y la direccin 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 declaracin vecina
para el router C no empareja el nmero del sistema autnomo del router A, el cual esta en el AS 65101. El router A puede alcanzar al AS 65102 va 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 autnomo que el router A. La segunda declaracin 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 direccin IP 10.2.2.2. Como un IBGP neighbor, el router B puede estar mltiples routers lejos del router A. Figura 3 Ejemplo: Comando BGP neighbor
6.3.3 Shutting Down a un BGP neighbor

Use el comando neighbor ip-address shutdown para administrativamente bajar y rehabilitar un BGP neighbor Figura 1 Si t llevas a cabo cambiar mayores polticas a un router vecino y cambias mltiples parmetros, t debes administrativamente bajar el router vecino, y despus traer de regreso el router vecino con el comando l respaldo vecino de la router con el comando no neighbor ipaddress shutdown
Figura 1 Comando BGP neighbor shutdown
6.3.4 Consideraciones de configuracin de BGP

La declaracin vecina de BGP informa al router de la direccin IP destino para cada paquete de actualizacin. El router debe decidir cual direccin IP usar como direccin ip origen en la actualizacin 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 direccin IP es de la interfaz de salida, como la tabla de enrutamiento indica, se utiliza como direccin IP origen del paquete BGP. Esta direccin Ip origen debe emparejar la direccin en la correspondiente declaracin vecina en el otro router. Si no, los routers no sern BGP peers ya que no pueden establecer una sesin BGP.
Figura 1 Problemas BGP con direccin IP origen
17
6.3.5 IBGP Peering Issue

Para establecer la sesin IBGP entre el router A y D, como se muestra en la figura 1, cual direccin ip vecina debera 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 travs del router B, la direccin IP origen es la 10.1.1.1. Cuando el router D recibe este paquete a travs 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 sesin IBGP entre el router A y el D no puede ser establecida Una solucin es establecer una sesin IBGP usando un interfaz de loopback cuando hay trayectorias mltiples entre los IBGP neighbors.
Figura 1 Ejemplo: BGP peering issue
6.3.6 Comando update-source de BGP neighbors

La opcin update-source del comando neighbor elimina la direccin IP de origen por defecto utilizada para los paquetes BGP. Es necesario decir al router qu direccin IP utilizar como direccin origen para todos los paquetes BGP si tu deseas utilizar una interfaz de loopback en vez de la interfaz fsica. Figura 1 Si t no utilizas la opcin update-source, un aviso yendo a un neighbor utiliza la direccin IP de la interfaz existente como direccin origen para un paquete. Cuando un router crea un paquete, si este Figura 1 Comando BGP neighbor update-source es una actualizacin de enrutamiento, un ping, o algn otro tipo de paquete IP, el router busca la direccin destino en la tabla de enrutamiento. La tabla de enrutamiento enumera la apropiada interfaz para conseguir la direccin destino. La direccin de esta interfaz de salida es utilizada como la direccin origen de estos paquetes por defecto. Considerar qu sucedera si un router vecino utiliza la direccin 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 actualizacin y mira la direccin origen del paquete, ve que no tiene ninguna relacin vecina con esa direccin origen, as que desecha el paquete. El BGP no acepta actualizaciones no solicitadas. Debe estar enterado de cada router vecino y tener una declaracin vecina para l. Las trayectorias mltiples pueden existir para alcanzar a cada vecino cuando esta en peering con un router IBGP neighbor. Si el router BGP est utilizando una direccin vecina que es asignada para un interfaz especfico en otro router, y que la interfaz se caiga, el router que seala a esta direccin pierde su sesin BGP con ese vecino.
Si el router mira con fijeza (peers) con la interfaz de loopback en vez de otro router, la interfaz de loopback esta siempre disponible mientras el router no falle. Este arreglo de peering agrega viveza a las sesiones IBGP ya que los routers no se atan en una interfaz fsica, la cual puede caerse por un sin numero de razones. Para mirar con fijeza con el loopback de otro vecino interno, el primer router seala la declaracin vecina en la direccin de loopback del otro vecino interno. Asegrese de que ambos routers tengan una ruta a la direccin de loopback del otro vecino en su tabla de enrutamiento. Tambin asegrese de que ambos routers estn anunciando sus direcciones de loopback en su protocolo de enrutamiento local. Ejemplo: Utilizando una direccin de loopback con el BGP En la figura 2. El router B tiene al router A como EBGP neighbor. La nica direccin accesible para el router B a utilizar para una direccin vecina en BGP es la direccin directamente conectada 172.16.1.1. El router B tiene trayectorias mltiples para alcanzar la router C, IBGP neighbor Todas las redes, incluyendo la red IP para la interfaz de loopback del router C, pueden Figura 2 Ejemplo: Usando direcciones loopback en BGP ser alcanzadas del router B. El router B puede alcanzar estas redes porque los routers B y C intercambian actualizaciones de EIGRP; los routers B y A no intercambian actualizaciones de EIGRP. La relacin vecina entre los routers B y C no se ata a un interfaz fsico porque el router B mira con fijeza (peers)con la interfaz de loopback en el router C y utiliza su direccin de loopback como la direccin 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 relacin vecina de BGP tambin se caera. El comando neighbor update-source se debe utilizar en ambos routers. Si el router B apunta a la direccin de loopback 3.3.3.3 del router C, y el router C apunta a la direccin de loopback 2.2.2.2 del router B, y ninguna utiliza el comando neighbor update-source, la sesin BGP entre estos routers no comienza. El router B enviara un paquete abierto BGP al router C con la direccin origen siendo la 10.1.1.1 o la 10.2.2.1. El router C revisara la direccin origen y procurara emparejarlo contra su lista de neighbors conocidos. El router C no encontrara un emparejamiento y no respondera 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 direccin que puede alcanzar sin la configuracin adicional es la de la interfaz que est directamente conectada con se router EBGP. Recordar que la informacin de enrutamiento interna no est intercambiada con peers externos. Por lo tanto, el router tiene que sealar a una direccin directamente conectada para ese vecino externo.
Figura 1 Comando BGP neighbor ebgp-multihop
19
Si una interfaz de loopback se utiliza en vez del interfaz directamente conectado, se requiere la configuracin adicional. Para permitir que el router acepte y ensaye conexiones BGP a pares (peers) externos que residen en las redes que no estn directamente conectadas, tu debes configurar el comando de configuracin en el router neighbor ip-address ebgp-multihop [ttl]. La Figura 1 y la figura 2 muestran los parmetros de este comando Los EBGP peers estn 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 direccin 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 declaracin vecina y apunta a la 192.168.1.18 en el router B del AS 65101 y ese link se cae, no hay sesin BGP entre estos sistemas autnomos. Consecuentemente, ningn paquete pasa Figura 3 Ejemplo: Comando ebgp-multihop de un sistema autnomo 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 actualizacin 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 direccin de loopback del router B y viceversa, y cada router usa esta direccin de loopback como la direccin IP de origen para esta actualizaciones BGP. Debido a que IGP no es utilizado entre los sistemas autnomos, ningn router puede alcanzar el loopback del otro router sin asistencia. Cada router necesita utilizar dos rutas estticas para informar al BGP de las trayectorias disponibles para alcanzar la direccin de loopback del otra router. Una direccin 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 direccin IP esta a mas de un salto lejos. En la figura, el comando utilizado en el router A informa a BGP que direccin vecina de 1.1.1.1 esta a dos saltos lejos. Nota: BGP no esta diseado para realizar balanceo de carga. Las trayectorias se eligen debido a la poltica, 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 travs de las dos trayectorias entre los sistemas autnomos.
Figura 2 Parmetros del comando neighbor ebgp-multihop
6.3.8 Comportamiento del Next Hop

La manera en la cual el BGP establece una relacin de IBGP es muy diferente a la manera que los IGPs se comportan. El mtodo que BGP utiliza que denota su direccin del next hop es tambin muy diferente. BGP informa al siguiente sistema autnomo sobre las trayectorias a otros sistemas autnomos y las redes que esos otros sistemas autnomos poseen. BGP, como IGPs, es un protocolo de enrutamiento del salto-por-salto. Sin embargo, diferente de IGPs, BGP rutea de sistema autnomo a sistema autnomo, y el next hop por
defecto es el siguiente sistema autnomo. Un router IBGP neighbor que aprende sobre una red fuera de su sistema autnomo ve, como la direccin de next hop, el punto de entrada para los siguientes sistemas autnomos a lo largo de la trayectoria para alcanzar la red distante. Figura 1 Para EBGP, el next hop por defecto es la direccin IP del router vecino que enva la actualizacin. Para IBGP, el protocolo BGP afirma que el next hop anunciado por EBGP debera 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 direccin 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 travs de un IGP o de una ruta esttica. Si no, el router C elimina los Figura 2 Ejemplo: Comportamiento del Next-hop paquetes destinados para la red 172.16.0.0 porque no puede conseguir a la direccin del next hop para esa red. Un router IBGP neighbor realiza operaciones de bsqueda recurrentes para descubrir cmo alcanzar una direccin del next hop del BGP usando sus entradas de IGP en la tabla de enrutamiento. Por ejemplo, el router C aprende en una actualizacin 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 direccin IP de origen de una actualizacin de enrutamiento (ruta origen) como la direccin del next hop, mientras que BGP utiliza un campo separado por red para registrar la direccin 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 bsqueda 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.
Figura 1 Comportamiento del Next-hop
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 direccin de next hop para las rutas enviadas a un router vecino.
21
El comando neighbor next-hop-self fuerza al BGP a utilizar su propia direccin IP como la direccin del next hop para cada red que anuncie a su IBGP neighbor, en vez de dejar que el protocolo elija la direccin 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 direccin de next hop para las rutas enviadas a un router vecino. Un protocolo interno, tal como RIP, EIGRP, u OSPF, utiliza siempre la direccin de la actualizacin de enrutamiento como su direccin 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 direccin IP origen como direccin del next hop para cada red anunciada. La figura 2 exhibe los parmetros del comando. Ejemplo: Configuracin 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 detrs 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 direccin IP de la interfaz del loopback) a su IBGP neighbor, ya que este es la direccin ip origen de la actualizacin de enrutamiento a su IBGP neighbor (fijar con el comando neighbor update-source). Cuando el router C anuncia las redes que estn en el o detrs del AS 65101 a los EBGP neighbors, tales como el router D en el AS 65102, el router C, por defecto, utiliza su direccin de interfaz de salida
Figura 3 Ejemplo: Configuracin next-hop self
Figura 1 Comando BGP neighbor next-hop-self
Figura 2 Parmetros del comando neighbor next-hop-self
Figura 4 Ejemplo: next hop en una red multiacceso
22
192.168.1.2 como la direccin del next hop. Esta direccin es tambin la direccin por defecto del next hop para el router D para alcanzar cualquier red en el o detrs del AS 65101. Al funcionar BGP sobre una red multi acceso tal como Ethernet, un router BGP ajusta la direccin de next hop (next-hop) para evitar insertar saltos adicionales en la red. Esta caracterstica a veces se llama un next hop de tercera persona (third-party next hop) Ejemplo: Next Hop en una red multiacceso Segn lo muestra la figura 4, los routers B y C en el AS 65000 estn corriendo IGP de modo que el router B pueda alcanzar la red 172.30.0.0 va 10.10.10.2. El router B tambin corre EBGP con el router A. Cuando el router B enva una actualizacin 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 direccin 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 va la router B. La direccin del next hop tiene ms sentido cuando t revisas esta desde la perspectiva de un ISP. Un ISP grande en un punto de peering publico que tiene mltiples 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 pblicos 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 travs del AS 65000 para conseguir a las redes en el y detrs del AS 64600. El router A tiene una relacin vecina solamente con el router B en el del AS 65000. Sin embargo, el router B no maneja el trfico que va al AS 64600. La trayectoria preferida del router B para el AS 64600 est a travs 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 estn 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 Inyeccin de Informacin de enrutamiento dentro de BGP

Utilice el comando network networknumber para permitir que BGP anuncie una red si esta presente en la tabla de enrutamiento. La figura 1 y 2 muestra los parmetros de este comando. El comando network determina las redes que el router origina. Este concepto es diferente de usar el comando network cuando tu ests configurando un IGP. Diferente a un IGP, el comando network no arranca el BGP en interfaces especficos. En lugar indica al BGP que redes debera originar este router. El parmetro de la mscara indica que BGP4 puede dirigir subnetting y supernetting. La lista del comando network debe incluir todas las redes en su sistema autnomo que usted desee anunciar, y no solo las redes que estn localmente conectadas en el router
Figura 1 Comando BGP network
Figura 2 Parmetros del comando network
Antes de Cisco IOS Software Release 12.0, haba un lmite de 200 comandos de red por el router BGP. Se ha quitado este lmite. Los recursos del router, tales como la NVRAM o la RAM, determinan el nmero mximo de redes en el comando que t puedes utilizar. El comando neighbor dice a BGP donde anunciar, y el comando network dice a BGP que anunciar
6.3.11 Ejemplo del comando network de BGP

El propsito nico del comando network es notificar al BGP qu red anunciar. Sin la opcin de la mscara, este comando anuncia solamente el nmero 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 opcin network-mask, un match exacto a la red (direccin y mscara) 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 cmo 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 ningn vecino
Figura 1 Ejemplo: Comando BGP network
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 Figura 2 Ejemplo: Comando BGP network (cont.) 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 ningn vecino. En este caso, usted puede configurar la siguiente ruta esttica 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 Despus 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 configuracin BGP del router auto-summary determina cmo BGP maneja la predistribucin 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 estn 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 Sincronizacin BGP

La regla de sincronizacin 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 autnomo pasa trfico a otros sistemas autnomos, el BGP no debe anunciar una ruta antes de que todas las routers en el sistema autnomo hayan aprendido sobre la ruta va el IGP. Un router que aprende una ruta va IBGP espera hasta que el IGP ha propagado la ruta dentro del sistema autnomo y despus anuncia a los pares externos. Esta regla asegura de que todas los routers en el sistema autnomo estn sincronizados y puedan encaminar el trfico que el sistema autnomo anuncia a otros sistemas autnomos. Este acercamiento asegura la consistencia de la informacin de enrutamiento (evita "black holes") dentro del sistema autnomo.
La sincronizacin del BGP es inhabilitada por defecto en el Cisco IOS Software Release 12.2(8)T y ms adelante. Era encendido por defecto en revisiones anteriores del Cisco IOS Cuando la sincronizacin esta deshabilitada, el BGP puede utilizar y anunciar las rutas aprendidas de un IBGP neighbor que no estn presentes en la tabla de enrutamiento local a un vecino externo del BGP. La sincronizacin del BGP es innecesaria en algunas situaciones. Por ejemplo, es seguro tener sincronizacin de BGP apagado si todas los routers en la trayectoria de trnsito en el sistema autnomo estn corriendo IBGP en full mesh
Figura 1 Sincronizacin BGP
Tener la sincronizacin deshabilitada permite a los routers llevar pocas rutas en el IGP y permite que el BGP converja ms rpidamente. Use sincronizacin si los routers en la trayectoria de trnsito de BGP en el sistema autnomo no estn corriendo BGP (por lo tanto, los routers no estn en full mesh IBGP dentro del sistema autnomo Nota: En el pasado, la mejor prctica era redistribuir el BGP en el IGP que funcionaba en un sistema autnomo de modo que IBGP no fuera necesitado en cada router en la trayectoria de trnsito. En este caso, la sincronizacin fue necesitada para cerciorarse de que los paquetes no se pierdan; por lo tanto, la sincronizacin era encendida por defecto. Mientras que el Internet creci, el nmero de rutas en la tabla del BGP llego a ser demasiado para que el IGPs dirija. La mejor prctica cambiante para no redistribuir el BGP en el IGP, en lugar de esto utilizar IBGP en todas las routers en la trayectoria de trnsito. En este caso, la sincronizacin no es necesaria, as que ahora est apagado por defecto.
6.3.13 Ejemplo de sincronizacin BGP

En la figura 1, los routers A, B, C, y D estn 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 sincronizacin 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 trfico que es destinado para la red 172.16.0.0, este no tiene una ruta para esa red y no puede enviar el trfico. Si la sincronizacin 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 direccin del next hop para la red 172.16.0.0). El router A anuncia la ruta al router E.
25
El router E despus tiene una ruta a la 172.16.0.0 y puede enviar el trfico que es destinado para esa red. El router E enva 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 va 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 autnomos modernos, ya que el tamao de la tabla de enrutamiento del Internet es grande, la redistribucin del BGP en un IGP no es escalable. Por lo tanto, la mayora de los sistemas autnomos modernos corren IBGP en full mesh y no requieren la sincronizacin. Los mtodos avanzados de configuracin del BGP, por ejemplo, con los reflectores y las confederaciones de la ruta, reducen los requisitos para un full mesh.
Figura 1 Ejemplo: Sincronizacin BGP
6.3.14 Ejemplo de configuracin de BGP

La figura 1 muestra un ejemplo de BGP. La figura 2 muestra la configuracin 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 declaracin Vecina en el router A para el router B esta apuntando a la direccin IP directamente conectada para a un EBGP neighbor, router A. Sin embargo, la declaracin vecina en el router B apunta a la interfase de loopback del router C, ya que el router B tiene mltiples trayectorias para alcanzar al router C.
Figura 1 Ejemplo: Configuracin BGP
Si el router B apunta a la direccin IP 192.168.3.2 del router C y esta interfase se cayera, el router B no podra restablecer la sesin BGP hasta que el enlace suba. Sealando 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 tambin sealar a la direccin de loopback del router B en su configuracin. La lnea 4 se notifica que el router B utilice siempre su direccin de loopback 0, 192.168.2.1, como su direccin IP de origen cuando enve una actualizacin al router C, 192.168.2.2.
En la lnea 5, el router B cambia la direccin del nexthop para las redes que son accesibles con ella. La configuracin del next-hop o next hop por defecto para las redes del AS 64520 es la direccin IP 10.1.1.2. Con este comando next-hop-self, el router B fija la direccin del next hop a la direccin IP origen de la actualizacin de la enrutamiento, la cual es la interfaz de loopback 0 del router B, como lo fijo el comando update-source Las lneas 6 y 7 notifican al BGP sobre cuales redes anunciar. La lnea 6 contiene una subred de direccin de clase B usando la opcin mask. Las lneas 7 y 8 tienen dos declaraciones de red para las dos redes de clase C que conectan a los routers B y C. La mscara por defecto es 255.255.255.0, as que no necesitas incluir esto en el comando. En la lnea 9, la sincronizacin es deshabilitada. Si Figura 2 Ejemplo de configuracin BGP el router A est anunciando la red 172.20.0.0 en BGP, el router B recibe esa ruta y la anuncia al router C. Puesto que la sincronizacin 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 sincronizacin en el router B tambin necesitara estar apagada. En esta red, la sincronizacin puede estar apagada porque todas las routers dentro del sistema autnomo estn corriendo IBGP.
6.4 Configuracin y verificacin avanzada de BGP

6.4.1 Estados de BGP neighbors
El proceso de negociacin de BGP neighbors procede a travs de varios estados. Figura 1. Estos pasos se pueden describir en trminos de una mquina de estado finito (FSM finite-state machine). Un FSM es un sistema de estados posibles que pueden ir a travs, 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 Despus de que hayas incorporado el comando neighbor, el BGP toma la direccin IP que esta enumerada y chequea la tabla de enrutamiento local para saber si hay una ruta a esta direccin. A este punto, el BGP est en el estado IDLE. Si el BGP no encuentra una ruta a la direccin IP, permanece en el estado IDLE. Si encuentra una ruta, entra al estado connect cuando el paquete TCP handshaking synchronize acknowledge (SYN ACK) retorna. Despus de que la conexin del TCP haya finalizado, el BGP crea un paquete abierto BGP y lo enva al vecino. Una vez de que
Figura 1 Estados BGP
Figura 2 Estados FSM BGP
27
BGP enve este paquete abierto, la sesin 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 (evaluacin) de la tabla de enrutamiento para que las trayectorias enven 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 sesin. 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 debera ser encendido nicamente cuando es necesario
Figura 3 Ejemplo: establecimiento de sesin BGP
6.4.2 Estados Established e Idle de BGP

Es estado idle indica que el router no sabe como alcanzar la direccin IP que esta enlistada en la declaracin vecina Figura 1 El router puede estar en idle dado uno de los siguientes escenarios: Este esta esperando por una ruta esttica para la direccin de red o red a ser configurada. Este esta esperando por un protocolo de enrutamiento local (IGP) para aprender acerca de esta red a travs de un anuncio de otro router. La mas comn razn para que un router entre al estado de idle es que el vecino no esta anunciando la direccin IP o la red que la declaracin vecina del router esta apuntando. Queque estas dos condiciones primero para corregir este problema: Asegrese que el vecino anuncie la ruta en su protocolo de enrutamiento local. Verifique que tu no hayas entrado una direccin IP incorrecta en la declaracin vecina El estado establecido es un estado deseado por las relaciones de neighbors. Figura 2. Figura 3 Ejemplo: Comando show ip bgp neighbors
28
Figura 1 Estado idle BGP
Figura 2 Estado establecido BGP
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 informacin 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 conexin TCP y dos peers tienen agregado utilizar BGP para comunicarse
6.4.3 Verificacin de problemas de BGP en estado Activo

Si el router est en el estado activo, ha encontrado la direccin IP en la declaracin vecina y ha creado y ha enviado un paquete abierto de BGP. Sin embargo, el router no ha recibido una respuesta (paquete de confirmacin abierto). Figura 1 Un problema comn en este caso es que el neighbor puede no tener una ruta de Figura 1 Estado activo BGP regreso a la direccin IP origen. Asegrese de que la direccin IP origen o red de los paquetes se haya anunciado al protocolo de enrutamiento local (IGP). Otro problema comn asociado al estado activo ocurre cuando un router BGP procura mirar con fijeza (peers) con otro router BGP que no tenga una declaracin vecina de peering detrs en el primer router, o cuando el otro router est mirando con fijeza con una direccin IP incorrecta en el primer router. Cheque para asegurarse de que el otra router tenga una declaracin vecina de peering con la direccin 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 desconfiguracin del numero de sistema autnomo La figura 2 muestra el mensaje de consola generado en el router con el nmero remoto del sistema autnomo equivocado en la declaracin vecina
Figura 2 Ejemplo: Estado activo BGP
6.4.4 Configurando un Peer Group

En BGP, los neighbors routers son frecuentemente configurados con las mismas polticas de actualizacin. Por ejemplo, los neighbors routers pueden tenerle mismo filtro aplicado. En los routers Cisco, los neighbors routers con las mismas polticas de actualizacin se pueden agrupar en grupos peers (peers groups) para simplificar la configuracin y para hacer la actualizacin ms eficiente y para mejorar funcionamiento. Los miembros del peer group heredan todas las opciones de configuracin 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 ms eficientes ya que las actualizaciones se generan solamente una vez por peer group en vez de que repetidamente para cada router vecino. La actualizacin generada es replicada para cada neighbor que sea parte del interno peer group. Los peer group ahorran tiempo de transformacin en la generacin 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 ningn otra router. Los peers group hacen la configuracin del router ms fcil leer y manejar.
29
Use el comando neighbor peer-groupname 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 direccin 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 direccin IP en otros comandos, por ejemplo, para linkear Figura 1 Usando un peer group una poltica 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 actualizacin dinmica de peer group en BGP usando peers templates para optimizar dinmicamente las actualizaciones a grupos de neighbors para compartir polticas de salida. Ms informacin sobre esta caracterstica 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 estn utilizando la direccin IP de su interfaz de loopback 0 como la direccin IP origen para todos los paquetes BGP. Cada router est utilizando una de sus propias direcciones IP como la direccin del next hop para cada red anunciada a travs de BGP. stas son polticas de salida Adems, el router C tiene una lista de distribucin de salida asociada a cada IBGP neighbor. Este filtro de salida realiza la misma funcin que el comando distribute-list que t usas Figura 1 Ejemplo: Usando un peer group para los protocolos enrutamiento interno. Sin embargo, se liga a un vecino especfico para usar con BGP. El ISP detrs 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 configuracin del router C cuando no est utilizando un peer group. Todos los IBGP neighbors tienen la lista de distribucin de salida para ellos individualmente. Si el router C recibe un cambio del AS 65101, este debe generar una actualizacin individual para cada IBGP neighbor y correr cada actualizacin contra distribuir
la lista 20. Si el router C tiene una gran cantidad de IBGP neighbors, el poder de procesamiento necesitado para informar a los IBGP neighbors de los cambios del AS 65101 podra ser extensa. La figura tambin demuestra la configuracin en el router C cuando est utilizando a peer group llamado interno. Los comandos update-source, next-hop-self, y distribute-list 20 out estn 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 actualizacin y procesa esto a travs de la lista distribuida 20, lo cual ahorra tiempo de procesamiento. La actualizacin 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 poltica de salida comn de BGP. La adicin de un nuevo neighbor al router C que usa a un peer group con las mismas polticas de los otros IBGP neighbors requiere la adicin solamente de una sola declaracin 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 tambin hace la configuracin ms fcil de leer y cambiar cuando es necesario. Si necesitas agregar una nueva poltica, 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 poltica 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: direccin IP que todos los otros BGP speakers reconocen como una representacin de este router BGP table versin: Aumenta de incrementos cuando la tabla del BGP cambia. Main routing table versin: la ltima versin de la base de datos de BGP que fue inyectada en la tabla de enrutamiento principal. Neighbor: direccin IP que se utiliza en la declaracin vecina con Figura 1 Ejemplo: BGP peering la cual este router tiene una relacin. Versin (V): Versin de BGP que este router est corriendo con el neighbor mencionado. AS: numero del sistema autnomo del neighbor mencionado. Messages received (MsgRcvd): Nmero 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): Versin de la tabla de BGP. In queue (InQ): Nmero de los mensajes que esperan para ser procesados por este neighbor. Out queue (OutQ): Nmero 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).
31
State (established, active, idle, open sent, open confirm, or idle [admin]): estados de BGP. Tu puedes setear a un neighbor para que administrativamente este abajo (admin state) utilizando el comando shutdown en el neighbor Prefix received (PfxRcd): Cuando la sesin est en el estado establecido, este valor representa el nmero de las entradas de red BGP recibidas del neighbor mencionado.
6.4.7 Configurando autenticacin BGP

T puedes configurar la autentificacin vecina BGP en un router de modo que el router autentique la fuente de cada paquete de actualizacin de enrutamiento que recibe. Esto es logrado intercambiando una llave de autenticidad (designada a veces una contrasea) que es conocida por ambos router el que enva y el de recepcin. El BGP soporta autentificacin vecina MD5. MD5 enva un message digest (tambin 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 leda por un eavesdropper mientras que se est transmitiendo. Para habilitar autenticacin MD5 en una conexin TCP entre dos BGP peers, use el comando de configuracin de router neighbor {ip-address | peer-group-name} password string la figura 1 y 2 muestra los parmetros:
Figura 1 Autenticacin de vecino BGP
Tu puedes configurar la autentificacin MD5 entre dos BGP peers, dando a entender que cada segmento enviado en la conexin TCP entre los pares est verificado. La autentificacin MD5 se debe configurar con la misma contrasea en ambos BGP peers; si no, la conexin entre ellos no es hecha. La autentificacin de configuracin MD5 hace que el software del IOS de Cisco genere y compruebe MD5 digest de cada segmento enviado en la conexin TCP.
Figura 2 Parmetros del comando neighbor
Precaucin: Si la secuencia de autentificacin se configura incorrectamente, la sesin del BGP peering no se establece. Se recomienda que ingreses una secuencia de autentificacin cuidadosamente y verifiques que la sesin peering este establecida despus de que se configure la autentificacin. Si tu especificas un BGP peer group usando el argumento peer-group-name, todos los miembros del peer group heredan la caracterstica configurada con este comando. Si un router tiene una contrasea 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 contraseas 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)
32
Si configuras o cambias la contrasea o la llave usada para la autentificacin MD5 entre dos pares del BGP, el router local no rasga abajo la sesin existente despus de que configures la contrasea. El router local procura mantener la sesin que mira con fijeza usando la nueva contrasea hasta que expira el contador de tiempo del asentamiento del BGP. El perodo de defecto es 180 segundos. Si la contrasea no se incorpora ni se cambia en el router alejada antes de que expire el contador de tiempo, los tiempos de la sesin hacia fuera. Nota: Si cambias el valor del mantenimiento, toma efecto solamente despus que se ha reajustado la sesin. No puedes cambiar el contador de tiempo del asentamiento para evitar de reajustar la sesin del BGP. El ejemplo en la figura 3 autentificacin de configures MD5 para la sesin que mira con fijeza del BGP entre las routers A y B. La misma contrasea se debe configurar en el par alejado antes de que expire el contador de tiempo del mantenimiento
Figura 3 Ejemplo: Autenticacin de vecino BGP
6.4.8 Troubleshooting BGP

Utilizar el comando show ip bgp muestra la base de datos de la topologa del BGP (tabla del BGP). La figura 1 muestra una salida parcial de la muestra del comando del BGP del IP de la demostracin. Los cdigos de estado se demuestran al principio de cada lnea de la salida, y los cdigos de origen se demuestran en el extremo de cada lnea
En esta salida, hay un asterisco (*) en la mayor parte de las entradas en la primera columna. Esto significa que la direccin del next hop (en la quinta columna) es vlida. La direccin del next hop no es siempre el router que est conectado directamente con este router. Otras opciones para la primera columna son las siguientes: s: Se suprimen las rutas especificadas (generalmente porque se han resumido las rutas y solamente se est enviando la ruta sumaria). d: La ruta se est desalentando (penalizado) ya que la ruta sube y baja demasiado a menudo. Aunque la ruta pudo estar arriba Figura 1 Ejemplo: Comando show ip bgp ahora, no se anuncia hasta que ha expirado la penalizacin. h: La ruta es inasequible y est probablemente abajo. La informacin histrica sobre la ruta existe, pero una mejor ruta no existe. r: La ruta no fue instalada en la base de informacin de enrutamiento (RIB). La razn que la ruta no est instalada se puede mostrar usando el comando show ip bgp rib-failure S: La ruta esta averiada o aeja (este smbolo es usado en el nonstop forwarding-aware router). La segunda columna muestra > cuando BGP ha seleccionado la trayectoria como la mejor trayectoria a una red.
La tercera columna es espacio en blanco o muestra el i Si est en blanco, BGP aprendi la ruta de un peer externo. Una i indica que un IBGP neighbor anunci esta trayectoria al router. La cuarta columna enumera las redes que el router aprendi. La columna next hop enumera todas las direcciones del next hop para cada ruta. Esta columna puede contener la entrada 0.0.0.0, que significa que este router es el autor de la ruta. Las tres columnas a la izquierda de la columna Path lista tres atributos de trayectoria BGP que se asocian a la trayectoria: metric (multi-exit discriminator [MED]), local preference, y weight. La columna con la cabecera de Path puede contener una secuencia de sistemas autnomos en la trayectoria. De izquierda a derecha, el primer sistema autnomo enumerado es el sistema autnomo adyacente que esta red ha aprendido. El ltimo nmero (el nmero de sistema autnomo de la derecha) es el sistema autnomo que origina esta red. Los nmeros de sistema autnomo entre estos dos representan la trayectoria exacta que un paquete toma de regreso al sistema autnomo originado. Si la columna de la trayectoria est en blanco, la ruta es el sistema autnomo 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 declaracin de la red para introducir esta red en BGP. Si el carcter es una e, el router que originaba aprendi esta red del EGP, que Figura 2 Ejemplo: Comando show ip bgp rib-failure es el precursor histrico de BGP. Un signo de interrogacin (?) 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 razn 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 sesin BGP

BGP puede potencialmente manejar volmenes enormes de informacin de enrutamiento. Cuando ocurre un cambio de configuracin de la poltica, el router no puede pasar a travs de la tabla enorme de informacin de BGP y recalcular qu entrada no es ms vlida en la tabla local. Ni puede el router determinar cul ruta debe ser retirada de un neighbor. Figura 1 Figura 1 Limpiando la sesin BGP Hay un riesgo obvio que el primer cambio de configuracin ser seguido inmediatamente por un segundo, que hara 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 despus de que se haya realizado el cambio de configuracin de la poltica de BGP. La nueva poltica, implementada por los filtros, se aplica solamente en las rutas que se reciben o se envan despus del cambio.
Un administrador de red que quisiera que el cambio de poltica fuera aplicado a todas las rutas, deba accionar una actualizacin para forzar al router que deje que todas las rutas pasen a travs del nuevo filtro. Si el filtro se aplica en la informacin saliente, el router tiene que volver a enviar la tabla BGP a travs del nuevo filtro. Si el filtro se aplica en la informacin entrante, el router necesita a que su neighbor vuelva a enviar su tabla BGP de modo que pase a travs de los nuevos Hay tres maneras de accionar una actualizacin: con un hard reset, soft reset, o route refresh.
6.4.10 Hard Reset de sesiones BGP

El reajuste de una sesin es un mtodo de informar a los neighbors de un cambio de poltica. Si se reajustan las sesiones BGP, toda la informacin recibida en esas sesiones se invalida y se quita de la tabla del BGP. Tambin, el neighbor remoto detecta una sesin BGP abajo e invalida las rutas que fueron recibidas. Despus de 30 a 60 segundos, las sesiones BGP se restablecen automticamente, y la tabla de BGP es intercambiada otra vez pero a travs de los nuevos filtros. Sin embargo, resetear la sesin 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 estn 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 informacin a cada uno de los neighbors afectados por el particular comando que es utilizado. El comando clear ip bgp * causa que la tabla de BGP de forwarding en el router que se emite este comando sea completamente Figura 1 Hard reset de sesiones BGP borrada, y todas las redes deben ser reaprendidas de cada neighbor. Si un router tiene mltiples neighbors, esta accin es un acontecimiento muy dramtico. Este comando fuerza a todos los neighbors a volver a enviar sus tablas enteras simultneamente. Debes utilizar este comando con la precaucin extrema, y no se utiliza normalmente en un ambiente en produccin. Por ejemplo, considere una situacin en qu el router A tiene ocho neighbors, y cada neighbor tiene una tabla llena de Internet de cerca de 32 MB de tamao. 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 necesitara 256 MB de RAM, y tambin necesitara estar disponible para poder procesar toda esta informacin. Procesando 256 MB de actualizaciones tomara un nmero 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 poltica de todos los neighbors, ya que cada uno debe ser dado individualmente ms bien que de una vez con el comando clear ip bgp *. El comando clear ip bgp [neighbor-address] todava realiza un hard reset y debe restablecer la sesin TCP con la direccin especificada, pero afecta solamente a solo neighbor a la vez.
35
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 sesin BGP. En su lugar, el router crea una nueva actualizacin y enva la tabla entera a los vecinos especificados. Esta actualizacin incluye los comandos de retiro para las redes que el otro neighbor no mirara mas all basado en la nueva poltica de salida. Figura 1 Soft reset
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 reconfiguracin suave de entrada: Usar informacin de actualizacin de enrutamiento almacenada Dinmicamente 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 poltica 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.
Figura 2 Soft reset default-metric
Figura 3 Soft reset dinmico
Cisco IOS Software Release 12.0(2)S y 12.0(6)T introdujo un realce de las caractersticas de soft reset de BGP, tambin conocida como route refresh, que proporciona la ayuda automtica para el reajuste del software dinmico de las actualizaciones de entrada de la tabla de enrutamiento de BGP, y no es dependiente sobre la informacin almacenada de la actualizacin de la tabla de enrutamiento. El comando clear ip bgp soft in pone esta caracterstica en ejecucin. Este mtodo no requiere ninguna preconfiguracin y necesita perceptiblemente menos memoria que el mtodo suave anterior para las actualizaciones de la tabla de enrutamiento de entrada. Nota: El comando clear ip bgp soft realiza una reconfiguracin suave de las actualizaciones de entrada y de salida. La opcin soft in genera nuevas actualizaciones de entrada sin resetear la sesin 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 poltica de entrada de BGP y t no deseas completar un hard reset, configure el router para realizar una reconfiguracin 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 automticamente asumido.
6.4.12 El comando debug ip bgp

La figura 1 muestra la salida parcial del comando debug ip bgp updates en el router A despus de que el comando clear ip bgp fuera publicado para borrar las sesiones BGP con su IBGP neighbor 10.1.0.2. Despus de que se restablezca la adyacencia vecina, el router A crea y enva actualizaciones a 10.1.0.2. La primera actualizacin se destac en la figura, 10.1.1.0 /24, next 10.1.0.1, es una actualizacin sobre la red 10.1.1.0 /24, con un next hop de 10.1.0.1, que es la direccin del router A. La segunda actualizacin destacada en la figura, 10.97.97.0/24, next 172.31.11.4, es una actualizacin sobre la red 10.97.97.0/24, con un next hop de 172.31.11.4, el cual es la direccin de uno Figura 1 Comando debug ip bgp updates de los EBGP neighbors del router A. La direccin del hop next de EBGP se est llevando dentro de IBGP. El router A recibe ms adelante actualizaciones de la 10.1.0.2. La actualizacin 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 actualizacin se describen en la siguiente leccin. Nota: Debbugging utiliza recursos del router y debe ser encendido solamente cuando es necesario.
6.5 Seleccionando un BGP Path

6.5.1 Caractersticas de los atributos de BGP
Los BGP routers envan mensajes de actualizacin BGP sobre redes destino a otros BGP routers. Los mensajes de actualizacin contienen una o ms rutas y un set de sistema de mtricas 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 tambin ser parcial. No todas las combinaciones de estas caractersticas son vlidas. Los atributos de Path caen en las cuatro categoras siguientes: Well-known mandatory Well-known discretionary Optional transitive Optional nontransitive
Figura 1 Atributos path BGP
Solamente los atributos Optional transitive se pueden marcar como parciales.
37
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 wellknown 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: Figura 3 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 ejecucin 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
Figura 2 Atributos bien conocidos
6.5.2 Atributos de BGP

Lo que sigue es una lista de los atributos comunes de BGP segn a las categoras que ellos pertenecen figura 1 Well-known mandatory attributes o Sistema Autnomo 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)
Figura 1 Atributos BGP
Nota: Adems, 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 tpicos, a excepcin de los atributos atomic aggregate y aggregator Estos dos atributos se relacionan con la summarization (o la agregacin) de BGP, y puedes encontrar ms informacin sobre ellos en Cisco.com
6.5.3 Atributo AS Path

El AS path es un atributo well-known mandatory. Siempre que una actualizacin de ruta pase a travs de un Sistema Autnomo, el nmero del Sistema Autnomo es agregado a esa actualizacin cuando se anuncia al siguiente EBGP neighbor.
El atributo AS path es realmente la lista de los nmeros de Sistemas Autnomos que una ruta ha atravesado para alcanzar un destino, con el nmero del Sistema Autnomo 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 nmero del Sistema Autnomo a este. Cuando la 192.168.1.0 alcanza el router B, tiene dos nmeros de Sistema Autnomo unidos a este. Desde la perspectiva del router B, la trayectoria para alcanzar la 192.168.1.0 es (65500, 64520) Un proceso similar se aplica para las trayectorias a las redes 192.168.2.0 y 192.168.3.0. La trayectoria o path del router A a la 192.168.2.0 es (65500, 65000), lo cual significa que atraviesa el AS 65500 y luego el AS 65000. El router C debe atravesar el path (65000) para alcanzar la 192.168.2.0, y el path (64520) para alcanzar a la 192.168.1.0.
Figura 1 Atributo AS path
6.5.4 Atributo Next-Hop

El atributo del next hop de BGP es un atributo well-known mandatory que indica la direccin IP del next hop que debe ser utilizada para alcanzar un destino. BGP enruta Sistema Autnomo por Sistema Autnomo, no router por router. El atributo del next hop define la direccin IP del router frontera que se debe utilizar como el next hop para el destino. Para EBGP, el next hop es la direccin IP del vecino que envi la actualizacin. 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. Figura 1 Atributo Next-hop 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 (direccin 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, va un IGP o una ruta esttica. Si no, este eliminar los paquetes destinados a la red 172.16.0.0, porque no puede conseguir la direccin 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
39
6.5.5 Atributo Origen

El atributo origen define el origen de la informacin de la trayectoria. El atributo origen puede ser uno de estos tres valores: figura 1 IGP La ruta es interior al Sistema Autnomo que origina. Este valor normalmente resulta cuando el comando network es utilizado para anunciar la ruta va BGP. Un origen de IGP se indica con una i en la tabla BGP EGP: La ruta se ha aprendido va EGP. Este valor se indica con una e en la tabla BGP. El EGP se considera un protocolo histrico 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 algn otro medio. Este valor resulta generalmente cuando una ruta se redistribuye en BGP. Un origen incompleto se indica con un signo de interrogacin (?) en la tabla BGP La figura 2 muestra un ejemplo de la salida del comando show ip bgp El cdigo de origen, refleja que el atributo origen, est en la ultima columna al final de cada lnea. En este ejemplo, todos los cdigos de origen son i, indicando un atributo origen de IGP; las rutas son interiores al Sistema Autnomo que origina.
Figura 1 Atributo origen
Figura 2 Ejemplo: Atributo origen
6.5.6 Atributo Local Preference

La preferencia local (Local preferente) es un atributo well-known discretionary que proporciona una indicacin a los routers en el Sistema Autnomo sobre cual trayectoria se prefiere para salir del Sistema Autnomo. Una trayectoria con una preferencia local ms 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 Autnomo nicamente. El valor prefijado para la preferencia local en un router Cisco es 100. En la figura 1, el AS 64520 recibe actualizaciones sobre la red 172.16.0.0 a partir de dos direcciones. La preferencia local en el router A para la red 172.16.0.0 se
Figura 1 Atributo preferencia local

40
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 informacin de la local preferente es intercambiada dentro del AS 64520, todo el trfico en el AS 64520 direccionado a la red 172.16.0.0 se enva al router A como punto de salida del Sistema Autnomo 64520 (debido a su preferencia local ms alta)
6.5.7 Atributo MED

El atributo MED, tambin llamado la mtrica, es un atributo no transitivo opcional. El MED es una indicacin a los EBGP neighbors sobre la trayectoria preferida en un Sistema Autnomo. El atributo MED es una manera dinmica de influenciar a otro Sistema Autnomo sobre cual trayectoria este debe elegir para alcanzar una cierta ruta en su Sistema Autnomo cuando existen mltiples puntos de entrada. Se prefiere la mtrica mas baja. Distinto a la preferencia local, el MED se intercambia entre los sistemas autnomos. El MED se enva a los EBGP peers. Esos routers propagan el MED dentro de su Sistema Autnomo, y los routers dentro del Sistema Autnomo utilizan el MED pero no lo pasan encendido al siguiente Sistema Autnomo. Cuando la misma actualizacin se pasa encendida a otro Sistema Autnomo, la mtrica se fija de nuevo por defecto a 0. MED influencia al trfico de entrada de un Sistema Autnomo, y la preferencia local influencia al trfico de salida. Por defecto, un router compara el atributo de MED solamente para las trayectorias de vecinos en el mismo Sistema Autnomo Nota: El atributo de MED significa que BGP es el nico protocolo que puede afectar cmo las rutas se envan en un Sistema Autnomo. En la figura 1, el atributo del router B MED se fija a 150, y el atributo del router C MED se fija a 200. Cuando el router A recibe actualizaciones de los routers B y C, elige al router B como el mejor next hop ya que su MED de 150 es menor que la del router C.
Figura 1 Atributo MED
6.5.8 Atributo Weight

El atributo weight es un atributo de Cisco para la seleccin de trayectoria. El peso se configura localmente en un router y no se propaga a ningn otro routers. Esta cualidad se aplica cuando ests utilizando un router con mltiples puntos de salida en Sistema Autnomo, en comparacin con el atributo de preferencia local, el cual es usado cuando dos o ms routers proporcionan puntos mltiples 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 ms alto son preferidas Figura 1 Atributo Weight (solo Cisco)
41
cuando las mltiples 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 actualizacin 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 ms 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 seleccin del BGP Path

Mltiples trayectorias pueden existir para alcanzar una red dada. Como las trayectorias para una red se evalan, esto determinada que las que no sean la mejor trayectoria sean eliminadas de los criterios de seleccin 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 disea para realizar balancear Figura 1 Seleccin path BGP de la carga. Las trayectorias se eligen debido a la poltica, no se basan en el ancho de banda. El proceso de seleccin de BGP elimina cualquier trayectoria mltiple hasta que una sola mejor trayectoria es dejada. La mejor trayectoria se somete al proceso de administracin de la tabla de enrutamiento y se evala contra cualquier otro protocolo de enrutamiento que pueda tambin alcanzar esa red. La ruta de origen con la distancia administrativa ms baja es instalada en la tabla de enrutamiento. El proceso de decisin es basado en los atributos descritos tempranamente
6.5.10 Seleccionando un BGP Path

Despus de que el BGP recibe actualizaciones sobre diversos destinos de diversos sistemas autnomos, este elige la mejor trayectoria para alcanzar un destino especfico. El proceso de decisin se basa en los atributos de BGP. BGP considera solamente las rutas sincronizadas sin lazos del Sistema Autnomo y un next hop vlido. El siguiente proceso resume cmo BGP elige la mejor ruta en un router Cisco: figura 1 1. Preferir la ruta con el peso ms alto. (El atributo del peso es propietario a Cisco y es local a router solamente.) 2. Si mltiples rutas tienen el mismo peso, preferir la ruta con el ms alto valor de preferencia local. (La preferencia local se utiliza dentro de un Sistema Autnomo.) 3. Si las rutas mltiples 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 ms corta de Sistema Autnomo. 5. Si la longitud de trayectoria de Sistema Autnomo es igual, preferir Figura 1 Proceso de seleccin de ruta el cdigo de origen ms bajo (IGP < EGP < incompleto).
6. Si todos los cdigos de origen son iguales, preferir la trayectoria con el MED ms bajo. (El MED se intercambia entre Sistema Autnomos.) se hace la comparacin de MED solamente si el Sistema Autnomo vecino es igual para todas las rutas consideradas, a menos que el comando bgp alwayscompare-med este habilitado Nota: La decisin ms 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 estndar del IETF, utilizar el comando bgp bestpath missing-asworst 7. Si las rutas tienen el mismo MED, preferir trayectorias externas a las trayectorias internas. 8. Si la sincronizacin es deshabilitada y solamente permanecen las trayectorias internas, preferir la trayectoria a travs del vecino ms cercano de IGP, que significa que el router prefiere la trayectoria interna ms corta dentro del Sistema Autnomo para alcanzar el destino (el Shortest-Path al next hop del BGP). 9. Para los EBGP paths, seleccionar la ruta ms vieja para reducir al mnimo el efecto de las rutas que van hacia arriba y hacia abajo (flapping). 10. Preferir la ruta con el valor ms bajo de la identificacin del BGP router del vecino. 11. Si las identificaciones de los routers BGP son iguales, preferir el router con la direccin 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 seleccin de la ruta sumarizada aqu no cubre todos los casos sino es suficiente para una comprensin bsica de cmo BGP selecciona las rutas. Por ejemplo, suponer que hay siete trayectorias para alcanzar la red 10.0.0.0. Todas las trayectorias no tienen ningn lazo de Sistema Autnomo y tienen direcciones vlidas 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 continan el proceso de la evaluacin al paso siguiente. Los otros tres todava estn en la BGP forwarding table, pero son actualmente descalificadas como la mejor trayectoria. BGP contina el proceso de evaluacin 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 Seleccin de la trayectoria (path) con conexiones Multihomed

Un Sistema Autnomo raramente implementa BGP con una nica conexin EBGP. Esta situacin significa generalmente que mltiples 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 seleccin de trayectoria que ocurra porque hay solamente una trayectoria, y la manipulacin de ella no produce ninguna ventaja. La figura 1 destaca las razones ms comunes para la seleccin del path. Sin la Figura 1 Proceso de seleccin de ruta
43
manipulacin de la ruta, la razn ms comn de seleccin de trayectoria es el paso 4, la preferencia por la trayectoria ms corta de Sistema Autnomo. 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 Autnomo. 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.
Figure 2 Proceso de seleccin de ruta
El paso 4 selecciona la trayectoria que tiene el ms corto Sistema Autnomos a cruzarse. sta es la razn ms comn que una trayectoria se selecciona en BGP. Si un administrador de red no tiene gusto de la trayectoria con el ms corto Sistema Autnomos, 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 cmo una red fue introducida en el BGP. Esta introduccin se logra generalmente con las declaraciones de red (i para un cdigo de origen) o a travs de redistribucin (? para un cdigo de origen). El paso 6 mira el MED para juzgar donde el Sistema Autnomo vecino quisiera que este Sistema Autnomo enviara los paquetes para una red dada. Cisco fija el MED a 0 por defecto; por lo tanto, MED no participa en la seleccin de la trayectoria a menos que el administrador de red del Sistema Autnomo vecino manipule las trayectorias usando MED Si las mltiples trayectorias tienen el mismo nmero de Sistemas Autnomos a atravesarse, el segundo punto de decisin mas comn 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 Autnomo 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 Autnomo. Si la trayectoria del Sistema Autnomo es igual y el router en un Sistema Autnomo no tiene ningn EBGP neighbor para esa red (solamente IBGP neighbors), tiene sentido tomar la trayectoria ms rpida al punto ms cercano de la salida. El paso 8 busca al IBGP neighbor ms cercano. La mtrica IGP determina que significa ms 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 Autnomo es igual y los costes va todos los IBGP neighbors son iguales, o si todos los vecinos para esta red son EBGP, el paso 9 es la siguiente razn ms comn de seleccionar una trayectoria sobre otra. Los EBGP neighbors rara vez establecen sesiones al tiempo exacto. Una sesin es probable que sea ms vieja que otra, as que las trayectorias a travs de esos viejos vecinos son consideradas ms estables ya que han estado arriba anteriormente Si todos los criterios mencionados son iguales, la siguiente decisin ms comn es tomar al vecino con la identificacin ms baja del BGP router, que es el paso 10. Si las identificaciones del BGP router son iguales (por ejemplo, si las trayectorias estn a el mismo BGP router), el paso 11 indica que la ruta con el la direccin IP vecino ms baja es utilizada
44
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 diseado para elegir la trayectoria ms rpida. BGP fue diseado para manipular la circulacin para maximizar o para reducir al mnimo uso del ancho de banda. Esta figura demuestra una situacin comn que puede resultar cuando ests utilizando BGP sin ninguna manipulacin de la poltica. Utilizar default settings para la seleccin 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 utilizacin es aceptable por el administrador, no hay manipulacin necesaria.
Figura 1 BGP es designado para implementar la poltica de enrutamiento
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 situacin causa perdida de paquetes, ms alta latencia, y ms alto uso de CPU debido al nmero de paquetes que est siendo ruteado. Cuando otro link a la misma localizacin est disponible y no es muy usado, tiene sentido de dividir algo del trfico a la otra trayectoria. Para cambiar la seleccin 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 anlisis del trfico sobre el borde de Internet examinando las direcciones de pginas web, o los nombres de dominio visitadas y mas pesadas. Esta informacin puede ser encontrada generalmente examinando expedientes de administracin de la red o informacin de contabilidad de un firewall.
6.6.2 Seteando Local Preference con ejemplo de Route Maps

En a figura 1, asumir que el 35 por ciento de todo el trfico del AS 65001 han estado yendo a www.cisco.com. El administrador puede obtener la direccin de Cisco o el nmero de AS realizando operaciones de bsqueda reversas del Domain Name System (DNS) o yendo a www.arin.net y buscando el nmero de AS de Cisco Systems o del espacio de direcciones que se asigna a la compaa. Despus de que se haya determinado esta informacin, el administrador utiliza route maps para manipular la seleccin de la trayectoria para la red de Cisco.
Figura 1 BGP es designado para implementar la poltica de enrutamiento
Usando un route map, el router B puede anunciar todas las redes que se asocien a ese Sistema Autnomo con una preferencia local ms alta que el router A anuncia para esas redes. Otros routers en el AS65001 corren BGP prefieren las rutas con la preferencia local ms alta. Para las redes Cisco, el router B anuncia la preferencia local ms alta, as que todo el trfico destinado para ese Sistema Autnomo sale del AS 65001 va el router B. La carga de salida para el router B aumenta su carga anterior de 20 por ciento para contar por el trfico adicional del AS 65001 destinado a las redes Cisco. La carga de salida para el router A, que era originalmente 60 por ciento, debe disminuir, y este cambio trae a la carga de salida en ambos links en equilibrio relativo
As como hay problemas de carga de salida en el AS 65001, puede haber un problema similar en la entrada. Puede ser que los sales web servers estn localizados en la misma subred detrs del router B, causando que la carga de entrada para el router B haga un promedio de una utilizacin ms alta. Para manipular cmo el trfico entra en un Sistema Autnomo, utilice el atributo de BGP MED. Por ejemplo, AS 65001 anuncia un MED ms bajo para la red 192.168.25.0/24 para el AS 65004 fuera del router A. Este MED es una recomendacin al siguiente Sistema Autnomo en cmo entrar al AS 65001; sin embargo, la MED no es considerada hasta el paso 6 del proceso de seleccin de trayectoria BGP. Si el AS 65004 prefiere guardar su trayectoria de Sistema Autnomo va el router Y al router B en el AS 65001, el AS 65004 simplemente necesita tener que el router Y anuncie una preferencia local ms 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 evala antes del MED que viene del router A en el AS 65001. MED es considerado una recomendacin ya que el Sistema autnomo de recepcin puede eliminarla teniendo que ese Sistema Autnomo manipule un valor antes de que se considere la MED. En la figura, asumir que el 55 por ciento de todo el trfico esta yendo a la subred 192.168.25.0/24 (router A). La utilizacin de entrada al router A est promediando solamente el 10 por ciento, pero la utilizacin de entrada al router B est promediando un 75 por ciento. Si el AS 65001 fuese fijado para preferir que todo el trfico yendo a la 192.168.25.0 /24 entre a travs 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 disminuira. El problema es que si la carga de entrada para los puntos del router A sube ms del 100 por ciento y causa que este link aletee, todas las sesiones que cruzan por ese link podran perderse. Si estas sesiones fueran compradas siendo hechas en los servidores de web del AS 65001, el rdito sera 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 manipulacin de la trayectoria no puede ser necesaria; sin embargo, cuando un link comienza a alcanzar la capacidad del link por un perodo del tiempo extendido, ms ancho de banda es necesitado o la manipulacin de la trayectoria debe ser considerada
6.6.3 Cambiando la Local Preference de BGP para todas las Rutas

La preferencia local se utiliza solamente dentro de un Sistema Autnomo entre IBGP speakers para determinar la mejor trayectoria para salir del Sistema Autnomo para alcanzar una red exterior. La preferencia local es fijada a 100 por defecto; se prefieren valores ms altos. El comando bgp default local-preference cambia el valor por defecto de la preferencia local. La Figura 1 y 2 exhibe el parmetro del comando. Con este comando, todas las rutas IBGP que son anunciadas tienen la preferencia local en un valor especfico 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 Parmetro del comando bgp default local-preference
46
6.6.4 Ejemplo de Local Preference en BGP

La figura 1 ilustra un ejemplo de red que corre BGP para demostrar la manipulacin 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 estn aprendiendo de los IBGP neighbors de A y de B. El paso 3 no ayuda a decidir la Figura 1 Preferencia local 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 Autnomos. Las opciones son dos Sistemas Autnomos (65002, 65003) a travs del router A o tres Sistemas Autnomos a travs del IBGP neighbor router B (65005, 65004, 65003). De esta manera, las ms corta trayectoria de Sistemas Autnomos del router C al AS 65003 es a travs del router A. La mejor trayectoria del router C a las redes en el AS 65005 tambin es seleccionada por paso 4. El ShortestPath del router C al AS 65005 est a travs del router B, porque este consiste en un AS (65005) comparado con los cuatro Sistemas Autnomos (65002, 65003, 65004, 65005) a travs del router A. La mejor trayectoria del router C a las redes en el AS 65004 tambin es seleccionado por el paso 4. El ShortestPath del router C al AS 65004 est a travs del router B, porque este consiste en dos Sistemas Autnomos (65005, 65004) comparado a los tres Sistema Autnomos (65002, 65003, 65004) a travs del router A.
6.6.5 Ejemplo de Local Preference en BGP (continuacin)

La figura 1 muestra la BGP forwarding table en el router C en el AS 65001 con solamente los default settings para la seleccin de trayectoria BGP. El diagrama muestra solamente las redes de inters 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, sincronizacin-deshabilitada, y que tienen una direccin vlida. 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 seleccin 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 ms corta de Sistemas Autnomos como sigue: Para la red 172.16.0.0, la trayectoria ms corta de Sistema Autnomo de dos Sistema Autnomos (65002, 65003) est a travs del next hop de 192.168.28.1. Para la red 172.24.0.0, la trayectoria ms corta de Sistema Autnomo del (65005) est a travs del next hop de 172.20.50.1. Para la red 172.30.0.0, la trayectoria ms corta de Sistema Autnomo de (65005, 65004) est a travs del next hop de 172.20.50.1.
47
Ninguno de los dos ni el router A ni el router B esta utilizando la opcin next-hop-self en este ejemplo Un anlisis de trfico revela lo siguiente: El link a travs del router B a la 172.20.50.1 es muy usado, y el link a travs 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 trfico del Internet va a la red 172.24.0.0 (va el router B); 20 por ciento van a la red 172.30.0.0 (va el router B); y 10 por ciento van a la red 172.16.0.0 (va el router A). Los otros 40 por ciento van a otras Figura 1 Tabla con valores por defecto del Router C destinos. Solamente 10 por ciento de todo el trfico esta utilizando el link fuera del router A a la red 192.168.28.1, y el 50 por ciento de todo el trfico est utilizando el link fuera del router B a la 172.20.50.1 El administrador de red ha decidido desviar el trfico 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 ms equilibrado.
6.6.6 Ejemplo de Local Preference en BGP (continuacin)

La figura 1 muestra que usando un route map en el router A para alterar la actualizacin 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 lnea del route map es una declaracin de permiso con un nmero de secuencia de 10 para un route map llamado local_pref; esto define la primera declaracin del route-map. La condicin de emparejamiento para esta declaracin 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.
Figura 1 Route map para el router A
La segunda declaracin del route map es una declaracin de permiso con un nmero de secuencia de 20 para el route map local_pref, pero no tiene ningn match o declaraciones fijadas. Esta declaracin es una declaracin de permit-all para todos los route maps. Ya que no hay condiciones de match para las redes restantes, estn 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 nmero de secuencia de 20 se elige para la segunda declaracin en caso de que otras polticas ms adelante tengan que ser puestas en ejecucin antes de la declaracin permit-all
Este route map se liga al neighbor 192.168.28.1 como un route map de entrada; por lo tanto, como el router A recibe actualizaciones de la 192.168.28.1, las procesa a travs del route map del local_pref y fija la preferencia local segn 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 despus de que la sesin BGP ha sido reseteada. Esta ilustra que el router C ha aprendido sobre el nuevo valor de local preferente (400) que vena 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 manipulacin 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 ms alta que la preferencia local de 100 para el next hop de 172.20.50.1. La trayectoria de Sistema Autnomo a travs de la 172.20.50.1 sigue siendo ms corta que la trayectoria con la 192.168.28.1, pero la longitud de la trayectoria no se evala hasta el paso 4, mientras que la preferencia local se examina en el paso 2. La trayectoria con la ms alta preferencia local elegida como la mejor trayectoria
Figura 2 Tabla con preferencia locales aprendidas en el Router C
6.6.7 Seteando la MED con Route Maps

Recordar que MED es utilizado para decidir cmo entrar en un Sistema Autnomo. Se utiliza cuando las trayectorias mltiples existen entre dos Sistema Autnomos y un Sistema Autnomo est intentando influenciar en la trayectoria entrante del otro. Ya que MED se evala tarde en el proceso de seleccin de trayectoria de BGP (paso 6), no tiene generalmente ninguna influencia en el proceso de seleccin de BGP. Por ejemplo, un Sistema Autnomo que recibe un MED para una ruta puede cambiar su preferencia local para permitir al Sistema Autnomo eliminar lo que est anunciando el otro Sistema Autnomo con su valor de MED.
Figura 1 Cambiando MED para todos los routers
Figura 2 Parmetro del comando default-metric
Cuando BGP est comparando los valores de MED para la misma red destino en el proceso de seleccin de trayectoria, se prefiere el valor ms bajo de MED. El valor por defecto de MED para cada red que un Sistema Autnomo 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 parmetros de este comando
6.6.8 BGP Utilizando Route Maps y un Ejemplo de MED

La figura 1 es utilizada en la siguiente configuracin para demostrar cmo manipular el trfico de entrada utilizando route maps para cambiar el atributo BGP MED. La intencin de estos route maps es sealar al router A como la trayectoria preferida para alcanzar las redes 192.168.25.0/24 y 192.168.26.0/24, y para sealar al router B como la trayectoria preferida para alcanzar la red 192.168.24.0/24. Las otras redes deberan aun estar accesibles a travs de cada router en caso de que un link o router falle
6.6.9 BGP Utilizando Route Maps y un Ejemplo de MED (continuacin)

El MED es fijado de salida cuando un router est anunciando a un EBGP neighbor. En el ejemplo de configuracin 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 enva una actualizacin al neighbor 192.168.28.1 (router X), procesa la actualizacin de salida a travs del route map med_65004 y utiliza una declaracin del sistema para cambiar cualquiera de valores que son especificados, siempre y cuando la declaracin de emparejamiento precedente se resuelva en la seccin del route map.
Figura 1 Usando route maps y el MED
La primera lnea del route map es una Figura 1 Route map para el router A declaracin de permiso con un nmero de secuencia de 10 para el route map med_65004. Esto define la primera declaracin del route-map. La condicin de match para esta declaracin chequea todas las redes que son permitidas por la access list 66 La primera lnea de la access list 66 permite a cualquier red que comience con los primeros tres octetos de 192.168.25.0, y la segunda lnea 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 lneas se fijan un MED de 100. El resto de las redes son negadas por esta access list (hay un implcito 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 declaracin de route map en el route map med_65004. La segunda declaracin del route map es una declaracin de permiso con un nmero de secuencia de 100 para el route map med_65004. El route map no tiene ninguna declaracin de match, apenas tiene el comando set metric 200. Este es una declaracin de permitir todo para los route maps. Ya que el administrador de red no especifica una condicin de match para esta porcin del route map, todas las redes que son procesadas a travs de esta seccin del route map (nmero 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 habra sido un MED de
0. Puesto que 0 es menos que 100, las rutas con un MED de 0 habran sido las trayectorias preferidas a las redes en el AS 65001. Semejantemente, en el ejemplo de configuracin 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 enve una actualizacin al neighbor 172.20.50.1, procesa la actualizacin de salida a travs del route map med_65004 y utiliza una declaracin del sistema para cambiar cualquier valor que este especificado, siempre y cuando la declaracin precedente de emparejamiento se resuelva en esta seccin del route map. La primera lnea del route map es una Figura 2 Route map para el router B declaracin de permiso con un nmero de secuencia de 10 para el route map med_65004, el cual define la primera declaracin del route-map. La condicin de emparejamiento para esa lnea 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 lnea 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 declaracin en el route map med_65004. La segunda declaracin del route map es una declaracin de permiso con un nmero de secuencia de 100 para el route map med_65004, pero no tiene ninguna declaracin de match, apenas un comando set metric 200. Este es una declaracin de todo permiso para los route maps. Ya que el administrador de red no especfica una condicin de match para esta porcin 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 habra sido fijado con un MED de 0. ya que 0 es menos de 100, las rutas con un MED de 0 habran sido las trayectorias preferidas a las redes en el AS 65001
6.6.10 BGP Utilizando Route Maps y un Ejemplo de MED (continuacin)

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 mltiples trayectorias para alcanzar a cada red. Figura 1. Todas estas trayectorias tienen direcciones vlidas de next hop, tienen sincronizacin inhabilitada, y estn 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 algn 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 Autnomo (65001) y fueron introducidas dentro del BGP con declaracin de red (i es el cdigo de origen), as que los pasos 4 y 5 son iguales. El paso 6 indica que BGP elige la MED ms baja si todos los pasos precedentes son igual o no se aplican.
51
Para la red 192.168.24.0, el next hop de 172.20.50.2 tiene una MED ms baja que el next hop de 192.168.28.2; por lo tanto, para la red 192.168.24.0, la trayectoria a travs 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 ms bajo de 100 comparado al MED de 200 a travs del next hop de 172.20.50.2; por lo tanto, 192.168.28.2 es la trayectoria preferida para esas redes
Figura 1 MED aprendido por el router Z
6.6.11 Implementando BGP en la Empresa

La figura 1 representa una puesta en prctica tpica de BGP en una empresa. La empresa es multihomed a dos ISPs para aumentar la confiabilidad y el funcionamiento de su conexin al Internet. El ISPs puede pasar solamente las rutas por defecto o puede tambin pasar otras rutas especficas, o an 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 trnsito dentro del Sistema Autnomo de la empresa corren Figura 1 BGP en una empresa IBGP. Estos routers pasan las rutas por defecto a los otros routers en la empresa en vez de redistribuir BGP en el protocolo de enrutamiento interior. Los atributos de BGP pueden ser manipulados, utilizando los mtodos discutidos hasta ahora, con cualquier de los routers que corren BGP para afectar la trayectoria del trfico para y desde el Sistema Autnomos.
Resumen
El Internet ha demostrado ser una herramienta valiosa a muchas compaas, dando por resultado mltiples conexiones redundantes a muchos Internet service providers (ISPs). El Border Gateway Protocol (BGP) es utilizado por ISPs para mover trfico entre los sistemas autnomos y tambin utilizado por las compaas individuales que son multihomed para controlar la seleccin de trayectorias.
52
Mdulo 8: IPv6
Descripcin
IP version 6 (IPv6) fue desarrollado para superar las limitaciones del estndar 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 direccin. La explosin de nuevos dispositivos IP-enabled y el crecimiento de regiones subdesarrolladas han impulsado la necesidad de ms direcciones. En los Estados Unidos, el Department of Defense (DoD) es un conductor principal para la adopcin de IPv6. Las otras oportunidades de mercado principales son la National Research and Education Network (NREN), agencias gubernamentales, empresas, proveedores de servicio, home networking, electrodomsticos de consumidor, juego en lnea distribuido, y servicios wireless. Este mdulo proporciona una descripcin de IPv6, direccionamiento y enrutamiento IPv6, OSPFv3, y la traduccin IPv4 a IPv6.
8.1 Explicacin de IPv6

8.1.1 Introduccin 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 ms eficiente y feature-rich para enfrentar las demandas para redes escalables en el futuro. IPv6 satisface los requerimientos cada vez ms complejos de direccionamiento jerrquico 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 generacin 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 despus de que IPv6 reemplaze por completo a IPv4. Sin embargo, IPv4 no est en peligro de desaparecer de la noche a la maana. Ms bien, coexistir y despus ser substituido gradualmente por IPv6. Este cambio ya ha comenzado, particularmente en Europa, Japn, y Asia del Pacfico. Estas reas han estado agotando sus direcciones IPv4 asignadas, lo cual hace a IPv6 ms atractivo a todos. Adems de su potencial tcnico y de negocio, IPv6 ofrece virtualmente una fuente ilimitada de direcciones IP. IPv4 provee actualmente aproximadamente 2 billones direcciones utilizables con su espacio de direccin de 32 bits. Debido al abundante espacio de direccin 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 pases, tales como Japn, estn adoptando agresivamente IPv6. Otros, tales como la Unin Europea, se estn moviendo hacia IPv6, y China est considerando construir redes puras IPv6 desde el ground up. Incluso en Norteamrica, 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 Caractersticas de IPv6

IPv6 es una mejora poderosa para IPv4, y varias caractersticas IPv6 ofrecen mejoras funcionales: Espacio de direccin ms grande: Ofrece alcanzabilidad y flexibilidad globales mejoradas; la agregacin de prefijos que se anuncian en las tablas de enrutamiento; multihoming a varios Internet
Modulo 8: IPV6 Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks 1
service providers (ISPs); autoconfiguracin que puede incluir direcciones de capa de enlace en el espacio de direccin; opciones plug-and-play; redireccionamiento publico a privado extremo a extremo sin traduccin de direccin; y mecanismos simplificados para renumeracin y modificacin de direccin. Encabezado ms 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 extensin ms simples y ms 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 estndares IP mvil 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 mviles - con muchos que tienen conectividad inalmbrica. Mobile IP es un estndar de la Internet Engineering Task Force (IETF) disponible para IPv4 e IPv6. El estndar permite a los dispositivos mviles moverse sin interrupciones en conexiones de red establecidas. Debido a que IPv4 no proporciona automticamente esta clase de movilidad, usted debe agregarla con configuraciones adicionales. IPsec es el estndar IETF para la seguridad de red IP, disponible para IPv4 e IPv6. Aunque las funcionalidades son esencialmente idnticas 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 ms segura. IPsec tambin requiere claves para cada parte, lo que implica un despliegue y distribucin claves global. Riqueza de transicin: 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 tcnica IPv6 sobre IPv4 (tambin llamada tunneling 6to4), que usa un tnel IPv4 para llevar trfico IPv6. Este mtodo (RFC 3056) reemplaza al tunneling IPv4-compatible (RFC 2893). Cisco IOS Software Release 12.3(2)T (y posteriores) tambin permite la protocol translation (NAT-PT) entre IPv6 e IPv4. Esta traduccin permite la comunicacin directa entre los hosts que hablan protocolos diferentes.
8.1.3 Espacio de Direccin Largo

IPv6 aumenta el nmero de bits direccin en un factor de cuatro, de 32 a 128, lo que permite un nmero muy grande de nodos direccionables. Sin embargo, como en cualquier esquema de direccin, no todas las direcciones estn utilizadas o disponibles. El uso de la direccin de protocolo IPv4 actual se extendi al aplicar tcnicas tales como NAT y asignaciones de direccin temporales. Pero la manipulacin de la carga til de los datos por dispositivos intermedios desafa (o complica) las ventajas de la comunicacin del peer-to-peer y la calidad de servicio (QoS). IPv6 da a cada usuario mltiples direcciones globales que se pueden usar para una variedad amplia de dispositivos, incluyendo celulares, personal digital assistants (PDAs), y vehculos IP-enabled. Estas direcciones son alcanzables sin usar la traduccin de direcciones IP, pooling, y tcnicas de asignacin temporales. El aumento del nmero de bits para la direccin tambin aumenta el tamao del encabezado IPv6. Debido a que cada encabezado IP contiene una direccin origen y destino, el tamao del campo de encabezado es de 256 bits para IPv6, comparado a los 64 bits para IPv4. Nota: Para ms informacin IETF sobre detalles del direccionamiento IPv6, consultar RFC 3513. Espacios de direccin ms grandes dan espacio a los ISPs y a las organizaciones para asignaciones de direccin 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 direccin incrementado es suficiente para permitir que las organizaciones definan un prefijo nico para la red entera.
Modulo 8: IPV6 Error! Nombre desconocido de propiedad de documento. CCNP: Building Scalable Internetworks
La agregacin de prefijos de cliente da lugar a una tabla de enrutamiento eficiente y escalable. El enrutamiento escalable es necesario para expandir la adopcin ms amplia de funciones de red, permitiendo que Internet adecuar lo siguiente: Nmero creciente de consumidores de banda ancha con de alta velocidad, conexiones always-on Los usuarios pasan mas tiempo online adquiriendo servicios de comunicacin (tales como msica) y participando en ofertas de alto valor que se pueden encontrar Redes caseras con aplicaciones de red expandidas tales como Voice over IP (VoIP) inalmbricas, vigilancia casera, y los servicios avanzados tales como vdeo 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 bsicos, seguidos por un campo de opciones y una porcin de datos (generalmente el segmento de capa de transporte). El encabezado IPv4 bsico tiene un tamao fijo de 20 octetos. El campo de opciones de longitud variable aumenta el tamao del encabezado IP total. IPv6 contiene cinco de los 12 campos de encabezado bsicos de IPv4. El encabezado IPv6 no requiere los otros siete campos. Los routers manejan fragmentacin en IPv4, lo que causa una variedad de problemas de procesamiento. Los routers IPv6 no realizan la fragmentacin. En su lugar, un proceso de descubrimiento determina la maximum transmission unit (MTU) ptima a usar durante una sesin dada. En el proceso de descubrimiento, el dispositivo IPv6 origen intenta enviar un paquete del tamao especificado por las capas superiores, tales como la capa del transporte o aplicacin. Si el dispositivo recibe un mensaje "ICMP packet too big", retransmite el paquete de descubrimiento MTU con un MTU ms pequeo y repite el proceso hasta que consiga una respuesta de que lleg intacto el paquete de descubrimiento. Luego fija la MTU para la sesin. El mensaje "ICMP packet too big" contiene el tamao de MTU apropiado para el camino. Cada dispositivo origen necesita hacer seguimiento del tamao de MTU para cada sesin. Generalmente, el seguimiento se hace creando un cache que se base en la direccin destino. Sin embargo, tambin puede ser hecho usando la etiqueta de flujo. Si se realiza el enrutamiento basado en el origen, el seguimiento del tamao de MTU puede usar la direccin origen. El proceso de descubrimiento es beneficioso porque, como los caminos de enrutamiento cambian, una MTU nueva podra ser la ms apropiada. Cuando un dispositivo recibe un mensaje "ICMP packet too big", ste disminuye el tamao 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 aplicacin y transporte para IPv6 aceptan notificaciones de reduccin 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 fragmentacin. Las tecnologas de la capa de enlace ya realizan checksum y control de error. Debido a que las tecnologas de la capa de enlace son relativamente confiables, una checksum de encabezado IP se considera redundante. Sin la checksum de encabezado IP, las checksums opcionales de capa superior, tales como el User Datagram Protocol (UDP), son obligatorias ahora.
8.2.2 Comparacin de los Encabezados IPv4 e IPv6

El encabezado IPv6 tiene 40 octetos, en contraste a los 20 octetos en IPv4. IPv6 tiene un menor nmero de campos, y el encabezado esta alineado a 64-bit para permitir el procesamiento rpido por los procesadores actuales. Los campos de direccin son cuatro veces ms grandes que en IPv4. El encabezado IPv6 contiene estos campos: Versin: Campo de 4 bits, lo mismo que en IPv4. Contiene el nmero 6 en vez del nmero 4 para IPv4. Clase de Trfico: Campo de 8 bits similar al campo type of sevice (TOS) en IPv4. Etiqueta al paquete con una clase de trfico 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 trfico sea etiquetado. Se puede usar para tcnicas de switching multicapa y ejecucion de conmutacin de paquetes ms rpido. 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 extensin. Este campo es similar al campo Protocolo en IPv4. Lmite de Salto: Especifica el nmero mximo 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. Direccin Origen: Este campo tiene 16 octetos o 128 bits. Identifica al origen del paquete. Direccin Destino: Este campo tiene 16 octetos o 128 bits. Identifica al destino del paquete. Encabezados de Extensin: Sigue a los ocho campos anteriores. El nmero de encabezados de extensin no es fijo, por lo que la longitud total de la cadena del encabezado de extensin es variable.
8.2.3 Encabezados de Extensin IPv6

Hay muchos tipos de encabezados de extensin. Cuando se usan mltiples encabezados de extensin en el mismo paquete, el orden de los encabezados debe ser como sigue: 1. Encabezado IPv6: Encabezado bsico 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 despus del encabezado del paquete IPv6 bsico. 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 tambin en cada direccin 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 mvil usa este encabezado. 4. Encabezado de enrutamiento: Usado para el enrutamiento del origen e IPv6 mvil (valor = 43). 5. Encabezado de fragmentacin: Usado cuando un origen debe fragmentar un paquete que sea ms 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 autenticacin y encabezado de carga til de seguridad de encapsulamiento: Usado dentro de IPsec para proporcionar autenticacin, integridad, y confidencialidad de un paquete. El encabezado de autenticacin (valor = 51) y el encabezado ESP (valor = 50) son idnticos para IPv4 e IPv6. 7. Encabezado de capa superior: Encabezados tpicos usados dentro de un paquete para transportar los datos. Los dos protocolos de transporte principales son TCP (valor = 6) y UDP (valor = 17).
8.2.4 Definicin de la Representacin de Direccin

Las direcciones IPv6 de 128 bits se representan dividindolas en ocho segmentos de 16 bits. Cada segmento se escribe en hexadecimal entre 0x000 y 0xFFF, separados por dos puntos. Los dgitos hexadecimales A, B, C, D, E, y F representados en IPv6 no son sensibles a maysculas. IPv6 no requiere notacin de la secuencia de la direccin de forma explcita. Use las pautas siguientes para las notaciones de la secuencia de la direccin 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 direccin. Una direccin sin especificar se escribe como "::" porque contiene solamente ceros. Usar la notacin "::" reduce grandemente el tamao de la mayora de las direcciones. Por ejemplo, FF01:0:0:0:0:0:0:1 se convierte en FF01::1. Nota: Un analizador sintctico de direccin identifica el nmero de ceros faltantes separando las dos partes e introduciendo 0 hasta que los 128 bits estn completos. Si se colocan dos notaciones "::" en la direccin, no hay forma de identificar el tamao de cada bloque de ceros.
8.2.5 Tipos de Direcciones IPv6

La estructura del direccionamiento IPv6 esta definida en mltiples 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 Direccin unicast Direccin muticast Direccin anycast Direccin Unicast Una direccin unicast identifica un solo dispositivo. Un paquete enviado a una direccin unicast es entregado a la interfaz identificada por esa direccin. Figura 1 Direccionamiento IPv6 unicast
Hay dos tipos de direcciones unicast: Direccin unicast de linklocal: El alcance se configura para enlace nico. La direccin es nica solamente en este enlace, y no es ruteable fuera del enlace. Direccin unicast global: Globalmente nica, as que puede ser enrutada globalmente sin modificacin. Figura 2 Tipos de direcciones IPv6 Una direccin 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 direccin unicast link-local. Sin embargo, una caracterstica fundamental del IPv6 es que una sola interfaz puede tambin tener mltiples direcciones IPv6 de cualquier tipo (unicast, anycast, y multicast). Nota: Tambin existe una direccin unicast de site-local; sin embargo, la IETF est trabajando actualmente en quitar o reemplazar direcciones site-local. Por lo tanto, este mdulo no incluye este tipo de direccin.
Direccin Multicast IPv6 no tiene direcciones de broadcast. El broadcasting en IPv4 da varios problemas: Genera un nmero 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 operacin eficiente de la red al usar funcionalmente grupos multicast especficos para enviar peticiones a un nmero limitado de computadoras en la red. Un paquete enviado a una direccin multicast se entrega a todas las interfaces identificadas por esa direccin. El rango de direcciones multicast en IPv6 es ms grande que en IPv4. Para el futuro prximo, la asignacin de grupos multicast no estar limitada. Direccin Anycast IPv6 tambin define un nuevo tipo de direccin llamado anycast. Una direccin anycast identifica una lista de dispositivos o nodos; por lo tanto, una direccin anycast identifica mltiples interfaces. Un paquete enviado a una direccin anycast se entrega a la interfaz ms cercana, segn lo definido por los protocolos de enrutamiento en uso. Las direcciones anycast son sintcticamente indistinguibles de direcciones unicast globales, porque las direcciones anycast se asignan del espacio de direccin unicast global. Nota: Las direcciones anycast no se pueden usar como la direccin origen de un paquete IPv6. Direcciones especiales Hay un nmero de direcciones con significado especial en IPv6. Algunos de stos se presentan en Figura 3
Figura 3 Direcciones especiales IPv6
8.2.6 Direcciones Unicast Globales y Anycast IPv6

Las direcciones unicast globales y anycast comparten el mismo formato. El espacio de direccin unicast asigna direcciones anycast. Estas direcciones aparecen como direcciones unicast para los dispositivos que no se configuran para anycast. Figura1. Cuando una direccin unicast se asigna a ms de una interfaz, volvindola asi en una direccin anycast, los nodos a los cuales se asigna la direccin se deben configurar explcitamente para usar y reconocer la direccin anycast. Un paquete que se enva a una direccin anycast enruta al dispositivo o interfaz ms cercana que comparte la direccin. Un remitente crea un paquete con anycast como la direccin destino y lo remite a su router ms cercano. El origen puede usar
Figura 1 Direcciones globales IPv6 unicast (y anycast) addresses

6
direcciones anycast para controlar el camino a travs 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 mltiples ISPs con mltiples conexiones a otro. El cliente puede configurar una direccin anycast diferente para cada ISP. Cada router para la ISP dada tiene la misma direccin anycast configurada. El dispositivo origen puede elegir a qu ISP enva el paquete. Sin embargo, los routers a lo largo del camino determinan el router ms cercano para alcanzar a es ISP usando la direccin anycast IPv6. Otro uso para un anycast se da cuando una LAN se une a mltiples routers. Estos routers pueden tener la misma direccin anycast IPv6 para que los dispositivos distantes necesiten identificar solamente la direccin anycast. Los dispositivos intermedios pueden elegir el mejor camino para alcanzar el punto de entrada ms cercano a esa subred. La direccin unicast global IPv6 es el equivalente de la direccin unicast global IPv4. La estructura de la direccin permite agregar prefijos de enrutamiento, de ese modo se limita el nmero de entradas en la tabla de enrutamiento global. Las direcciones unicast globales usadas en enlaces se agregan hacia arriba a travs 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 direccin unicast IPv6 comprende el rango de direccin IPv6 entera, a excepcin del FF00::/8 (1111 1111), el cual se usa para las direcciones multicast. La asignacin de direccin 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 direccin IPv6 total y es el bloque ms grande del bloque de direcciones asignadas. Las direcciones con un prefijo de 2000::/3 (001) al E000::/3 (111), a excepcin 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 direccin unicast global consiste tpicamente 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 Direccin Unicast Global Agregable IPv6, el prefijo de enrutamiento global incluy otros dos campos estructurados jerrquicamente llamados Top Level Aggregator y Next-Level Aggregator. Debido a que estos campos fueron basados en polticas, la IETF decidi quitarlos de los RFCs. Sin embargo, algunas redes IPv6 existentes desplegadas al principio pudieron todava usar redes basadas en arquitectura ms antigua. Un campo de subnet de 16 bits llamado ID de subred podra ser usada por organizaciones individuales para crear su propia jerarqua de direccionamiento local e identificar subredes. Este campo permite que una organizacin use hasta 65.535 subredes individuales. (el RFC 2374 ha sido sustituido por el RFC 3587.)
8.3 Direcciones IPv6 Dinmicas

8.3.1 Definicin de las Direcciones de Interfaz de Host
Una direccin 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 dinmicamente basado en medios de capa 2 y encapsulacin. En el caso simple de un medio Ethernet, el identificador local usualmente se deriva de la direccin MAC EUI-48. El identificador local de 64 bits en una direccin 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 tambin ser nico sobre un alcance ms amplio. En muchos casos, un identificador de interfaz es igual a o se basa en la direccin (MAC) de capa de enlace de una interfaz. Como en IPv4, un prefijo de subred en IPv6 se asocia con un enlace.
8.3.2 Direccin Local de Enlace

Los identificadores de interfaz en direcciones IPv6 identifican interfaces en un enlace. Las direcciones link-local tambin pueden ser pensadas como la porcin de host de una direccin IPv6. La direccin 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 podran remitirlos a otros enlaces no estn permitidos porque no ha habido verificacin de la unicidad fuera del contexto del enlace origen. Fig.1 Las direcciones link-local se crean Figura 1 Direcciones de enlace local dinmicamente usando un prefijo linklocal de FE80::/10 y un identificador de interfaz de 64 bits en un proceso llamado autoconfiguracin stateless.
8.3.3 Autoconfiguracin Stateless

La autoconfiguracin stateless es una caracterstica plug-and-play que permite a los dispositivos conectarse automticamente con una red IPv6 sin configuracin 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 autoconfiguracin stateless no necesita ningn servidor o relevo porque no hay estado a mantener. Cada sistema IPv6 (con excepcin de los routers) puede construir su propia direccin global unicast, lo cual permite nuevos dispositivos, tales como celulares, los dispositivos inalmbricos, electrodomsticos, y redes caseras, se desplieguen en la Internet. Debido a que la longitud de prefijo es fija y bien conocida, un sistema construye automticamente una direccin link-local durante la fase de la inicializacin de los NICs IPv6. Despus de la verificacin de unicidad, este sistema puede comunicarse con otros hosts IPv6 en ese enlace sin ninguna otra intervencin manual. Para un sistema conectado con un enlace Ethernet, la construccin y validacin de la direccin link-local se logra en las fases siguientes. Figura 1.
Figura 1 Fases de autoconfiguracin stateless
Fase 1 Aunque manualmente configurable, el mtodo ms comn para obtener un identificador nico en un enlace Ethernet es usando la direccin MAC EUI-48 y aplicando el algoritmo estndar IEEE EUI-64 modificado. Por ejemplo, al transformar la direccin MAC 00-0C-29-C2-52-FF usando los estndares EUI-64 conduce a 000C-29-FF-FE-C2-52-FF. Si esta direccin es para permanecer local, la notacin IPv6 sera 000C:29FF:FEC2:52FF. Sin embargo, si la direccin es para ser una direccin unicast global, el formato correcto es 020C:29FF:FEC2:52FF. Nota: Para direcciones con alcance global, la porcin inicial de la direccin MAC se altera de 00-0C a 02-0C. Este proceso se discute en el tpico siguiente.
Fase 2 El bien conocido prefijo link-local fe80::/64 se premedita al identificador de 64 bits a partir de la fase uno para crear la direccin link-local de 128 bits, por ejemplo, fe80::20c:29ff:fec2:52ff. Esta direccin se asocia a la interfaz y etiquetada como "tentativa Fase 3 Antes de la asociacin final, es necesario verificar la unicidad de la direccin en el enlace, llamada duplicate address detection (DAD). La probabilidad de tener una direccin 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 enva paquetes ICMPv6 en el enlace donde la deteccin tiene que ocurrir. Esos paquetes contienen mensajes de solicitacin de vecino. Su direccin origen es la direccin indefinida "::", y la direccin objetivo es la direccin tentativa. Un nodo que ya esta usando esta direccin tentativa contesta con un mensaje de anuncio de vecino. En ese caso, la direccin no se puede asignar a la interfaz. Si no hay respuesta, se asume que la direccin es nica y se puede asignar a la interfaz. Si la direccin no es nica debe ser manipulada manualmente. Fase 4 Esta fase quita la etiqueta tentativa y formalmente asigna la direccin a la interfaz de red. El sistema puede ahora comunicarse con sus vecinos en el enlace. Para intercambiar la informacin 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 autoconfiguracin link-local automtico se aade a este prefijo global en la fase 2. Generalmente, los prefijos globales son distribuidos a las compaas 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 autoconfiguracin stateless y el acercamiento de thick-client de DHCP stateful. DHCP stateless para IPv6 tambin 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 direccin MAC (IEEE 802) tiene 48 bits de longitud. El espacio para el identificador local en una direccin IPv6 es de 64 bits. El estndar EUI-64 explica cmo 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 direccin MAC 0090-27-17-FC-0C usando el estndar EUI-64 da como resultado 00-90-27-FF-FE-17-FC0C. Al convertir esto en notacin IPv6 generara 0090:27FF:FE17:FC0C. Fig.1 Cuando el identificador de interfaz se crea a partir de una direccin MAC Ethernet, se asume que la direccin MAC es universalmente nica y, por lo tanto, que el identificador de interfaz es universalmente nico. Universal/Local (U/L) El sptimo bit en un identificador de interfaz
Figura 2 Bit universal/local EUI-64
9
Figura 1 Identificador de interface EUI-64 para IPv6
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 direccin se administra localmente. El administrador de red ha eliminado la direccin manufacturada y ha especificado una direccin diferente. Si el bit U/L se fija a 1, el IEEE, con la designacin de una ISP, ha administrado la direccin. Por lo tanto, para hacer a esta direccin una direccin administrada universalmente, nuestra direccin IPv6 0090:27FF:FE17:FC0C se convertira 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 direccin es una direccin individual (unicast) o una direccin grupal (multicast). Cuando se fija a 0, es una direccin unicast. Cuando se fija a 1, es una direccin multicast. Para una direccin de adaptador de red 802.x tpico, los bits U/L y I/G se fijan a 0, correspondiendo a una direccin MAC unicast administrada universalmente. Debido a ciertas preocupaciones de privacidad y seguridad, la implementacin de la autoconfiguracin por un host puede tambin crear un identificador de interfaz aleatorio usando la direccin MAC como una base. Esto se considera una extensin de privacidad porque, sin l, crear un identificador de interfaz a partir de una direccin MAC proporciona la capacidad de seguir la actividad y el punto de conexin. Microsoft Windows XP actualmente soporta la implementacin de esta capacidad y prefiere usar esta direccin para la comunicacin saliente, porque la direccin tiene un tiempo de vida corto y se regenera peridicamente.
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 seccin se pueden usar como punto de partida para cualquier esquema de redistribucin. La capa de enlace de datos define cmo se crean los identificadores de interfaz IPv6 y cmo el descubrimiento de vecino trata con la resolucin de direccin de capa de enlace de datos. IPv6 esta definido en la mayora 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 slo ATM permanent virtual circuit (PVC) y ATM LAN Emulation (LANE). ***Cisco soporta slo PVC Frame Relay. Un RFC describe el comportamiento de IPv6 en cada una de estas capas de enlace de datos especficas, pero el
Figura 1 Capas de enlace de datos Cisco que suportan IPv6

10
software Cisco IOS no necesariamente soporta todos ellos. Figura 1.
8.3.6 Multicasting IPv6

Una direccin multicast identifica un grupo de interfaces. El trfico enviado a una direccin multicast viaja a mltiples destinos al mismo tiempo. Una interfaz puede pertenecer a cualquier nmero de grupos multicast. El multicasting es extremadamente importante para IPv6, porque est en la base de muchas funciones IPv6. El formato de la direccin multicast es como sigue: Fig.1 Figura 1 - Multicasting Las direcciones multicast IPv6 se definen por el prefijo FF00::/8. El segundo octeto define el tiempo de vida (flag) y el alcance de la direccin multicast. o El parmetro flag es igual a 0 para una permanente, o conocida, direccin multicast. Para una direccin multicast temporal, el flag es igual a 1. o El parmetro de alcance es igual a 1 para el alcance de la interfaz (transmisin loopback), 2 para el alcance de enlace (similar al alcance link-local unicast), 3 para el alcance subnet-local donde las subredes pueden abarcar mltiples enlaces, 4 para el alcance admin-local (administrativamente configurado), 5 para el alcance de sitio, 8 para el alcance de organizacin (sitios mltiples), E para el alcance global. Por ejemplo, una direccin multicast que comienza con FF02::/16 es una direccin multicast permanente con un alcance link-local. La ID del grupo multicast consiste de los 112 bits siguientes de la direccin 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 direccin.
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, Figura 1 Ejemplo de direcciones multicast permanentes donde XX:XXXX est 24 bits a la derecha de la direccin unicast o anycast correspondiente al nodo. (Los mensajes de solicitacion de vecino se envan en un enlace local cuando un nodo desea determinar la direccin 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 correlacin directa al prefijo unicast site-local (ahora menospreciado) del de FEC0::/10.
8.3.8 Direcciones Que No Son nicas

En casos muy raros, los 24 bits a la derecha de la direccin unicast del objetivo no son nicos en el enlace. Las direcciones multicast solicited-node se usan en IPv6 para la resolucin de direccin de una direccin IPv6 a una direccin MAC en un segmento LAN. Fig.1 Por ejemplo, considere dos nodos con direcciones Figura 1 Direcciones IPv6 unicast o anycast 2001:DB8:200:300:400:500:aaaa:bbbb y 2001:DB8:200:300:400:501:aaaa:bbbb, donde el prefijo de enlace es 2001:DB8:200:300::/64. Estos dos nodos estaran escuchando la misma direccin multicast solicited-node. Cada uno recibira el paquete multicast, pero solamente el nodo cuya direccin completa coincida con la direccin objetivo completa del paquete multicast (embedida en el campo de datos del paquete multicast) respondera con un anuncio de vecino (el cual incluye la direccin MAC verdadera). El otro nodo recibira el paquete multicast, pero bajo la inspeccin de la direccin objetivo embedida se dara cuenta que no era el receptor previsto de la peticin y no respondera. Lo que sigue describe cmo funciona esta situacin. El nodo A tiene esta caracterstica: Direccin 2001:DB8:200:300:400:500:1234:5678 El nodo B tiene estas caractersticas: Direccin 2001:DB8:200:300:500:AAAA:BBBB Direccin multicast solicited-node FF02:0:0:0:0:1:FFAA:BBBB (la misma que la del nodo C) El nodo C tiene estas caractersticas: Direccin 2001:DB8:200:300:501:AAAA:BBBB Direccin 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 enva un paquete de descubrimiento de vecino a la direccin multicast solicited-node de B, FF02:0:0:0:0:1:AAAA:BBBB. Dentro del paquete, adems de otros datos, est la direccin IPv6 completa que el nodo A est buscando (2001:DB8:200:300:500:AAAA:BBBB). Esta se llama la direccin objetivo. 2. El nodo B y el nodo C estn escuchando la misma direccin multicast, por lo que ambos reciben y procesan el paquete. 3. El nodo B ve que la direccin objetivo dentro del paquete es su la suya y responde. 4. El nodo C ve que la direccin objetivo dentro del paquete no es la suya y no responde. De este manera, los nodos pueden tener la misma direccin multicast solicited-node en el enlace sin causar que el descubrimiento de vecino, la solicitacin de vecino, o el anuncio de vecino funcionen incorrectamente.
8.3.9 Anycast
Una direccin anycast IPv6 es una direccin unicast global que se asigna a ms de una interfaz. Fig.1 Cuando un paquete se enva a una direccin anycast, ste es enrutado hacia la interfaz "ms cercana" que tenga esa direccin.
Figura 1 Anycast
12
En un alcance WAN, la interfaz ms cercana se encuentra segn la medida de la distancia del protocolo de enrutamiento. En un alcance LAN, la interfaz ms cercana se encuentra segn el primer vecino que se aprendio. Lo que sigue describe las caractersticas de una direccin anycast: Las direcciones anycast se asignan del espacio de direccin unicast, as que son indistinguibles de la direccin unicast. Cuando est asignada a una interfaz del nodo, el nodo se debe configurar explcitamente para saber que la direccin es una direccin 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 ms cercana que es un miembro del grupo anycast, lo que permite un tipo de mecanismo de descubrimiento al punto ms 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 direccin anycast no se debe usar como la direccin origen de un paquete IPv6.
8.3.10 Mobilidad IPv6

La movilidad es una caracterstica muy importante en las redes hoy. Mobile IP es un estndar IETF disponible para IPv4 e IPv6. Mobile IP permite que los dispositivos mviles se muevan sin interrumpir conexiones actuales. En IPv6, la movilidad esta incorporada, lo cual significa que cualquier nodo IPv6 puede usarla segn sea necesario. Sin embargo, en IPv4, la movilidad es una funcin nueva que debe ser agregada. Los encabezados de enrutamiento de IPv6 hacen a Mobile IPv6 mucho ms 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. Tambin, la movilidad IPv6 crea un encabezado de extensin de "movilidad" nuevo. La movilidad IPv6 es diferente de la movilidad IPv4 de varias maneras: El espacio de direccin IPv6 permite el despliegue Mobile IP en cualquier clase de entorno grande. Debido al extenso espacio de direccin 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 direccin ruteable IPv6 global para todos los nodos mviles. El modelo Mobile IPv6 aprovecha algunos beneficios del mismo protocolo IPv6. Los ejemplos incluyen encabezados de opcin, descubrimiento de vecino, y la autoconfiguracin. En muchos casos, se elimina el enrutamiento de tringulo, porque la optimizacin de ruta Mobile IPv6 permite que los nodos mviles y los nodos correspondientes se comuniquen directamente. El soporte para la optimizacin de ruta es una parte fundamental del protocolo, ms que un conjunto no estandar de extensiones. El soporte tambin se integra en Mobile IPv6 para permitir que la optimizacin de ruta coexista eficientemente con los routers que realizan la filtracin de ingreso. La optimizacin de ruta Mobile IPv6 puede operar con seguridad incluso sin asociaciones de seguridad planeadas de antemano. Se espera que la optimizacin de ruta pueda ser desplegada a una escala global entre todos los nodos mviles y los nodos correspondientes. Los nodos mviles 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 dinmico en Mobile IPv6 devuelve una sola respuesta al nodo mvil. El acercamiento al broadcast dirigido usado en IPv4 devuelve replicas de cada agente casero. La mayora de paquetes enviados a un nodo mvil mientras est ausente de hogar en Mobile IPv6 son envados usando un encabezado de enrutamiento IPv6 ms que encapsulacin IP, reduciendo la cantidad de overhead resultante comparado a Mobile IPv4.
13
8.4 Enrutamiento IPv6

8.4.1 Descripcin 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 ms largas y diferentes estructuras de encabezado. Actualmente, estn disponibles los protocolos de enrutamiento actualizados mostrados en Figura 1. Los siguientes son resmenes de varios protocolos de enrutamiento usados con IPv6. Enrutamiento Esttico Figura 1 Protocolos de enrutamiento con IPv6 El enrutamiento esttico 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 direccin link-local de cada uno de sus routers vecinos para asegurar que la direccin objetivo de un mensaje redirect identifique al router vecino por su direccin link-local. Este requisito bsicamente da a entender que no se recomienda el uso de una direccin unicast global como una direccin de siguiente-salto con enrutamiento. RIPng El Routing Information Protocol next generation (RIPng, RFC 2080) es un protocolo de enrutamiento por vectordistancia con un lmite de 15 saltos que usa horizonte dividido y envenenamiento inverso para prevenir loops de enrutamiento. Fig.2 La implementacin del protocolo para IPv6 incluye estas caractersticas: Figura 2 - RIPng Basado en RIP versin 2 (RIPv2) IPv4 y similar a RIPv2 Usa IPv6 para el transporte Prefijo IPv6, direccin IPv6 de siguiente-salto Usa el grupo multicast FF02::9, el grupo multicast de routers all-RIP, como direccin destino para actualizaciones RIP Actualizaciones enviadas al puerto 521 UDP OSPFv3 La implementacin de protocolo para IPv6 incluye estas caractersticas: Basado en OSPF versin 2 (OSPFv2), con mejoras Distribuye prefijos IPv6 Funciona directamente sobre IPv6
Figura 3 OSPFv3
14
Opera como "ships in the night" con OSPFv2
Esta implementacion agrega estos atributos IPv6-especificos: Direcciones de 128 bits Direcciones link-local Mltiples direcciones e instancias por interfaz Autenticacin (ahora usa IPsec) OSPFv3 funciona sobre un enlace ms que una subred IS-IS El soporte para direccin larga facilita la familia de direccin 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 Direccin de interfaz IPv6 Nuevo IDS de protocolo
Figura 4 IS-IS
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 configuracin 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 informacin de otros protocolos, por ejemplo, Multiprotocol Label Switching (MPLS) e IPv6.
Figura 5 Multiprotocolo BGP (MP-BGP)
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 mquinas origen y destino. El estado de un enlace es una descripcin de esa interfaz y de su relacin con sus dispositivos de networking vecinos. La informacin de interfaz incluye el prefijo IPv6 de la interfaz, la mscara de red, tipo de red con el cual est conectada, routers conectados a esa red, etctera. Esta informacin se propaga en varios tipos de link-state advertisements (LSAs). Una coleccin 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 creacin de la tabla de enrutamiento OSPF.
La diferencia entre la base de datos y la tabla de enrutamiento es que la base de datos contiene una coleccin completa de informaciones en bruto. La tabla de enrutamiento contiene una lista de caminos ms cercanos a destinos conocidos va puertos de interfaz de router especficos. OSPFv3, que se describe en RFC 2740, soporta IPv6.
8.4.3 Similitudes entre OSPFv2 y OSPFv3

Muchas de las caractersticas OSPF para IPv6 son las mismas a las de OSPFv2. OSPFv3 para IPv6, el cual esta descrito en RFC 2740, ampla OSPFv2 para proporcionar soporte para los prefijos de enrutamiento IPv6 y para direcciones IPv6 de tamao ms grande.
Figura 1 OSPFv3, similitudes con OSPFv2
Otras semejanzas a OSPFv2 incluyen lo siguiente: Fig.1 Los mecanismos para descubrimiento de vecinos y formacin de adyacencia son idnticos. Las operaciones de OSPFv3 sobre modos de topologia nonbroadcast multiaccess (NBMA) y punto-a-multipunto RFC-compliant estan soportadaos. OSPFv3 tambin soporta otros modos de Cisco, tal como punto-a-punto y broadcast, incluyendo la interfaz. La inundacin y el Figura 2 Mejoras del protocolo de enrutamiento envejecimiento LSA son iguales para OSPFv2 y OSPFv3. OSPFv3 usa los mismos tipos de paquete bsicos que OSPFv2, tales como paquetes hello, descripcin de base de datos (tambin llamado paquete de descripcin 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) tambin estn 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 trmino "enlace" para indicar "una facilidad de comunicacin o medio sobre el cual los nodos puedan comunicar en la Figura 1 Procesos por enlace OSPv3 capa de enlace." Por lo
tanto, los trminos "red" y "subnet" usados en la especificacin 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 direccin IPv6 usada debe ser la direccin link-local del vecino. Soporte para multiples instancias OSPFv3 Fig.2 o Sistemas autnomos separados, cada uno con OSPF funcionando, usan un enlace comn. Un enlace nico podra pertenecer a mltiples reas. o OSPFv3 usa un campo Figura 2 Soporte de instancia mltiple OSPFv3 nuevo, llamado Instante ID, para permitir mltiples 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::5Representa todos los routers shortest path first (SPF) en el alcance link-local, equivalente a 224.0.0.5 en OSPFv2. o FF02::6Representa todos los designated routers (DRs) en el alcance link-local, equivalente a 224.0.0.6 en OSPFv2. Figura 3 Otras diferencias entre OSPFv2 y OSPFv3 Retiro de semnticas de direccin o Las direcciones IPv6 ya no estan presentes en el encabezado del paquete OSPF (parte de informacin 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 extensin Encapsulating Security Payload (ESP), en vez de la variedad de mecanismos definidos en OSPFv2. o La autenticacin ya no es parte de OSPF. Ahora es trabajo de IPv6 cerciorarse de que el nivel correcto de autentificacin este en uso.
8.4.5 Tipos de LSA para IPv6

Las caractersticas 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 direccin IPv4. Las LSAs de router y la LSAs de red contienen solamente IDs de 32 bits. No contienen direcciones. Las LSAs tiene alcances de inundacin que definen el dimetro al que podran ser inundados: o Enlace local: Inundan todos los routers en el enlace. o rea: Inundan todos los routers dentro del rea OSPF. o Sistema Autnomo: Inundan todas los routerss dentro del sistema autnomo OSPF entero.
OSPFv3 soporta el envio de LSAs desconocidas basado en el alcance de inundacion. Esto puede ser til en un NSSA. OSPFv3 aprovecha el multicasting IPv6, al usar FF02::5 para todas los routers OSPF, y FF02::6 para el OSPF DR y el OSPF BDR.
Las dos LSAs renombradss son como sigue: LSAs de prefijo de Interarea para area border routers (ABRs) (tipo 3): Las LSAs tipo 3 anuncian redes internas a los routers en otras reas (rutas de interarea). Lss LSAs tipo 3 puede representar una red nica o un conjunto de redes sumarizadas en una publicacin. 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 direccin, mscara. La ruta por defecto se expresa como prefijo con longitud 0. LSAs de router interarea para autonomous system boundary routers (ASBRs) (tipo 4): Las LSAs tipo 4 publican la localizacin 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 inundacin link-local y nunca estn inundadas ms all del enlace con el cual estn asociadas. Las LSAs de enlace proporcionan la direccin link-local del router al resto de routers unidos al enlace. Las LSAs de enlace tambin informan a otros routers unidos al enlace de una lista de prefijos IPv6 para asociar al enlace, y permiten que el router declare una coleccin 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 asociacin a la LSA de router o a la LSA de red. La ID de estado de enlace tambin contiene prefijos para redes matriz o de transito
8.4.6 Prefijo de Direccin y LSAs

Un prefijo de direccin ocurre en casi todas las LSAs definidas recientemente. El prefijo se representa por tres campos: Prefijo de Longitud, Prefijo de Opciones, y Prefijo de Direccin. En OSPF para IPv6, las direcciones para estas LSAs se expresan como prefijo, prefijo de longitud en vez de direccin, mscara. La ruta por defecto se expresa como un prefijo con longitud 0. Las LSAs de tipo 3 y tipo 9 llevan toda la informacin de prefijo IPv6, que, en IPv4, estn incluidas en las LSAs de router y en las LSAs de red.
8.5 Implementacin y Verificacin OSPFv3

8.5.1 Configuracin OSPFv3 en IPv6
Muchos comandos OSPFv3 son similares a los de OSPFv2. En la mayora 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 direccin IPv6, usted usa el comando ipv6 address. Para ver las rutas IPv6, usted da el comando show ipv6 route. Fig.1
Figura 1 Configurando OSPFv3 con software Cisco IOS
La configuracin de OSPFv3 no es un modo de subcomando del comando router ospf como lo es en la configuracin OSPFv2. Por ejemplo, en vez de usar el comando network area para identificar redes que son
18
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 mltiples reas. Paso 2 Habilite el enrutamiento unicast IPv6 usando el comando ipv6 unicastrouting. Fig.2
Figura 2 Comando ipv6 unicast-routing
Paso 3 Habilite IPv6 en la interfaz usando el comando ipv6 ospf area. Paso 4 (Opcional) Configure los ajustes especficos 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 configuracin de router, incluyendo la prioridad de router, sumarizacin de ruta, etctera.
8.5.2 Habilitacin OSPFv3 en una interfaz

La mayora de la configuracin OSPFv3 se hace en la interfaz. La Figura 1 muestra una configuracin de muestra habilitando una direccin 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.
Figura 1 Habilitando OSPFv3 en una interface
Figura 2 Comandos OSPFv3 interface configuration
8.5.3 Configuracin de Especificaciones de Enrutamiento OSPFv3

Las especificaciones de enrutamiento OSPFv3 se configuran desde el modo de configuracin de router. Para entrar al modo de configuracin de router, use el comando ipv6 router ospf process-id. Este comando habilita un proceso OSPF en el router. El parmetro ID de proceso identifica un proceso OSPFv3 nico.
Para un router IPv6-only, un parmetro ID de router se debe definir en la configuracin OSPFv3 como una direccin IPv4 usando el comando de configuracin de router router-id router-id. OSPFv3 usa un nmero de 32 bits para una ID de router. La ID de router OSPFv3 se puede expresar en decimal con punto, permitiendo el fcil encubrimiento de una red OSPFv3 en una red OSPFv2 existente. La Figura 1 muestra una configuracin 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 direccin IPv4 ms alta configurada en una interfaz loopback viene a ser la ID de router. Si no se configura las interfaces loopback, la direccin ms alta en cualquier otra interfaz vendr a ser la ID de router.
Figura 1 Configurando el router ID
8.5.4 Sumarizacion de Ruta OSPFv3

La Figura 1 muestra rutas OSPFv3 de muestra antes de la sumarizacin. Para consolidar y sumarizar rutas en un lmite 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 configuracin de muestra.
Figura 2 Resumen de rutas OSPFv3 Figura 1 Rutas OSPFv3 antes del resumen El costo de las rutas sumarizadas es el costo ms alto de las rutas que estn sumarizadas. Por ejemplo, las rutas mostradas en Figura 1 se convierten en una ruta sumarizada como se muestra en Figura 3.
Figura 3 Rutas OSPFv3 despus del resumen
8.5.5 Ejemplo de Configuracin 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 " dinmicamente, al igual que el comando ipv6 ospf 100 area 1.
Figura 1 Ejemplo de configuracin OSPFv3

8.5.6 Verificacin OSPFv3

Hay varios comandos show OSPFv3 comnmente usados, incluyendo el comando show ipv6 ospf [process-id] [area-id] interface [interface]. Este comando genera la informacin de interfaz relacionada OSPF, segn lo mostrado en Figura 1. El comando clear ipv6 ospf [process-id] {process | force-spf | redistribution | counters [neighbor [neighbor-interface | neighbor-id]]} provoca el reclculo SPF y el repoblamiento de la Routing Information Base (RIB). El comando show ipv6 ospf [process-id] [area-id] muestra informacin general sobre procesos OSPF, segn 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
21
8.5.7 Verificacin de vecinos OSPFv3

Para mostrar informacin 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 informacin detallada sobre vecinos OSPF IPv6, segn 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 Descripcin de los campos de show ipv6 ospf neighbot detail
22
8.5.8 Verificacin de la Base de Datos OSPFv3

Para mostrar listas de informacin relacionadas con la base de datos OSPF para un router especfico, use el comando show ipv6 ospf database en modo EXEC usuario o en modo EXEC privilegiado. Varias formas de este comando entregan informacin sobre distintas link-state advertisements (LSAs). Las Figuras 1 y 2 ilustran la salida parcial de muestra del comando show ipv6 ospf database. La Figura 3 proporciona descripciones de campo de salida del comando show ipv6 ospf database. La Figura 4 ilustra la salida de muestra del comando show ipv6 ospf database database-summary.
Figura 3 Descripcin de los campos de show ipv6 ospf database
Figura 1 Comando show ipv6 ospf database
Figura 4 Comando show ipv6 ospf database database-summary Figura 2 Comando show ipv6 ospf database (cont.)
8.6 Uso de IPv6 eIPv4

8.6.1 Mecanismo de Transicin IPv6 a IPv4
La transicin de IPv4 a IPv6 no requiere un upgrade en todos los nodos al mismo tiempo. Muchos mecanismos de transicin permiten la integracin 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.
23
Las dos tcnicas ms comunes para la transicin de IPv4 a IPv6 son como sigue: Dual snack Tuneles IPv6-over- IPv4 (6to4) Para la comunicacin entre redes IPv4 e IPv6, las direcciones IPv4 se pueden encapsular en direcciones IPv6. La Figura 1 muestra un ejemplo de un mecanismo de transicin e integracin. Los routers 6to4 encapsulan automticamente el trfico IPv6 dentro de paquetes IPv4.
Figura 1 Transicin IPv4-a-IPv6
8.6.2 Dual Stack de Cisco IOS

La mayora de las ms recientes versiones de software Cisco IOS son IPv6-ready. Tan pronto como las configuraciones bsicas IPv4 e IPv6 esten completas en la interfaz, la interfaz esta dual-stackeada, y remite el trfico IPv4 e IPv6. Usar IPv6 en un router Cisco IOS requiere que usted use el comando de configuracin global ipv6 unicastrouting. Fig 1 Este comando habilita el envi de datagramas IPv6. Todas las interfaces que envan trfico IPv6 deben tener una direccin IPv6. El comando ipv6 address [IPv6-address] [/prefix length] especifica una red IPv6 asignada a la interfaz y permite procesamiento IPv6 en la interfaz.
Figura 1 Dual stack de Cisco IOS
El dual-stack es un mtodo de integracin donde un nodo tiene la implementacin y conectividad a una red IPv4 y a red IPv6, y as el nodo tiene dos stacks. Fig. 2 Esta configuracin se puede llevar a cabo en la misma interfaz o en mltiples interfaces. Las consideraciones para dual-stack incluyen lo siguiente: Un nodo dual-stack elige que stack usar basadose en la direccin destino. Un nodo dual-stack prefiere IPv6 Figura 2 Dual stack cuando esta disponible. La estrategia dual-stack para integracin IPv6 en la cual los nodos tienen stacks IPv4 e IPv6 ser uno de los mtodos de integracin ms comnmente usados. Las antiguas aplicaciones IPv4-only continan trabajando como antes. Las aplicaciones nuevas y modificadas aprovechan de ambas capas IP.
24
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 aplicacin convertida puede hacer uso de IPv4 e IPv6. Un aplicacin puede ser convertida a la nueva API mientras que todava usa slo IPv4. La experiencia previa de porting en aplicaciones IPv4 hacia IPv6 sugiere que para la mayora de aplicaciones es un cambio mnimo en algunos lugares localizados dentro de cdigo fuente. Esta tcnica es bien conocida y se ha aplicado en el pasado para otras transiciones de protocolo. Permite mejoras graduales de la aplicacin, uno por uno, a IPv6.
8.6.3 Tneles de Encubrimiento

El networking usa a menudo tneles para encubrir una funcionalidad incompatible en una red existente. El trfico IPv6 tunneling sobre una red IPv4 requiere un router de borde que encapsule el paquete IPv6 dentro de un paquete IPv4 y otro router que desencapsule. Fig.1 Este proceso le permite conectar islas IPv6 sin convertir la red entera a IPv6. Figura 1 Tneles de encubrimiento El tunneling es un mtodo de integracin donde un paquete IPv6 se encapsula dentro de otro protocolo, tal como IPv4. Fig. 2 Este mtodo de encapsulacin es protocolo 41 IPv4 y tiene las siguientes caractersticas: 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 conexin 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 ningn campo opcional). o Difciltad para resolver problemas.
Figura 2 - Tunneling
El tunneling es una tcnica integracin intermedia y de transicin que no seria considerada una solucin final. La arquitectura IPv6 nativa debe ser la ltima meta.
25
8.6.4 Host Dual Stack Aislado

La encapsulacin 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 tnel 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 tnel, tales como un firewall, filtra hacia fuera protocolo 41 IPv4, que es la encapsulacin IPv6over-IPv4. Figura 1 Host dual stack aislado
8.6.5 Configuracin de Tunneling

Si usted est configurando un tnel manualmente, usted debera configurar las direcciones IPv4 e IPv6 estticamente. Debera realizar esta configuracin en los routers en cada extremo del tnel. Fig.1 Estos routers extremos deben estar dual stackeados, y la configuracin no puede cambiar dinmicamente como la red y las necesidades de enrutamiento cambian. El enrutamiento se debe configurar correctamente para enviar un paquete entre las dos redes IPv6.
Figura 1 Tnel configurado
Los puntos extremos del tnel pueden ser innumerables, pero los puntos extremos innumerables hacen difcil la solucin de problemas. La prctica IPv4 de ahorrar direcciones para puntos extremos del tnel no es ms un problema.
8.6.6 Ejemplo de un Tnel Configurado

El ejemplo en Figura 1 muestra cmo configurar un tnel de encubrimiento IPv6 manualmente. Con los tneles configurados IPv6 manualmente, una direccin IPv6 se configura en una interfaz de tnel, y las direcciones IPv4 configuradas manualmente se asignan al origen del tnel y al destino del tnel. El host o router en cada extremo de un tnel configurado debe soportar los stacks de protocolo IPv4 e IPv6. El comando que habilita el tnel de encubrimiento IPv6 es tunnel mode Figura 1 Ejemplo de configuracin de tnel con Cisco IOS
26
ipv6ip. Concretamente, especifica que IPv6 es el protocolo pasajero y que IPv4 ser usado como protocolo de encapsulacin y transporte. Existen varios otros mecanismos de transicin de tunneling automtico, 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 direccin IPv4 ruteable o alcanzable globalmente. Intra-Site Automatic Tunnel Addressing Protocol (ISATAP): Permite que una intranet privada IPv4 (que puede o no usar direcciones RFC 1918) implemente incrementalmente nodos IPv6 sin realizar un upgrade la red. Otro mecanismo de transicin es Teredo (conocido antes como Shipworm). Este mecanismo tunelea los datagramas IPv6 dentro de UDP IPv4. Este mtodo proporciona el uso de direccin IPv4 privada y NAT traversal IPv4.
8.6.7 Tunneling IPv6 a IPv4 y Direcciones

El mtodo tunneling 6to4 establece automticamente la conexin de islas IPv6 a travs de una red IPv4. Aplica un prefijo IPv6 vlido a cada isla IPv6, lo cual permite el rpido despliegue de IPv6 en una red corporativa, sin la recuperacin de la direccin de ISPs o de los registros. El mtodo de tunneliing 6to4 requiere un cdigo especial en los routers de borde, pero los hosts y routers IPv6 dentro del sitio 6to4 no requieren nuevas caractersticas para soportar 6to4. Cada sitio 6to4 recibe un prefijo /48, que es la concatenacin de 0x2002 y la direccin IPv4 hexadecimal de router de borde. En la Figura 1, la direccin 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 representacin hexadecimal de 192.168.99.1. La red IPv6 puede sustituir cualquier direccin IP en el espacio despus de la primera seccin de 16 bits (0x2002). Cuando un paquete IPv6 con una direccin destino en el rango de 2002::/16 alcanza al router de Figura 1 Tunneling 6to4 borde 6to4, el router de borde 6to4 extrae la direccin IPv4 que esta embedida en la direccin destino 2002:: (insertada entre el tercer y sexto octetos, inclusive). El router 6to4 luego encapsula el paquete IPv6 en un paquete IPv4 con la direccin IPv4 destino que fue extrada de la direccin destino IPv6. Esta direccin IPv4 representa la direccin 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 enva el paquete nativo hacia su destino final. Nota: 2002::/16 es el rango de direccin asignada especficamente a 6to4.
8.6.8 Transicin de NAT-PT

Para equipos heredados que no sern actualizados a IPv6 y para algunos escenarios de despliegue, las tcnicas que pueden conectar nodos IPv4-only a nodos IPv6-only estn disponibles. La traduccin es bsicamente una extensin de las tcnicas NAT. La NAT-Protocol Translation (NAT-PT) es un mecanismo de traduccin que se sienta entre una red IPv6 y una red IPv4. El traductor traduce los paquetes IPv6 en paquetes IPv4 y viceversa.
La NAT-PT esttica usa reglas de traduccin estticas para mapear una direccin IPv6 a una direccin IPv4. Los nodos de red IPv6 se comunican con nodos de red IPv4 usando un mapeo IPv6 de la direccin IPv4 configurada en el router NAT-PT. La Figura 1 muestra cmo el nodo IPv6only (nodo A) puede comunicarse con el nodo IPv4-only (nodo D) usando NATPT. El dispositivo NAT-PT se configura para mapear la direccin IPv6 origen para el nodo A de 2001:0db8:bbbb:1::1 a la direccin IPv4 192.0.2.2. NAT-PT tambin se configura para mapear la direccin origen del nodo C IPv4, 192.0.30.1 a 2001:0db8::a. Cuando los paquetes con una direccin IPv6 origen del nodo A se reciben en el router NATPT estos son traducidos para tener una direccin destino que coincida con el nodo D en la red IPv4-only. NAT-PT se puede tambin configurar para coincidir Figura 1 Transicin de NAT-PT una direccin IPv4 origen y traducir el paquete a una direccin 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 comunicacin a otro nodo IPv6. Y desde la perspectiva del nodo D, est estableciendo comunicacin IPv4 con su correspondiente. El nodo D no requiere modificacin. Si usted tiene mltiples hosts IPv6-only o IPv4-only que necesiten comunicarse, usted puede necesitar configurar muchos mapeos NAT-PT estticos. La NAT-PT esttica es til cuando las aplicaciones o servidores requieren acceso a una direccin IPv4 estable. El accesar a un servidor DNS IPv4 externo es un ejemplo donde la NAT PT esttica puede ser usada. Las traducciones NAT-PT tambin se pueden mapear dinmicamente basado en preguntas de DNS, usando un DNS application level gateway (DNS ALG). Otras posibles soluciones son como sigue: ALGs: Este mtodo 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 mdulo especfico en un stack TCP/IP de host para cada host en la red. El mdulo intercepta trfico IP con una API y lo convierte para las contrapartes IPv6.
Resumen
Este mdulo es una descripcin de IP versin 6 (IPv6), comenzando con el porqu se convertir en el protocolo de eleccin en el futuro y los beneficios de esa eleccin. Los cambios en el formato de direccin y el formato de encabezado de paquete fueron discutidos en detalle, incluyendo la autoconfiguracin y el rol de la direccin multicast. Una parte importante del mdulo 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 ms detalle. Tambin se definieron estrategias de transicin para emigrar de IPv4 a IPv6. Se mostro la configuracin del Cisco IOS, la verificacin, y los comandos de resolucion de problemas.
28

BGP IPv6 y Redistribucion

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BGP IPv6 y Redistribucion

Cargado por

Copyright:

Formatos disponibles

CCNP: Building Scalable Internetworks

Mdulo 5: Optimizacin de rutas.

5.1 Operando una red que utiliza mltiples protocolos de enrutamiento

Figura 1 Enrutamiento jerrquico

CCNP: Building Scalable Internetworks

5.1.2 Definiendo redistribucin de rutas

Usando mltiples protocolos de enrutamiento

CCNP: Building Scalable Internetworks

5.1.3 Redistribuyendo informacin de rutas

Redistribuyendo informacin de rutas

5.1.4 Utilizando mtricas

CCNP: Building Scalable Internetworks

Figura 1 Usando mtricas seed

5.1.5 Ejemplo de mtricas iniciales

CCNP: Building Scalable Internetworks

5.1.6 Definiendo la distancia administrativa.

Figura 1 Distancia administrativa

CCNP: Building Scalable Internetworks

5.1.7 Modificando las distancias administrativas

Figura 1 Modificando distancias administrativas

CCNP: Building Scalable Internetworks

Figura 3 Parmetros del comando distance eigrp

5.2 Configurando y verificando redistribucin en el router.

CCNP: Building Scalable Internetworks

5.2.2 Redistribuyendo rutas dentro de un protocolo de enrutamiento classful.

Figura 1 Configurando redistribucin en RIP

CCNP: Building Scalable Internetworks

Figura 3 Parmetros del comando redistribute

5.2.3 Redistribuyendo desde protocolos classless a protocolos classful.

Figura 1 Redistribuyendo en RIP

CCNP: Building Scalable Internetworks

Figura 3 Ejemplo de RIP teniendo una mscara ms larga que OSPF

CCNP: Building Scalable Internetworks

5.2.4 Redistribuyendo rutas dentro de un protocolo de enrutamiento classless.

Figura 2 Comando redistribute

CCNP: Building Scalable Internetworks

Figura 3 Parmetros del comando redistribute

5.2.5 Ejemplo de redistribucin de rutas dentro de OSPF.

5.2.6 Redistribuyendo rutas dentro de EIGRP.

CCNP: Building Scalable Internetworks

Figura 1 Configurando redistribucin en EIGRP

Figura 2 Comando redistribute

Figura 3 Parmetros del comando redistribute

CCNP: Building Scalable Internetworks

5.2.7 Ejemplo de redistribucin de rutas dentro de EIGRP.

Figura 1 Redistribucin en EIGRP

5.2.8 Redistribuyendo rutas dentro de IS-IS

CCNP: Building Scalable Internetworks

Figura 2 Parmetros del commando redistribute

Figura 3 Redistribucin IS-IS en otros protocolos de enrutamiento

5.2.9 Ejemplo de redistribucin de rutas dentro de IS-IS.

Figura 1 Redistribucin en IS-IS

CCNP: Building Scalable Internetworks

5.2.10 Redistribuyendo rutas estticas y conectadas.

5.2.11 Verificando la redistribucin de rutas.

Figura 1 Configuracin antes de la redistribucin

CCNP: Building Scalable Internetworks

Figura 3 Configurando la redistribucin de rutas

5.2.12 Ejemplo de verificacin de redistribucin de rutas.

CCNP: Building Scalable Internetworks

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

CCNP: Building Scalable Internetworks

5.2.13 Problemas de distancia administrativa con la redistribucin