EIGRP sumarización de rutas

EIGRP con sumarización de rutas.

El esquema de interconexión es el siguiente:


 Las rutas sin sumarización en R1 se muestran a continuación:

 

NAT-PT para IPv6

Network Address Translation (NAT)—Protocol Translation (PT).

NAT64 es un mecanismo que permite que hosts que solamente tienen conectividad IPv6 puedan comunicarse con hosts que solamente tienen conectividad IPv4.

Para lograr este objetivo se debe contar con un equipo de red que sea capaz de realizar una traslación de protocolos IPv4 <-> IPv6. Entre otras cosas, este mapeo debe incluir el mapeo de las direcciones de capa de red de uno y otro protocolo.

Del lado de la red solo-IPv6, las direcciones IPv4 se mapean dentro de un prefijo IPv6 el cual debe tener suficientes bits de host para mapear todo el espacio IPv4. Normalmente se utiliza el prefijo 64::ff9b/96.

Para que los hosts solo-IPv6 puedan comunicarse con los hosts solo IPv4 hace falta un componente adicional que es una traducción a nivel de DNS. Este es el rol del DNS64, el cual se encarga de recibir las consultas DNS de los hosts solo-IPv6 y modificar las respuestas de tal manera de incluir registros AAAA que mapean las direcciones IPv4 dentro del prefijo NAT64.

Ambos procesos están definidos en [RFC6146] y [RFC6147].

El diagrama general es:

OSPF + EIGRP redistribuir rutas

Vamos a ver un caso muy particular para redistribución de rutas, en este ejemplo partimos del supuesto que tenemos un Router R4 en un sitio remoto que tiene configurado OSPF, tenemos en otro extremo Routers R1, R2 y R3 con enrutamiento EIGRP configurado entre ellos, se habilitan 2 interfaces en R4 para interconectar con el AS EIGRP entre R3 y R2 por cuestiones de contar con redundancia y requerimos lo siguiente:

1. Habilitar enrutamiento entre los Routers sin eliminar las configuraciones previas, podemos agregar y cambiar valores por defecto.
2. Permitir que la ruta por defecto de todos los Routers sea por medio de R4
3. Establecer como ruta preferida para comunicar ambos sistemas mediante R3 y R4 quedando como ruta secundaria R2 y R4.

El esquema de interconexión y direccionamiento utilizado es el siguiente.

NAT ON STICK

La técnica de Nat on Stick consiste en combinar policy-map y NAT con la finalidad de enviar y recibir datos de diferente segmento por la misma interface, a decir de la documentación oficial de CISCO son pocas las ocasiones en que se utiliza esta técnica en la imagen 1 tenemos el caso básico en el cual aplica y sirve para entender el funcionamiento, en este caso los paquetes entrantes a R1 que procedan la dirección ip 192.168.1.2 serán siempre redirecciovados a la interface Loopback 0 y se hará NAT.

Para comprender como son tratados los paquete habilitamos los debug:
debug ip policy
debug ip nat

En la prueba inicial el R2 manda un traceroute a una ip fuera de su red en este caso 8.8.8.8

R2#traceroute 8.8.8.8

Type escape sequence to abort.

Tracing the route to 8.8.8.8

  1 192.168.1.1 40 msec 40 msec 48 msec

  2 2.2.2.2 !H  !H  * 

Y el debug muestra que se aplica el policy route-map y el NAT correctamente obviamente no encontramos el destino.

*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8, len 28, policy match

*Dec 27 11:41:20.931: IP: route map LOOP, item 10, permit

*Dec 27 11:41:20.931: IP: s=192.168.1.2 (FastEthernet0/0), d=8.8.8.8 (Loopback0), len 28, policy routed

*Dec 27 11:41:20.935: IP: FastEthernet0/0 to Loopback0 0.0.130.158

*Dec 27 11:41:20.935: NAT: s=192.168.1.2->2.2.2.2, d=8.8.8.8 [298]

*Dec 27 11:41:20.939: NAT: s=2.2.2.2, d=2.2.2.2->192.168.1.2 [64]

Vemos el que el fue NAT aplicado correctamente.

R1#show ip nat translations 

Pro Inside global      Inside local       Outside local      Outside global

udp 2.2.2.2:49211      192.168.1.2:49211  8.8.8.8:33437      8.8.8.8:33437

udp 2.2.2.2:49212      192.168.1.2:49212  8.8.8.8:33438      8.8.8.8:33438