Operación e Integración de Protocolos de Enrutamiento IGP para Redes Corporativas en I pv6-2

REDESCISCO.
NET
OPERACION E INTEGRACION DE MULTIPLES PROTOCOLOS DE
ENRUTAMIENTO INTERNOS (IGP) PARA REDES IPV6 CORPORATIVAS
Por
Paulo Colomés
Noviembre 2015

www.netlearning.cl www.redescisco.net
ÍNDICE GENERAL
INTRODUCCIÓN………………………………………………………………………. 3
CAPÍTULO I
DESCRIPCIÓN DEL PROBLEMA Y OBJETIVOS……………………………………. 4
CAPÍTULO II
FUNDAMENTOS DEL PROTOCOLO DE INTERNET VERSIÓN 6………………… 6
2.1. Diferencias comparativas de IPv6 frente a IPv4……………………………………. 11
CAPÍTULO III
PROTOCOLOS DE ENRUTAMIENTO INTERNOS PARA IPv6… ………………… 14
3.1. Protocolo de Información de Enrutamiento de Nueva Generación RIPng…………. 14
3.2. Protocolo de Enrutamiento de Pasarela Interior Avanzado para redes
IPv6 EIGRPv6…………………………………………………………………………… 22
3.3. Implementación del Protocolo Abierto de Ruta más Corta versión 3 OSPFv3……. 30
3.3.1. Configuración de OSPFv3 de área única…………………………………………. 30
3.3.2. Verificación de OSPFv3………………………………………………………….. 32
3.3.3. Aplicación de Enrutamiento OSPFv3 en entornos de múltiples áreas…………... 35
3.3.4. Aspectos técnicos de OSPFv3…………………………………………………..... 42
CAPÍTULO IV
FUNDAMENTOS DE INTERCONEXIÓN DE PROTOCOLOS IGP………………… 44
4.1. Métricas de RIPng, OSPFv3 y EIGRPv6………………………...…………………. 44
4.2. Integración de múltiples protocolos de enrutamiento en IPv6……………………… 51
4.2.1. Integración de RIPng con EIGRPv6……………………………………………… 52
4.2.2. Integración de RIPng con OSPFv3……………………………………………….. 62
4.2.3. Integración de OSPFv3 con EIGRPv6……………………………………………. 70
CAPÍTULO V
CASO DE ESTUDIO DE INTEGRACIÓN DE MÚLTIPLES PROTOCOLOS DE
ENRUTAMIENTO DINÁMICO EN IPv6………………………………………………. 75
5.1. Escenario actual…………………………………………………………………........75
5.2. Etapa de preparación………………………………………………………………… 78
5.3. Etapa de diseño/preparación………………………………………………………… 81
5.4. Etapa de implementación……………………………………………………………. 86
5.5. Etapa de verificación……………………………………………………………….. 104
5.6. Verificación de conectividad de capa 3……………………………………………. 120
CONCLUSIONES Y RESULTADOS………………………………………………….. 132
BIBLIOGRAFÍA………………………………………………………………………... 134
GLOSARIO TÉCNICO………………………………………………………………… 136

INTRODUCCION
Para nadie es secreto el hecho de que Internet ha evolucionado exponencialmente en la
última década y con ellos naturalmente las aplicaciones que sobre ella corren. Las
compañías requieren cada vez con mayor frecuencia el uso de aplicaciones de alto tráfico
y alta disponibilidad como son Streaming de videos, telefonía IP y aplicaciones en tiempo
real.
Para que las organizaciones puedan correr estas aplicaciones lo principal es que la red de
datos sobre la cual se sustentan sea convergente, es decir, que integre múltiples servicios
y que sea tolerante a fallas.
Estos aspectos se ven directamente afectados por el buen diseño de las redes a nivel de
capa 3 del modelo OSI y la correcta convergencia de los protocolos de enrutamiento que
permitan encaminar de manera correcta los paquetes de datos en las redes corporativas.
A partir desde hace un par de años ya se ha ido incorporando el direccionamiento IPv6 en
reemplazo de IPv4, que por más de 40 años ha sido el método predilecto de
direccionamiento en Internet, pero con graves deficiencias que IPv6 ha mejorado.
Este trabajo pretende establecer los parámetros, configuraciones, especificaciones
técnicas y técnicas de diseño para lograr implementar una red convergente de alta
disponibilidad utilizando protocolos de enrutamiento interior (IGP) basándose únicamente
en IPv6.

CAPITULO I
DESCRIPCIÓN DEL PROBLEMA
Resumen
En la actualidad las redes de datos deben ser no tan solo implementadas de manera robusta
y eficiente si no también diseñadas considerando una gran cantidad de aspectos tanto
técnicos como estructurales para poder funcionar de la manera más optimizada posible
asegurando así la continuidad del negocio y de todas las operaciones corporativas y
organizacionales que se sustentan en ellas.
Este trabajo plantea definir los parámetros, consideraciones y elementos fundamentales
necesarios para integrar múltiples protocolos de enrutamiento interior (IGP – Internal
Gateway Protocols) dentro de una única organización utilizando la versión 6 del protocolo
IP (IPv6) como reemplazo del actual direccionamiento de red basado en IPv4.
2. Descripción del Problema
El buen funcionamiento de una red de datos corporativa es sin duda un elemento
estratégico clave para el desarrollo de las demás operaciones de una organización actual.
Los recursos y aplicaciones de nivel de usuario como correo electrónico, páginas Web,
sistemas de gestión y recursos, bases de datos, entre otras, sustentan su funcionalidad en
la calidad de la red sobre la cual trabajan, ya sea WAN, LAN u otra. Si la red en
determinado momento presenta intermitencias, interrupciones, lentitud u otro tipo de
situaciones negativas, inmediatamente las aplicaciones de usuario se ven afectadas y, por
extensión, la continuidad del negocio de la empresa.

Muchas de estas deficiencias se presentan a nivel de diseño de red y no en las capas
superiores de los modelos de networking las cuales están asociadas a aplicaciones y
servicios sobre los cuales se sustenta el negocio. Es por eso que el desarrollo de una
estrategia y un buen diseño de red impacta directamente en la fiabilidad y calidad de la
misma y los servicios que sobre ella corren.
Uno de los problemas más complejos de solucionar es la integración de múltiples
protocolos de enrutamiento dentro de una misma área de administración común,
habitualmente denominada Sistema Autónomo (AS – Autonomous System). Por razones
de presupuesto, estratégicas o técnicas, no siempre se puede implementar una red de datos
con un mismo protocolo de enrutamiento y es necesario definir como, donde y bajo cuales
condiciones operarán los múltiples protocolos.
Los routers y dispositivos que ejecutan diferentes protocolos, tales como el Protocolo
Abierto de Ruta más Corta (OSPF – Open Short Path First), el Protocolo de Enrutamiento
de Pasarela Interior Mejorado (EIGRP – Enhanced Internal Gateway Routing Protocol),
el Protocolo de Enrutamiento de Pasarela Interior (IGRP – Internal Gateway Routing
Protocol), el Protocolo de Información de Enrutamiento (RIP – Routing Information
Protocol) y otros, deben interactuar entre sí e intercambiar información de enrutamiento
de la forma más óptima, económica y fluida posible. La implementación de múltiples
protocolos basados en IPv4 es un tema bastante recurrente en redes corporativas de
mediano a gran tamaño. Sin embargo, éste protocolo presenta una serie de deficiencias y
desventajas frente a IPv6 las que serán discutidas más adelante.

CAPITULO II
FUNDAMENTOS DEL PROTOCOLO DE INTERNET VERSION 6
IPV6
Para poder comprender de mejor manera de qué se trata IPv6 es necesario detallar su
antecesor inmediato: IPv4.
El protocolo de Internet (IP), definido originalmente en el RFC 791 (Request for
Comments) en el año 1981 bajo el nombre de DARPA Internet Protocol en su versión 4,
fue diseñado para proveer un método de direccionamiento de los paquetes de datos
enviados a la red de tal manera que los dispositivos intermedios puedan encaminar de
manera rápida y eficiente los datagramas desde que son generados en algún dispositivo o
nodo inicial hasta el destino correspondiente dejando toda la tarea de control de errores,
iniciación, mantención de sesiones y direccionamiento de aplicaciones (puertos) a las
capas superiores del modelo OSI o TCP/IP.
Dentro del modelo de referencia de interconexión de sistemas abiertos OSI (Open Systems
Interconnection) desarrollado por la Organización Internacional de Normalización ISO
(International Standarization Organization) el protocolo IP se ubica en la capa 3
denominada “red”.

Figura 2.1 – Representación de las capas del modelo de redes OSI y ubicación de IPv6
En la capa de red del modelo OSI operan distintos protocolos de direccionamiento de capa
3, como la versión 6 de IP y los desaparecidos IPX de Novell y AppleTalk de Apple Inc,
siendo estos dos últimos casi totalmente absorbidos por IPv4.
Figura 2.2 – Encabezado IPv4
Explicación de los campos del encabezado IPv4
- Versión: 4 bits de longitud. Aquí se indica la versión del protocolo IP que se está
ejecutando. Invariablemente lleva un valor 0100 (versión 4).

- IHL (Internet Header Lenght): 4 bits de longitud. Indica la longitud total del
encabezado IPv4 (Normalmente 20 bytes) expresados en múltiplos de 32. El valor
mínimo para este campo es 5 (50 x 32 = 160 bits o 20 bytes).
- ToS (Type of Service): Este campo ha sido reemplazado por el actual mecanismo
de DiffServ (Servicios Diferenciados) de acuerdo al RFC 2474 y ECN (Explicit
Network Congestion – Congestión explícita de red) en el RFC 3168.
Principalmente orientado a brindar calidad de servicio (QoS – Quality of Service)
mediante la identificación de distintos orígenes y tipo de tráfico IP, como por
ejemplo Voz sobre IP (VoIP).
- Longitud Total: A diferencia de IHL, que solamente indica la longitud del
encabezado, este campo de 16 bits de longitud indica el tamaño total del paquete
IP incluyendo la carga útil de las capas superiores. El tamaño mínimo es 20 bytes
(IHL + 0 bytes) y el máximo es 65.536 bytes.
- Identificación: Utilizado en forma experimental solamente, fue diseñado para
utilizar una forma de rastreo de datagramas IP en caso de que este pase por algún
mecanismo de fragmentación.
- IP Flags: Campo de 3 bits utilizado para determinar si un paquete IP debe ser
fragmentado o no al pasar por un enrutador.
- Offset: Campo de control de tamaño del encabezado en caso de fragmentación.
- TTL: Time to Live – Tiempo de Vida. Este valor de 8 bits de longitud permite
definir un mecanismo para evitar los bucles de enrutamiento y así controlar los
datagramas que recorren la red en círculos producto de un error. Por cada enrutador
o dispositivo de capa 3 que el paquete atraviese este valor se rebaja en uno. Así,

teóricamente un paquete IP podría pasar por un máximo de 256 routers hasta ser
descartado completamente.
- Protocolo: Este campo especifica el tipo de protocolo IP al cual pertenece el
paquete que lo contiene. Según el RFC 790, la IANA (Internet Assigned Numbers
Authority) ha definido distintos números para cada protocolo de capa 3. Así, el
mismo IPv4 recibe el número Ox04, ICMP 0x01, UDP 0x11, entre otros.
- Checksum: Al igual que el protocolo TCP y otros, IPv4 mantiene un mecanismo
de verificación de errores del encabezado de red. El router comprueba el paquete
entrante y verifica mediante un proceso de comprobación de redundancia cíclica
(CRC) si acaso este contiene errores. De ser así, se descarta el paquete.
- Dirección de origen: Campo de 32 bits de longitud que contiene la dirección IP
del host que inicia la conexión.
- Dirección de destino: Campo de 32 bits de longitud que contiene la dirección IP
del host que termina la conexión. Al igual que la dirección de origen, el valor de
este campo solo es modificado si existe algún mecanismo de traducción de
direcciones de red (NAT – Network Address Translation).
- Opciones: Campo opcional, no utilizado frecuentemente.
Al observar el encabezado de IPv4, principalmente los campos de dirección de origen y
destino, se sabe que las direcciones IP tienen una longitud de 32 bits separadas en 4
bloques denominados también “octetos” de 8 bits cada uno, permitiendo direcciones entre
0 y 255. Un ejemplo de esto es la siguiente dirección escrita en formato binario y en su
equivalente decimal punteado:
11000000.10101000.00000000.00000001 = 192.168.0.1

En cada octeto el número mínimo posible es 0 y el máximo es 255, permitiendo 28
combinaciones, es decir un total de 256 números.
El principal problema con IPv4 radica en la cantidad de direcciones que ofrece este
protocolo al tener una longitud de solamente 32 bits. Desde la IP 0.0.0.0 hasta
255.255.255.255 existen 232 combinaciones, dando un total de 4.294.967.296 direcciones.
Actualmente ese número aunque pareciese ser enorme ni siquiera alcanza para proveer de
una dirección IP por cada habitante del planeta, considerando que la población mundial
rodea los 7.000 millones de personas. Sumándole a esto el hecho de que cada persona
utiliza más de una sola dirección IP en distintos dispositivos tales como teléfonos
inteligentes, computadores personales, automóviles en algunos casos, consolas de
videojuegos, entre otros, además de la propia distribución de direcciones dentro del
estándar IP el cual determina que no todas son utilizables, reduciendo así la cantidad de
números útiles reales. El siguiente cuadro explica la división de direcciones IPv4.
Rango Descripción Documentado en el RFC
0.0.0.0 – 0.255.255.255 Red actual. (válido solo para enrutamiento y direcciones de 1700
origen)
10.0.0.0 – 10.255.255.255 Direcciones privadas no enrutables en Internet. 1918
127.0.0.0 – 127.255.255.255 Direcciones de bucle local (Loopback) 5735
169.254.0.0 – 169.254.255.255 Link-Local. Autodireccionamiento de red (APIPA) 3927
224.0.0.0 – 239.255.255.255 IP Multicast (Antes clase D) 5771
240.0.0.0 – 255.255.255.254 Experimental (Antes clase E) 1700
255.255.255.255 Broadcast (Difusión amplia) 919
Tabla 1.1 – División y clases de direcciones IPv4
Así, las direcciones utilizables en Internet denominadas públicas, no mostradas en la tabla,
se reducen considerablemente.
10

Desde el auge de Internet a mediados de los años 90, los ingenieros de redes,
principalmente pertenecientes al IETF (Internet Engineering Task Force) se dieron cuenta
de que al ritmo de entonces de crecimiento en el uso y masificación de la red no pasaría
mucho tiempo sin que el protocolo IPv4 ya no sea capaz de entregar direcciones necesarias
para seguir conectando usuarios y sistemas al mundo interconectado global. Es por eso
que decidieron trabajar en el desarrollo de una nueva versión de IPv4: la versión 6. El
número 5 ya estaba utilizado como experimental en el RFC 1819 que definía las bases del
Protocolo de Streaming de Internet (ST). Este nunca llegó a utilizarse y por eso se saltó a
la versión 6.
2.1 Diferencias comparativas de IPv6 frente a IPv4
IPv6 supone una serie de mejoras técnicas al viejo IPv4 donde la principal característica
es la nueva longitud de las direcciones de capa 3 ahora de 128 bits. Además se modificaron
y eliminaron algunos campos del anterior encabezado enfocándose siempre en reducir la
sobrecabecera (overhead) propia del encapsulamiento y algunos protocolos.
11

Bits
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 2.3 - Encabezado IPv4 en formato de texto según RFC 791
Bits
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Traffic Class | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Length | Next Header | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Source Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Destination Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figura 2.4 - Encabezado IPv6 en formato de texto según RFC 2460
12

Como se puede observar en la figura 2.4, las direcciones IPv6 de origen y de destino
ocupan un espacio 4 veces mayor al de las direcciones de 32 bits de IPv4. El encabezado
se ha preparado para ser enviado en flujos de 64 bits a fin de hacer el cálculo,
desencapsulación y encapsulación de los paquetes IP mucho más eficientes con los
actuales procesadores de 64 bits. Además, los campos IHL, identificación, Flags, Offset y
Checksum de IPv4 han sido eliminados. ToS (DSCP) ahora se denomina Traffic Class, se
ha agregado un nuevo campo denominado etiqueta de flujo. TTL se llama Hop Limit
(límite de saltos) y Protocolo se llama ahora Next Header o encabezado siguiente.
Un cambio visual importante es que la presentación de direcciones al usuario se realiza en
formato hexadecimal, en 8 bloques de 16 bits. Un ejemplo de una dirección IPv6 típica
sería 00FE:0001:0002:0003:ABCD:EF02:CA32:0001
IPv6 soporta 2128 direcciones o un total de
340.282.366.920.938.463.463.374.607.431.768.211.456.
Comparativamente IPv6 ofrece 79.228.162.514.264.337.593.543.950.336 direcciones por
cada IPv4 o 49.316.285.061.005.574.414.981.827.164 por cada habitante del planeta. Este
número increíblemente enorme está calculado que durará los próximos 400 años sin que
se requiera un nuevo cambio en la capa 3.
Los protocolos de enrutamiento más utilizados actualmente en entornos IGP, es decir,
dentro de un mismo sistema autónomo son EIGRP y OSPF, siendo el primero propietario
de la empresa Cisco y OSPF definido en el RFC 2328 en su versión 2 y en el RFC 5340
en versión 3 soportando IPv6. Ambos protocolos, incluyendo ya el casi desaparecido RIP
han sido ampliamente utilizados en redes IPv4 debido a sus características propias y su
naturaleza de enrutamiento dinámico. RIP tiene una versión con soporte para IPv6
denominado RIPng (New Generation) pero que no ofrece ninguna mejora ni ventaja en el
13

