CARP (англ. Common Address Redundancy Protocol) — це протокол комп’ютерної мережі, який дозволяє кільком хостам в одній локальній мережі спільно використовувати набір IP-адрес. Його основне призначення — забезпечити резервування при збоях, особливо при використанні з брандмауерами та маршрутизаторами. У деяких конфігураціях CARP також може забезпечити балансування навантаження. CARP забезпечує функції, подібні до протоколу резервування віртуального маршрутизатора (VRRP) і протоколу гарячого резервування маршрутизатора (HSRP) Cisco Systems. Він реалізований у кількох операційних системах на основі BSD і був перенесений на Linux (ucarp).
Якщо на одному комп’ютері працює фільтр пакетів, і він виходить з ладу, мережі з обох боків фільтра пакетів більше не можуть спілкуватися одна з одною, або вони спілкуються без фільтрації пакетів. Проте, якщо є два комп’ютери, на яких працює пакетний фільтр, який запускає CARP, тоді, якщо один з них виходить з ладу, інший візьме на себе роботу, і комп’ютери з обох боків пакетного фільтра не будуть знати про збій, тому робота продовжуватиметься у звичайному режимі. . Щоб переконатися, що новий активний/основний працює так само, як і старий, фільтр пакетів, який використовується, має підтримувати синхронізацію стану між двома комп’ютерами.
Група хостів, що використовують CARP, називається «групою надлишковості». Група резервування призначає собі IP-адресу, яка спільно або розділено між членами групи. У цій групі хост позначається як «активний/основний». Інші учасники знаходяться в режимі очікування. Головний хост - це той, який "бере" IP-адресу. Він відповідає на будь-який трафік або запит ARP, надісланий на цю адресу. Кожен хост може належати до кількох груп резервування. Кожен хост повинен мати другу унікальну IP-адресу.
Загальним використанням CARP є створення групи резервних брандмауерів. Віртуальна IP-адреса, призначена групі резервування, вказується як адреса маршрутизатора за замовчуванням на комп’ютерах за цією групою брандмауерів. Якщо основний брандмауер вийде з ладу або його буде від’єднано від мережі, віртуальну IP-адресу буде прийнято одним із підлеглих брандмауерів, і доступність служби не буде перервано.
Наприкінці 1990-х Інженерна робоча група Інтернету (IETF) почала роботу над протоколом для резервування маршрутизатора. У 1997 році Cisco повідомила IETF, що має патенти в цій галузі, а в 1998 році вказала на свій патент на HSRP. Незважаючи на це, IETF продовжив роботу над VRRP. Після деяких дебатів робоча група IETF VRRP вирішила схвалити стандарт, незважаючи на його залежність від запатентованих методів, за умови, що Cisco надасть патент третім сторонам на розумних і недискримінаційних умовах ліцензування. Оскільки VRRP вирішив проблеми з протоколом HSRP, Cisco почала використовувати замість нього VRRP, водночас вважаючи його власним.
Cisco повідомила розробникам OpenBSD, що вона буде застосовувати свій патент на HSRP. Позиція Cisco могла бути пов'язана з їх позовом з Alcatel. Оскільки ліцензійні умови Cisco перешкоджали реалізації VRRP з відкритим кодом, розробники OpenBSD замість цього почали розробляти CARP. OpenBSD зосереджується на безпеці. Вони розробили CARP для використання криптографії. Це суттєво відрізняло CARP від VRRP і гарантувало, що CARP не порушує патент Cisco. CARP став доступним у жовтні 2003 року. Пізніше він був інтегрований у FreeBSD (вперше випущений у травні 2005 року з FreeBSD 5.4), NetBSD і Linux (ucarp). Хоча термін дії патенту Cisco в США закінчився в 2014 році, два несумісних протоколи продовжують співіснувати.
OpenBSD використовує номер протоколу та MAC-адреси VRRP. Проект OpenBSD запитував унікальні номери від Управління присвоєння номерів в Інтернеті (IANA), але отримав відмову.
Для розподілу номерів IANA має кілька вимог. У той час вони були визначені в RFC 2780. Вимоги включають участь у тривалому спільному процесі обговорення в рамках IETF і створення детальної текстової специфікації протоколу. Розробники OpenBSD не виконали жодної вимоги. На веб-сайті OpenBSD зазначено наступне:
Наостанок, звичайно, коли ми звернулися до IANA, органу IETF, який регулює [sic] «офіційні» номери інтернет-протоколів, щоб надати нам номери для CARP і pfsync, наш запит було відхилено. Очевидно, ми не змогли пройти через офіційну організацію стандартів. Отже, ми були змушені вибрати номер протоколу, який не конфліктував би з чимось іншим цінним, і вирішили розмістити CARP на IP-протоколі 112. Ми також розмістили pfsync на відкритому та невикористаному номері. Ми повідомили IANA про ці рішення, але вони відмовилися відповідати.
IANA присвоїла VRRP номер протоколу 112 (у 1998 році через RFC 2338). Протокол № 112 залишається у використанні ВРРП.
CARP також використовує діапазон MAC-адрес Ethernet, які IEEE призначив IANA/IETF для протоколу VRRP.
Незважаючи на перекриття, все ще можна використовувати VRRP і CARP в одному широкомовному домені, якщо ідентифікатор групи VRRP і ідентифікатор віртуального хоста CARP відрізняються.