17 de noviembre de 2014

Ruta estática flotante + IP SLA

Un modelo de acceso a Internet habitual en redes de medianas dimensiones es el que está compuesto por 2 proveedores de acceso a Internet cuyo acceso se administra a partir de un único router de acceso.
Un modelo semejante al que ilustra el gráfico:
En este esquema, un requerimiento posible es que el enlace del ISP 1 sea el enlace activo y utilicemos el enlace al ISP 2 como enlace de respaldo.
Como se trata de enlaces a Internet, es siempre posible resolver el enrutamiento hacia Internet utilizando una ruta estática por defecto. Pero en este caso, si utilizamos 2 rutas estáticas por defecto (en principio) se balanceará tráfico entre ambos proveedores. Y no es este el requerimiento, no se desea balancear tráfico sino tener un enlace primario y otro de backup.

Una primera solución es dejar una ruta por defecto con la distancia administrativa por defecto (es decir 1), y utilizar distancia administrativa para dejar la otra ruta como flotante. La ruta flotante, al tener mayor distancia administrativa no irá a la tabla de enrutamiento sino que quedará como ruta de respaldo e irá a la tabla de enrutamiento cuando la ruta principal no esté disponible.

Router(config)#ip route 0.0.0.0 0.0.0.0 182.1.10.2
Router(config)#ip route 0.0.0.0 0.0.0.0 200.1.1.2 100

En este caso estamos utilizando como recurso la Distancia Administrativa de las rutas estáticas para definir cuál es nuestra ruta primaria y nuestra ruta de respaldo.
Hemos resuelto el requerimiento utilizando una ruta flotante. 
Pero esta solución no siempre es efectiva ya que dependiendo de la tecnología de acceso que esté utilizando el ISP es posible que perdamos el acceso primario a Internet mientras nuestra ruta por defecto sigue aún activa. Para resolver esta posibilidad es que se implementan las rutas por defecto vinculadas a un IP SLA:

Router#configure terminal
Router(config)#ip sla 1
Router(config-ip-sla)#icmp-echo 182.1.10.2 source-interface Se0/0/0
Router(config-ip-sla-echo)#timeout 500
Router(config-ip-sla-echo)#frequency 2
Router(config-ip-sla-echo)#exit
Router(config-ip-sla)#exit
Router(config)#ip sla schedule 1 life forever start-time now
Router(config)#track 1 ip sla 1 reachability
Router(config)#ip sla 2
Router(config-ip-sla)#icmp-echo 200.1.1.2 source-interface Se0/0/1
Router(config-ip-sla-echo)#timeout 500
Router(config-ip-sla-echo)#frequency 2
Router(config-ip-sla-echo)#exit
Router(config-ip-sla)#exit
Router(config)#ip sla schedule 2 life forever start-time now
Router(config)#track 2 ip sla 2 reachability
Router(config)#ip route 0.0.0.0 0.0.0.0 182.1.10.2 track 1
Router(config)#ip route 0.0.0.0 0.0.0.0 200.1.1.2 track 2 100

En este caso nuestras rutas por defecto ahora están asociadas a un track que hace seguimiento de un IP SLA específico, y luego calificadas por distancia administrativa.