algoritmo principal (Bellman-Ford), sino que solamente han cambiado los encabezados
para soportar las nuevas direcciones de 128 bits.
CAPITULO III
PROTOCOLOS DE ENRUTAMIENTO INTERNOS PARA IPV6
En este capítulo se tratarán los fundamentos, características y condiciones de
implementación de los protocolos de enrutamiento RIPng, OSPFv3 y EIGRPv6. Cada uno
tiene distintos elementos que deben ser considerados antes de realizar una instalación y
que merecen ser explicados previamente antes de tratar el problema de integración entre
ellos.
3.1 Protocolo de Información de Enrutamiento de Nueva Generación RIPng
El Protocolo de Información de Enrutamiento de Nueva Generación, RIPng, (Routing
Internet Protocol New Generation), definido en el RFC 2080, permite que los enrutadores
intercambien información y tablas de enrutamiento de manera automática y a intervalos
regulares de tiempo utilizando como base IPv6. Al igual que su predecesor RIP (que en
sus versiones 1 y 2 opera únicamente con IPv4), RIPng es un protocolo de tipo vector
distancia, el cual permite que los routers intercambien rutas solamente con sus vecinos
que están conectados directamente. Con la adopción de IPv6 se ha hecho necesario
modificar algunos componentes claves de RIPng y otros protocolos para poder soportar
direcciones de 128 bits y las características avanzadas que se incluyen en la versión 6 del
protocolo de Internet. A continuación se explica brevemente el funcionamiento de RIP
antes de detallar las diferencias con RIPng.
14

• RIP utiliza el puerto 520/UDP para intercambiar información de rutas. RIP utiliza
el conteo de saltos (cantidad de routers) desde el origen a la red de destino para
medir la distancia. El conteo de saltos (hop counting) se conoce como métrica,
siendo un máximo de 15 lo permitido y a cualquier ruta que esté a 16 o más saltos
de distancia se le asigna invariablemente la métrica 16 que es considerada como
infinita, lo que significa que la red de destino es inalcanzable.
• RIP tiene dos versiones: RIPv1 y RIPv2. Básicamente se diferencian entre sí en
que el primero es un protocolo Classful o con clase y RIPv2 es Classless o sin
clase. Los mensajes de RIPv1 no transportan la máscara de subred por lo tanto los
routers receptores deben asignar la máscara predeterminada (/8, /16 o /24) según
sea la clase (A, B o C) de la ruta.
RIPng opera básicamente de la misma forma que RIP con solo algunas diferencias que se
destacan a continuación:
• RIPng utiliza un encabezado diferente para soportar las direcciones de 128 bits.
• RIP puede correr sobre redes IPX e IP, mientras que RIPng solo opera bajo IPv6.
• En RIPng se utiliza el mecanismo de autenticación propio de IPv6 mientras que
en RIP se debe configurar esta opción como parte del método de ruteo.
• RIPng utiliza el puerto 521/UDP.
15

Figura 3.1.1 – Topología de red de ejemplo para un escenario de aplicación de RIPng
La figura 3.1.1 representa el núcleo de red de una organización compuesto por tres routers
interconectados entre sí los cuales comunican las redes LAN remotas 1 y 2.
Dado el direccionamiento indicado en la figura, los routers deben ser capaces de
intercambiar información de enrutamiento de manera dinámica y a intervalos de tiempo
regulares establecidos por el mismo protocolo RIPng.
La métrica de RIPng es la cuenta de saltos (hop count). Esto quiere decir que un router
determinará que la mejor ruta para llegar a la red de destino es aquella que cuenta con
menor cantidad de dispositivos intermedios. Para R1 la ruta preferencial para alcanzar la
red 2001::2:0:0:0:0/64 es mediante el enlace WAN con R2, ya que la cuenta de saltos es
1 y a través de R3 es 2. Esta información se agrega a la tabla de enrutamiento local y se
utiliza para alcanzar la red remota designada.
El detalle de configuración de la topología anterior es el siguiente para cada router.
Configuración de direccionamiento en R1
R1(config)#
R1(config)#int s0/0
R1(config-if)#ipv6 address 2001:A:A:A::5/64
R1(config-if)#no shutdown
16

R1(config-if)#int f0/0
R1(config-if)#ipv6 address 2001:A:A:C::5/64
R1(config-if)#ipv6 address 2001:0:0:1::1/64
R1(config-if)#
R2(config)#
R2(config)#int s0/0
R2(config-if)#ipv6 address 2001:A:A:A::6/64
R2(config-if)#ipv6 address 2001:A:A:B::5/64
R2(config-if)#ipv6 address 2001::2:0:0:0:1/64
R2(config-if)#
R3(config)#int f0/0
R3(config-if)#ipv6 address 2001:A:A:C::6/64
R3(config-if)#ipv6 address 2001:A:A:B::6/64
R3(config-if)#
Para comprobar que los enlaces funcionan correctamente en la capa 3 es necesario probar
con mensajes ICMP Echo Request y Echo Reply para IPv6. En los dispositivos Cisco la
comprobación se demuestra con el comando “ping” y el signo de exclamación (!). Como
se envían de manera predeterminada 5 mensajes ping, una secuencia de 5 símbolos de
exclamación (!!!!!!) indican que la conexión es correcta.
17

Figura 3.1.2 – Comprobación de conexión desde R1 hacia 2001:A:A:A::6 mediante ping IPv6
El mismo procedimiento de comprobación aplica a los demás enrutadores para determinar
conectividad entre los enlaces. El paso siguiente corresponde a habilitar el proceso de
enrutamiento global IPv6 en cada router.
R1(config)#ipv6 unicast-routing
Finalmente para habilitar RIPng solamente se debe ingresar a cada interfaz de router que
se desea publicar en el proceso y ejecutar el comando ipv6 rip IDENTIFICADOR
enable donde IDENTIFICADOR es un ID de proceso muy similar al PID en OSPF. Este
valor puede ser numérico o alfanumérico. Aunque las interfaces FastEthernet0/1 de R1 y
R3 no conectan con ningún otro router es necesario, sin embargo, en ellas también
habilitar RIPng para que esas redes se publiquen hacia sus vecinos y éstos tengan noción
de que son alcanzables en su tabla de enrutamiento.
Habilitación de enrutamiento en R1
R1(config)#interface FastEthernet0/0
R1(config-if)#ipv6 rip SISTEMA1 enable
R1(config-if)#interface FastEthernet00/1
R1(config-if) interface Serial0/0
18

R1(config-if)#end
R2(config)# interface FastEthernet0/0

R2(config-if)# interface FastEthernet0/1
R2(config-if)#interface Serial0/0
R2(config-if)#end

R3(config-if)# interface FastEthernet0/1
El nombre de proceso no necesariamente debe ser el mismo en todos los router. Como es
un identificador local, puede ser el mismo o diferente en toda la red RIPng y el
enrutamiento funcionará igualmente. Sin embargo, es necesario que en el mismo router
todas las interfaces si pertenezcan al mismo proceso. Las rutas son aprendidas por los
demás routers mediante el intercambio de mensajes de actualización del protocolo RIPng
y agregadas a la tabla de enrutamiento de los dispositivos que reciben estos updates.
19

Figura 3.1.3 – Tabla de enrutamiento IPv6 de R1
20

Las entradas de la tabla de enrutamiento marcadas con R han sido aprendidas mediante
RIP. Enviando una consulta ping (ICMPv6) desde R1 hacia la red LAN2 se comprueba
que el enrutamiento ha sido configurado correctamente.
Figura 3.1.6 – Ping desde R1 hacia 2001:0:0:2::1 para comprobar conectividad a través de la red RIPng
RIPng es un protocolo bastante simple de implementar, sin embargo los problemas de
escalabilidad asociados a él, principalmente debido al tipo de métrica y el máximo de
saltos establecido en 15 hacen que en muchas ocasiones los administradores de redes
prefieran protocolos más avanzados como EIGRP u OSPF.
21

3.2 Protocolo de Enrutamiento de Pasarla Interior Avanzado para redes IPv6
EIGRPv6
EIGRP (Enhanced Internal Gateway Routing Protocol) es un protocolo de enrutamiento
de vector distancia propietario de la compañía Cisco y no compatible con dispositivos de
otra marca/fabricantes a diferencia de OSPF y RIP que son estándares definidos bajo sus
respectivos RFC que aseguran interoperabilidad entre fabricantes diferentes. No obstante
lo anterior, EIGRP es capaz de funcionar igualmente en un entorno donde otros protocolos
IGP existen ya que está diseñado para aceptar información de otros routers y traspasarla
a su propia tabla de enrutamiento en un proceso conocido como redistribución de rutas.
Al igual que EIGRP para IPv4, EIGRPv6 se trata de un protocolo de tipo vector distancia
que utiliza una métrica compuesta, actualizaciones confiables (es decir, que por cada
mensaje que se envía con una actualización de enrutamiento a su vecino, éste responde de
vuelta con un acuse de recibo o Acknowledgment) y se basa en la utilización del algoritmo
de máquina finita DUAL (Diffusing Update Algorithm) para asegurar una convergencia
rápida.
Existen, sin embargo, algunas pequeñas diferencias entre ambas versiones debido
principalmente a la naturaleza de IPv6 como la ausencia de mensajes de difusión amplia
en este protocolo (Broadcast) o el hecho de que no exista el concepto de enrutamiento con
clase (Classful). Algunas características de EIGRPv6 son
• Al igual que OSPv3 y RIPng la configuración se realiza basada en comandos de
interfaz.
• EIGRPv6 requiere un especificar un Router-id.
22

• Las interfaces pasivas son configuradas solamente a nivel de proceso de
enrutamiento.
• La autosumarización en EIGRPv6 no es equivalente a IPv4 por la ausencia de
enrutamiento con clase.
Dentro de las similitudes entre EIGRP para IPv4 y EIGRP para IPv6 destacan
• Igual tipo de métrica (Compuesta. Explicada en detalle más adelante en este
trabajo).
• Ambos soportan autenticación de los mensajes de actualización mediante MD5.
• Capacidad para poder definir el porcentaje de uso del ancho de banda del enlace
para transmitir los mensajes de actualización. Por defecto fijado en 50%.
• La regla de “Horizonte Dividido” (Split-Horizon) está activada de manera
predeterminada. Esto es, que los routers no reenviarán publicaciones EIGRP
saliendo por la misma interfaz en la cual se recibió ese mensaje.
• Temporizadores para el intervalo de envío de mensajes Hello y Tiempo de Espera
(Hold Time) en 5 segundos y 15 respectivamente.
• Soporte para redes Stub.
• Soporte para balanceo de carga por enlaces con métricas diferentes mediante el
comando variance. EIGRP es el único protocolo con esta opción. Todos los demás
solamente realizan balanceo de carga única y exclusivamente cuando los costos o
métricas hacia una red determinada son iguales por 2 o más vecinos.
Configuración básica de EIGRPv6
23

La configuración de un router para implementar EIGRPv6 es, en cierta medida,
bastante similar a RIPng. A continuación se demuestra lo anterior con un ejemplo:
Router(config)# ipv6 unicast-routing

Router(config)# interface FastEthernet 0/0
Router(config-if)# ipv6 address 2001:0:3:1::/64
Router(config-if)# ipv6 eigrp 10
Router(config-if)# no shutdown
Router(config-if)# exit
Router(config-if)# ipv6 address 2001:0:3:2::/64
Router(config-if)# ipv6 eigrp 10
Router(config-if)# no shutdown
El comando ipv6 unicast-routing habilita el enrutamiento global de IPv6. A
continuación solamente es necesario configurar la dirección IPv6 en la interfaz que se
requiere publicar mediante EIGRPv6 y complementariamente se agrega el comando
ipv6 eigrp 10 donde 10 corresponde al número de sistema autónomo (ASN) escogido.
Este número debe ser el mismo para todos los routers de la red ya que de ser diferentes,
dos routers vecinos no podrán intercambiar mensajes EIGRP. Es requerido entonces
repetir la configuración anterior en los demás enrutadores.
Para demostrar lo anterior se detalla a continuación la configuración de la misma
topología de ejemplo utilizada en la figura 3.1.1 y las correspondientes pruebas de
verificación de conectividad. Asumiendo que el direccionamiento IPv6 ya fue
previamente configurado como se muestra en el esquema, el resto de la configuración
es como sigue:
1. Habilitar el proceso de enrutamiento global IPv6 en cada router:
24

2. Habilitar el proceso de enrutamiento EIGRPv6 en cada router.
Para esto es necesario definir un Número de Sistema Autónomo (ASN) común para todos.
En el ejemplo se utilizará el ASN 100. Además se debe definir el Router-ID¸ que es el
identificador de cada enrutador en formato IPv4 y levantar el proceso con no shutdown.
R1(config)# ipv6 router eigrp 100

R1(config-rtr)# router-id 1.1.1.1
R1(config-rtr)# no shutdown


3. Configuración de las interfaces y rutas de cada router en la red para ser
publicadas en EIGRPv6
R1(config)#interface FastEthernet 0/0

R1(config-if)#ipv6 eigrp 100
R1(config-if)#exit
R1(config-if)#exit
R1(config)#interface Serial0/0
R1(config-if)#exit

R2(config-if)#exit
R2(config-if)#exit
R2(config)#interface Serial0/0
R2(config-if)#exit

R3(config-if)#exit
25

R3(config-if)#exit
4. Verificación de EIGRPv6
Para verificar que este protocolo esté funcionando correctamente es necesario en primer
lugar revisar el estado de las adyacencias entre los vecinos. Esto se logra con el comando
show ip eigrp neighbor.
Figura 3.2.1- Verificación de vecinos y adyacencias de R1
Figura 3.2.2 - Verificación de vecinos y adyacencias de R2
Figura 3.2.3 - Verificación de vecinos y adyacencias de R3
En las figuras 3.2.1, 3.2.2 y 3.2.3 se puede observar que las adyacencias están
correctamente establecidas con los routers vecinos. Cabe destacar que EIGRPv6 forma
26

adyacencias con las direcciones Link-Local de IPv6 de los routers y no con las direcciones
IPv6 globales configuradas previamente en las interfaces. R1 ha levantado una adyacencia
correctamente contra FE80::C215:19FF:FE44:0 que es la dirección Link-Local de R2 y
contra FE80::C214:19FF:FE44:0 que es la dirección Link-Local de R3. Esto es
comprobable mediante el comando show ipv6 interface brief en R2 y R3. El asunto de
las direcciones Link-Local se tratará en mayor detalle más adelante.
Figura 3.2.4 – Verificación de direcciones IPv6 de las interfaces de R2
Figura 3.2.5 – Verificación de direcciones IPv6 de las interfaces de R3
En cada router se debe verificar la tabla de enrutamiento (show ipv6 route) para
comprobar que las rutas se están intercambiando correctamente y que las LAN1 y LAN2
son accesibles desde todos los hosts.
27

Figura 3.2.6 - Tabla de enrutamiento IPv6 de R1 bajo EIGRPv6
28

Como es posible identificar en las figuras 3.2.6, 3.2.7 y 3.2.8 las redes han sido
correctamente aprendidas mediante EIGRPv6 y se indican mediante la letra D
correspondiente al algoritmo DUAL mencionado anteriormente y que es la base de EIGRP
para los cálculos de ruta.
Por último se comprueba conectividad desde R1 hacia la LAN2 (2001:0:0:2::1)
Figura 3.2.9 – Comprobación de conectividad desde R1 hacia 2001:0:0:2::1 mediante ping IPv6
EIGRPv6 ha convergido e intercambiado rutas IPv6 correctamente entre todos los routers.
29

