4.

2 Integración de múltiples protocolos de enrutamiento en IPv6

Habiendo demostrado como los routers calculan las métricas hacia una red determinada

utilizando distintos protocolos de enrutamiento, el siguiente paso será demostrar la

interoperabilidad de los distintos protocolos corriendo con IPv6. En esta sección se

explicará secuencialmente las siguientes situaciones:

a) Integración de RIPng con EIGRPv6

b) Integración de RIPng con OSPFv3

c) Integración de OSPFv3 con EIGRPv6

Para demostrar la interoperabilidad de los tres casos se utilizará la siguiente topología

base, la cual tiene 5 routers donde uno ejecutará el rol de “router de borde” y los otros

cuatro ejecutarán un protocolo determinado.

Figura 4.2.1 – Topología base para demostración de integración de múltiples protocolos de enrutamiento bajo

IPv6
Tanto R1 como R2 estarán ejecutando un único protocolo, al igual que R3 y R4. Será

Border el router que se encargue de traspasar correctamente la información de

enrutamiento generada en un método hacia el otro y viceversa.

4.2.1. Integración de RIPng con EIGRPv6

Asumiendo que el direccionamiento IPv6 está correctamente realizado y todos los Router

tienen conectividad de capa 3 entre sí se debe configurar el enrutamiento indicado

separadamente. Esto es, primero RIPng y luego EIGRPv6.

Configuración de direccionamiento y habilitación de enrutamiento RIPng en R1 y

R2 y BORDER

Configuración de RIPng en R1

R1(config)# ipv6 unicast-routing

R1(config)# ipv6 router rip RIPng
R1(config)# exit
R1(config)# interface FastEthernet 0/0
R1(config-if)# ipv6 address 2002:F:0:1::2/64
R1(config-if)# ipv6 rip RIPng enable
R1(config-if)# exit
R1(config)# interface Loopback0
R1(config-if)# ipv6 address 2002:0:1:A::1/64
R1(config-if)# ipv6 rip RIPng enable
R1(config-if)# exit
R1(config)# interface Loopback1
R1(config-if)# ipv6 address 2002:0:1:B::1/64
R1(config-if)# ipv6 rip RIPng enable
R1(config-if)# exit

Configuración de RIPng en R2
R2(config)# ipv6 unicast-routing
R2(config)# ipv6 router rip RIPng
R2(config)# exit
R2(config)# interface FastEthernet 0/0
R2(config-if)# ipv6 address 2002:F:0:2::2/64
R2(config-if)# ipv6 rip RIPng enable
R2(config-if)# exit
R2(config)# interface Loopback0
R2(config-if)# ipv6 address 2002:0:2:A::1/64
R2(config-if)# ipv6 rip RIPng enable
R2(config-if)# exit
R2(config)# interface Loopback1
R2(config-if)# ipv6 address 2002:0:2:B::1/64
R2(config-if)# ipv6 rip RIPng enable
R2(config-if)# exit

Configuración de RIPng en BORDER

BORDER(config)# ipv6 unicast-routing

BORDER(config)# ipv6 router rip RIPng
BORDER(config)# exit
BORDER(config)# interface FastEthernet 0/0
BORDER(config-if)# ipv6 address 2002:F:0:1::1/64
BORDER(config-if)# ipv6 rip RIPng enable
BORDER(config-if)# exit
BORDER(config)# interface FastEthernet 1/0
BORDER(config-if)# ipv6 address 2002:F:0:2::1/64
BORDER(config-if)# ipv6 rip RIPng enable
BORDER(config-if)# exit

Configuración de direccionamiento y habilitación de enrutamiento EIGRPv6 en

R3, R4 y BORDER

Configuración de EIGRPv6 en R3

R3(config)# ipv6 unicast-routing

