Protocolo de redundancia de direcciones comunes

El Protocolo de Redundancia de Direcciones Comunes ( CARP) es un protocolo de red informática que permite que varios hosts en la misma red de área local compartan un conjunto de direcciones IP . Su propósito principal es proporcionar redundancia de conmutación por error , especialmente cuando se utiliza con firewalls y enrutadores . En algunas configuraciones, CARP también puede proporcionar funcionalidad de equilibrio de carga . CARP ofrece una funcionalidad similar al Protocolo de Redundancia de Enrutador Virtual (VRRP) y al Protocolo de Enrutador de Reserva Activa (HSRP) de Cisco Systems . Está implementado en varios sistemas operativos basados ​​en BSD y se ha portado a Linux (ucarp). ^{[ 1 ]}

Si un único ordenador ejecuta un filtro de paquetes y este falla, las redes a ambos lados del filtro dejan de comunicarse entre sí o se comunican sin ningún filtrado. Sin embargo, si dos ordenadores ejecutan un filtro de paquetes con CARP, si uno falla, el otro tomará el control y los ordenadores a ambos lados del filtro no se darán cuenta del fallo, por lo que el funcionamiento continuará con normalidad. Para garantizar que el nuevo maestro funcione igual que el anterior, el filtro de paquetes utilizado debe admitir la sincronización de estado entre ambos ordenadores.

Un grupo de hosts que utiliza CARP se denomina "grupo de redundancia". Este grupo se asigna una dirección IP que se comparte o divide entre sus miembros. Dentro del grupo, un host se designa como "maestro". Los demás miembros son "de respaldo". El host principal es el que "toma" la dirección IP y responde a cualquier tráfico o solicitud ARP que se le presente. Cada host puede pertenecer a varios grupos de redundancia y debe tener una segunda dirección IP única.

Un uso común de CARP es la creación de un grupo de firewalls redundantes. La dirección IP virtual asignada al grupo de redundancia se indica como la dirección del enrutador predeterminado en los equipos ubicados detrás de este grupo de firewalls. Si el firewall principal falla o se desconecta de la red, la dirección IP virtual será asumida por uno de los firewalls secundarios y la disponibilidad del servicio no se verá interrumpida.

A finales de la década de 1990, el Grupo de Trabajo de Ingeniería de Internet (IETF) comenzó a trabajar en un protocolo para la redundancia de enrutadores. En 1997, Cisco informó al IETF que poseía patentes en este ámbito y, en 1998, señaló su patente sobre HSRP . ^{[ 2 ]} No obstante, el IETF continuó trabajando en VRRP . Tras cierto debate, el grupo de trabajo VRRP del IETF decidió aprobar el estándar, a pesar de su dependencia de técnicas patentadas, siempre y cuando Cisco pusiera la patente a disposición de terceros bajo términos de licencia razonables y no discriminatorios .

Cisco informó a los desarrolladores de OpenBSD que haría valer su patente sobre HSRP. La postura de Cisco pudo deberse a su demanda con Alcatel. Como los términos de la licencia de Cisco impedían una implementación de VRRP de código abierto, los desarrolladores de OpenBSD comenzaron a desarrollar CARP en su lugar. OpenBSD se centra en la seguridad. Diseñaron CARP para usar criptografía . Esto hizo que CARP fuera fundamentalmente diferente de VRRP y aseguró que CARP no infringiera la patente de Cisco. CARP estuvo disponible en octubre de 2003. ^{[ 3 ]} Posteriormente, se integró en FreeBSD (lanzado por primera vez en mayo de 2005 con FreeBSD 5.4), ^{[ 4 ]} NetBSD y Linux (ucarp). ^{[ 1 ]} Si bien la patente estadounidense de Cisco expiró en 2014, los dos protocolos incompatibles continúan coexistiendo.

OpenBSD utiliza el número de protocolo y las direcciones MAC de VRRP. El proyecto OpenBSD solicitó números únicos a la Autoridad de Números Asignados de Internet (IANA), pero su solicitud fue denegada.

Para asignar números, IANA tiene varios requisitos. En ese momento, estos se especificaron en el RFC 2780. Los requisitos incluyen participar en un proceso de discusión colaborativo y extenso dentro del IETF y producir una especificación textual detallada del protocolo. Los desarrolladores de OpenBSD no cumplieron con ninguno de los dos requisitos. El sitio web de OpenBSD afirma lo siguiente: ^{[ 5 ]}

Para finalizar, cabe mencionar que, cuando solicitamos a IANA, el organismo del IETF que regula los números de protocolo de internet "oficiales", que nos asignara números para CARP y pfsync , nuestra solicitud fue denegada. Al parecer, no habíamos tramitado el protocolo a través de una organización de estándares oficial. En consecuencia, nos vimos obligados a elegir un número de protocolo que no entrara en conflicto con ningún otro protocolo de valor, y decidimos asignar a CARP el número 112. También asignamos a pfsync un número libre y sin usar. Informamos a IANA de estas decisiones, pero se negaron a responder.

IANA asignó el protocolo número 112 a VRRP (en 1998, a través de RFC 2338). ^{[ 6 ]} VRRP sigue utilizando el protocolo número 112.

CARP también utiliza un rango de direcciones MAC Ethernet que IEEE había asignado a IANA/IETF para el protocolo VRRP. ^{[ 7 ]}

A pesar de la superposición, todavía es posible usar VRRP y CARP en el mismo dominio de difusión , siempre que el ID de grupo de VRRP y el ID de host virtual de CARP sean diferentes.

• Protocolo de equilibrio de carga de puerta de enlace (GLBP)
• HSRP
• pfsync
• VRRP
• Multipathing de red IP (IPMP)

• carp(4) – Manual de interfaces del kernel de OpenBSD 
• carp(4) – Manual de interfaces del kernel de FreeBSD 
• UCARP: implementación de CARP en el espacio de usuario
• Versión de CARP para NetBSD
• La canción 3.5 de OpenBSD: "Licencia CARP" y "La redundancia debe ser gratuita".