3.3 Implementación del Protocolo Abierto de Ruta más Corta versión 3 OSPFv3
El protocolo OSPF (Open Short Path First) es un estándar de enrutamiento dinámico
definido en el RFC2328 para IPv4 (OSPFv1 y OSPFv2) y en el RFC5340 para redes IPv6
(OSPFv3). A diferencia de EIGRP y RIP, OSPF es un protocolo de tipo link-state. En
términos prácticos esta denominación significa que cada router OSPF de la red tendrá
almacenada una base de datos completa de la topología o el área a la cual pertenece. Los
protocolos vector distancia solamente son capaces de evaluar la información que les envía
un vecino directamente, mientras que OSPF puede observar lo que ocurre en cualquier
punto de la red. Esto último hace que eventualmente para implementar OSPF los requisitos
de hardware y de ancho de banda sean mayores que con otros protocolos.
Una de las ventajas que supone OSPF frente a EIGRP y RIP es que el primero es estándar
al igual que RIP y el diseño de redes que operen bajo este protocolo se puede realizar en
zonas, con un máximo sugerido de 50 enrutadores por cada área. Así es posible
implementar OSPF en redes corporativas de gran tamaño. OSPF se puede implementar en
un área única, conocida como área 0 o Backbone y también en un entorno multiárea donde
las demás áreas se conectan directamente al área 0.
3.3.1 Configuración de OSPFv3 de área única
La misma topología de la figura 3.1.1 se utilizará para demostrar la implementación de
OSPFv3 en un área única. Asumiendo que el direccionamiento IPv6 se debe configurar
los siguientes comandos en cada router para levantar OSPFv3
Configuración de R1
R1(config)#ipv6 router ospf 1
R1(config-rtr)#router-id 1.1.1.1
30

R1(config-rtr)#exit
R1(config)#
R1(config)# ipv6 ospf 1 area 0
R1(config)# interface Serial0/0
R2(config-rtr)#exit
R2(config)#
R2(config)# interface Serial0/0
R3(config-rtr)#exit
R3(config)#
Al igual que en EIGRPv6, en OSPFv3 es obligatorio definir manualmente un Router-ID
escrito en formato IPv4. Este ID no tiene ninguna incidencia en el proceso de enrutamiento
ni direccionamiento, si no que sirve para identificar a cada enrutador en la red. Cada
interfaz que se quiera agregar al entorno OSPF y publicar a los demás routers debe llevar
el comando ipv6 ospf 1 area 0 donde 1 es el Process-ID escogido localmente y el área 0
31

representa el backbone de la red. El tema de la implementación de OSPF con múltiples
áreas de describe más adelante.
3.3.2 Verificación de OSPFv3
Tal como EIGRPv6, OSPF también maneja una tabla de adyacencias con vecinos. A
continuación se muestra la salida del comando show ipv6 ospf neighbor para los 3 routers
a fin de verificar que el proceso de establecimiento de relación de vecindad haya sido
correcto en la topología.
Figura 3.3.2.1 – Verificación del estado de adyacencias de OSPFv3 en R1
Como se puede apreciar en las figuras 3.3.2.1, 3.3.2.2 y 3.3.2.3 cada router ha formado
una adyacencia con su respectivo vecino identificado por el Router-ID manualmente
ingresado en la configuración. El estado FULL indica conectividad correcta con el vecino.
32

Es necesario revisar las tablas de enrutamiento y realizar un ping desde R1 a la LAN2 para
verificar que el intercambio de rutas IPv6 se ha realizado correctamente.
Figura 3.3.2.4 - Tabla de enrutamiento IPv6 para R1 bajo OSPFv3
33

34

Por último se comprueba conectividad desde R1 hacia la LAN2 (2001:0:0:2::1)
Figura 3.3.2.7 – Comprobación de conectividad desde R1 hacia 2001:0:0:2::1 mediante ping IPv6
OSPFv3 ha convergido e intercambiado rutas IPv6 correctamente entre todos los routers.
3.3.3 Aplicación de Enrutamiento OSPFv3 en entornos de múltiples áreas
OSPF se diferencia de los demás protocolos porque permite adaptarse con facilidad a redes
de mediano a gran tamaño permitiendo optimizar los procesos de enrutamiento dentro de
la infraestructura completa al utilizar el concepto de división de áreas. A diferencia de los
protocolos de enrutamiento de vector-distancia como RIP (v1, v2, ng) y EIGRP, OSPF
permite tener distintas áreas que facilitan la administración y reducen las tablas de
enrutamiento de los routers, permitiendo una mayor rapidez de conmutación de capa 3 y
también reduciendo la carga de recursos 3en ellos, tales como ancho de banda, uso de
CPU, RAM, entre otros.
Para comprender como opera el enrutamiento OSPF multiárea en IPv6 es necesario
conocer los elementos y características aplicadas en este modo, tanto para IPv4 como
IPv6.
35

Áreas de OSPF
OSPF divide su funcionamiento en múltiples áreas, cada cual con ciertas reglas. Esto
permite mejorar la administración de redes de gran extensión y reducir la tabla de
enrutamiento de los routers.
Sin duda que OSPF es un protocolo complejo y requiere mucho estudio para poder
comprender bien cómo funciona y mucha práctica para poder dominarlo. Uno de los
conceptos más importantes dentro de OSPF es el diseño y funcionamiento de las distintas
áreas, asunto que puede tornarse confuso fácilmente debido a la similitud de nombres y
variedad de opciones que soporta.
Para poder explicar cómo funciona cada una de ellas es necesario conocer los mensajes
que se intercambian los routers llamados LSA (Link State Advertisements o mensajes de
estado de enlace) que utiliza OSPF para comunicarse entre vecinos y traspasar
información de enrutamiento entre ellos.
Tipo 1 (Router LSA)
Cada router dentro de un área X envía LSA de tipo 1 a sus vecinos. Este LSA nunca sale
del área a la cual pertenece y contiene el Router-ID del remitente, y todos los enlaces que
lo conectan.
Tipo 2 (Network LSA)
Es enviado por el DR (Designated Router) dentro de la red. Él informa a los demás las
redes y máscara que tiene conectados. Este LSA nunca sale del área a la cual corresponde.
Es decir, un ABR (Area Border Router – Enrutador de Borde de Área) no lo reenvía a otra
36

área. Un ABR es un router que tiene al menos una de sus interfaces en el área 0 y una o
más en otra área. Este dispositivo se encarga de traducir las LSA de un área a otra.
Tipo 3 (Summary LSA)
Las envía un ABR para traspasar la información de un área a otra. OSPF las denomina
“summary”.
Tipo 4 (ASBR-Summary LSA)
Representa a un ASBR (Autonomous System Border Router) que es un router que se
encuentra con una de sus interfaces generalmente en el área 0 y con una o más de las
demás interfaces en otro método de enrutamiento externo a OSPF, como puede ser RIP,
EIGRP o enrutamiento estático.
Tipo 5 (External LSA)
Representa a una ruta externa redistribuida dentro de OSPF desde otro protocolo (Ej:
EIGRP). El ASBR toma las rutas provenientes del protocolo externo y las reenvía como
tipo 5 a todas las áreas internas, excepto a las de tipo Stub.
Las normas de OSPF dicen que solamente en un área Backbone debería haber
redistribución desde un protocolo externo. En un área NSSA (Not-so-stubby-area)
(cualquiera menos área 0) se puede conectar un Router que tenga conexión con otro
protocolo de enrutamiento externo (ej: RIP) y el ASBR enviaría esas redes en formato de
tipo 7, de tal manera que el ABR las tome y las redistribuya como tipo 5.
Las LSA de tipo 1 y 2 están presentes en todas las áreas y nunca se envían fuera de la cual
pertenecen. Las demás LSA se envían entre áreas dependiendo de la función que cumplan.
37

Tipos de área en las cuales opera OSPF
OSPF maneja distintos tipos de áreas según sea su utilidad o ubicación dentro de la red.
A continuación se explican brevemente en qué consisten cada una de ellas.
Área Standard
Es el área por defecto y permite actualización de enlaces, sumarización de rutas y rutas
externas.
Backbone
Es el área principal de una topología OSPF. Es obligatorio que exista y todas las demás
deben estar conectadas a ella. Se etiqueta como area 0 y tiene las mismas características
de un área estándar. En una implementación de OSPF de área única, solamente se utilizará
ésta área.
Stub Area
Este tipo de área no acepta información acerca de rutas externas al sistema autónomo
(redistribución), tales como rutas desde orígenes no OSPF. Si los Router necesitan
comunicarse hacia redes ubicadas fuera del sistema autónomo OSPF, utilizan una ruta
por defecto (0.0.0.0/0) que es enviada por el ABR hacia los demás Router internos del
área Stub. En esta área no se permiten ASBR (a menos que el ABR sea al mismo tiempo
un ASBR).
Totally Stubby Area
38

Esta área es propietaria de Cisco y no acepta rutas de sistemas autónomos externos
(redistribución) o rutas sumarizadas desde otras áreas internas del sistema autónomo. Al
igual que en las áreas Stub, los ABR envían una ruta por defecto para todas las rutas
externa y sumarizadas, siendo esto último el elemento diferenciador con un área Stub. En
esta área no se permiten ASBR (a menos que el ABR sea al mismo tiempo un ASBR).
Not-so-stuby AREA (NSSA)
En este tipo de áreas existen los LSA de tipo 7. Son similares a las área Stub ya que no
aceptan información de rutas externas al sistema autónomo (el mundo OSPF) y las
reemplaza por una ruta por defecto originada en el ABR. Sin embargo, la diferencia radica
en que las NSSA sí aceptan un ASBR que conecte con otro protocolo de enrutamiento (ej:
RIP, EIGRP, etc) directamente. El ASBR de las NSSA reenvía las rutas dentro del área
como LSA 7, y el ABR correspondiente las traduce a tipo 5 para ser tratadas de forma
normal.
Totally stubby NSSA
Totally Stubby Not-so-stubby Area o Totally Stubby NSSA es un área propietaria de Cisco
que se comporta igual que las Totally Stubby Area, es decir, no permite ni rutas externas
ni sumarizadas, pero que sí permite un ASBR al igual que las NSSA.
39

Figura 3.3.3.1 – Ejemplo de implementación OSPF con múltiples áreas
En la figura 3.3.3.1 R3 y R6 son ABRs ya que interconectan diferentes áreas, mientras
que R4 y R8 son ASBR por que conectan con otro sistema autónomo u otros protocolos
de enrutamiento. En el área 0 existen todos los LSA, por lo tanto cuando R4 aprenda una
ruta RIP y la redistribuya a OSPF tanto R3 como R5 y R6 las verán como externas.
El administrador ha decidido levantar un área Stub entre R1 y R2 para reducir la carga de
los routers. Como resultado de esto R1 y R2 verán de manera normal todas las rutas de la
topología excepto aquellas que han sido aprendidas por fuentes externas, como RIP, ya
que R3 al ser un ABR de un área Stub, reemplazará esas redes por una ruta por defecto.
Por lo tanto en la tabla de enrutamiento de R1 y R2 aparecerán todas las redes del mundo
OSPF más una ruta por defecto.
En R7 y R8 ocurre algo similar. Al ser ésta un área NSSA (Not So Stubby Area) ocurre lo
mismo que en un área Stub. Por lo tanto R7 y R8 verán las redes RIP como una ruta por
40

defecto que ha sido informada por R6. Pero acá existe un ASBR (R8) que conecta con una
red externa de tipo EIGRP lo cual no se permite en un área Stub. Cuando R8 reenvía las
rutas aprendidas por EIGRP hacia el mundo OSPF las envía como tipo LSA 7 y el próximo
ABR (R6) las convierte en tipo 5. Este es un caso especial ya que lo óptimo es que la
redistribución se realice en el área 0.
Se podría convertir el área Stub en una Totally Stubby Area. Lo único que cambiaría en
este caso respecto al área Stub es que no ya no se aceptarían rutas sumarizadas. Lo demás
se mantiene. También se podría convertir el área NSSA en un área Totally Stubby Area.
Lo único que cambiaría en este caso es que la NSSA no aceptaría más rutas sumarizadas.
Figura 3.3.3.2 - Diagrama de implementación de las distintas áreas de OSPF
Algunas cosas importantes a considerar en el diseño de OSPF con múltiples áreas:
• Un área no debería tener más de 50 routers.
41

• Un router no debería estar en más de 3 áreas simultáneamente.
3.3.4 Aspectos técnicos de OSPFv3
Luego de haber mostrado las configuraciones y elementos esenciales de OSPF es
necesario enfocarse en la implementación de la versión 3 de este protocolo orientado
específicamente al funcionamiento bajo IPv6.
OSPFv3 está definido bajo el RFC 5340 y presenta ciertas diferencias con OSPFv2 para
redes IPv4. Ambas versiones son incompatibles entre sí, pero pueden ejecutarse
simultáneamente en paralelo en el mismo router pero separadamente para soportar
dominios de enrutamiento tanto IPv4 como IPv6. Esto puede ser útil en un entorno Dual-
Stack para transición de IPv4 a IPv6.
Tipos de LSA en OSPFv3
OSPFv3 utiliza los 7 tipos de LSA incorporados en OSPFv2. Sin embargo los LSA de tipo
1 y 2 han sido reajustados y además incorpora dos nuevos tipos: Link LSA y Intra-Area
Prefix.
42

OSPFv2 OSPFv3
1 Router LSA 0x2001 Router LSA
2 Network LSA 0x2002 Network LSA
3 Network Summary LSA 0x2003 Inter-Area Prefix LSA
4 ASBR Summary LSA 0x2004 Inter-Area Router LSA
5 AS-External LSA 0x2005 AS-External LSA
6 Group Membership LSA 0x2006 Group Memership LSA
7 NSSA External LSA 0x2007 Type-7 LSA
0x2008 Link LSA
0x2009 Intra-Area Prefix LSA
Tabla 3.3.4.1- Comparación entre los LSA de OSPFv2 y OSPFv3
Además es necesario indicar algunos aspectos importantes diferenciadores que es
necesario tener en cuenta al momento de configurar OSPFv3
• Al habilitar OSPFv3 en una interfaz IPv6 automáticamente se inicia el proceso de
enrutamiento y no es necesario crearlo administrativamente desde el menú de
configuración de un router.
• Los vecinos se comunican mediante la dirección IPv6 enlace-local o Link-Local
del mismo modo que EIGRPv6 como fue demostrado anteriormente.
• Al igual que OSPFv2, OSPFv3 toma su identificador de enrutador (Router-id) de
la dirección IP de la interfaz Loopback más alta en formato IPv4 decimal si es que
existe. Aunque este valor es irrelevante al proceso de enrutamiento en sí es
altamente recomendable configurarlo manualmente.
43

CAPITULO IV
FUNDAMENTOS DE INTERCONEXIÓN DE PROTOCOLOS IGP
4.1 Métricas de RIPng, OSPFv3 y EIGRPv6
En los capítulos anteriores se demostró cómo operan de manera independiente los
protocolos RIPng, OSPFv3 y EIGRPv6, todos ellos sobre el protocolo IPv6. En este
capítulo se aborda el problema de interconexión de redes con distintos protocolos y se
demostrará como solucionar el problema del intercambio de actualizaciones de
enrutamiento en distintos formatos y como efectivamente los routers son capaces de
intercambiar rutas aun cuando éstas provengan de algún protocolo diferente al que en ellos
se ejecuta.
Para poder comprender mejor la problemática de interconexión e intercambio de
actualizaciones de enrutamiento es necesario tener en consideración las métricas y los
métodos de cálculo de mejor ruta de cada protocolo.
Cálculo de métrica y mejor ruta de RIPng
El protocolo RIPng, al igual que sus predecesores para redes IPv4 RIPv1 y RIPv2, utiliza
el conteo de saltos (hops) para determinar cuál es la ruta predilecta en caso de tener
múltiples alternativas hacia un mismo destino.
44

Figura 4.1.1 – Topología de ejemplo con dos caminos y diferente cantidad de saltos
En la figura 4.1.1 el router R1 debe tomar la decisión de obtener la mejor ruta hacia la red
de destino 2001:4:4:4::/64. Como ya se mencionó, este protocolo utiliza la cantidad de
saltos para escoger el mejor camino, por lo tanto se escogerá de manera predeterminada
la ruta por R2 como la preferida ya que solamente tiene 2 saltos de distancia (R2 y R5)
hacia el destino, mientras que por R3 hay 3 saltos (R3, R4 y R5).
Figura 4.1.2 – Topología de ejemplo con dos caminos y la misma cantidad de saltos
En el caso de la topología de la figura 4.1.2 R1 tiene la misma cantidad de saltos tanto por
R2 como por R3 para llegar a 2001:4:4:4::/64. En otras palabras, esa red tiene la misma
métrica (2 hops). Cuando este es el caso, RIPng utilizará un método Round-Robin para
45

alternar el envío de mensajes por ambos enlaces logrando activar el balanceo de carga
para esa red.
RIPng es una alternativa de enrutamiento válida para redes muy pequeñas (menos de 15
routers) y no es escalable en grandes redes. La razón es que por una parte la métrica
máxima de RIP es 15 saltos (más allá se considera infinito o métrica 16) y además es muy
probable que en la elección de la mejor ruta escoja un camino cuyo ancho de banda sea
considerablemente menor a los demás enlaces. Si se vuelve a analizar la figura 4.1.1 y se
considera que el enlace entre R1 y R2 es de 10 Mbps y los enlaces entre R1, R3, R4 y R5
son de 100Mbps cada uno, queda claro que RIP no es la mejor alternativa de enrutamiento.
Cálculo de métrica y mejor ruta de OSPF
OSPF, en sus versiones para IPv4 e IPv6 utiliza una métrica denominada costo para
encontrar la mejor ruta. Este costo se obtiene directamente desde el ancho de banda del
enlace que conecta entre los routers mediante la fórmula 108/BW donde BW es el ancho
de banda del enlace expresado a razón de bits por segundo.
Dada la siguiente topología, asumiendo que la red de destino se encuentra en una LAN de
100Mbps.
46