R3(config)# ipv6 Router eigrp 100
R3(config-rtr)# Router-id [Link]
R3(config-rtr)# no shutdown
R3(config-rtr)# exit
R3(config)# interface FastEthernet 0/0
R3(config-if)# ipv6 address 2002:F:0:3::2/64
R3(config-if)# ipv6 eigrp 100
R3(config-if)# exit
R3(config)# interface Loopback0
R3(config-if)# ipv6 address 2002:0:3:A::2/64
R3(config-if)# ipv6 eigrp 100
R3(config-if)# exit
R3(config)# interface Loopback1
R3(config-if)# ipv6 address 2002:0:3:B::2/64
R3(config-if)# ipv6 eigrp 100

Configuración de EIGRPv6 en R4

R4(config)# ipv6 unicast-routing

R4(config)# ipv6 Router eigrp 100
R4(config-rtr)# Router-id [Link]
R4(config-rtr)# no shutdown
R4(config-rtr)# exit
R4(config)# interface FastEthernet 0/0
R4(config-if)# ipv6 address 2002:F:0:4::2/64
R4(config-if)# ipv6 eigrp 100
R4(config-if)# exit
R4(config)# interface Loopback0
R4(config-if)# ipv6 address 2002:0:4:A::2/64
R4(config-if)# ipv6 eigrp 100
R4(config-if)# exit
R4(config)# interface Loopback1
R4(config-if)# ipv6 address 2002:0:4:B::2/64
R4(config-if)# ipv6 eigrp 100

Configuración de EIGRPv6 en BORDER

BORDER(config)# ipv6 unicast-routing

BORDER(config)# ipv6 Router eigrp 100
BORDER(config-rtr)# Router-id [Link]
BORDER(config-rtr)# no shutdown
BORDER(config-rtr)# exit
BORDER(config)# interface FastEthernet 1/0
BORDER(config-if)# ipv6 address 2002:F:0:3::1/64
BORDER(config-if)# exit
BORDER(config)# interface FastEthernet 2/0
BORDER(config-if)# ipv6 address 2002:F:0:4::1/64
BORDER(config-if)# exit
Con estos comandos se habilitan los protocolos RIP y EIGRP para funcionar bajo IPv6 de

manera independiente. Los routers BORDER, R1 y R2 son capaces de intercambiar rutas

e información de enrutamiento utilizando el protocolo RIPng mientras que BORDER, R3

y R4 lo hacen utilizando EIGRPv6. A continuación una captura de pantalla de los 5 routers

que muestran sus tablas de enrutamiento:

Figura [Link] – Tabla de enrutamiento de R1 ejecutando RIPng

 Figura [Link] – Tabla de enrutamiento de R2 ejecutando RIPng

Figura [Link] – Tabla de enrutamiento de BORDER donde se observan las entradas aprendidas por EIGRPv6

(D) y RIPng (R)

Figura [Link]. – Tabla de enrutamiento de R3 ejecutando EIGRP

Figura [Link] – Tabla de enrutamiento de R4 ejecutando EIGRP

En las figuras [Link], [Link] y [Link] se puede identificar claramente las rutas aprendidas

mediante RIPng (marcadas con una R) y en las figuras [Link], [Link] y [Link] aquellas

aprendidas por EIGRPv6 (marcadas con una D, de DUAL, algoritmo utilizado por este

protocolo para buscar las mejores rutas).

A excepción del router de borde intermedio, cada router solo conoce las rutas que

pertenecen a su propio método de enrutamiento. En este caso R1 y R2 no conocen los

prefijos que están instalados en la red EIGRPv6, ni R3 y R4 tampoco conocen las rutas

hacia las redes ubicadas en el dominio RIPng. BORDER sí los conoce pues él tiene

configurados ambos protocolos ya que tiene dos interfaces en la red RIPng y dos en la red

EIGRPv6.

Debido a esto, ningún host que esté eventualmente conectado a R1 podrá alcanzar las

redes que conecten directamente a R3 ni R4, sino que solamente a R2 y BORDER. Para

lograr convergencia en toda la topología es necesario activar las funciones de

redistribución de rutas en BORDER.

