IP SLA – ICMP Echo Operation with Track

NUESTROS CURSOS Foros CCNP 350-401 ENCOR IP SLA – ICMP Echo Operation with Track

Viendo 9 entradas - de la 1 a la 9 (de un total de 9)
  • Autor
    Entradas
  • #23597
    AdminNG
    Superadministrador
    #31908
    DANIEL GONZALEZ
    Participante

    Hola Álvaro, espero te encuentres muy bien.

    Tengo una duda sobre la configuración, con el mismo ejemplo pero ahora habilitando NAT.

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

    Supongamos que ya tenemos habilitado IP SLA con TRACK en R3 y nos comunicamos al SVR1 con la 2.2.2.2 desde PC(.10), falla el enlace entre ISP1(R1) to R4 y al momento de que cambia de enlace al ISP2(R2) to R4, el ISP2 NO tendrá en su RIB la 2.2.2.0/30 y no podrá comunicarnos.

    Mi pregunta es, que configuración podemos realizar para poder mantener la comunicación ya con NAT habilitado?

    Quedo pendiente a tu respuesta.

    Saludos !!

    #31921
    AlvaroM
    Superadministrador

    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! =)

    #31934
    DANIEL GONZALEZ
    Participante

    Buen día Álvaro.

    Listo ya me quedó claro que con BGP es la única forma de tener redundancia al 100% con el servidor, obteniendo una IP Publica y un AS.

    Entonces para confirmar, esta seria la única forma de implementar IP SLA en un ambiente real, teniendo un servidor con una IP publica y un AS

    Quedo atento, y muchas gracias de nuevo.

    Saludos!

    #31938
    AlvaroM
    Superadministrador

    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! =)

    #36984
    almer.franco
    Participante

    Hola Alvaro,

    Para el caso de tener comunicación con dos ISP manejando enrutamiento BGP y se quisiera conocer el packet loss de mis enlaces WAN y con base en un umbral de este packet loss realizar la conmutación de un enlace a otro. Cual deberia ser la configuración correcta en cuanto a IP SLA tracking?

    Gracias

    #36995
    AlvaroM
    Superadministrador

    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 10 meses por AlvaroM.
    #38753

    Entre IP SLA y BGP respecto la redundancia, cual consume mayor procesamiento?
    Habra una aplicacion del IP SLA para el protocolo VRRP para que cuando detecte la caida logica de la wan, decremente la prioridad?

    #38795
    AlvaroM
    Superadministrador

    ¡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! =)

Viendo 9 entradas - de la 1 a la 9 (de un total de 9)
  • Debes estar registrado para responder a este debate.