Figura 4.1.3 – Topología de ejemplo con dos caminos, diferente cantidad de saltos y ancho de banda de cada
enlace
OSPF, a diferencia de RIP, toma como referencia el ancho de banda de las interfaces para
obtener el costo de cada enlace y así calcular la sumatoria de los costos hacia la red de
destino para obtener la mejor ruta.
Para calcular el costo de cada enlace OSPF utiliza la fórmula 108/BW donde BW es el
ancho de banda de una interfaz expresado en bits por segundo. Así, por ejemplo, un enlace
de 10 Mbps tendría un costo de 10.
Enlace Ancho de banda Costo (108/BW)
R1 – R2 10.000 Kbps 10
R2 – R5 10.000 Kbps 10
R1 – R3 100.000 Kbps 1
R3 – R4 100.000 Kbps 1
R4 – R5 100.000 Kbps 1
R5 – LAN 100.000 Kbps 1
Tabla 4.1.1 – Ancho de banda y costo de OSPF entre los enlaces de la topología de la figura 4.1.3
47

De acuerdo a los cálculos hechos por OSF en la figura 4.1.3, R1 determinará que la mejor
ruta para alcanzar la red 2001:4:4:4::/64 es mediante R3 ya que el costo acumulado es de
4, mientras que a través de R2 el valor asciende a 21. El valor del costo en OSPF es
inversamente proporcional al ancho de banda de la interfaz. Mientras mayor ancho de
banda, menor será el costo y por ende se convertirá en la ruta preferida.
Cálculo de métrica y mejor ruta en EIGRP
RIP utiliza saltos, OSPF costo según el ancho de banda de las interfaces y EIGRP utiliza
una fórmula avanzada que incluye 5 elementos dentro del cálculo de la mejor ruta. Cada
uno de estos elementos se conoce como constantes o valores K y son los siguientes:
Valor K Nombre Valor predeterminado
de K
K1 Ancho de Banda (BW) 1
K2 Confiabilidad 0
K3 Retraso o Delay (DLY) 1
K4 Carga 0
K5 MTU 0
Tabla 4.1.2 – Valores predeterminados de las constantes K para el cálculo de métrica EIGRP
K1 es el ancho de banda de la interfaz. K2 es la confiabilidad del enlace y representa un
valor entre 1 y 255, siendo 255 un enlace 100% confiable, es decir, que no ha presentado
fallas en la última medición. K3 es el delay o retraso de la interfaz. Este valor viene
predeterminado según el tipo de interfaz y representa el tiempo que demoran los paquetes
o tramas en cruzar el enlace. K4 representa la carga o uso del enlace, siendo 1 un 0% de
carga y 255 un 100%. K5 corresponde a la MTU de 1500 bytes.
48

Figura 4.1.4 – Fórmula de cálculo de métrica de EIGRP
La figura 4.1.4 muestra la fórmula utilizada por el protocolo EIGRP para calcular la
métrica hacia una red de destino y luego poder determinar la mejor (más baja) de todas
las opciones. En la fórmula bw = 107/ancho de banda mínimo de toda la ruta hacia el
destino expresado en kbps y delay = Sumatoria de todos los delay desde el router que hace
el cálculo hacia la red de destino expresado en µsecs / 10.
Ya que los valores por defecto de las constantes K son 0 para todas excepto K1 y K3, la
fórmula anterior queda resumida como Métrica = (BW + DLY) * 256
Dado el siguiente ejemplo, se puede determinar la métrica de ambas rutas hacia el destino.
Figura 4.1.5 – Topología de ejemplo con dos caminos, diferente cantidad de saltos, ancho de banda de cada
enlace y valores del retraso (DLY) entre interfaces
Paso 1: Calcular la métrica desde R1 hacia 2001:4:4:4::/64 por R3
49

Como se mencionaba, la fórmula de EIGRP para obtener la métrica se reduce a Métrica
= (BW + DLY) * 256
Donde BW (Bandwidth) = 107/ Ancho de banda mínimo en esa ruta hacia el destino. Como
todas las interfaces son de 100 Mbps se toma este valor como referencia expresado en
Kbps. Por lo tanto:
BW = 107/100000
BW = 100
Y DLY (delay) = Σ de todos los delays desde R1 hacia 2001:4:4:4::/64 dividido en 10. Por lo tanto:
DLY = (2000 + 2000 + 2000 + 1000) /10
DLY = 700
Entonces
Métrica = (100 + 700) * 256
Métrica = 204800
Paso 2: Calcular la métrica desde R1 hacia 2001:4:4:4::/64 por R2
El mismo procedimiento aplica para calcular la ruta hacia la misma red pero por R2
BW = 107/10 Mbps
BW = 107/10000 Kbps
BW = 1000
DLY = (5000 + 5000 + 1000) /10
DLY = 1100
Métrica = (1000 + 1100) * 256
Métrica = 537600
Como R1 ha determinado que la ruta a través de R3 tiene una métrica de 204800 y a través
de R2 es de 537600, entonces para llegar a 2001:4:4:4::/64 este router escogerá R3 como
50

camino preferencial. Existen sin embargo otras opciones que están relacionadas con el
cálculo de métrica de EIGRP, como son los estados SIA (Stuck-In-Acive) y otros, pero
estas características escapan al objetivo de este trabajo.
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
51

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)# exit
R1(config-if)# ipv6 address 2002:0:1:B::1/64
R1(config-if)# exit
Configuración de RIPng en R2
52

R2(config)# ipv6 router rip RIPng
R2(config)# exit
R2(config-if)# exit
R2(config-if)# exit
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-if)# ipv6 rip RIPng enable
Configuración de direccionamiento y habilitación de enrutamiento EIGRPv6 en
R3, R4 y BORDER
Configuración de EIGRPv6 en R3

R3(config)# ipv6 Router eigrp 100
R3(config-rtr)# Router-id 3.3.3.3
R3(config-rtr)# exit
R3(config-if)# ipv6 eigrp 100
53

R3(config-if)# exit
R3(config-if)# exit
Configuración de EIGRPv6 en R4

R4(config)# ipv6 Router eigrp 100
R4(config-rtr)# Router-id 4.4.4.4
R4(config-rtr)# exit
R4(config-if)# exit
R4(config-if)# exit
Configuración de EIGRPv6 en BORDER

BORDER(config)# ipv6 Router eigrp 100
BORDER(config-rtr)# Router-id 10.10.10.10
BORDER(config-rtr)# no shutdown
BORDER(config-rtr)# exit
54

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 4.2.1.1 – Tabla de enrutamiento de R1 ejecutando RIPng
55

Figura 4.2.1.2 – Tabla de enrutamiento de R2 ejecutando RIPng
Figura 4.2.1.3 – Tabla de enrutamiento de BORDER donde se observan las entradas aprendidas por EIGRPv6
(D) y RIPng (R)
56

Figura 4.2.1.4. – Tabla de enrutamiento de R3 ejecutando EIGRP
Figura 4.2.1.5 – Tabla de enrutamiento de R4 ejecutando EIGRP
57

En las figuras 4.2.1.1, 4.2.1.2 y 4.2.1.3 se puede identificar claramente las rutas aprendidas
mediante RIPng (marcadas con una R) y en las figuras 4.2.1.3, 4.2.1.4 y 4.2.1.5 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.
58

¿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,
59

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 4.2.1.6 – Tabla de enrutamiento de R1 incluyendo las rutas redistribuidas desde EIGRP
60

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.
61

Figura 4.2.1.7 – 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
4.2.1.7. 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
62

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 1.1.1.1
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-if)# ipv6 ospf 1 area 0
63

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 router ospf 1
R3(config-router)# router-id 3.3.3.3
R3(config-router)# exit
R3(config-if)# ipv6 ospf 1 area 0
R3(config-if)# exit
R3(config)#interface Loopback0
R3(config-if)exit
R3(config-if)# exit
Configuración de OSPFv3 en R4

R4(config)# ipv6 router ospf 1
R4(config-router)# router-id 4.4.4.4
R4(config-router)# exit
R4(config-if)# exit
R4(config-if)# exit
R4(config-if)# exit
Configuración de OSPFv3 en BORDER

BORDER(config)# ipv6 router ospf 1
BORDER(config-router)# router-id 10.10.10.10
BORDER(config-router)# exit
BORDER(config-if)# ipv6 ospf 1 area 0
64

BORDER(config-if)# ipv6 ospf 1 area 0
Una vez configurados los routers se comprueban las rutas IPv6 en ambas redes, tanto
RIPng como OSPFv3.
Figura 4.2.2.1 – Tabla de enrutamiento de R1 con las rutas de RIPng
65

Figura 4.2.2.2 – Tabla de enrutamiento de R2 con las rutas de RIPng
Figura 4.2.2.3 – Tabla de enrutamiento de BORDER mostrando las rutas RIPng (R) y OSPF (O)
66

Figura 4.2.2.4 – Tabla de enrutamiento de R3 mostrando las rutas OSPF
Figura 4.2.2.5 – Tabla de enrutamiento de R4 mostrando las rutas OSPF
67

Como se puede apreciar en las tablas de enrutamiento mostradas en las figuras 4.2.2.1,
4.2.2.2 y 4.2.2.3, 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 4.2.2.3, 4.2.2.4 y 4.2.2.5.
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
68

indica el valor [110/20], siendo 110 el valor de la distancia administrativa predeterminada
de OSPF y 20 es la métrica.
Figura 4.2.2.6 – Tabla de enrutamiento de R1 mostrando todas las redes de la topología
69

Figura 4.2.2.7 – Tabla de enrutamiento de R3 mostrando todas las redes de la topología
En las figuras 4.2.2.6 y 4.2.2.7 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
70

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.
71

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 4.2.3.1 - Tabla de enrutamiento de R1 mostrando las redes aprendidas correctamente de forma interna
(D) y externas (D EX)
Figura 4.2.3.2 - Tabla de enrutamiento de R3 mostrando las redes aprendidas correctamente de forma interna
(O) y externas (OE2)
72

Una vez formadas las adyacencias y traspasadas las rutas corresponde ejecutar pruebas
ping para verificar conectividad de capa 3.
Figura 4.2.3.3 - Ping desde R1 hacia una Loopback de R3 y una Loopback de R4
Figura 4.2.3.4 - Ping desde R3 hacia una Loopback de R1 y una Loopback de R2
Como se demuestra en las figuras 4.2.3.1 y 4.2.3.2, 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 4.2.3.3 y 4.2.3.4 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
73

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.
74

CAPITULO V: CASO DE ESTUDIO DE INTEGRACIÓN DE MÚLTIPLES
PROTOCOLOS DE ENRUTAMIENTO DINAMICO EN IPv6
En este trabajo se han demostrado las diversas formas y consideraciones técnicas de la
instalación y configuración de enrutadores en un entorno de red que utiliza el protocolo
de direccionamiento IPv6 los cuales trabajan y son capaces de operar entre ellos aun
cuando los métodos de enrutamiento sean totalmente distintos e incompatibles
directamente. Al utilizar un router denominado “de borde”, el cual posee al menos una
interfaz de red en un protocolo específico y al menos una segunda en otro protocolo, éste
es capaz de actuar como pasarela entre ambos entornos y utilizando la técnica de
“redistribución de rutas” convirtiendo las actualizaciones de enrutamiento de un lenguaje
a otro. Es este router quien convierte las métricas y encabezados de cada protocolo de
enrutamiento de un lado hacia el otro y viceversa.
Existen, sin embargo, situaciones donde el entorno de aplicación de esta solución es
considerablemente más complejo y donde se requiere tomar medidas extras para poder
finalmente lograr la convergencia deseada de la red de toda una organización que
incorpore múltiples protocolos dinámicos de ruteo basados en IPv6. A continuación se
muestra una situación similar a las descritas anteriormente y donde se hace necesario
planificar estratégicamente la solución diseñada para resolver el problema de
interconexión de nodos pertenecientes a múltiples protocolos de enrutamiento.
5.1 Escenario actual
Este caso de estudio presenta la situación de tres compañías independientes del mismo
rubro, ABC.COM, XYZCorp y NETSoluciones S.A. ABC.COM utiliza el protocolo
75

RIPng dentro de sus redes internas como método de direccionamiento basado en IPv6,
XYZCorp por su parte trabaja con OSPFv3 ya que opera con equipamiento de distintos
fabricantes y necesita tecnología estándar y NETSoluciones utiliza EIGRPv6. Dado el
buen rendimiento económico de ABC.COM, esta compañía ha decidido comprar a las
otras dos como estrategia comercial frente a sus competidores.
Figura 5.1.1 – Topología de red de ABC.COM
Figura 5.1.2 – Topología de red de XYZCorp
76

Figura 5.1.3 – Topología de red de NETSoluciones S.A.
El proceso de fusión de estas empresas a nivel de red requiere una planificación previa
que considere todos los aspectos técnicos y de diseño necesarios para asegurar un
funcionamiento óptimo y sin inconvenientes que pudiesen afectar las operaciones
normales de la compañía. Se requiere, además, formular una estrategia de implementación
que afecte lo menos posible a los usuarios existentes y minimice los tiempos de inactividad
(downtime). Para lograr esto se definen a continuación 4 etapas del proceso, desde la
recopilación de información hasta verificar que finalmente todo haya convergido
correctamente y según lo esperado.
1. Preparación
2. Diseño/Planificación
3. Implementación
4. Verificación
77

5.2 Etapa de Preparación
Antes de siquiera diseñar y pensar la mejor solución que se podrá aplicar a este escenario,
es sin duda un requisito obligatorio recopilar información de las redes y sistemas
existentes a fin de analizar de mejor manera el enfoque estratégico de la implementación
definitiva.
La información más importante que se puede recopilar es un mapa topológico actualizado
que indique la distribución lógica del equipamiento, los servicios y subredes existentes.
Se debe revisar las redes y dispositivos para indicar claramente cual o cuales son los
bloques IPv6 actualmente asignados y en operación. A modo de ejemplo, la siguiente tabla
puede utilizarse para documentar y esta información.
Los comandos show ip interfaces brief, show running-config y show interfaces pueden
ser utilizados para llenar la tabla.
Dispositivo Interfaz Dirección IPv6 global Conecta
con:
ABC1 FastEthernet0/0 2002:2E00:0:1::1/64 Internet
ABC1 FastEthernet0/1 2002:2E00:0:AAAA::1/64 ABC2
ABC1 FastEthernet1/0 2002:2E00:0:BBBB::1/64 ABC3
ABC2 FastEthernet0/0 2002:2E00:0:2::1/64 LAN
ABC2 FastEthernet0/1 2002:2E00:0:AAAA::2/64 ABC1
ABC2 FastEthernet1/0 2002:2E00:0:CCCC::1/64 ABC3
ABC3 FastEthernet0/0 2002:2E00:0:3::1/64 LAN
ABC3 FastEthernet0/1 2002:2E00:0:BBBB::2/64 ABC1
ABC3 FastEthernet1/0 2002:2E00:0:CCCC::2/64 ABC2
Tabla 5.2.1 - Direccionamiento IPv6 en ABC.COM. Bloque 2002:2E00::/32
78

Estos datos se recopilan en cada dispositivo ejecutando los comandos show ipv6
protocolos y show running-config.
Dispositivo Protocolo de ID de Opciones
Enrutamiento Protocolo Especiales
ABC1 RIPng RIPABC Ninguna
Tabla 5.2.2 – Información de enrutamiento de ABC.COM
Dispositivo Interfaz Dirección IPv6 global Conecta
con:
Internet FastEthernet0/0 2001:FF0A:CC00::1/64 Internet
Internet FastEthernet0/1 2001:FF0A:CC00:1::1/64 Servers
Servers FastEthernet0/0 2001:FF0A:CC00:1::2/64 Router
(Internet)
Servers FastEthernet0/1 2001:FF0A:CC00:2::1/64 LAN
Servers FastEthernet1/0 2001:FF0A:CC00:3::1/64 LAN
Tabla 5.2.3 - Direccionamiento IPv6 en XZYCorp. Bloque 2001:FF0A:CC00::/40
Dispositivo Protocolo de ID de Opciones

Enrutamiento Protocolo Especiales
Internet OSPFv3 1 Area 0
Servers OSPFv3 1 Area 0
Tabla 5.2.4 – Información de enrutamiento de XYZCorp
79

Dispositivo Interfaz Dirección IPv6 global Conecta con:
NS1 FastEthernet0/0 2002:AAF3:1C:6::1/64 Internet
NS1 FastEthernet0/1 2002:AAF3:1C:5::1/64 NS2
NS2 FastEthernet0/1 2002:AAF3:1C:1::1/64 LAN
Tabla 5.2.5 - Direccionamiento IPv6 en NETSoluciones S.A.
Dispositivo Protocolo ID de Protocolo (ASN) Opciones Especiales
NS1 EIGRPv6 150 Sumarización automática