Esta propiedad del router de borde se utiliza para servir de “traductor” de redes de un

protocolo a otro. Para poder permitir que las rutas de un lado se vean en el otro es necesario

implementar una técnica conocida como redistribución de rutas, que permite tomar las

rutas aprendidas en un protocolo determinado y traducirlo a otro, convirtiendo las

propiedades de ellas, como etiquetado, métrica, distancia administrativa y otros valores

hacia el protocolo en el cual se están redistribuyendo o “inyectando” las rutas de tal

manera que los demás routers que están en la red puedan manipular esa información y

actualizar sus tablas de enrutamiento correctamente.

¿Por qué no es posible que BORDER traspase automáticamente las rutas de un lado al

otro? RIPng y EIGRPv6, al igual que OSPFv3 son totalmente diferentes entre sí en cuanto

a su funcionamiento interno. Mientras que, como se explicaba al inicio de este capítulo,

RIPng utiliza la cuenta de saltos (hops) como mejor ruta posible hacia una red de destino,

OSPFv3 utiliza un parámetro denominado “costo” que es obtenido mediante una serie de

cálculos realizados por el mismo algoritmo SPF tomando como referencia el ancho de

banda de los enlaces escogiendo la ruta que tenga mejor ancho de banda aunque la

cantidad de saltos sea mayor. Por su parte EIGRP utiliza una métrica compuesta de

distintos parámetros como ancho de banda, retraso (delay), confiabilidad y carga del

enlace, MTU, entre otros.

Dadas la naturaleza divergente de las métricas de cada protocolo los routers no son

capaces de “comprender” o procesar una ruta que viene con una métrica originada en un

protocolo de enrutamiento diferente al cual tienen configurado. Si EIGRPv6 anuncia una

red con métrica 204830, RIPng no entendería ese número porque él solo soporta un

máximo de 15 hops y a partir del 16 lo considera infinito, lo cual hará que descarte

totalmente la ruta. Esta incompatibilidad requiere que existan routers que se dediquen a

traducir desde un protocolo de enrutamiento determinado a otro. En la topología de la

figura 4.2.1 será BORDER quien traduzca las rutas generadas en RIPng hacia EIGRPv6

y viceversa.

Redistribución desde EIGRPv6 hacia RIPng

Hasta este punto solamente se ha logrado conectividad en las mismas áreas de

enrutamiento. Esto es, únicamente en los routers RIPng y también de manera

independiente en los routers EIGRPv6. Para lograr que las redes 2002:0:3:A::/64,
2002:0:3:B::64, 2002:0:4:A::/64, 2002:0:4:B::/64, 2002:F:0:3::/64 y 2002:F:0:4::/64 sean

aprendidas en R1 y R2 es necesario configurar el router BORDER para que tome estas

redes que él mismo ha aprendido mediante EIGRPv6 y las redistribuya hacia RIPng. Esta

“inyección” de rutas se logra con el siguiente comando:

BORDER(config-rtr)#ipv6 Router rip RIPNG

BORDER(config-rtr)#redistribute eigrp 100 metric 1

Básicamente se le está indicando al proceso RIPng denominado RIPNG que tome las rutas

originadas en el protocolo EIGRP 100 y los envíe a los routers RIP con una métrica de 3.

Se puede comprobar en R1 o R2 que las redes mencionadas han sido aprendidas:

Figura [Link] – Tabla de enrutamiento de R1 incluyendo las rutas redistribuidas desde EIGRP
Sin embargo, aún no hay conectividad completa en la topología ya que los routers R3 y

R4 desconocen las redes 2002:0:1:A::/64, 2002:0:1:B::/64, 2002:0:2:A::/64,

2002:0:2:B::/64, 2002:F:0:1::/64 y 2002:F:0:2::/64 que pertenecen a RIP.

En el mismo router BORDER es necesario esta vez indicarle al protocolo EIGRPv6 que

inyecte las rutas aprendidas en RIP hacia R3 y R4.