21 comentarios:

  1. Hola Oscar, estoy tratando de hacer esto en un 6509 con IOS 12.2(18)SXF16 y no me permite agregar la opcion "track" en una linea ip route. Sabés cual puede ser la sintaxis en esta versión?
    Gracias.-

    ResponderBorrar
    Respuestas
    1. Estimado.
      No debieras tener inconveniente ya que es un feature soportado en IOS 12.2 para Cat 6500.
      Este es el command reference correspondiente: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr-book/iri-cr-a1.html#wp1220876511

      Borrar
    2. Por lo que veo en este documento la opcion track se agrego en la version 12.3(2)XE, puede ser?
      Tampoco tengo el comando "ip sla" ni la opcion de agregar "track" en un route map con set ip next-hop verify-availability [next-hop-address sequence track object] .

      Tengo que hacer esto que debería ser muy simple y no puedo!

      Borrar
    3. Tengo otro 6500 con la 12(2)33.SXJ y ese sí lo tiene...

      Borrar
    4. Evidentemente, la versión de sistema operativo que está implementando el dispositivo no soporta esa opción. La solución es actualizar sistema operativo.

      Borrar
  2. ¡Hola Oscar! he leído varios de tus post y realmente es un buen trabajo, con mucha dedicación, he reforzado conceptos, tus notas me han servido como retroalimentación e incluso me has sacado de aprietos. ¡Muchas gracias!, te felicito.

    ResponderBorrar
  3. Estimado Oscar tengo una consulta, cuento con una topologia similar al del grafico en ve de un router cuento con un switch core cisco 4500x en el se tienen conectados dos routers de dos isp distintos , deseo que ciertas vlans pasen por de uno de los routers isp y el resto de vlans pasen a traves del otro enlace.
    Se puede aplicar SLA para esta solucion? Si fuera asi como podria hacer?
    Se tiene otra alternativa?
    De antemano mil gravias por el apoyo.


    Saludos.


    Edson Acosta

    ResponderBorrar
    Respuestas
    1. Edson.
      Si lo que quieres es que diferentes porciones de la red utilicen diferentes ISPs, la respuesta es PBR, no SLA.
      Se puede aplicar una política que defina el próximo salto en función de la VLAN en la que se origina el tráfico.
      Una nota más: no es buena práctica que utilices un switch de core como router de borde de tu red.

      Borrar
  4. Buen día Oscar, tengo un problema conun router 800 series de cisco, tiene 2 isp, el de trabajo es atravez de un router de cable(HFC), el problema surge cuando el router por cable se va a offline, como el link hacia el router 800 sigue up, entonces no usa la ruta de backup. Apoyandome en tu blog, vi la opción de ip sla, estoy realizando pruebas con otro router 800, declaré una ruta por default condicionada a un track, y como solo tengo una interfaz WAN,es la de trabajo, en la WAN tengo un router de cable, intencionalmente lo mando a offline y me aparece el log de que el track esta en down, pero en la tabla de ruteo, me sigue apareciendo la ruta estática condicionada al track, esto es normal? Al desconectar el cable UTP que va del router de cable al cisco 800, y revisar la tabla de ruteo, ya no me aparece la entrada condicionada al track; mis dudas son las siguientes:
    - Si el estado del link de la interfaz de salida por default nunca se cae, el router va a queren usarla como default, aunque el track este en down? Esto lo pienso porque sigue apareciendo en la tabla de ruteo.
    - Como esta configuración la quiere implementar en el router con 2 interfaces WAN, tengo el temor de que no haga el cambio de ruta mientras el link este en up, aunque el track este en down.
    Gracias de antemano. Saludos.

    ResponderBorrar
  5. Eliezer.
    Si el IP SLA cae, pero la ruta sigue estando presente en la tabla de enrutamiento, hay que revisar algún detalle mal definido en la asociación del SLA a la ruta.
    Si el ejemplo del post no te sirve de referencia suficiente, puedes considerar este ejemplo, un poco más complejo, de la comunidad de soporte: https://supportforums.cisco.com/document/30296/using-ipsla-change-routing

    ResponderBorrar
    Respuestas
    1. Muchas gracias Oscar, voy a revisar la configuración y el ejemplo de la comunidad de soporte y te comento. Saludos.

      Borrar
  6. tengo un problema, actualmente tengo un proveedor y el me entrega dos ip publicas, por alguna razón la segunda ip pierde conexión luego de un tiempo de estar inactiva, pero cuando hago ping al gateway de la segunda ip vuelve a normalizar, la solucion que tenia era implementar sla para que cada 40s hiciera ping, el problema es que el router 1921 que actualmente tengo no soporta sla y solo me indica las siguientes opciones authetification, response y server, que otra alternativa tengo para estar enviando ping desde el router al gateway con una x cantidad de frecuencia

    ResponderBorrar
    Respuestas
    1. Cuando necesitas features que no están disponibles en el momento, lo que tienes que buscar es la versión de IOS que los soporta. Me resulta extraño que aún tratándose de un IOS 15 base no tenga la opción icmp-echo.
      http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipsla/configuration/15-mt/sla-15-mt-book/sla_icmp_echo.html
      Más allá de IP SLA, no conozco otra alternativa a nivel de comando, lo que podrías hacer es correr un script que esté realizando el pint periódicamente.

      Borrar
  7. Bueno, si ponemos la dirección del siguiente salto y esta conexión se cae, la ruta dejará de estar activa. yo recomiendo utilizar un echo de un salto más lejano solo alcanzable por esta conexión.

    ResponderBorrar
    Respuestas
    1. En principio, el estado de la interfaz no depende de la disponibilidad de la IP del próximo salto, en tecnologías como Frame-Relay o MPLS es posible que la interfaz permanezca activa aún cuando el próximo salto no es accesible.
      Pero, por otra parte, si utilizas un próximo salto más lejano la ruta queda condicionada a la presencia de una ruta a esa IP y generaría varias búsquedas recursivas lo que incrementa el uso de procesamiento cada vez que es necesario hacer un lookup de la ruta.

      Borrar
  8. hola Oscar, si tengo 2 router core cada uno en diferente ubicacion no estan en la misma sede. Router 1 un enlace de internert principal y el router
    2 el internet backup, tener encuenta que estos 2 router no cuenta con HSRP porque son diferentes segmento de RED. Se podria aplica el SLA?

    ResponderBorrar
  9. Raúl
    Tu pregunta no puede tener una respuesta precisa.
    Sería necesario conocer la topología y configuración de esos dispositivos para poder hacer una evaluación clara.

    ResponderBorrar
  10. Estimnado, tengo la misma arquitectura armada tal cual esta en el doc, solo que los track se llaman track 100 y 200 , la consula es , cuando fuerzo la caida del la interfaz con el enlace primario.. los host de la lan, no logran navegar hasta que borro maualmente los nat translations del router.. y luego.. cuando vuelvo a levantar la interfaz primaria.. el trafico sigue pasando por la secundaria.. aunque tambien borre los nat translations.. hay manera de indicarle al router que cuando la interfaz primaria esta arriba nuevamente .. el trafico lo envie por dicha interfaz? y tambien me gustaria saber si hay manera de que ante la caida de un enlace la tabla nat se actualice automaticamente. Gracias

    ResponderBorrar
    Respuestas
    1. Martín.
      Tu problema no es de enrutamiento sino de NAT.
      La tabla de traducciones NAT es parte del proceso de reenvío de los paquetes. Lo aconsejable sería que manejes tu redundancia WAN o de Internet en un router de borde y tu NAT en el firewall.

      Borrar

Gracias por tu comentario.
En este blog los comentarios están moderados, por lo que su publicación está pendiente hasta la revisión del mismo.