desactivada
desactivada
desactivada
Tabla 5.2.6 - Información de enrutamiento de NETSoluciones S.A.
Con la información anterior ya es posible tener un cuadro claro y consistente de las
configuraciones existentes en las tres compañías tanto a nivel IP como en enrutamiento.
El siguiente paso es comenzar la etapa de diseño y planificación que definirá la solución
a implementar para poder funcionar las tres compañías.
80

5.3 Etapa de diseño / planificación
En esta etapa se considera la mejor solución posible dados los elementos recopilados en
la etapa previa. Esta solución debe estar enfocada en tres objetivos primordiales:
• Impacto más bajo posible en las operaciones actuales. Esto es, lograr un bajo
downtime, minimizar lo máximo posible la configuración en los dispositivos de
red (Routers, Switches, Cortafuegos, entre otros) y las estaciones de trabajo de los
usuarios.
• Mantener o mejorar el rendimiento y calidad de la infraestructura existente, es
decir, que la solución no implique una reducción del ancho de banda disponible ni
se produzcan problemas a nivel de red que afecten a las aplicaciones que sobre ella
se ejecutan, tales como bucles (loops) de enrutamiento, envío de información
innecesaria entre los routers y evitar que las tablas de enrutamiento crezcan
demasiado, afectando el tiempo de procesamiento y conmutación de los paquetes.
• Bajo costo de la implementación. Evitar diseñar una topología nueva que involucre
la adquisición de equipamiento extra o que signifique considerar una gran
inversión para poder implementarse.
Basándose en estos principios y en la información recopilada en la etapa de preparación
es posible anticipar al menos dos soluciones posibles:
1. Unificar las redes de XYZCorp y NETSoluciones S.A.dentro de la actual
ABC.COM, siendo esta última quien adquirirá finalmente a las dos primeras. En
esta opción se considera que las tres compañías formen una sola gran red que opere
bajo el protocolo RIPng (utilizado previamente en ABC.COM).
81

2. Lograr unir las tres compañías de tal manera que conserven sus configuraciones y
protocolos actuales de manera independiente y mediante la técnica de
redistribución de rutas, detallada ampliamente en los primeros capítulos de este
trabajo y poder interconectar y traspasar las rutas de cada una de ellas.
Dentro de las ventajas de unificar las tres redes en un único protocolo de enrutamiento
está que al reducir la complejidad de la estructura de red, por consecuencia directa, los
costos de mantenimiento y la necesidad de contar con personal altamente calificado para
la administración de red también se reducen bastante.
Otra ventaja de este modelo es que las métricas y cálculos de enrutamiento en cada router
se mantienen intactos de extremo a extremo, por lo que no supone una carga extra en el
recálculo de las rutas en caso de haber una caída o una falla, agregando un índice de
rapidez de respuesta asociada al protocolo que se esté usando. Este índice, aunque menor,
puede ser un aspecto importante en la decisión final.
Es importante mencionar que dentro de los 3 protocolos acá utilizados, RIPng, OSPFv3 y
EIGRPv6, el menos recomendable sería RIPng ya que sus características técnicas lo hacen
muy poco escalable (no pueden haber más de 15 routers en la red) y el tiempo de falla y
reposición de una ruta es en promedio de 30 segundos. La mejor solución podría ser
EIGRPv6 si lo que se busca es rapidez de convergencia y estabilidad. Sin embargo esto
implicaría que todos los enrutadores de otro fabricante que no sean Cisco deben
reemplazarse por esta marca ya que es un protocolo propietario. Por esta razón la mejor
solución si se busca unificar todo bajo un único protocolo sería implementar OSPFv3 en
las tres compañías, pero hay que verificar muy en detalle si es que los actuales dispositivos
soportan OSPFv3 ya que al ser un protocolo de tipo link-state, ellos mantienen una base
82

de datos topológica muy grande y que requiere recursos extras de memoria, CPU y ancho
de banda para su óptimo procesamiento.
Por otro lado, la idea de mantener las topologías actuales y utilizar la redistribución de
rutas pareciera ser la mejor de ambas soluciones manteniendo como base los tres objetivos
antes mencionados.
Las desventajas de este modelo son que por una parte se deben definir los así llamados
“routers de borde” (border routers) que servirán como traductor de un protocolo a otro y
esto puede suponer un punto de falla. A pesar de eso, esta dificultad es solucionable con
el uso de “etiquetas de ruta” (route tags) y sin la necesidad de incurrir en gastos mayores.
El concepto de etiquetado de rutas se comentará más adelante.
La gran ventaja es que los cambios en la configuración de los routers se reducen al mínimo
posible ya que ni los dispositivos de los usuarios ni los mismos routers que los conectan
directamente deben ser modificados, si no única y exclusivamente aquellos enrutadores
que se definan como “de borde”.
En este trabajo se aplicará la segunda opción utilizando redistribución como solución al
caso de estudio principalmente por las ventajas descritas que supone esta tecnología,
porque es interesante su aplicación desde el punto de vista práctico y además porque
supone una de las técnicas más utilizadas actualmente por las compañías que requieren
dar solución a problemáticas como las descritas en este caso. Aunque la redistribución ha
sido utilizada históricamente bajo IPv4, también es perfectamente aplicable y es
considerada una solución válida en IPv6 porque el problema de la integración de diferentes
protocolos de enrutamiento no se soluciona per se por el solo hecho de implementar IPv6
en una infraestructura, ya que no es una situación inherente al direccionamiento IP en sí,
sino más bien a la subdivisión de una topología en diferentes áreas de enrutamiento y del
83

tipo de enrutadores que sean capaces de ejecutar una instancia de RIPng, OSPFv3 o
EIGRPv6.
La topología de solución será realizada en primera instancia como se indica a
continuación. Los cuadros en rojo representan las redes de cada compañía y sus
respectivos bloques IPv6 existentes mientras que el router ABC1 cumplirá con la función
border router. Los enlaces directos entre los routers ABC1, NS1 e INTERNET pueden
ser instalado sobre una red MPLS, ATM, Frame Relay o similar mediante algún proveedor
que preste servicios de capa 2, lo cual es absolutamente transparente a la solución que
plantea este caso de estudio, haciéndolo escalable a cualquier tecnología como las
mencionadas.
Figura 5.3.1 – Topología de integración de las redes de ABC.COM, XYZCorp y NETSoluciones S.A.
El diagrama de red de la figura 5.3.1 muestra la solución más simple y económica posible,
aunque no por eso menos efectiva. Sin embargo, esta solución presenta una gran debilidad
en su diseño y es que toda la infraestructura se soporta en un único router (ABC1). Si este
84

dispositivo falla, toda las compañías perderán conexión entre sí y la falla no se
solucionaría hasta que el equipo se repare o se reconfigure.
Aunque podría ser considerada una solución viable es necesario hacer un ajuste más a este
diseño para obtener una topología tolerante a fallas. Se deben definir al menos dos
enrutadores de borde que actúen como respaldo uno del otro. El mayor inconveniente
radica en que la configuración se hace indudablemente más compleja y otros factores
deben ser tomados en cuenta para asegurar la operación óptima de las redes conjuntas.
Esos factores, como son los llamados mapas de rutas (route maps), etiquetado de rutas
(route tags) y redistribución bidireccional con múltiples puntos será tratado en detalle más
adelante en este capítulo.
Figura 5.3.2 – Topología definitiva de solución incluyendo dos routers de borde para asegurar redundancia.
Como es posible apreciar en la figura 5.3.2 se ha creado un enlace directo entre XYZcorp
y NETSoluciones, dejando a INTERNET como un segundo router de borde que tendrá la
misión de traducir las rutas desde EIGRPv6 a OSPFv3 directamente.
85

Lo interesante de este diagrama es que es posible obtener redundancia (failover) entre los
routers principales permitiendo que la red completa siga funcionando en caso de una falla
de enlaces y eliminando el punto de falla único que representaba ABC1 en la figura 5.3.1.
A pesar de esta mejora se presenta un problema mayor que debe ser atacado correctamente
y muy bien planificado para evitar los bucles de enrutamiento, ya que si NS1 le informa a
ABC1 de una red LAN que pertenece a NETSoluciones, ABC1 tomará esa información y
la volverá a reenviar al router INTERNET, el cual a su vez volverá a enviarle esa misma
ruta a NS1, y como vendrá con una distancia administrativa menor, es probable que NS1
crea que la ruta más conveniente hacia su misma LAN sea por el router INTERNET y no
a través de NS2 o NS3, lo cual crearía un bucle de enrutamiento. Para solucionar ese
problema será necesario implementar los denominados route tags o etiquetado de rutas.
5.4 Etapa de Implementación
En esta etapa se definen los lineamientos de implementación y las instrucciones de
configuración de los dispositivos de red. A continuación se indican las configuraciones
utilizadas en la topología conjunta que unificará a las tres compañías junto con una
explicación respecto a qué función tienen los comandos utilizados.
Importante es destacar que los routers internos de cada red, es decir ABC2, ABC3,
Servers, NS1, NS2 y NS3 utilizan una configuración de enrutamiento estándar según sea
el protocolo que utilice en esa área de la red, tal como se explicó en la primera parte de
este trabajo donde se detalló esta situación. En la etapa de implementación es necesario
definir exactamente los parámetros y datos necesarios para que, por ejemplo, un técnico
pueda configurar los routers sin mayor complejidad. Para los routers terminales o internos
86

la configuración no varía respecto a los parámetros recopilados en la etapa de preparación
(Sección 5.2). Los cambios más importantes suceden en los routers de borde ABC1 e
INTERNET.
Las siguientes tablas indican las configuraciones y parámetros de red necesarios para
habilitar el direccionamiento correcto y los protocolos de enrutamiento en cada router.
Nota: Las interfaces de cada router que conectan con alguna red LAN donde se ubiquen
usuarios, servidores o cualquier otro dispositivo de acceso, han sido reemplazadas por
interfaces virtuales de bucle local (Loopback) para efectos de simulación, sin embargo,
esto no afecta en ningún grado a los procesos de enrutamiento que son demostrados en
este trabajo.
El proceso de implementación secuencialmente procede como sigue:
a) Es necesario verificar la configuración existente y compararla con la tabla de
implementación del dispositivo que se está revisando. Si la configuración ya existe
entonces se deja intacta y se procede al siguiente ítem hasta completar la tarea.
b) Configurar las direcciones IPv6 nuevas en los routers de borde que conectan con
las demás sucursales.
c) Levantar el proceso de enrutamiento correspondiente previamente diseñado.
Nota: La posterior revisión de los estados de adyacencia y convergencia de la red se
harán en la etapa de verificación.
Tablas de implementación de los routers de ABC.COM
87

Dispositi Interfaz Dirección IPv6 Dirección IPv6 Link- Conect
vo global Local a con:
ABC1 FastEthernet0 2002:2E00:0:AAA FE80::C800:15FF:FE08 ABC2
/0 A::1 :0
ABC1 FastEthernet1 2002:2E00:0:BBBB FE80::C800:15FF:FE08 ABC3
/0 ::1 :1C
ABC2 FastEthernet0 2002:2E00:0:AAA FE80::C203:BFF:FE1C: ABC1
/0 A::2 0
ABC2 FastEthernet0 2002:2E00:0:CCCC FE80::C203:BFF:FE1C: ABC3
/1 ::1 1
ABC2 Loopback0 2002:2E00:0:2::1 FE80::C203:BFF:FE1C: LAN
ABC3 FastEthernet0 2002:2E00:0:BBBB FE80::C204:BFF:FE1C: ABC1
/0 ::2 0
ABC3 FastEthernet0 2002:2E00:0:CCCC FE80::C204:BFF:FE1C: ABC2
/1 ::2 1
ABC3 Loopback0 2002:2E00:0:3::1 FE80::C204:BFF:FE1C: LAN
Tabla 5.4.1 – Tabla de direccionamiento de ABC.COM
88

Tabla 5.4.2 - Tabla de enrutamiento de ABC.COM
Dispositivo Interfaz Dirección IPv6 Dirección IPv6 Link- Conecta

global Local con:
Servers FastEthernet0/0 2001:FF0A:CC00:1::2 FE80::C205:6FF:FEF8:0 INTERNET
Servers Loopback0 2001:FF0A:CC00:2::1 FE80::C205:6FF:FEF8:0 LAN
Servers Loopback1 2001:FF0A:CC00:3::1 FE80::C205:6FF:FEF8:0 LAN
Internet FastEthernet0/0 2001:FF0A:CC00::1 FE80::C202:BFF:FE1C:0 ABC1
Internet FastEthernet1/0 2001:FF0A:CC00:1::1 FE80::C202:BFF:FE1C:10 Servers
Tabla 5.4.3 - Tabla de direccionamiento de XYZCorp
Dispositivo Protocolo ID de Protocolo Opciones Especiales
Servers OSPFv3 1 Area 0
Internet OSPFv3 1 Area 0
ABC1 OSPFv3 1 Area 0
Tabla 5.4.4 - Tabla de enrutamiento de XYZCorp
89

Dispositivo Interfaz Dirección IPv6 Dirección IPv6 Link- Conecta
global Local con:
NS1 FastEthernet0/0 2002:AAF3:1C::1 FE80::C801:11FF:FE48:0 Internet
NS1 FastEthernet1/0 2002:AAF3:1C:6::1 FE80::C801:11FF:FE48:1C NS2
NS1 FastEthernet1/1 2002:AAF3:1C:4::1 FE80::C801:15FF:FE48:1D NS3
NS1 FastEthernet2/0 2002:AAF3:1C:5::1 FE80::C801:15FF:FE48:38 NS2
NS2 FastEthernet0/0 2002:AAF3:1C:5::2 FE80::C206:6FF:FEF8:0 NS1
NS2 Loopback0 2002:AAF3:1C:1::1 FE80::C206:6FF:FEF8:0 LAN
NS3 FastEthernet0/0 2002:AAF3:1C:4::2 FE80::C207:6FF:FEF8:0 NS1
ABC1 FastEthernet2/0 2002:AAF3:1C::2 FE80::C800:15FF:FE08:38 NS1
INTERNET FastEthernet0/1 2002:AAF3:1C:6::2 FE80::C202:BFF:FE1C:1 NS1
Tabla 5.4.5 - Tabla de direccionamiento de NETSoluciones S.A.
NS1 EIGRPv6 150 Ninguna
90

ABC1 EIGRPv6 150 Ninguna
INTERNET EIGRPv6 150 Ninguna
Tabla 5.4.6 - Tabla de enrutamiento de NETSoluciones S.A.
Con la información mostrada en las tablas 5.4.1 a 5.4.6 se configuran los routers con sus
respectivas direcciones IPv6 y el protocolo de enrutamiento correspondiente. El
procedimiento mostrado a continuación aplica a los routers terminales o interiores, que
son todos a excepción de ABC1 e INTERNET. Para estos dos routers se muestra la
configuración más adelante ya que es necesario implementar una serie de parámetros
especiales que no se requieren en los demás, pues la redistribución debe ocurrir de manera
controlada dado los posibles bucles de enrutamiento.
Ya que la configuración es similar en las áreas interiores se muestra a continuación los
detalles de un solo router por cada una tomando los parámetros de las tablas de
direccionamiento y de enrutamiento. Esto es solamente Servers, NS2 y ABC2. Se
destacan las opciones obtenidas desde las tablas de implementación.
1) Configuración de Servers
Servers#show run | section router

ipv6 router ospf 1
router-id 3.3.3.3
Servers#show run | section interface
interface Loopback0
no ip address
ipv6 address 2001:FF0A:CC00:2::1/64
ipv6 ospf 1 area 0
interface Loopback1
no ip address
ipv6 ospf 1 area 0
interface FastEthernet0/0
no ip address
91

duplex auto
speed auto
ipv6 ospf 1 area 0
En este caso se ha declarado globalmente que Servers trabaja bajo OSPFv3 con la
instrucción ipv6 router ospf 1 y con el identificador de router 3.3.3.3 y luego en cada
interfaz que se desea publicar a la red se agrega, aparte del direccionamiento IPv6, la
opción ipv6 ospf 1 area 0.
En comparación, NS2, perteneciente a la empresa NETSoluciones S.A que ejecuta
EIGRPv6 tiene la siguiente configuración:
2) Configuración de NS2
NS2#show run | section router

ipv6 router eigrp 150
router-id 5.5.5.5
no shutdown
NS2#show run | section interface
interface Loopback0
no ip address
ipv6 address 2002:AAF3:1C:1::1/64
ipv6 eigrp 150
no ip address
duplex auto
speed auto
ipv6 address 2002:AAF3:1C:5::2/64
ipv6 eigrp 150
Aquí se ha habilitado EIGRPv6 con el comando ipv6 router eigrp 150 donde 150 es el
número de sistema autónomo que identifica a todos los routers de esa red, se utiliza el
identificador de router 5.5.5.5 y con no shutdown se activa el proceso de enrutamiento.
Muy similar a OSPFv3, en este caso se habilita cada interfaz que contenga un prefijo IPv6
92

