3 de noviembre de 2013

First Hop Redundancy Protocol - FHRP

Cuando una red LAN tiene más de una puerta de salida (gateway), la implementación de un protocolo de redundancia en el primer salto (First Hop Redundancy Protocol - FHRP) es una de las maneras privilegiadas de administrar esa redundancia.
Estos protocolos posibilitan que los múltiples gateways existentes sean vistos por las terminales de la red como un único default gateway. De esta manera el usuario de un dispositivo terminal no debe hacer nada para sacar provecho de la redundancia de puertas de salida: siempre utiliza el mismo default gateway y su tabla ARP no cambia.
Si bien hay varios protocolos que cubren esta tarea, todos ellos tienen características comunes:

  • Todas las terminales tienen una única configuración de default gateway que no se modifica.
  • Los routers de borde comparten una dirección IP virtual.
  • Las terminales utilizan la dirección IP virtual como default-gateway.
  • Los routers intercambian mensajes del protocolo FHRP para coordinar cuál es el router operativo en cada momento.
  • Cuando el router operativo falla, el protocolo FHRP define cuál es el dispositivo que lo reemplaza en la tarea.

Hay 3 protocolos que desempeñan esta tarea:

HSRP

  • Hot Standby Router Protocol.
  • Propietario de Cisco.
  • Aplica un esquema de redundancia Activo/Standby.
  • No soporta balanceo de carga.
VRRP

  • Virtual Router Redundancy Protocol.
  • definido por la IETF.
  • Aplica un esquema de redundancia Activo/Standby.
  • No soporta balanceo de carga.
GLBP

  • Gateway Load Balancing Protocol.
  • Propietario de Cisco.
  • Aplica un esquema de redundancia Activo/Activo.
  • Soporta balanceo de carga.
Otros posts sobre el tema:


4 comentarios:

  1. Cual de estos tres protocolos recomendarias para una red grande, sin tomar en cuenta la diferencia Activo/Standby y el soporte de balanceo de carga, lo que me interesa principalmente seria una rapida convergenia para evitar perdida de servicios ya que la red practicamente no puede estar en ningun momento sin servicios.

    ResponderEliminar
    Respuestas
    1. Si el elemento crítico s la velocidad de convergencia del sistema, esto no depende principalmente de la elección del protocolo, sino del diseño y la configuración. Hay que tener presente que es posible trabajar los timers al nivel de milisegundos, pero la convergencia dependerá también de la convergencia de STP en la red LAN conectada.

      Eliminar
  2. Tomando en cuenta que cisco en las nuevas practicas tiende a dejar de lado al STP para optar por el ethechannel, el de mejor convergencia seria HSRP?
    conociendo que hello son configurables al igual que los holdtime se podria llegar a los 3 ms de convergencia?

    ResponderEliminar
    Respuestas
    1. Gonzalo.
      En primer lugar, al implementar EtherChannel no se deja de lado STP. STP sigue corriendo sobre el canal con la diferencia que considera al canal como un único enlace. Si hay redundancia de EtherChannel STP se ocupará de administrar esa redundancia.
      En segundo, HSRP no adminsitra redundancia de capa 2, solamente administra redundancia de Default Gateway, y en ese sentido, si hay redundancia de gateway las condiciones siguen siendo las mismas independientemente de que al gateway se llegue por un enlace físico o un EtherChannel.
      Respecto de los temporizadores, reducir excesivamente los tiempos de convergencia no es una buena práctica. La convergencia de gateway debe estar coordinada con la convergencia de los protocolos de enrutamiento hacia la WAN y con la actualización de las tablas CAM hacia la LAN. Tiempos excesivamente bajos pueden provocar inestabilidad cuando por algún motivo tienes un enlace que está "flapeando", haciendo en definitiva inaccesible la red.
      Por otra parte, tiempos de convergencia por debajo de los 100 mseg. son imperceptibles tanto para sesiones TCP como UDP.

      Eliminar

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.