BORDER(config-rtr)#ipv6 router eigrp 100

BORDER(config-rtr)#redistribute rip RIPNG metric 400000 100 255 1 1500

La métrica de EIGRP incluye el ancho de banda, retraso, confiabilidad, carga y MTU. Es

necesario decirle al protocolo que traduzca la métrica originada en RIP que está basada en

la cantidad de saltos, a los parámetros necesarios para que los routers EIGRP comprendan

las nuevas redes que se han agregado. Los valores ingresados en el ejemplo son arbitrarios

y no influyen en el comportamiento de la redistribución, aunque es mandatorio

declararlos. Luego de completar la redistribución, es posible ver que en R3 y R4 si se ven

las rutas que pertenecen al dominio RIP.

 Figura [Link] – Tabla de enrutamiento de R4 incluyendo las rutas redistribuidas desde RIP

Destacable es que el protocolo EIGRPv6 identifica aquellas rutas que han sido inyectadas

desde una fuente externa y las marca como EX (External) tal como se muestra en la figura

[Link]. RIPng no diferencia en absoluto y solamente marca las redes con una R como si

se tratara de otra red aprendida directamente por este protocolo.

4.2.2 Integración de RIPng con OSPFv3

Para lograr conectividad entre los routers que ejecutan RIPng con aquellos que corren una

instancia de OSPFv3 es necesario en primer lugar establecer correctamente las rutas entre
los dispositivos de un mismo protocolo. Es decir, todos los routers RIPng deben ser

capaces de alcanzar las redes que administran entre sí y los routers OSPFv3 también.

Asumiendo la misma configuración de RIPng mostrada anteriormente en la integración

con EIGRPv6 se muestra a continuación solamente la configuración de los routers

OSPFv3.

Los parámetros requeridos para habilitar OSPFv3 son:

1.- Habilitar el modo enrutamiento global de IPv6.

Router(config)# ipv6 unicast-routing

2.- Configurar un identificador de router en formato de dirección IPv4. Esto es obligatorio.

Este identificador no influye en absoluto en el cálculo de las rutas, sino simplemente se

utiliza para visualizar el contenido de las adyacencias.

Router(config)# ipv6 router ospf 1

Router(config-router)# router-id [Link]

3.- Cada interfaz que se quiera publicar en OSPF se debe habilitar el identificador de

proceso (por ejemplo 1) correspondiente y el área en la cual se ubica.

Router(config)# interface FastEthernet 0/0

Router(config-if)# ipv6 ospf 1 area 0

Configuración de direccionamiento y habilitación de enrutamiento OSPFv3 en R1 y

R2 y BORDER

Configuración de OSPFv3 en R3

R3(config)# ipv6 unicast-routing

R3(config)# ipv6 router ospf 1
R3(config-router)# router-id [Link]
R3(config-router)# exit
R3(config)# interface FastEthernet 0/0
R3(config-if)# ipv6 ospf 1 area 0
R3(config-if)# exit
R3(config)#interface Loopback0
R3(config-if)# ipv6 ospf 1 area 0
R3(config-if)exit
R3(config)# interface Loopback1
R3(config-if)# ipv6 ospf 1 area 0
R3(config-if)# exit

Configuración de OSPFv3 en R4

R4(config)# ipv6 unicast-routing

R4(config)# ipv6 router ospf 1
R4(config-router)# router-id [Link]
R4(config-router)# exit
R4(config)# interface FastEthernet 0/0
R4(config-if)# ipv6 ospf 1 area 0
R4(config-if)# exit
R4(config)# interface Loopback0
R4(config-if)# ipv6 ospf 1 area 0
R4(config-if)# exit
R4(config)# interface Loopback1
R4(config-if)# ipv6 ospf 1 area 0
R4(config-if)# exit

Configuración de OSPFv3 en BORDER

BORDER(config)# ipv6 unicast-routing