que se quiera publicar a los vecinos con el comando ipv6 eigrp 150. La misma
configuración se aplica a los routers NS1 y NS3.
En el caso de ABC1, donde se ejecuta RIPng, la configuración de ABC2 y ABC3 es la
siguiente:
3) Configuración de ABC2
ABC2#show run | section router

ipv6 router rip RIPABC
ABC2#show run | section interface
interface Loopback0
no ip address
ipv6 address 2002:2E00:0:2::1/64
ipv6 rip RIPABC enable
no ip address
duplex auto
speed auto
ipv6 address 2002:2E00:0:AAAA::2/64
no ip address
duplex auto
speed auto
ipv6 address 2002:2E00:0:CCCC::1/64
En este caso simplemente se inicia RIPng con ipv6 router rip RIPABC donde RIPABC
es el identificador de proceso y el comando ipv6 rip RIPABC enable se aplica a todas
las interfaces que deben ser publicadas a los vecinos e intercambiadas como enrutamiento.
Todo lo anteriormente indicado es la configuración estándar para habilitar enrutamiento
en IPv6 dentro de la red corporativa. Sin embargo, el proceso más relevante ocurre en los
routers de borde ABC1 e INTERNET ya que son ambos los que interconectan con los
distintos protocolos y tienen como misión intercambiar rutas mediante el proceso de
redistribución.
93

Configuración de enrutamiento para los routers de borde INTERNET y ABC1.
En comparación a los demás routers, ABC1 e INTERNET tienen una configuración
mucho más compleja ya que son los dispositivos encargados de recibir las rutas desde un
protocolo de enrutamiento y convertirlas en otro para que los demás routers internos
puedan administrar esa información y completar sus tablas de enrutamiento
correctamente.
Para poder comprender los comandos de redistribución aplicados en estos dispositivos es
necesario explicar la problemática de redistribución bidireccional con múltiples puntos ya
que entre las redes de NETSoluciones y XYZCorp pueden suceder bucles de enrutamiento
donde un paquete IP que provenga, por ejemplo, desde la LAN de NS2 y vaya con destino
a la LAN de Servers, termine siendo desviado por INTERNET hacia ABC1 en vez de
Servers, y a su vez ABC1 lo envíe de vuelta a NS1. Este bucle de enrutamiento (routing
loop) es negativo y provoca que los paquetes no lleguen a destino afectando finalmente la
operación de la red y la continuidad del negocio.
Problemática de redistribución bidireccional con múltiples routers.
El concepto de redistribución es la base de la integración de múltiples protocolos de
enrutamiento dentro de una compañía o, como es el caso de este trabajo, cuando ocurre la
fusión de múltiples compañías con distintos sistemas ya preestablecidos.
El método más simple de redistribución ocurre cuando un router de borde envía las redes
de un protocolo hacia el otro pero no hace este mismo procedimiento de vuelta. Por
ejemplo, desde RIP hacia OSPF pero no en el sentido inverso. Este caso de redistribución
es sin duda el más simple pero también el menos común ya que habitualmente este proceso
94

sucede de manera bidireccional, es decir, cuando el mismo router de borde envía las redes
de un lado hacia otro y viceversa.
Figura 5.4.1 - Redistribución bidireccional con un único router.
En el caso de la redistribución bidireccional con único router existe un único equipo que
utiliza la función de router de borde y la redistribución se hace de manera simple en ambas
direcciones. En la figura 5.4.1, este router tomará las rutas aprendidas mediante OSPF y
las enviará a los routers del área EIGRP para que los dispositivos de la LAN1 puedan
acceder a la LAN2. El proceso inverso ocurre también en este router intermedio que
tomará las rutas EIGRP y las enviará a los routers OSPF. Esta bidireccionalidad permite
que los paquetes IP vayan y vuelvan como es requerido que lo hagan en cualquier red.
95

Figura 5.4.2 - Redistribución bidireccional con múltiples routers.
En la figura 5.4.2 se muestra una variante conocida como redistribución bidireccional con
múltiples routers que es exactamente la situación que en el caso de estudio sucede entre
las redes de XZYCorp y NETSoluciones. En este caso surge un problema adicional con
la redistribución que puede llegar a causar bucles de enrutamiento.
El router OSPF interno que conecta con la LAN2 envía mediante este protocolo la
información que permitirá a B2 y a B1 acceder a la LAN. Debido a la activación de la
redistribución en ambos routers. Tanto B1 como B2 enviarán su actualización a sus
vecinos. Es decir B1 enviará mediante EIGRP un mensaje a B2 que le diga que él es una
forma válida de llegar a la LAN2 y B2 hará lo mismo de vuelta y le enviará un mensaje a
B1 para indicarle que él también es válido para alcanzar esta red.
96

Figura 5.4.3 – Envío de actualizaciones de enrutamiento con redistribución bidireccional con múltiples puntos
Si se observa a B1 en la figura 5.4.3 (lo cual es igualmente aplicable a B2) se observa que
este router es informado acerca de la LAN2 por el mismo router LAN y simultáneamente
por B2. Existe el riesgo que B1 tome la información que le envía B2 y la vuelva a
redistribuir de vuelta hacia el mundo OSPF. Esto generaría un bucle de enrutamiento que
degradaría en un 100% la calidad operativa de la red. Es necesario observar que este
fenómeno sucede de la misma manera en el caso de B2 cuando el router LAN y B1 le
informan sobre la misma LAN2. Lo anterior considerando solamente las rutas que son
redistribuidas unidireccionalmente desde OSPF hacia EIGRP pero aún falta considerar lo
que ocurre de forma inversa cuando los routers de borde redistribuyen rutas desde EIGRP
hacia OSPF (también ocurre entre estos dos protocolos y otros como RIP, RIPng, BGP,
IS-IS y otros).
La solución a este problema consiste en implementar un mecanismo de filtrado que evite
que los routers de borde tomen las rutas aprendidas en un sistema y las vuelvan a reenviar
97

de vuelta al mismo de origen. La forma de lograr esta solución son los denominados
“mapas de rutas” o route maps.
El funcionamiento de los route maps consiste en una serie de argumentos que permite
realizar una selección de rutas mediante una ACL (Access Control List o Lista de Control
de Acceso) y luego aplicar una forma de distinguirlas cuando son enviadas en una
actualización de enrutamiento. Para ello se utiliza una etiqueta o tag con el cual se le
asigna un número a una determinada ruta seleccionada con la ACL y luego se bloquea al
momento de redistribuir.
Un ejemplo de sintaxis de un mapa de ruta estándar es el siguiente:
Router(config)# route-map NOMBRE permit 10

Router(config-route-map)# match ip address 10
Router(config-route-map)# set tag 1
Router(config-route-map)# exit
Router(config)# route-map NOMBRE permit 20
Router(config-route-map)# set tag 2
Router(config-route-map)# exit
Router(config)# access-list 10 permit 192.168.0.0 0.0.0.255
En esta secuencia de comandos se está creando un mapa de ruta llamado NOMBRE el
cual está permitiendo el tráfico que coincida (match) con la lista de acceso que lleve el
número 10, la cual selecciona la red 192.168.0.0/24 (donde 0.0.0.255 es la máscara
wildcard y no la máscara de subred) y le asigna un tag de 1. Así los routers cada vez que
envíen esta red a un vecino lo harán indicando que tiene la etiqueta 1. La idea de aplicar
un tag es tan simple como asignarle un “color” a esa ruta de tal manera que los dispositivos
puedan tomar decisiones con esa red en particular.
Luego el mismo mapa de ruta con el número de secuencia 20 le asigna una etiqueta 2 a
cualquier ruta, ya que no hay una ACL específica que seleccione una subred en particular
y al no tener ACL se asume todo el tráfico. Básicamente se trata de una estructura simple
98

de IF/Then donde la palabra clave match funciona como IF y el set opera como Then. Así,
este mapa de ruta se lee como “si se recibe una actualización de enrutamiento que contenga
la red 192.168.0.0/24 entonces se le asigna una etiqueta con valor 1, y cualquier otra ruta
se le asigna una etiqueta 2”.
Este sencillo mapa de ruta permite ser incorporado en el proceso de redistribución y filtrar
mediante esta selección aquellas rutas que NO deben ser reenviadas de vuelta.
El mapa de ruta NOMBRE se aplicaría en un router de borde con la instrucción
redistribute PROTOCOLO route-map NOMBRE. A diferencia del comando normal
redistribute PROTOCOLO, al agregarle el mapa de ruta se está condicionando aquellas
rutas que serán incluidas en este proceso.
Figura 5.4.4 – Actualizaciones de enrutamiento bloqueadas mediante un mapa de ruta.
En el caso de estudio es necesario aplicar esta técnica de filtrado entre los routers de borde
ABC1 e INTERNET que interconectan las redes de XYZCorp y NETSoluciones S.A., ya
99

que en este caso se cumple la condición de redistribución bidireccional con múltiples
puntos.
Para el caso de la redistribución desde XYZCorp y NETSoluciones hacia y desde
ABC.COM no es necesario implementar el sistema de etiquetado y filtrado de rutas pues
al existir solamente un router de borde (ABC1) no existen riesgos de bucles de
enrutamiento.
La siguiente es la configuración de los routers de borde ABC1 e INTERNET incluyendo
las listas de acceso para redes IPv6, los mapas de ruta y la redistribución bidireccional
condicionada.
Configuración de enrutamiento de ABC1
ABC1(config)# ipv6 router eigrp 150

ABC1(config-rtr)# eigrp router-id 3.3.3.3
ABC1(config-rtr)# no shutdown
ABC1(config-rtr)# redistribute connected
ABC1(config-rtr)# redistribute rip RIPABC metric 100000 20 255 1 155 include-
connected
ABC1(config-rtr)# redistribute ospf 1 metric 100000 20 255 1 150 route-map XYZCORP-
A-NETS include-connected
ABC1(config-rtr)# ipv6 router ospf 1
ABC1(config-rtr)# router-id 1.1.1.1
ABC1(config-rtr)# redistribute rip RIPABC metric 2 include-connected
ABC1(config-rtr)#redistribute eigrp 150 route-map NETS-A-XYZCORP include-
connected
ABC1(config-rtr)# ipv6 router rip RIPABC
ABC1(config-rtr)# redistribute ospf 1 metric 2 include-connected
ABC1(config-rtr)# redistribute eigrp 150 metric 2 include-connected
Configuración de los mapas de ruta de ABC1
ABC1#
route-map XYZCORP-A-NETS deny 5
match tag 20
route-map XYZCORP-A-NETS permit 10
match ipv6 address REDES_XYZCORP
set tag 10
100

route-map NETS-A-XYZCORP deny 5
match tag 10
route-map NETS-A-XYZCORP permit 10
match ipv6 address REDES_NETSOLUCIONES
set tag 20
ABC1#
Configuración de las listas de acceso para seleccionar tráfico en ABC1
ABC1#show run | section access-list

ipv6 access-list REDES_XYZCORP
permit ipv6 2001:FF0A:CC00::/40 any
ipv6 access-list REDES_NETSOLUCIONES
permit ipv6 2002:AAF3:1C::/48 any
ABC1#
redistribute rip RIPABC metric 10000 20 255 1 1500 include-connected
redistribute ospf 1 metric 100000 20 255 1 150 route-map XYZCORP-A-NETS
include-connected
Con esto se está indicando que dentro del proceso EIGRP 150 del router ABC1 se
redistribuirán las redes aprendidas por RIP (RIPABC) y también las del proceso OSPF 1.
La instrucción “metric 10000 20 255 1 1500” incluye los valores que se deben asignar a
la métrica de EIGRP cada vez que se redistribuye en este protocolo, donde 10000 es el
ancho de banda en Kbps, 20 es el retraso en microsegundos, 255 es la confiabilidad (donde
255 es 100%), 1 es la carga, donde 255 es un 100% y 1500 es la MTU estándar. Estos
valores son requeridos. Lo importante está en la instrucción “route-map XYZCORP-A-
NETS”.
Aquí se está condicionando la redistribución de rutas dentro de EIGRP (las que irán a los
routers de NETSoluciones S.A.) para que cumplan con el mapa de ruteo llamado
XYZCORP-A-NETS. Es importante notar que el proceso bidireccional ocurre en la
siguiente línea:
101

ipv6 router ospf 1
redistribute rip RIPABC
redistribute eigrp 150 route-map NETS-A-XYZCORP include-connected
Esto indica que este router enviará a los demás routers OSPF, es decir, los de XYZCorp,
todas las rutas que se aprendan por RIP con el proceso RIPABC y además los que se
aprendan desde el protocolo EIGRP con sistema autónomo 150. Este envío de rutas estará
condicionado por el mapa de ruta llamado NETS-A-XYZCORP.

match tag 20
set tag 10

match tag 10
set tag 20
ABC1#
En primer lugar se está negando la redistribución (deny) a todas las redes que coincidan
con el tag 20. Estas son aquellas que están siendo seleccionadas en el siguiente mapa de
ruta NETS-A-XYZCORP y que coincidan con la lista de acceso ipv6 llamada
REDES_NETSOLUCIONES.

102

Las ACL del router ABC1 están seleccionando el bloque IPv6 completo de la empresa
NETSoluciones S.A y asociándolo al nombre REDES_NETSOLUCIONES y además el
bloque completo de la empresa XYZCorp y asociándolo al nombre REDES_XYZCORP
En estos mapas de ruta se están asignando las etiquetas 20 a todas las redes de
NETSoluciones S.A y 10 a todas las de XYZCorp. La primera línea de estos mapas de
ruta las está bloqueando las rutas para que no sean redistribuidas en el proceso de
enrutamiento del cual provienen las redes seleccionadas.
Exactamente la misma configuración se aplica al router INTERNET-
INTERNET# sh run | s router

router-id 2.2.2.2
no shutdown
redistribute ospf 1 metric 100000 20 255 1 150 route-map XYZCORP-A-NETS include-
connected
ipv6 router ospf 1
router-id 2.2.2.2
redistribute eigrp 150 route-map NETS-A-XYZCORP include-connected
INTERNET#
INTERNET#show run | section route-map

match tag 20
set tag 10
match tag 10
set tag 20
INTERNET#show run | section access-list

103

INTERNET#
Nota: En IPv4, si se redistribuye un protocolo por defecto también se redistribuyen las
subredes conectadas directamente en las interfaces en las cuales está ejecutándose ese
protocolo. En IPv6 este no es el comportamiento predeterminado. Para redistribuir las
subredes de las interfaces directamente conectadas en las que corre IPv6 se debe usar la
palabra clave include-connected.
Si se observa bien en la configuración se ha agregado el comando redistribute connected
dentro del proceso EIGRP, el cual tiene el mismo efecto que include-connected. Con esto
se completa la fase de implementación de la solución.
5.5 Etapa de verificación
En esta etapa se deben revisar las distintas configuraciones, estados de adyacencias,
traspaso de rutas y posibles errores que puedan haber ocurrido en la fase de
implementación a fin de determinar que lo realizado en la etapa de implementación se
haya completado de manera correcta y efectivamente los routers hayan sido capaces de
intercambiar las rutas de todas las empresas para tener finalmente conectividad de extremo
a extremo entre las LANs.
En primer lugar se debe verificar que los enrutadores de cada zona hayan establecido
correctamente las adyacencias entre vecinos. Esto es, que tanto en NETSoluciones como
en XYZCorp los routers hayan podido configurar correctamente sus procesos de
enrutamiento y hayan establecido un vínculo con el vecino correspondiente.
104

Para las redes corriendo en OSPFv3 se debe ejecutar el comando show ipv6 ospf
neighbor el cual muestra el estado de la adyacencia con cada vecino, mientras que en los
routers EIGRP debe ejecutarse show ipv6 eigrp neighbor. Para la red de ABC.COM no
es posible verificar el estado de las adyacencias con vecinos ya que RIPng no posee un
mecanismo que controle este tipo de sesión.
Estados de adyacencia entre vecinos de XYZCorp
Figura 5.5.1 – Verificación de adyacencias OSPF de ABC1
Figura 5.5.2 – Verificación de adyacencias OSPF de INTERNET
Figura 5.5.3 – Verificación de adyacencias OSPF de Servers
El comando show ipv6 ospf neighbor muestra información que permite establecer que se
ha establecido correctamente una adyacencia con el respectivo vecino.
La columna Neighbor ID muestra el Identificador de Router (Router ID) del vecino con
el cual está establecida correctamente la adyacencia. En el caso del router ABC1, hay una
adyacencia formada contra el router identificado como 2.2.2.2 a través de la interfaz local
105

FastEthernet1/1 lo cual se indica con el estado “FULL” indicando que la formación de la
adyacencia se ha completado. Si se revisan los comandos de configuración establecidos
en la etapa de implementación, es posible ver que el Router-ID 2.2.2.2 corresponde al
router INTERNET mientras que ABC1 es identificado como 1.1.1.1 y Servers se conoce
como 3.3.3.3 dentro de la topología OSPFv3.
Estados de adyacencia entre vecinos de NETSoluciones S.A.
A continuación se muestran las tablas de vecinos entre los routers de la topología de
NETSoluciones S.A. operando bajo EIGRPv6.
Figura 5.5.4 – Verificación de adyacencias EIGRP en ABC1
Figura 5.5.5 – Verificación de adyacencias EIGRP en INTERNET
Figura 5.5.6 – Verificación de adyacencias EIGRP en NS1
106

