Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64

Parece loco, pero no lo es: Server DNS recursivo detrás de NAT64. Explicando IPv6-only Capable Resolvers Utilising NAT64 

Internet táctil e IPv6

Introducción
Un concepto (si, ¡otro más !) que seguro aumentará los próximos años será “Internet táctil”, así como suena ¿bonito?, ¡yo lo veo super!, incluso suena como un sueño, todo eso que vimos en películas y en comics los últimos 35 años parece que finalmente será una realidad.
¿Cuales sueños?, unos super lentes, con unos super guantes, manejar un robot a distancia, hacer lo que yo le diga, con una maravillosa visión y virtualmente unos superpoderes, salvar una vida, ufff muy cool, ¿no?. No estamos tan lejos de todo esto

Para apreciar el futuro es importante recordar el pasado
Para los que nacimos antes de los años 80 muy seguramente nos recordaremos un poco de la evolución de los monitores monocromáticos (MDA), CGA, EGA, VGA, SVGA, etc. Cada cambio ya era MUY importante, poder ver colores en la pantalla, poder pintar decentemente algo. Luego esos colores “estáticos” vinieron apoyados con algo de movimiento, luego video e incluso audio, los conceptos de multimedia ya estaban con nosotros (multi medios). El Internet táctil representa algo así como un super-mega-multimedia !

Comencemos: ¿Qué es el Internet Tactil?
No voy a inventar la rueda indicando el término, aquí les dejo un copy/paste tomado de [1]:
“Aunque esta denominación parece nueva no lo es. El término 'internet táctil' fue acuñado a principios de 2014 por el propio profesor Fettweis. La Unión Internacional de Telecomunicaciones (UIT) ya lo definió en un informe en Agosto de 2014. Básicamente, según su definición, va a combinar múltiples tecnologías, tanto a nivel de redes como de aplicaciones. El internet táctil va a permitir la interacción háptica con la retroalimentación visual.”
Si buscamos otros conceptos aquí y allá es básicamente utilizar nuestros sentidos a través de la red, es decir: tacto, olfato, ver, gusto y escuchar. Bueno, es cierto, varios de estos ya lo hacemos hoy en día.

Entonces: ¿por qué el nuevo concepto?
El nuevo concepto viene por varios temas novedosos, principalmente: la palabra háptica que se encuentra en nuestra definición antes indicada. Háptica en el concepto de Internet Táctil se refiere precisamente al sentido del tacto, Por otro lado, según Wikipedia [2]
“.... el significado de la palabra háptica, refiriéndose por exclusión a todo el conjunto de sensaciones no visuales y no auditivas que experimenta un individuo.

¿Para qué servirá el Internet táctil?
Aquí es donde no hay límites, solo me vienen las palabras de Buzz Lightyear en las famosas películas de Toy Story: “Hasta el infinito y más allá”
¿Por dónde comienzo?, tengo una idea, comienza tú mismo, piensa en algo que hayas querido hacer: ¿lanzarte en paracaídas?, ¿nadar con tiburones? ¿ser un bombero durante un incendio? ¿jugar tenis contra Roger Federer? ¿anotar un gol en un mundial de Fútbol?
Otra: ¿qué quieres aprender que pienses que necesite presencia física?, ¿cocinar? ¿una clase de piano o guitarra? ¿clases de natación?.., lo que sea.
Esto es precisamente donde Internet táctil toma relevancia; Internet Tactil busca acercar lo que no se puede hacer remoto, conceptos como hologramas ya son posibles transmitirlos, manipular objetos remotos, robótica, realidad virtual, realidad aumentada, lógicamente IoT,. Vivir con nuestros sentidos lo que no está cerca.
En estos momentos de pandemia podríamos tener a la profesora vía holograma en la sala de tu casa enseñando matemáticas a tu niño. ¿Suena genial, no?
Que opinas de esto: acercar un gurú médico para una operación (ciertamente ya se han hecho varias) muy delicada a un paciente, si hoy es posible, mañana será habitual. Ya incluso imagino un médico recibiendo clases a distancia con holograma, robots, guantes, VR, etc de cómo va a operar remotamente, lo mejor, todo va a salir bien!.
¿Prácticas de diferentes actividades?, virtualmente todo se podrá practicar: música, deportes, cocina, piloto, conductor, odontología y un larguísimo etcétera. Un ejemplo: hoy en día existen “robots limitados” donde se realizan prácticas quirúrgicas. Muy pronto tendremos pacientes humanoides que responderán a lo que el practicante realice y responderán ante un dolor, una acción, un movimiento.
Vamos bien, ¿no?. Antes de continuar, al día de hoy (Julio 2020) Internet Táctil está muy ligado a redes celulares 5G sin embargo mi presentimiento es que no será siempre así, eventualmente saldrán redes 6G, 7G, algún super Wifi, etc, etc.