BORDER(config)# ipv6 router ospf 1
BORDER(config-router)# router-id [Link]
BORDER(config-router)# exit
BORDER(config)# interface FastEthernet 2/0
BORDER(config-if)# ipv6 ospf 1 area 0
BORDER(config-if)# exit
BORDER(config)# interface FastEthernet 3/0
BORDER(config-if)# ipv6 ospf 1 area 0
BORDER(config-if)# exit

Una vez configurados los routers se comprueban las rutas IPv6 en ambas redes, tanto

RIPng como OSPFv3.

Figura [Link] – Tabla de enrutamiento de R1 con las rutas de RIPng

 Figura [Link] – Tabla de enrutamiento de R2 con las rutas de RIPng

Figura [Link] – Tabla de enrutamiento de BORDER mostrando las rutas RIPng (R) y OSPF (O)
Figura [Link] – Tabla de enrutamiento de R3 mostrando las rutas OSPF

Figura [Link] – Tabla de enrutamiento de R4 mostrando las rutas OSPF

Como se puede apreciar en las tablas de enrutamiento mostradas en las figuras [Link],

[Link] y [Link], tanto R1 como R2 y BORDER ven correctamente las rutas RIPng,

mientras que R3 y R4 y también BORDER (por ser el intermediario) ven las rutas OSPFv3

según se indica en las figuras [Link], [Link] y [Link].

Para poder permitir que los routers del área RIPng alcancen las redes ubicadas en la red

OSPFv3 y viceversa, es necesario habilitar el proceso de redistribución de rutas en ambos

sentidos también llamado redistribución bidireccional. Luego de ejecutar el comando de

redistribución de OSPF dentro de RIPng, las rutas contenidas en R3 y R4 serán aprendidas

por R1 y R2.

BORDER(config)# ipv6 router rip RIPng

BORDER(config-rtr)# redistribute ospf 1 metric 3

Para que R3 y R4 aprendan las rutas de R1 y R2, es necesario que BORDER tome las

redes aprendidas mediante RIP y las inyecte en el proceso OSPFv3. De esta manera la

métrica original de RIPng, que es el conteo de saltos, es transformada en costo para que

los routers OSPF puedan administrar la ruta. El comando para lograr esto es:

BORDER(config)# ipv6 router ospf 1

BORDER(config-rtr)# redistribute rip RIPng

Una vez aplicada esta configuración es posible comprobar en R3 que las rutas de RIPng

2002:0:1:A::/64, 2002:0:1:B::/64, 2002:0:2:A::/64 y 2002:0:2:B::/64 han sido aprendidas

mediante OSPF. Éstas aparecen como OE2, que significa “OSPF External o Ruta Externa

de OSPF” de tipo 2. Las rutas de tipo 2 son aquellas que mantienen una métrica de 20 en

toda la red, lo cual puede verificarse en el comando show ipv6 route en R1 donde se
indica el valor [110/20], siendo 110 el valor de la distancia administrativa predeterminada

de OSPF y 20 es la métrica.

Figura [Link] – Tabla de enrutamiento de R1 mostrando todas las redes de la topología

 Figura [Link] – Tabla de enrutamiento de R3 mostrando todas las redes de la topología

En las figuras [Link] y [Link] se puede ver que las rutas han sido correctamente

aprendidas por todos los routers.

4.2.3 Integración de OSPFv3 con EIGRPv6

En este tópico se tratará el problema de integración entre los protocolos OSPF versión 3

y EIGRP para redes IPv6. Tal como se ha visto en los dos otros casos anteriores de

integración entre RIPng con OSPFv3 y RIPng con EIGRPv6, en este caso también ocurre

la situación donde los routers de ambos lados deben recibir rutas que fueron originadas
en otro protocolo y con distintas propiedades (métrica, distancia administrativa, entre

otros) y es el router de borde quien se encargará de realizar la redistribución bidireccional

tomando las rutas aprendidas en OSPF para publicarlas en el mundo EIGRP y viceversa.

