IP SLA – ICMP Echo Operation with Track

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

Viendo 5 entradas - de la 1 a la 5 (de un total de 5)
  • 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 !!

    • Esta respuesta fue modificada hace 4 meses, 3 semanas por DANIEL GONZALEZ.
    #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! =)

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