¿Y en que apoya IPv6 al Internet táctil?
Con todo lo anterior no me cabe la menor duda que la mejor manera de conectar cada cosa será con IPv6. Sin embargo, la mejor manera de responder esta pregunta es pensar: ¿Qué requiere Internet Táctil?. Aquí lo presentamos:

1. Algo que viene de la mano con Internet táctil es el tiempo de respuesta de los objetos (RTT/Delay de los enlaces en muy pocos milisegundos); imaginemos utilizar un robot a distancia, queremos que sea tan rápido como si estuviese al lado de uno. Si hablamos con un holograma, queremos que sea fluido. IPv6 cada día demuestra que los RTT son mejores a los de IPv4.
2. Una red muy confiable, al día de hoy sabemos que la pérdida de paquetes en IPv6 es inferior a IPv4 (0.25% vs 0,33%). [3]
3. Redes resilientes, para ello, IPv6 al no tener que traducir de direcciones (NAT) existe mayor posibilidad de éxito en las conexiones. [7]
4. Mucho ancho de banda (claro, depende de lo que se desea hacer).

¿Es todo esto suficiente?
La respuesta es mayormente un NO. Podemos tener ancho de banda al orden de Gigas o Teras, no tener pérdida de paquetes, IPv6 en los dispositivos pero aún así la barrera del tiempo de respuesta estará allí, cada milisegundo cuenta. Nos referimos a la interacción humana. Aunque parezca mentira la velocidad de la luz pareciera ser lenta en este contexto, aprox 300.000 km/seg (¿por cierto, sabías que la luz pierde el 31% de su velocidad sobre fibra óptica?) [4]
La velocidad de respuesta es sumamente importante -al menos para gran cantidad de implementaciones-; imaginemos que tenemos unos lentes (tipo Virtual Reality) que nos muestra un paisaje, si movemos la cabeza a la derecha ese paisaje que vemos en los lentes debe cambiar al mismo tiempo (máximo 1 ms), sino, nos sentiremos un poco mal, es llamado Cybersickness [6].

Conclusiones
El uso que se le da a Internet seguirá incrementándose, nuevas ideas saldrán todo el tiempo, las posibilidades de lo que se podrá hacer sobre la red son infinitas.
El tiempo de respuesta parece ser la limitante más complicada a solucionar.
En pocos años tendremos una red más confiable, nos convertirá en personas más productivas. Confío que estas tecnologías apoyaran a los ciudadanos y por ello a sus respectivos países a ser más competitivos y estos beneficios se trasladarán a la población en general. El uso correcto de dichas innovaciones mejorará notablemente la calidad de vida en 1 o 2 generaciones. Hay que aprovecharlo!.

Referencias:
[1] https://innovadores.larazon.es/es/el-internet-tactil-que-viene/
[2] https://es.wikipedia.org/wiki/H%C3%A1ptica
[3] https://www.hindawi.com/journals/mpe/2017/3056475/
[4] https://www.wired.com/2013/03/internet-at-the-speed-of-light/
[5] https://www.youtube.com/watch?v=NOG4zft9rxY&list=PLvZsgabGn2vR4TDEGeUIVJ36RgSV05UGW
[6] https://www.scitecheuropa.eu/virtual-reality-motion-sickness/89447/
[7] https://www.distributednetworks.com/internet-proxy-server/module2/nat-limitations.php