Dado que la configuración de los enrutadores para establecer adyacencia y traspasarse las

rutas dentro del mismo protocolo es exactamente la misma que se ha mostrado

anteriormente, se dará énfasis en mostrar únicamente la configuración del router de borde

que realizará la traducción de métricas hacia ambos lados. Asumiendo que según la figura

4.2.1 los routers R1, R2 y BORDER ejecutan EIGRP con el ASN 100 mientras que R3,

R4 y BORDER ejecutan OSPF 1 se muestra a continuación la configuración de la

redistribución aplicada en BORDER.

BORDER(config)# ipv6 router eigrp 100

BORDER(config-rtr)# redistribute ospf 1 metric 100000 20 255 1 1500 include-connected
BORDER(config-rtr)# ipv6 router ospf 1
BORDER(config-rtr)# redistribute eigrp 100 include-connected

Esta configuración permite que hacia los routers del ASN EIGRP 100 se redistribuya una

red OSPF funcionando bajo el proceso 1 y viceversa. Los valores 100000 20 255 1 1500

corresponden a los parámetros de la métrica de EIGRP, ancho de banda en Kbps, Delay

en microsegundos, confiabilidad de la red (255 = 100%), carga (1/255) y el valor de MTU.

Es decir, se esá indicando cómo se calculará la métrica nueva para esas rutas que están

siendo aprendidas por OSPF (cuya métrica es costo) y cómo se pasarán al mundo EIGRP.

La palabra clave include-connected permite que también se redistribuyan las redes

conectadas directamente en el router BORDER.

Es posible ver las rutas traspasadas desde un lado a otro consultando la tabla de

enrutamiento de R1 y también de R3 (aunque R2 y R4 también son válidos para este

propósito) y luego haciendo ping entre ambos routers.

Figura [Link] - Tabla de enrutamiento de R1 mostrando las redes aprendidas correctamente de forma interna

(D) y externas (D EX)

Figura [Link] - Tabla de enrutamiento de R3 mostrando las redes aprendidas correctamente de forma interna

(O) y externas (OE2)

Una vez formadas las adyacencias y traspasadas las rutas corresponde ejecutar pruebas

ping para verificar conectividad de capa 3.

Figura [Link] - Ping desde R1 hacia una Loopback de R3 y una Loopback de R4

Figura [Link] - Ping desde R3 hacia una Loopback de R1 y una Loopback de R2

Como se demuestra en las figuras [Link] y [Link], los routers interiores han aprendido

correctamente las rutas de los protocolos externos. En el caso de R1 se muestran las rutas

de OSPF con un indicador D EX (Dual Externo) para indicar que es una red que ha sido

redistribuida dentro de EIGRP. En el caso contrario, en R3, las rutas EIGRP se muestran

como O E2 (OSPF Externo de tipo 2) indicando lo mismo.

Las pruebas de ping de las figuras [Link] y [Link] muestran que la conectividad es exitosa

entre ambas zonas de enrutamiento distintas.

Hasta este punto se ha demostrado como se pueden interconectar redes que ejecuten

distintos protocolos de enrutamiento bajo el método de direccionamiento IPv6. Se ha

demostrado como son capaces de interoperar los routers que ejecutan EIGRP versión 6,

OSPF versión 3 y RIP New Generation (RIPng) y efectivamente logran traspasar las rutas

cuando a uno de ellos se le asigna el rol de “borde”, que es finalmente el dispositivo

encargado de realizar la redistribución.

Se ha mostrado además algunos aspectos técnicos importantes para comprender estos

procesos como son el concepto de métrica y características especiales de cada protocolo,

además de una descripción detallada de la operación de IPv6 y los puntos comparativos

con su predecesor IPv4.

Todo lo anterior ha tenido por objetivo establecer las bases técnicas de la aplicación real

de IPv6 en un entorno donde coexisten múltiples protocolos de enrutamiento y es

necesario realizar los ajustes pertinentes para integrarlos en una única gran red.