Common Address Redundancy Protocol или CARP — это сетевой протокол , который позволяет нескольким хостам в одной локальной сети совместно использовать набор IP-адресов . Его основная цель — обеспечить отказоустойчивость , особенно при использовании с брандмауэрами и маршрутизаторами . В некоторых конфигурациях CARP также может обеспечивать функциональность балансировки нагрузки . CARP предоставляет функциональность, похожую на Virtual Router Redundancy Protocol (VRRP) и на протокол маршрутизатора горячего резервирования Cisco Systems ( HSRP). Он реализован в нескольких операционных системах на базе BSD и был перенесен в Linux (ucarp). [1]
Если есть один компьютер, на котором запущен пакетный фильтр , и он выходит из строя, сети по обе стороны пакетного фильтра больше не могут взаимодействовать друг с другом или взаимодействуют без какой-либо фильтрации пакетов. Однако если есть два компьютера, на которых запущен пакетный фильтр, работающий по протоколу CARP, то в случае отказа одного из них другой возьмет на себя управление, и компьютеры по обе стороны пакетного фильтра не будут знать об отказе, поэтому работа будет продолжаться в обычном режиме. Чтобы убедиться, что новый активный/основной работает так же, как и старый, используемый пакетный фильтр должен поддерживать синхронизацию состояния между двумя компьютерами.
Группа хостов, использующих CARP, называется «группой избыточности». Группа избыточности выделяет себе IP-адрес, который совместно используется или делится между членами группы. Внутри этой группы хост обозначается как «активный/основной». Остальные члены являются «резервными». Основной хост — это тот, который «занимает» IP-адрес. Он отвечает на любой трафик или ARP-запрос, доведенный до сведения этого адреса. Каждый хост может принадлежать к нескольким группам избыточности. Каждый хост должен иметь второй уникальный IP-адрес.
Распространенным применением CARP является создание группы избыточных брандмауэров. Виртуальный IP-адрес, выделенный группе избыточности, указывается как адрес маршрутизатора по умолчанию на компьютерах за этой группой брандмауэров. Если основной брандмауэр выходит из строя или отключается от сети, виртуальный IP-адрес будет занят одним из подчиненных брандмауэров, и доступность сервиса не будет прервана.
В конце 1990-х годов Internet Engineering Task Force (IETF) начала работу над протоколом для резервирования маршрутизаторов. В 1997 году Cisco сообщила IETF, что у нее есть патенты в этой области, а в 1998 году указала на свой патент на HSRP . [2] Тем не менее, IETF продолжила работу над VRRP . После некоторых дебатов рабочая группа IETF VRRP решила одобрить стандарт, несмотря на его зависимость от запатентованных технологий, при условии, что Cisco сделает патент доступным для третьих лиц на разумных и недискриминационных условиях лицензирования.
Cisco сообщила разработчикам OpenBSD , что будет применять свой патент на HSRP. Позиция Cisco могла быть вызвана их судебным процессом с Alcatel. Поскольку условия лицензирования Cisco не позволяли реализовать VRRP с открытым исходным кодом, разработчики OpenBSD вместо этого начали разрабатывать CARP. OpenBSD фокусируется на безопасности. Они разработали CARP для использования криптографии . Это сделало CARP принципиально отличным от VRRP и гарантировало, что CARP не нарушит патент Cisco. CARP стал доступен в октябре 2003 года. [3] Позднее он был интегрирован в FreeBSD (впервые выпущен в мае 2005 года с FreeBSD 5.4), [4] NetBSD и Linux (ucarp). [1] Хотя патент Cisco в США истек в 2014 году, два несовместимых протокола продолжают сосуществовать.
OpenBSD использует номер протокола VRRP и MAC-адреса. Проект OpenBSD запросил уникальные номера у Internet Assigned Numbers Authority (IANA), но получил отказ.
Для распределения номеров IANA предъявляет несколько требований. В то время они были указаны в RFC 2780. Требования включают участие в совместном, длительном процессе обсуждения в рамках IETF и создание подробной текстовой спецификации протокола. Разработчики OpenBSD не выполнили ни одно из требований [ требуется ссылка ] . На сайте OpenBSD указано следующее: [5]
В качестве последнего замечания, конечно, когда мы обратились в IANA, орган IETF, регулирующий [sic] «официальные» номера интернет-протоколов, с просьбой предоставить нам номера для CARP и pfsync , наша просьба была отклонена. По-видимому, мы не смогли обратиться в официальную организацию по стандартизации. Следовательно, мы были вынуждены выбрать номер протокола, который не будет конфликтовать ни с чем другим, представляющим ценность, и решили поместить CARP в IP-протокол 112. Мы также поместили pfsync в открытый и неиспользуемый номер. Мы сообщили IANA об этих решениях, но они отказались отвечать.
IANA присвоила протоколу VRRP номер 112 (в 1998 году через RFC 2338). [6] Протокол с номером 112 по-прежнему используется VRRP.
CARP также использует диапазон MAC-адресов Ethernet , которые IEEE назначил IANA/IETF для протокола VRRP. [7]
Несмотря на совпадение, по-прежнему возможно использование VRRP и CARP в одном и том же широковещательном домене , при условии, что идентификатор группы VRRP и идентификатор виртуального хоста CARP различаются.