Hirola Infotech Solutions is one of the Best Digital Marketing company in Bangalore,Ranked among the Top digital marketing agencies in Bangalore Digital Marketing, Web Development, Software and mobile app development Company In Bangalore, India Best Best Digital Marketing company in Bangalore,Top digital marketing agencies in Bangalore, ppc, seo Hirola InfoTech Solutions, your number one source for our passion for helping small and medium size businesses has grown us into a full service strategic marketing company ,we are end to end provider of Digital marketing Web development & Applicatio

Animacion: La triste historia de un ISP sin IPv6

`




La triste historia de un ISP sin IPv6. Guion: Alejandro Acosta, Producido en: Universidad de Guadalajara - Coordinacion General de Tecnologia de Informacion, Animacion y Diseno: Marco Sierra, Voz: Dolores Hernandez - Red Radio Universidad de Guadalajara, Grabacion: Mauricio Urbina - Red Radio Universidad de Guadalajara, Edicion: de Sonido Marco Sierra, Tema Musical: "Children" Matti Paalanen.

Historia original en: https://blog.acostasite.com/2015/01/tecno-cuento-la-triste-historia-de-un.html

NAT66 en Linux

Hola,

  El dia de hoy voy a hacer un post el cual no deseo que sea tomado de mala manera. Indiscutiblemente no estoy a favor del NAT pero aun asi pienso que es un mecanismo que no desaparecera en IPv6 (se reducira drasticamente) pero siempre existira. En lo posible recomiendo evitar hacer NAT cuando exista la posibilidad.

  Pueden haber muchas razones para implementar NAT66, a) seguramente los clientes acostumbrados a hacer NAT querran hacerlo en IPv6 (suene feo o bonito), b) personas que quieran ocultar su topologia a Internet, c) empresas que consideren NAT como mecanismo para cambiar los IPs de sus redes, d) la tendencia mundial de no permitir tethering en los celulares, e) querer ofrecer IPv6 detras de un dispositivo y mi proveedor no tenga DHCPv6-PD o solo me entregue una red /64, f) alguien que piense que NAT sirve de mecanismo de seguridad, etc, etc, etc, etc.

  En base a lo anterior la intencion de este post no es estar a favor o en contra de NAT, solo deseo indicar que esta disponible en el mundo de IPv6 y ofrecer un sencillo ejemplo. Para bien o para mal puede ser utilizado en algunos escenarios.

Requerimientos:

  El equipo a realizar el NAT66 debe tener:

  - Kernel > 3.9 

  - iptables > 1.4.18

  Ubuntu 14.04 cubre ambos requerimientos "out-of-the-box" y por ello es muy sencillo hacerlo.

  Existen patch para hacer NAT66 en versiones previas pero no lo indicare en este momento.

Escenario:

  Esta es la topologia en la que estoy trabajando. Deseo que "Device 2"  traduzca la direccion IPv6 origen de "Device 1" con la direccion IPv6 de la interfaz saliente (eth2). Con el comando NAT implementado estoy realmente haciendo NAT de toda la subred 2001:db8:12::/48

Configuraciones:

En DEVICE 1:

#ifconfig eth0 inet6 add 2001:db8:12::2/48

#route -A inet6 add default gw 2001:db8:12::1

En DEVICE 2:

Configurar las direcciones IPv6 en el equipo

#ifconfig eth1 inet6 add 2001:db8:12::1/48

#ifconfig eth2 inet6 add 2001:db8:23::1/48

Habilitar enrutamient o IPv6 entre las interfaces:

#sysctl -w net.ipv6.conf.all.forwarding=1

Configurar el NAT66:

#ip6tables -t nat -A POSTROUTING -o eth2 -s 2001:db8:12::/48 -j MASQUERADE

(es de notar que existen muchas otras maneras de hacer NAT con ip6tables)

En DEVICE 3:

#ifconfig eth1 inet6 add 2001:db8:23::2/48

#route -A inet6 add default gw 2001:db8:23::1

  Del lado de Device 3 pueden verificar de muchas maneras que todo funcione, incluso sin ruta por default en Device 3, DEVICE 1 puede llegarle. De igual manera tcpdump, wireshark o una sencilla revision de los logs puedes verificar que efecticamente el NAT esta llevandose a cabo.

  Espero sea de tu utilidad

Tunel GRE entre Cisco y Linux + NAT

Introducción:
  En el siguiente escenario se plantean dos oficinas conectadas mediante un tunel GRE. En la oficina "A" existe un router Cisco y en la oficina "B" un servidor Linux.

Objetivo:
  Que la oficina "A" (la red con el router Cisco) salga a Internet (nateada) con el IP de la red de la oficina "B" (red con el servidor Linux)


Topologia:
 
Lado Cisco (Oficina A):
   LAN: 192.168.56.6
   WAN: 98.76.54.32
   TUNNEL 0: 192.168.56.6

Lado Linux (Oficina B):
   LAN: 192.168.1.200/24  (gre_if0)
   WAN: 123.45.67.89 (Interfaz: venet0:0)

Pasos (lado equipo Linux):
1) Levantar el modulo GRE
  #modprobe ip_gre

2) Crear la interfaz del tunel (llamada gre_if0). Puede tener cualquier nombre:
   #ip tunnel add gre_if0 mode gre remote 98.76.54.32 local 123.45.67.89 ttl 255

3) Asignarle un IP a la interfaz recien creada (gre_if0)
   #ip addr add 192.168.1.200/24 dev gre_if0

4) Levantar la interfaz del tunel (por defecto viene shutdown)
   #ip link set gre_if0 up (Levantar la interfaz gre_if0)

5) Enrutar por el tunel aquellas rutas que sean necesarias, por ejemplo: 
   #route add -net 192.168.56.6 netmask 255.255.255.255 dev gre_if0

Pasos (lado Cisco)


!Creación de la interfaz tunel
interface Tunnel0
 ip unnumbered FastEthernet0/0
 tunnel source Vlan1
 tunnel destination 123.45.67.89
 
!Configuración de la interfaz LAN
interface FastEthernet0/0
 description **Conexion LAN**
 ip address 192.168.56.6 255.255.255.252
 duplex auto
 speed auto
 
!La interfaz VLAN1 es la interfaz WAN
interface Vlan1
 description **Conexion WAN**
 ip address 98.76.54.32 255.255.255.248
 
!Hacer las rutas necesarias en el router
!para alcanzar la LAN de la oficina B
ip route 192.168.1.200 255.255.255.255 Tunnel0

PARA EL NAT (LADO LINUX):
1) Permitir routing en el equipo
  # echo 1 > /proc/sys/net/ipv4/ip_forward

2) Que el servidor Linux sepa alcanzar la LAN de Oficina A
   #route add -net 192.168.56.0 netmask 255.255.255.0 dev gre_if0


3) Realizar el NAT
   # iptables -A POSTROUTING -t nat -s 192.168.56.0/24 -j SNAT --to 123.45.67.89





  Notese que hubo que hacer Source NAT (SNAT). La explicación del motivo está indicada en el post: "Linux iptables, solucion al error: Warning: wierd character in interface"

 
Espero te sea útil,

Entrevista en la radio sobre IPv6

http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Gustavo Terrero, Presidente de CAVEDATOS; Ricardo Holmquist, Presidente de ISOC Venezuela; y Alejandro Acosta, director del Foro Latinoamericano de IPv6; conversan con Peter Cernik en la oportunidad de explicar la necesidad de migrar toda la estructura de direcciones de internet al Protocolo de Internet version 6, que debe sustituir al IPv4, ya que este último ha agotado su capacidad de manejar identificaciones únicas para cada dispositivo conectado y por conectarse en la red de redes.

Click Aqui

- - - 

Duración = 00:24:38. 


Tomado de/Información original en:
http://tecnologiahechapalabra.com/archivo/media.asp?i=858

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion: 

 Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde. 

Escenario: 

    {Internet} --- {RTR con IP publica} ------- {Granja de Servidores} 

IP Publica: 11.12.13.14 

Mail Server: 192.168.1.5 Web Server: 192.168.1.4 

SSH: 192.168.1.6 

IP WAN: 11.12.13.14/30 

IP LAN: 192.168.1.1/24 

  

Solucion: 

 La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo. En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera: Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5) Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4) Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6) 

Procedimiento: 

 La configuracion del router seria la siguiente: 

  ! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES 

interface FastEthernet0 

description Mi granja de servidores 

ip address 192.168.1.1 255.255.255.0 

ip nat inside 

! ! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET 

interface Serial0 

description Hacia Internet 

ip address 11.12.13.14 255.255.255.252 

ip nat outside 

! !En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web 

ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable 

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail 

ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable 

!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh 

ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable 

Tips:

  Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente: !El usuario desde Internet debe acceder a http://11.12.13.14:61234 ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red. Espero haya sido de tu utilidad, Suerte!

Guardar los registros del nat translation en un servidor Linux

Situación:
Deseo guardar en un servidor Linux las entradas de NAT en un router Cisco de tal manera de conocer siempre que dirección IP y puerto tenian asignado en un moment especifico.


Solución:
Salvar cada uno de los registros NAT creado por el Router Cisco en un servidor Linux (Debian) usando rsyslog...

Procedimiento:
Comencemos con el servidor Linux...

Para lograr esto, empezamos creando el archivo que vamos a utilizar para guardar todo los registros que nos va a enviar el router.

#touch /var/log/cisco-nat.log
#chmod 640 /var/log/cisco-nat.log

Una vez hecho esto, procedemos a editar el siguiente archivo "/etc/rsyslog.conf" y tenemos que quitarle el símbolo de "#" (usados para documentar) a las siguientes entradas:


# provides UDP syslog reception
#$ModLoad imudp
#$UDPServerRun 514

Quedando de la siguiente manera,

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

Adicionalmente, agregamos las siguientes entradas

$UDPServerAddress 0.0.0.0
$AllowedSender UDP, 3.3.3.3

La primera usada para decirle que use toda las interfaces que tenga disponible, y la segunda, "3.3.3.3" la usamos para permitirle a la dirección 3.3.3.3 enviar los registros.

Luego, procedemos a colocar la siguiente linea

local7.* /var/log/cisco-nat.log

(Opcional)

Una vez que hayamos colocado las entradas mencionadas anteriormente, es posible que estas se empiecen a duplicar en los archivos "syslog" o "messages", etc...

Para evitar que esto ocurra y tengamos las entradas duplicadas en los archivos, podemos editar las entradas que mencionan "syslog" y "messages"

Por ejemplo,

Esta linea:
*.* -/var/log/syslog
La modificamos para que quede de la siguiente manera

*.*;local7.* -/var/log/syslog

De esta manera evitamos que los registros se dupliquen...

Una vez hecho esto, reiniciamos el servicio de la siguiente manera:

/etc/init.d/rsyslog restart


Luego, en el equipo cisco, es bastante sencillo lo que tenemos que hacer...

Router#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# no logging console
Router(config)# no logging monitor
Router(config)# ip nat log trans sys
Router(config)# logging host 1.1.1.1


Listo!!!!!

Ya deberíamos de comenzar a ver los registros de nuestro Router en el archivo cisco-nat.log


Revisión:
A continuación, una muestra de como quedaría


2010-08-04T16:52:23.759260-04:18 3.3.3.3 2178773: 14w1d: %IPNAT-6-NAT_CREATED: Created tcp 10.58.50.50:64807 11.11.11.11:30079 192.69.239.224:445 192.69.239.224:445
2010-08-04T16:52:23.764009-04:18 3.3.3.3 2178774: 14w1d: %IPNAT-6-NAT_CREATED: Created tcp 10.58.51.2:3019 11.11.11.11:30167 69.63.190.18:80 69.63.190.18:80

Cualquier comentario se agradece.

Suerte!

NAT en Cisco. 2 ISPs diferentes

Necesidad: 

  Tener un enlace primario y un enlace secundario en un mismo router con dos proveedores a Internet diferentes. 

Escenario(abajo la configuración detallada y explicada): 

 Router Cisco 1760 donde: 

Interfaz Fastethernet0/0 LAN (IP 172.20.0.1) 

Internaz Serial1/0.1 ISP Primario (IP 10.0.0.58) 

Internaz Serial0/0.1 ISP Secundario (IP 10.1.1.58) 

  Diagrama: Procedimiento: 

Primero es necesario configurar unas rutinas en el router que se van a encargar de monitorear las interfaces WAN. 

ip sla monitor 1 (deseo monitorar el next-hop del enlace del ISP primario) 

type echo protocol ipIcmpEcho 10.0.0.57 source-interface Serial1/0.1 timeout 1000 threshold 400 frequency 3 ip sla monitor schedule 1 life forever start-time now (esta linea es para activar realmente el monitoreo) 

ip sla monitor 2 (deseo monitorar el next-hop del enlace del ISP secundario) type echo protocol ipIcmpEcho 10.1.1.57 source-interface Serial0/1.1 timeout 2000 threshold 1000 frequency 3 ip sla monitor schedule 2 life forever start-time now (esta linea es para activar realmente el monitoreo) ! 

Con las lineas arribas indicadas lo que se hace es monitorear si el next hop en el enlace WAN esta levantado. 

Por ejemplo en el primer caso se hace ping (ipIcmpEcho) al IP 10.0.0.57, con un timeout de 2000 ms, un umbral de 1000 ms cada 3 segundos. Posteriormente es necesario habilitar los comandos track en Cisco. Estos son muy utiles para conocer luego el estado de los SLA previamente configurados. Los comandos son: track 123 rtr 1 reachability delay down 15 up 10 ! track 345 rtr 2 reachability delay down 15 up 10 ! El truco se encuentra en el NAT (tanto asi que lo anterior se puede hacer con rutas flotantes, sin embargo de la manera implementada es la mejor practica). 

El NAT debe ser realizado en base a route-maps (no lo intentes de otra manera). Las lineas que personalmente utilice fueron: 

ip nat pool POOL-MINAT 200.30.30.30 200.30.30.30 prefix-length 29 

ip nat inside source route-map ISP-1 pool POOL-MINAT overload 

ip nat inside source route-map ISP-2 interface Serial0/1.1 overload 

access-list 150 remark PARA-NAT 

access-list 150 permit ip 172.20.0.0 0.0.0.255 any 

route-map ISP-1 permit 5 

 match ip address 150 

  match interface Serial1/0.1 

! 

route-map ISP-2 permit 5 

  match ip address 150

  match interface Serial0/1.1 

En el ejemplo anterior vemos que el NAT es en base a los route-maps ISP-1 e ISP-2, el ACL a utilizar es el 150 extendido donde estamos nateando toda la red 172.20.0.0/24 Cuando los paquetes salgan por el ISP-1 saldran nateados con el IP 200.30.30.30 y cuando salgan con el ISP-2 saldran con el IP de la interfaz WAN. Logicamente puedes ajustar esto a tu necesidad. 

 Ahora bien, la ruta de los paquetes de salida son definidas con la siguiente configuracion: 

ip route 0.0.0.0 0.0.0.0 Serial1/0.1 track 123 

ip route 0.0.0.0 0.0.0.0 Serial0/1.1 track 345 

 La ruta por default es la interfaz s1/0.1 cuando el IP 10.0.0.57 se encuentre UP, en caso de que se caiga la interfaz y/o el ping al IP 10.0.0.57 NO sea satisfactorio se utilizara la ruta por la interfaz S0/1.1 (enlace secundario) 

Verificacion: 

1760-WAN#sh track 123 

Track 123 Response Time Reporter 1 reachability Reachability is Up 33 changes, last change 08:27:17 Delay up 10 secs, down 15 secs Latest operation return code: OK Latest RTT (millisecs) 11 

1760-WAN#sh track 345 

Track 345 Response Time Reporter 2 reachability Reachability is Up 36 changes, last change 3d01h Delay up 10 secs, down 15 secs Latest operation return code: OK Latest RTT (millisecs) 8 1760-WAN

#sh ip nat t [OUTPUT SUPRESSED] 

Links de informacion: http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a0080950834.shtml y http://www.cisco.com/en/US/tech/tk648/tk361/technologies_configuration_example09186a00808d2b72.shtml 

 Espero haya sido de tu ayuda, Suerte!,


pdf to word