Hola Daniel!

«Cuando el SVR1 se encuentre con NAT en ambas interfaces del R4 (f1/0 y f0/1).»

No estoy seguro si interprete bien tu consulta, pero acá te refieres a las interfaces FE1/0 y FE0/0 del router R4… y estas asumiendo que la red empresarial del otro lado es el server + el router R4 no es cierto?… y además que aplicamos NAT en ESE router a la red 2.2.2.0/24; si esta es la situación que planteas, en este caso no hay mucho que hacer, ya que la red 2.2.2.0/30 no estará disponible de acuerdo a tu traducción y por ende no podrías tener comunicación con el servidor, si quieres utilizar el otro enlace, esto significaría realizar un cambio de IP al servidor, y un cambio de IP a nivel de NAT.
Para este tipo de situaciones a nivel de Internet, es que necesitamos BGP; esta situación la describimos en la clase de BGP a partir del minuto 17 +-.
Si esta no fue la situación que planteas, házmelo saber.

Atento a tus comentarios.

Saludos! =)

Hola Daniel!

En realidad, si existen soluciones en servidores que pueden ser configurados con 2 IPs publicas diferentes, y el momento de falla se puede reflejar el cambio de IP a nivel de DNS hacia los clientes; en estos casos no necesitarias hacer nada especial a nivel de red, ya que podrías tener tus configuraciones de NAT hacia cada salida a Internet, y utilizar SLA para hacer el cambio de ruta. (Existen soluciones que se ocupan de esto como balanceo de carga con equipos F5 o soluciones Cloudfare), sin embargo no he visto las configuraciones de estas soluciones a nivel servicios; el tema en este primer caso, es que de acuerdo a la solución elegida, se experimentara algún tipo de interrupción de servicio para los usuarios a medida que se actualicen los registros DNS y puedan acceder al nuevo servidor. En el caso que necesites 100% de redundancia sin interrupción de servicio, necesitas implementar BGP sí o sí. Con lo que tenemos en la topología mostrada, lastimosamente perderías el acceso a tu servidor como lo mencionamos.

Espero haberte ayudado, estoy atento a tus comentarios.

Saludos! =)

Hola Almer!

Te soy sincero, nunca he realizado alguna configuración similar en base al packet loss, sin embargo, sé que es posible hacerlo a través de 2 operaciones, podrías utilizar ICMP Jitter, o UDP Jitter, ambas tienen la opción de medir el Packet Loss. Te recomiendo también darle una mirada a IP SLA reaction configuration, lo que permite realizar esto, es que se genere un log cada vez que se pierden paquetes; de acuerdo a este log, podrías realizar un script EEM con las configuraciones que necesites para realizar las modificaciones de BGP.

ICMP Jitter: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_icmp_jitter.html
UDP JItter: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_udp_jitter.html#task_49723D1D58A249DDAEF50E40059622BE
Reaction-Configuration: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_threshold_mon.html

Espero que te sirvan.

Saludos! =)

• Esta respuesta fue modificada hace 2 años, 6 meses por AlvaroM.

¡Hola Anthony!

En realidad, IP SLA y BGP son cosas totalmente diferentes (no comparables), una es una herramienta para medir niveles de servicios, y el otro es un protocolo de enrutamiento; respecto al nivel de procesamiento de consumo, pues todo va variar de acuerdo a la forma como implementes las herramientas; si eres parte de la tabla BGP global, obviamente BGP necesitara muchísimos recursos para funcionar. Lo mismo ocurriría con IP SLA, si tienes cientos/miles de sensores, obviamente tendrá impacto en tu procesamiento, ya que IP SLA es una característica basada en software, y no así en hardware; además, cada operación de IP SLA funciona de manera diferente, y por ende consumirá diferente cantidad de recursos. Acá te paso una presentación de Cisco donde detallan en porcentajes, cuanto consumirían de CPU… cierta cantidad de operaciones de acuerdo a la plataforma: https://www.cisco.com/c/dam/global/en_ca/assets/plus/assets/pdf/Intro-to-IP-SLA-DJEROME.pdf , lo puedes apreciar en la página 40 y 50.
Por otro lado, respecto a VRRP, sí es soportado con IP SLA ICMP Echo, cuando falla la operación de tracking, se decrementa la prioridad para hacer el cambio de GW. El comando dentro de la interface que funciona con VRRP, es «vrrp 1 track 1 decrement valor», la configuración de la operación SLA y del track, es la misma que se vio en la clase.

Espero que mi respuesta te ayude.

Saludos! =)

Hola Eduardo.

Te soy sincero no lo he probado, sin embargo, la teoría hace referencia a que la diferencia entre ambos tiene que ver con el valor de threshold. Con IP SLA puedes configurar valores de timeout y de threshold. El timeout es el tiempo que espera SLA para que la operación se pueda completar antes de catalogarla como fallida, este valor por defecto es de 5000 ms, y el threshold define un tiempo límite para calcular las estadísticas de la operación hasta ese momento, se puede configurar un valor desde 0 hasta 60000 ms; este es un punto intermedio para sacar estadísticas de la operación sin la necesidad de esperar a que la operación fallé, por lo tanto, siempre tiene que tener un menor valor al timeout. Sin embargo, dicho valor se puede utilizar para el track.

Esto es lo que nos dice Cisco: «Two aspects of an IP SLAs operation can be tracked: state and reachability. The difference between these aspects relates to the acceptance of the OverThreshold return code. Table 79 shows the state and reachability aspects of IP SLAs operations that can be tracked. »

Y la tabla es esta:

Tracking            Return Code             Track State

State                    OK                    Up
                 (all other return codes)      Down
	
Reachability      OK or over threshold         Up
                 (all other return codes)      Down
	

Cuando configures el threshold, al verificar las operaciones con el comando show, tendrás un contador: «Over thresholds occurred: FALSE», esto significa que la operación se ha completado dentro del valor del threshold. Además, que el «OVERTHRESHOLD» será un posible «Return Code» extra al «OK».

Con todo lo anterior, si configuramos el «state» y un valor de threshold, solo te dará un resultado de «UP» cuando tengas el return code de «OK» (No se superó ni el timeout ni el threshold). Por el otro lado, si el tiempo de la operación supera al valor threshold, se te devolverá un “Return Code” de «OVERTHRESHOLD» lo que hara que tu track se vaya a “DOWN”. Si lo analizas, esto puede ser utilizado por un ISP para monitorear el SLA con un cliente, de manera que puedan tomar acciones antes que la operación de track sea considera fallida.

Espero que ahora quede claro.

Te dejo el link de referencia: https://www.cisco.com/c/en/us/td/docs/ios/ipsla/command/reference/sla_book/sla_05.html#wp1093733

Saludos! =)

• Esta respuesta fue modificada hace 9 meses por AlvaroM.