En el caso de NS1, NS2 y NS3, la información arrojada por la tabla de vecinos es
levemente distinta ya que en el campo Address no muestra los identificadores de router
como lo hacían en OSPF si no que muestra la dirección de enlace local del vecino con el
cual se está estableciendo la conexión en EIGRP.
Conviene explicar que uno de los aspectos técnicos que varía entre IPv4 e IPv6 está en la
existencia de direcciones de enlace local que permiten establecer automáticamente una
conexión de tipo IP entre nodos vecinos de una red (por ejemplo aquellos conectados a un
Switch en una LAN) sin necesidad de configurar el direccionamiento en forma manual ni
tener que utilizar un servidor DHCP. Un mecanismo similar existe en IPv4 denominado
A.P.I.P.A (Automatic Private Internet Protocol Addressing o Direccionamiento IP
privado automático) que de manera dinámica y sin intervención permite a los hosts auto
asignarse direcciones IP en el bloque 169.254.0.0/16 si es que estos están configurados en
modo cliente DHCP y no existe ningún servidor de este tipo que entregue el
direccionamiento solicitado.
107

El método utilizado en IPv6 en reemplazo de APIPA es llamado Link-Local Addressing o
Direccionamiento de Enlace Loca y consiste en que los hosts de una red IPv6 tendrán
asignadas automáticamente sus direcciones locales en el bloque FE80::/10. Esto es,
cualquier dirección entre el rango FE80:: hasta FEBF:: (sección 2.5.6 del RFC 4291).
Las direcciones locales de la topología del caso de estudio están especificadas en las tablas
de la sección 5.3. Además de las direcciones de enlace local, cada nodo deberá tener
configurada una dirección IPv6 global. En el caso de estudio estas IP están compuestas en
los bloques 2002:2E00::/32, 2001:FF0A:CC00::/40 y 2002:AAF3:001C::/48
pertenecientes a ABC.COM, XYZCorp y NETSoluciones S.A. respectivamente.
EIGRPv6 establece sus vínculos de vecinos exclusivamente en las direcciones IPv6 de
tipo Link-Local y no en sus direcciones globales. Es por esta razón que en las capturas de
pantalla del comando show ipv6 eigrp neighbor se muestra que la adyacencia se forma
con una dirección de tipo FE80:: que representa al vecino.
Es así que ABC1 tiene un enlace con la dirección FE80::C801:11FF:FE48:0 que según la
tabla 5.4.1 corresponde a la interfaz FastEthernet0/0 del router NS1 y que como se indica
en la figura 5.5.6 este a su vez ha establecido correctamente las adyacencias con los
vecinos ABC1, INTERNET, NS2 y NS3 identificados cada uno por su dirección de enlace
local.
Por otro lado, RIPng carece de un método de formación de relaciones entre vecinos como
prerrequisito para intercambiar rutas, por lo que solamente es posible detectar que
funciona correctamente revisando las tablas de enrutamiento y verificando que tanto
ABC2 como ABC3 hayan recibido la información de las redes remotas desde ABC1, es
decir, que las redes contenidas en los bloques 2001:FF0A:CC00::/40 y
108

2002:AAF3:001C::/48 aparezcan en la salida del comando show ipv6 route de cada
router.
Verificación de las tablas de enrutamiento
Ya que se ha demostrado que las adyacencias han sido establecidas correctamente entre
los distintos routers vecinos de cada área, es necesario entonces verificar que finalmente
las tres compañías hayan podido fusionar de manera correcta la información de
enrutamiento y sean capaces de redirigir paquetes IP entre ellas sin inconvenientes.
Finalmente, mediante el envío de paquetes ping se comprobará que los hosts de cada LAN
de una compañía puedan alcanzar sin problemas las demás redes ubicadas en las otras dos
compañías.
109

Verificación de las tablas de enrutamiento de ABC.COM
Figura 5.5.9 – Tabla de enrutamiento de ABC1 mostrando rutas OSPF (O), RIP (R) y EIGRP (D).
110

Figura 5.5.10 – Tabla de enrutamiento de ABC2 mostrando rutas externas aprendidas mediante RIPng
111

Figura 5.5.11 – Tabla de enrutamiento de ABC3 mostrando rutas externas aprendidas mediante RIPng
En las tres tablas de las figuras 5.5.9, 5.5.10 y 5.5.11 se muestran las rutas completas de
la topología que han sido correctamente aprendidas por los routers de la compañía
ABC.COM. La “R” al comienzo de cada línea indica que esa ruta se aprendió vía RIP,
mientras que aquellas con L (Local) y C (Conectadas) son las que cada router tiene
directamente conectada en sus interfaces.
112

Se observa como los routers de la compañía ABC.COM han aprendido los prefijos
2001:FF0A:CC00::/48 y sus respectivos bloques IPv6, correspondiente a las redes de
XYZCorp y 2002:AAF3:1C::/48 que pertenece a NETSoluciones S.A.
Además se observa también que el router de borde ABC1 ha aprendido todas las redes
directamente en cada protocolo y ha redistribuido correctamente hacia ABC2 y ABC3.
Con esto, los eventuales nodos ubicados en las redes LAN de la compañía podrán alcanzar
con éxito las redes remotas de las otras dos compañías. Sin embargo la conectividad aún
no está asegurada de manera bidireccional pues falta que los routers en las redes de
XYZCorp y NETSoluciones S.A. aprendan los prefijos de ABC.COM.
113

Tablas de enrutamiento de XYZCOrp
Figura 5.5.12 – Tabla de enrutamiento de INTERNET mostrando rutas externas aprendidas mediante OSPF
(OE2)
114

Figura 5.5.13 – Tabla de enrutamiento de Servers mostrando rutas externas aprendidas mediante RIPng
En el caso de los routers INTERNET y Servers, pero más específicamente este último, es
posible apreciar de mejor manera las redes que han sido aprendidas por el protocolo OSPF
directamente dentro de la compañía XYZCorp y distinguirlas de aquellas que provienen
de manera externa desde ABC.COM y NETSoluciones S.A.
115

El router Servers aprende el prefijo 2001:FF0A:CC00::/64 mediante OSPF (verificable
con la letra “O” al principio de la tabla de enrutamiento) desde su vecino
FE80::C202:16FF:FEB8:10 que es la dirección de enlace local IPv6 de INTERNET.
El prefijo 2002:2E00::/32 es aprendido por el router ABC1 y redistribuido dentro de
OSPF. Esto se demuestra con el identificador “OE2” que significa ruta OSPF externa de
tipo 2. Las redes de tipo 2 son aquellas que no modifican su métrica, por defecto en 20, a
medida que se envían por la red local.
Servers también ha aprendido correctamente las redes de NETSoluciones S.A.
correspondientes al prefijo 2002:AAF3:1C::/48. Nótese además el valor “tag 20” en estos
bloques que indican que el etiquetado de rutas implementado para reducir los bucles de
enrutamiento en la redistribución bidireccional con múltiples puntos ha sido aplicado con
éxito.
116

Tablas de enrutamiento de NETSoluciones S.A.
Figura 5.5.14 – Tabla de enrutamiento de NS1 mostrando rutas externas aprendidas mediante EIGRP (EX)
117

118

Los routers de NETSoluciones S.A. que trabajan bajo EIGRPv6 también son capaces de
distinguir entre aquellas rutas aprendidas de manera interna por este protocolo y las que
han sido redistribuidas desde un protocolo externo dentro de EIGRP. Las rutas internas
son marcadas con una “D” que significa DUAL (Diffusing Update Algorithm) que es el
119

algoritmo principal que utiliza EIGRP para calcular las mejores rutas y las rutas externas
son marcadas como “EX” o DUAL Externo. Otra forma de diferenciarlas es que EIGRP
asigna una distancia administrativa de 90 para las redes internas y 170 para las externas.
Destacable además es que los routers NS1, NS2 y NS3 reciben de manera externa las
redes de ABC.COM y XYZCorp pero solamente estas últimas son efectivamente
marcadas con el tag 10 según se especificó en el mapa de ruta XYZCORP-A-NETS con
lo cual se pone en funcionamiento el mecanismo de prevención de bucles entre ambas
redes.
5.6 Verificación de conectividad de capa 3
La prueba final para determinar conectividad entre los nodos de todas las redes y
comprobar que la fusión a nivel de red de todas las compañías ha ocurrido correctamente
según el diseño implementado y sin problemas de enrutamiento es enviar un paquete
ICMP (ping) de prueba entre las LANs remotas.
Dado que en la simulación del caso de estudio se han utilizado interfaces locales de tipo
Loopback para representar las redes LAN es necesario utilizar la aplicación llamada “ping
extendido”.
Figura 5.6.1 – Envío de paquete PING desde un router hacia un nodo
120

En el envío de un paquete Ping desde un router, éste siempre escogerá la dirección IP de
la interfaz más cercana en dirección al destino. En la figura 5.6.1 se describe el envío de
un paquete ping desde el router a un servidor con IP 199.10.28.127. El enrutador escoge
entonces la dirección IP de su interfaz FastEthernet0/0 como origen del mensaje en el
paquete de solicitud de eco (Echo Request) de tal manera que el servidor invertirá estos
campos para responder a la solicitud con un Echo Reply.
En este caso solamente se está comprobando que las rutas entre el router y el servidor
están operando adecuadamente, pero no se está validando que el servidor efectivamente
llegue a la interfaz Loopback que representa a la LAN de la topología.
Para lograr esto es necesario habilitar la función extendida que permite al router
seleccionar desde todas sus interfaces activas la dirección IP de origen que tendrá el
paquete Ping, de tal manera que el servidor responda hacia la Loopback y no hacia la IP
de la interfaz FastEthernet. Si los routers intermedios tienen correctamente la información
necesaria para alcanzar la red 10.0.0.0 entonces el paquete Ping tendrá éxito. La función
extendida del comando PING se habilita de la siguiente manera:
#ping RED_DE_DESTINO source INTERFAZ_DE_DESTINO
Este ejemplo ha sido mostrado con direcciones de tipo IPv4 aunque es exactamente igual
de aplicable a IPv6.
121

Figura 5.6.2 – Envío de paquete PING desde un router hacia un nodo utilizando las opciones extendidas
En la figura 5.6.2 se muestra un paquete ping similar al del a figura 5.6.1 pero la dirección
de origen ha sido modificada por la de la interfaz Loopback0 de tal manera que el nodo
de destino responderá el ping hacia esta IP y se podrá verificar que las rutas intermedias
funcionan adecuadamente.
En esta fase del plan de verificación de conectividad se comprueba conexión entre las
LAN de ABC1 hacia XYZCORP, luego desde ABC1 hacia NETSoluciones S.A. y
finalmente entre XYZCorp y NETSoluciones S.A. Ya que la herramienta Ping consiste en
el envío de mensajes round-trip (ida y vuelta) desde un nodo a otro, no es necesario
verificar en ambos sentidos la conexión ya que si la respuesta es exitosa entonces se habrá
probado inmediatamente las rutas de ida y de vuelta en esa dirección.
Pruebas de ping desde ABC1 hacia XYZCorp.
Por defecto se envían 5 mensajes echo request y por cada paquete exitoso que vuelve
(echo reply) se muestra un símbolo de exclamación (!), por lo que la verificación de que
122

las rutas han sido correctamente redistribuidas son 5 símbolos de exclamación sucesivos
(!!!!!).
Figura 5.6.7 – Pruebas de ping desde ABC2 hacia las interfaces de Servers
Figura 5.6.8 – Pruebas de ping desde ABC3 hacia las interfaces de Servers
123

Pruebas de ping desde ABC1 hacia XYZCorp
Figura 5.6.9 – Pruebas de ping desde ABC2 hacia las interfaces de NS1
124

125

126

Pruebas de Ping desde XYZCorp hacia NETSoluciones S.A.
Figura 5.6.15 – Pruebas de ping desde la interfaz Loopback 0 de Servers hacia NS1
127

128

129

Como se puede apreciar en las figuras 5.6.7 a 5.6.19 se ha podido establecer conectividad
entre todas las redes de la topología del caso de estudio confirmando que los
procedimientos utilizados para integrar los diferentes protocolos de enrutamiento
dinámicos internos (IGP – Internal Gateway Protocols) han sido correctos y los
mecanismos de prevención de bucles de enrutamiento han funcionado adecuadamente
para evitar rutas defectuosas que afecten la operación de las aplicaciones que corran sobre
la red que fusiona las tres compañías aquí incluidas. Obsérvese que los comandos ping
han sido ejecutados especificando la dirección de origen (source Loopback).
Tanto las capturas de pantalla de las tablas de enrutamiento como los mensajes ping
demuestran que se ha logrado establecer conectividad de capa 3 en toda la topología del
caso de estudio, lo cual a su vez es un indicador de que los procedimientos realizados para
implementar la redistribución de rutas e integración de múltiples protocolos IGP han
concluido correctamente. Los usuarios no tendrán inconvenientes a nivel de red que les
130

perjudique en sus labores diarias y de existir alguno éste se situaría en las capas superiores
de red cayendo por lo general en la capa de aplicaciones.
A pesar de los distintos tipos de métrica y propiedades de cada zona de enrutamiento los
routers de borde ABC1 e INTERNET han logrado traspasar la información y
actualizaciones necesarias a los routers vecinos que la necesitaban. Esto queda
demostrado en las figuras 5.5.9 a 5.5.16 donde se indica claramente que las rutas fueron
exitosamente aprendidas aun cuando éstas provenían de sistemas externos incompatibles
entre sí.
131

CONCLUSIONES Y RESULTADOS
En este trabajo se ha demostrado como resolver la problemática de inclusión de múltiples
protocolos de enrutamiento dinámicos internos (IGP) en una red, cuáles son los aspectos
técnicos y las consideraciones de diseño necesarias a tener en cuenta para realizar este tipo
de implementaciones en una compañía de mediano a gran tamaño.
El problema principal a resolver fue cómo los routers efectivamente eran capaces de
convertir la métrica de un protocolo determinado a otro para asegurar compatibilidad y
también diseñar una solución que ofrezca ventajas como escalabilidad, seguridad y otros
parámetros a la red que se está modificando. Estos aspectos se lograron al instalar, en el
caso de estudio, dos routers de borde en vez de uno. Sin embargo, surgió la problemática
de los bucles de enrutamiento.
La solución a los bucles de enrutamiento se dio con los mapas de rutas (route maps) y
etiquetas de ruta (route tags) que permiten filtrar aquellas rutas aprendidas en un sistema
y evitando que vuelvan a ser reenviadas de vuelta al mismo.
Por otro lado se hizo énfasis en estructurar una solución al caso de estudio que vaya acorde
al perfil de ingeniería que se requiere para resolver estos problemas, lo cual llevó a generar
una serie de etapas previas a la implementación (configuración) en sí. Estas etapas de
preparación y diseño fueron claves para dar con la solución más óptima posible y evitar
incurrir en modificaciones posteriores. La etapa de verificación ha determinado que la
topología finalmente convergió y los routers de borde han podido traspasar exitosamente
las rutas entre las redes de las compañías ABC.COM, XYZCorp y NETSoluciones S.A.
Lo anterior es prueba de que las organizaciones actuales de mediano y gran tamaño pueden
perfectamente basar su direccionamiento en IPv6 en reemplazo de IPv4 porque es
132

perfectamente posible intercambiar rutas entre ellas y asegurar de que las aplicaciones que
requieren estabilidad en la capa 3 del modelo OSI van a operar satisfactoriamente. Además
pueden aprovechar las ventajas de IPv6 comentadas en el capítulo II.
133

BIBILIOGRAFIA
Para la realización de este trabajo se obtuvo información de las siguientes fuentes:
1. Internet Engineering Task Force, IETF (1981). RFC 791 - Internet Protocol.
Darpa Internet Protocol Specification
http://www.ietf.org/rfc/rfc791.txt
2. Internet Engineering Task Force, IETF (1998). RFC 2474 - Definition of the
Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers
3. Internet Engineering Task Force, IETF (2001). RFC 3168 - The Addition of
Explicit Congestion Notification (ECN) to IP
4. Internet Engineering Task Force, IETF (1981). RFC 790 – Assigned Numbers
5. Internet Engineering Task Force, IETF (1995) RFC 1819 - Internet Stream
Protocol Version 2 (ST2) - Protocol Specification - Version ST2+
6. Internet Engineering Task Force, IETF (1998) RFC 2328 – OSPF version 2
7. Internet Engineering Task Force, IETF (2008) RFC 5340 – OSPF for IPv6
8. Internet Engineering Task Force, IETF (2006) RFC 4291 – IP Version 6

Addressing Architecture
9. Internet Engineering Task Force, IETF (1997) RFC 2080 – RIPng for IPv6
10. Cisco Systems (n.d.). Cisco IOS IPv6 Command Reference - MPLS traffic
engineering auto bandwidth through route-map.
http://www.cisco.com/en/US/docs/ios/ipv6/command/reference/ipv6_10.html
11. Cisco Systems (n.d.). IP Routing - Redistributing Routing Protocols

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080094
87e.shtml
134

12. Cisco Systems (n.d.). IP Routing – Introduction to EIGRP
http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f
07.shtml
13. Cisco Systems (n.d.). Implementing EIGRP for IPv6

http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-
eigrp_external_docbase_0900e4b1805a3c5e_4container_external_docbase_0900
e4b181b83f78.html
14. Jeremy Stretch (2008). PacketLife – Implementation of IPv6 and OSPFv3

http://packetlife.net/blog/2008/sep/1/ipv6-and-ospfv3/

135

GLOSARIO TÉCNICO
ABR: En inglés, Area Border Router o Enrutador de borde de área. Corresponde a un
Router que opera con el protocolo OSPF y que tiene al menos una interfaz en un área y
otra en un área distinta, actuando como intermediario entre distintas áreas.
Actualización (Update): Tipo de mensaje que se intercambian dos Routers en los cuales
se ejecuta un protocolo de enrutamiento común. Normalmente se intercambian distintos
tipos de mensajes y son las actualizaciones las que contienen las rutas y redes o subredes.
Acuse de Recibo (Acknowlegment): Es un tipo especial de mensaje que intercambian los
nodos de una red para indicar a la contraparte la exitosa recepción de un paquete anterior.
Por cada mensaje enviado se espera recibir un paquete de tipo “Ack” a modo de
confirmación de que no se sufrió pérdida de algún bit en el transcurso de la transmisión.
Adyacencia: Estado en el cual dos routers que comparten un enlace en común han
establecido una conexión y comparten mensajes exitosamente.
ASBR: En inglés, Autonomous System Border Router o Enrutados de Borde de Sistema
Autónomo, corresponde a un Router que ejecuta el protocolo OSPF y tiene al menos una
interfaz conectada con algún protocolo o método de enrutamiento distinto (ej. EIGRP,
BGP, entre otros). Al tener una interfaz fuera del protocolo OSPF, este Router es capaz
de convertir las rutas provenientes de un protocolo externo en rutas compatibles con
OSPF.
136

ASN: En inglés, Autonomous System Number o Número de Sistema Autónomo.
Corresponde a un número de identificación de un grupo de Routers bajo una
administración común. Este número es asignado directamente por un RIR.
Backbone: Nombre con el que se conoce a la red de alta velocidad de una organización.
Obtiene su nombre en el hecho de que habitualmente constituye la columna vertebral de
la red.
Balanceo de Carga: Capacidad de un dispositivo de utilizar dos o más enlaces
simultáneamente a fin de dividir la carga de envío de datos y aumentar la capacidad de
transmisión o recepción de los mismos. Habitualmente un enrutador utiliza solamente un
enlace hacia una red de destino, pero si luego de realizar los cálculos correspondientes
para encontrar la mejor ruta se determina que hay dos o más enlaces con la misma métrica,
ambos son utilizados simultáneamente para el envío de paquetes, por lo general utilizando
un algoritmo Round-Robin.
BGP: Border Gateway Protocol o Protocolo de Pasarela de Borde, corresponde al
protocolo principal utilizando en la Internet actual con el cual se comunican diferentes
sistemas autónomos de todo el mundo e intercambian cerca de 300.000 rutas.
Border Router (Router de Borde): Un Router que ejecuta más de un protocolo de
enrutamiento simultáneamente y actúa como traductor de las rutas de uno hacia el otro.
137

Broadcast (Difusión amplia): Tipo de comunicación dentro de una red en la cual un nodo
envía simultáneamente un mensaje a todos los demás de la misma red. En contraposición
a los paquetes de tipo Unicast que van dirigidos solamente de un nodo a otro, o Multicast
que van desde un nodo a un grupo.
Convergencia: Estado en el cual todos los routers de una red han intercambiado
exitosamente las rutas y la topología se mantiene estable.
Core: Ver Backbone.
DARPA: Ac+oonimo de “Defense Advanced Research Projects Agency” (Agencia de
proyectos de investigación avanzados de defensa). Es una organización militar
estadounidense responsable del desarrollo de nuevas tecnologías militares de ese país.
Fueron quienes desarrollaron tanto el actual modelo TCP/IP como el mismo protocolo
IPv4.
Delay: En inglés, retraso. Corresponde al tiempo que demora un paquete de datos en viajar
desde una interfaz de red de salida hacia la interfaz de entrada de otro nodo. Por lo general
es medido en microsegundos.
Desencapsulación: Proceso inverso a la encapsulación. En la desencapsulación los
paquetes de datos recibidos en un dispositivo de networking son abiertos en cada capa
138

respectivamente, desde la trama hasta el paquete, segmento o datos, según lo requiera la
aplicación correspondiente.
DUAL: Diffusing Update Algorithm o Algoritmo de Actualización Difusa. Es el algoritmo
que utiliza el protocolo EIGRP para lograr calcular la mejor ruta hacia una red de destino.
DUAL se considera una máquina de estados finitos y utiliza valores como ancho de banda,
retraso, confiabilidad y carga de los enlaces para determinar el mejor camino.
Dual-Stack: Los Routers Dual-Stack son aquellos que ejecutan simultáneamente una
instancia del protocolo IPv4 y otra de IPv6, cada una en interfaces físicas independientes.
Esto les permite estar instalados directamente en ambos tipos de redes.
EIGRP: Enhanced Internal Gateway Routing Protocol o Protocolo de Enrutamiento de
Pasarela Interior Mejorado. Es un protocolo propietario desarrollado por la empresa Cisco
y sucesor de IGRP. Este protocolo permite realizar cálculos de ruta y realizar una rápida
transición a las rutas de respaldo en caso de una falla, sin necesidad de realizar
recalculaciones posteriores. En Febrero de 2013, Cisco ha anunciado el envío de un
borrador del protocolo EIGRP al IETF para su estandarización.
Enrutador (Router): Dispositivo de red cuya principal labor es reenviar paquetes de
datos basándose únicamente en la dirección IP de destino. Cuando ingresa un paquete, el
Router examina el campo “Destination Address” en el encabezado IP y revisa su propia
tabla de enrutamiento para buscar una coincidencia. En caso de existir, ese paquete IP es
139

enviado por la interfaz de red que coincida. Si no hay coincidencias el paquete se descarta
y se envía un mensaje de tipo ICMP de “host de destino inalcanzable” al dispositivo que
envió el mensaje.
Enrutamiento con clase (Classful): Tipo de enrutamiento donde se consideran las
subredes y máscaras de subred para realizar el encaminamiento de datos a redes remotas.
Enrutamiento sin clase (Classless): Tipo de enrutamiento donde no se consideran las
subredes ni máscaras de subred y los Routers deben convertir las redes a sus bloques IP
Classful o máscaras IP por defecto según la clase de la dirección (A, B o C) por defecto
para tomar decisiones de encaminamiento.
Gateway: Pasarela o puerta de enlace. Corresponde a la dirección IP del Router de una
LAN.
Host: Un host o nodo es cualquier dispositivo de red que ejecute una instancia del
protocolo IP.
ICMP: Internet Control Message Protocol, es un protocol de control de mensajes de
Internet con el cual se intercambian mensajes de capa 3 para conocer el estado de una red.
140

Un ejemplo conocido del uso de este protocolo es la herramienta PING que envía
mensajes ICMP de tipo Echo Request (solicitud de eco) y Echo Reply (respuesta de eco).
IETF: Internet Engineering Task Force o Fuerza de Trabajo de Ingeniería de Internet. Es
una organización internacional que define y regula los protocolos y estándares de uso
común en Internet.
IGP: Internal Gateway Protocols o Protocolos de Pasarela Interna, es una categoría de
protocolos de enrutamiento que se ejecutan dentro de un mismo sistema autónomo (AS).
Dentro de los IGP están RIP (V1 y V2), IGRP, EIGRP, OSPF e IS-IS.
IGRP: Internal Gateway Routing Protocol o Protocolo de Enrutamiento de Pasarela
Interna. Es un protocolo propietario desarrollado por la empresa Cisco. Antecesor del
actual EIGRP.
IPv4: Versión 4 del Protocolo de Internet (IP) utilizado actualmente desde 1974. Las
direcciones IPv4 son de 32 bits de longitud, soportando un máximo de 4.3×109 direcciones
IP.
IPv6: Versión 6 del Protocolo de Internet (IP) desarrollado en 1996 por el IETF como
reemplazo de IPv4. Al tener 128 bits de longitud, IPv6 permite un máximo de 3.4×1038
direcciones.
141

M
MD5: Message Digest 5, es un algoritmo de hash o codificación que genera códigos de
32 caracteres hexadecimales. Ampliamente utilizado para métodos de autenticación,
verificación de integridad y cifrado de contraseñas.
Métrica: Corresponde al valor entregado a una ruta determinada por un Router a partir de
un proceso de cálculo especificado según el algoritmo que se utilice. Un Router calcula
todas las métricas hacia una red de destino y determina que el valor de métrica más bajo
es una ruta más confiable.
MTU: Maximal Transfer Unit o Unidad Máxima de Transferencia. Es un valor
habitualmente configurado en 1500 Bytes el cual determina el tamaño máximo de una
trama que es puesta en el medio físico. A excepción de las tramas “Jumbo”, un frame
nunca excederá los 1500 bytes mientras viaje por el medio Ethernet.
OSI: Open Systems Interconnection o Interconexión de Sistemas Abiertos, es un modelo
estándar de especificación de transmisión de datos de red diseñado por la Organización
Internacional de Normalización (ISO) el cual ha sido utilizado ampliamente como
referencia en la construcción y diseño de sistemas de redes.
OSPF: Open Short Path First es un protocolo estándar de enrutamiento que utiliza el
algoritmo SPF diseñado por Edgar Dikjstra para buscar la ruta más corta entre dos puntos.
En la actualidad es ampliamente utilizado en entornos IGP con múltiples fabricantes.
142

R
RFC: Request for Comments o Solicitud de Comentarios, es un estándar de
documentación utilizado por el IETF para definir los aspectos generales y técnicos de los
distintos protocolos que gobiernan Internet. Un ejemplo es el RFC2616 que detalla la
operación de HTTP.
RIP: Routing Information Protocol o Protocolo de Información de Enrutamiento es uno
de los protocolos más antiguos de enrutamiento dinámico y ya en desuso en la actualidad.
La métrica de RIP es la cuenta de saltos o Routers intermedios entre un origen y un destino,
siendo la ruta con menor cantidad de enrutadores la escogida como mejor y utilizada para
reenviar los datos.
RIR: Regional Internet Registry o Registro de Internet Regional es una institución
reguladora de Internet cuya principal misión es administrar y asignar bloques públicos de
direcciones IPv4 e IPv6 así como también números de sistema autónomo (ASN) a las
organizaciones y proveedores de servicios de Internet (ISP) que soliciten
direccionamiento. En Latinoamérica el RIR responsable es LACNIC (Latin America and
Caribbean Network Information Center).
Ruta Externa: Concepto en el cual se clasifica una ruta proveniente de un protocolo de
enrutamiento diferente al que se ejecuta en un Router y que haya sido redistribuido en él.
143

Sobrecabecera (Overhead): Información extra que es requerida por ciertos protocolos
de control. Hay algunos elementos que generan mayor sobrecabecera que otros, como es
el caso de TCP (Transmission Control Protocol) cuya cabecera es de 20 Bytes, frente a
UDP (User Datagram Protocol) que agrega tan solo 8 Bytes.
TCP/IP: Modelo de redes estándar con el cual funciona la Internet actual. Se trata de un
Stack o Pila de protocolos dentro de los cuales destacan TCP (en capa 4) e IP (en capa3).
WAN: Wide Area Network o Red de Área Amplia, es un tipo de topología que cubre una
extensa área geográfica en contraposición a las LAN que cubren un área reducida de alta
velocidad. Un ejemplo clásico de una WAN es Internet.
WLAN: Wireless Local Area Network o Red de Área Local Inalámbrica es la conexión
sin cables a dispositivos dentro de una LAN. La tecnología Wi-Fi (802.11) se asocia
directamente con redes WLANs.
144


Operación e Integración de Protocolos de Enrutamiento IGP para Redes Corporativas en I pv6-2

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

Operación e Integración de Protocolos de Enrutamiento IGP para Redes Corporativas en I pv6-2

Cargado por

Copyright:

Formatos disponibles

REDESCISCO.

OPERACION E INTEGRACION DE MULTIPLES PROTOCOLOS DE

ENRUTAMIENTO INTERNOS (IGP) PARA REDES IPV6 CORPORATIVAS

Para nadie es secreto el hecho de que Internet ha evolucionado exponencialmente en la

y alta disponibilidad como son Streaming de videos, telefonía IP y aplicaciones en tiempo

y que sea tolerante a fallas.

A partir desde hace un par de años ya se ha ido incorporando el direccionamiento IPv6 en

reemplazo de IPv4, que por más de 40 años ha sido el método predilecto de

direccionamiento en Internet, pero con graves deficiencias que IPv6 ha mejorado.

Este trabajo pretende establecer los parámetros, configuraciones, especificaciones

disponibilidad utilizando protocolos de enrutamiento interior (IGP) basándose únicamente

DESCRIPCIÓN DEL PROBLEMA

y eficiente si no también diseñadas considerando una gran cantidad de aspectos tanto

asegurando así la continuidad del negocio y de todas las operaciones corporativas y

organizacionales que se sustentan en ellas.

Este trabajo plantea definir los parámetros, consideraciones y elementos fundamentales

necesarios para integrar múltiples protocolos de enrutamiento interior (IGP – Internal

IP (IPv6) como reemplazo del actual direccionamiento de red basado en IPv4.

2. Descripción del Problema

El buen funcionamiento de una red de datos corporativa es sin duda un elemento

sistemas de gestión y recursos, bases de datos, entre otras, sustentan su funcionalidad en

determinado momento presenta intermitencias, interrupciones, lentitud u otro tipo de

situaciones negativas, inmediatamente las aplicaciones de usuario se ven afectadas y, por

extensión, la continuidad del negocio de la empresa.

superiores de los modelos de networking las cuales están asociadas a aplicaciones y

estrategia y un buen diseño de red impacta directamente en la fiabilidad y calidad de la

misma y los servicios que sobre ella corren.

Uno de los problemas más complejos de solucionar es la integración de múltiples

protocolos de enrutamiento dentro de una misma área de administración común,

habitualmente denominada Sistema Autónomo (AS – Autonomous System). Por razones

de presupuesto, estratégicas o técnicas, no siempre se puede implementar una red de datos

condiciones operarán los múltiples protocolos.

de Pasarela Interior Mejorado (EIGRP – Enhanced Internal Gateway Routing Protocol),

el Protocolo de Enrutamiento de Pasarela Interior (IGRP – Internal Gateway Routing

Protocol), el Protocolo de Información de Enrutamiento (RIP – Routing Information

Protocol) y otros, deben interactuar entre sí e intercambiar información de enrutamiento

de la forma más óptima, económica y fluida posible. La implementación de múltiples

protocolos basados en IPv4 es un tema bastante recurrente en redes corporativas de

desventajas frente a IPv6 las que serán discutidas más adelante.

FUNDAMENTOS DEL PROTOCOLO DE INTERNET VERSION 6

antecesor inmediato: IPv4.

El protocolo de Internet (IP), definido originalmente en el RFC 791 (Request for

Comments) en el año 1981 bajo el nombre de DARPA Internet Protocol en su versión 4,

fue diseñado para proveer un método de direccionamiento de los paquetes de datos

iniciación, mantención de sesiones y direccionamiento de aplicaciones (puertos) a las

capas superiores del modelo OSI o TCP/IP.

Interconnection) desarrollado por la Organización Internacional de Normalización ISO

(International Standarization Organization) el protocolo IP se ubica en la capa 3

3, como la versión 6 de IP y los desaparecidos IPX de Novell y AppleTalk de Apple Inc,

siendo estos dos últimos casi totalmente absorbidos por IPv4.

Figura 2.2 – Encabezado IPv4

Explicación de los campos del encabezado IPv4

ejecutando. Invariablemente lleva un valor 0100 (versión 4).

encabezado IPv4 (Normalmente 20 bytes) expresados en múltiplos de 32. El valor

mínimo para este campo es 5 (50 x 32 = 160 bits o 20 bytes).

de DiffServ (Servicios Diferenciados) de acuerdo al RFC 2474 y ECN (Explicit

Network Congestion – Congestión explícita de red) en el RFC 3168.

Principalmente orientado a brindar calidad de servicio (QoS – Quality of Service)

mediante la identificación de distintos orígenes y tipo de tráfico IP, como por

ejemplo Voz sobre IP (VoIP).

- Longitud Total: A diferencia de IHL, que solamente indica la longitud del

IP incluyendo la carga útil de las capas superiores. El tamaño mínimo es 20 bytes

(IHL + 0 bytes) y el máximo es 65.536 bytes.