Protocol CARP: Difference between revisions

From Nasqueron Agora
Yousra (talk | contribs)
No edit summary
Yousra (talk | contribs)
No edit summary
Line 8: Line 8:
== Master host and backup hosts ==
== Master host and backup hosts ==


CARP creates a redundancy group, meaning several hosts are configured to share a set of IP address. However, at any given time, only one host uses the shared IP address. This host is called the master host.  
CARP creates a redundancy group, meaning several hosts are configured to share a virtual IP address. However, at any given time, only one host uses the shared IP address. This host is called the master host and it receives and handles all traffic destined to that virtual IP.


When the master host becomes unavailable (it crashed, turned off, or lost its network connection), the other hosts in the same redundancy group detect the failure. Immediately, one of the backup hosts is elected as the new master host. That means that it will take over the shared IP address.
When the master host becomes unavailable (it crashed, turned off, or lost its network connection), the other hosts in the same redundancy group detect the failure. Immediately, one of the backup hosts is elected as the new master host. That means that it will take over the shared IP address.
Line 14: Line 14:
This switch happens automatically, ensuring service continuity without clients noticing any interruption.
This switch happens automatically, ensuring service continuity without clients noticing any interruption.


[[File:Schema_redondance_routers.png]]
[[File:Schema redondance routeurs.png]]


(petite image ici : https://wxcafe.net/posts/redondance-routeurs-openbsd-freebsd/)
== CARP advertisements ==


== Advertisement packets ==
- The master host periodically broadcasts CARP advertisements to the backup hosts.


- The master node periodically sends advertisement packets.
- Backup hosts listen but do not send any packets.


- Standby nodes listen but do not send advertisements.


 
'''Each CARP advertisement contains''':
'''Each advertisement packet contains''':


1. The VHID (Virtual Host ID), which identifies the redundancy group.
1. The VHID (Virtual Host ID), which identifies the redundancy group.


2. The CARP version and packet type.
2. The CARP version and packet type.
3. The advertisement parameters (advbase and advskew), which determine the host’s priority.
'''All CARP advertisements are cryptographically signed :'''
Steps :
1. The master host creates an advertisement.
2. It calculates a cryptographic signature using:
      - the shared secret,
      - the VHID,
      - the virtual IP addresses,
      - the advertisement parameters (advbase and advskew),
      - and other header fields.
3. It then sends the signed advertisement.
4. The backup hosts receives the signed advertisement.
5. Each backup host recalculates the signature using the same shared secret :
- If the calculated signature matches the received signature → the packet is considered valid.
- If it does not match → the packet is rejected.
It protects against spoofing attacks : without cryptographic authentication, an attacker could send fake CARP advertisements and attempt to become the master host.
Also, all hosts must have the same set of virtual IP addresses configured in order to calculate the signature (because the IP addresses are not send), but only one host actually uses these IP addresses at any given time.
== Multiple VHID ==
Using multiple VHIDs in CARP allows several virtual IP addresses to be managed separately. This means different hosts can be master for different services. For example, one host can manage the web service, while another manages the DNS service. Thanks to this, the hosts can be used efficiently while still ensuring high availability. It would not be practical to use a machine only when the other machine is not responding.
== Split-brain ==
Normally:
- master
- backups
If the master host stops sending advertisements, the backup nodes know that the master is no longer reachable. However, a problem can occur if the backup nodes stop receiving each other's advertisements because the link between them is broken. In that case, each node may assume it is the master.
When communication is restored, CARP resolves the problem:
1. The masters can see each other
2. They receive advertisements from each other
3. They compare priority
4. The hosts with lower priority automatically switche back to backup
== Master Election Process ==
1. All hosts start
  - All hosts begin in BACKUP state.
2. Each host starts a timer
  - The delay depends on the priority (advskew).
  - The lower the advskew, the shorter the delay.
  - The lower the advskew, the higher the priority.
3. The higher-priority host’s timer expires first
  - That host sends CARP advertisements when the timer expires.
  - It assigns the virtual IP (VIP) to its interface.
  - It becomes the MASTER host.
4. The other hosts receive the advertisement
  - They detect that a higher-priority host is active.
  - They remain in BACKUP state.
  - They do not send CARP advertisements.
In CARP, we usually choose the preferred master by giving it a higher priority (lower advskew). If the master fails and two backup hosts have the same priority, they may both try to become master at the same time. This can temporarily create a split-brain situation, where both hosts start sending CARP advertisements. However, they will quickly detect each other’s advertisements. Because of small timing differences in the network, one host will effectively win and remain master, while the other will switch stay in backup mode. To avoid this situation, it is recommended to configure different priorities for each host.
== Configuration ==




'''All advertisement packets are cryptographically signed, meaning:'''


1. All nodes in the redundancy group must share the same secret.


2. The password is never sent in plaintext.




'''In practice''' :


a. The MASTER sends an advertisement packet.


b. It calculates a signature (HMAC) using:


      1. the VHID, packet information and the shared secret.


      2. The BACKUPs receive the packet.


      3. They recalculate the signature using their copy of the                  secret.


      4. If it matches → valid packet.
        If it doesn't match → rejected packet.




If the backup nodes stop receiving CARP advertisement packets for a certain period of time, they assume that the master node has failed. One of the backup nodes then promotes itself to become the new active node and starts sending CARP advertisements. If the original active node later comes back online, it detects that another node is already acting as MASTER and remains in the passive (BACKUP) state.




https://freebsdfoundation.org/wp-content/uploads/2022/11/zaborski_CARP.pdf
https://freebsdfoundation.org/wp-content/uploads/2022/11/zaborski_CARP.pdf


All nodes must be configured with exactly the same set of shared IP addresses, since these are used to calculate the cryptographic signature.


As long as the active node continues sending correctly signed advertisements with the correct VHID, the standby nodes remain passive and do nothing
 
 
 
 
 
Source :
 
https://wxcafe.net/posts/redondance-routeurs-openbsd-freebsd/
https://freebsdfoundation.org/wp-content/uploads/2022/11/zaborski_CARP.pdf

Revision as of 21:13, 14 February 2026

Introduction

CARP stands for Common Address Redundancy Protocol and its basic functionality is to allow multiple hosts to share a set of IP addresses

CARP was first introduced in 2003 in OpenBSD as an alternative to Cisco’s VRRP protocol. It was created to avoid patent issues related to VRRP. Later, CARP was added to FreeBSD and NetBSD. A userland implementation of CARP protocol called ucarp was also developed, which allowed CARP to be used on Linux systems.

Master host and backup hosts

CARP creates a redundancy group, meaning several hosts are configured to share a virtual IP address. However, at any given time, only one host uses the shared IP address. This host is called the master host and it receives and handles all traffic destined to that virtual IP.

When the master host becomes unavailable (it crashed, turned off, or lost its network connection), the other hosts in the same redundancy group detect the failure. Immediately, one of the backup hosts is elected as the new master host. That means that it will take over the shared IP address.

This switch happens automatically, ensuring service continuity without clients noticing any interruption.

CARP advertisements

- The master host periodically broadcasts CARP advertisements to the backup hosts.

- Backup hosts listen but do not send any packets.


Each CARP advertisement contains:

1. The VHID (Virtual Host ID), which identifies the redundancy group.

2. The CARP version and packet type.

3. The advertisement parameters (advbase and advskew), which determine the host’s priority.


All CARP advertisements are cryptographically signed :

Steps :

1. The master host creates an advertisement.

2. It calculates a cryptographic signature using:

     - the shared secret,
     - the VHID,
     - the virtual IP addresses,
     - the advertisement parameters (advbase and advskew),
     - and other header fields.

3. It then sends the signed advertisement.

4. The backup hosts receives the signed advertisement.

5. Each backup host recalculates the signature using the same shared secret :

- If the calculated signature matches the received signature → the packet is considered valid.
- If it does not match → the packet is rejected.


It protects against spoofing attacks : without cryptographic authentication, an attacker could send fake CARP advertisements and attempt to become the master host.

Also, all hosts must have the same set of virtual IP addresses configured in order to calculate the signature (because the IP addresses are not send), but only one host actually uses these IP addresses at any given time.

Multiple VHID

Using multiple VHIDs in CARP allows several virtual IP addresses to be managed separately. This means different hosts can be master for different services. For example, one host can manage the web service, while another manages the DNS service. Thanks to this, the hosts can be used efficiently while still ensuring high availability. It would not be practical to use a machine only when the other machine is not responding.

Split-brain

Normally:

- master
- backups

If the master host stops sending advertisements, the backup nodes know that the master is no longer reachable. However, a problem can occur if the backup nodes stop receiving each other's advertisements because the link between them is broken. In that case, each node may assume it is the master.

When communication is restored, CARP resolves the problem:

1. The masters can see each other
2. They receive advertisements from each other
3. They compare priority
4. The hosts with lower priority automatically switche back to backup

Master Election Process

1. All hosts start

  - All hosts begin in BACKUP state.

2. Each host starts a timer

  - The delay depends on the priority (advskew).
  - The lower the advskew, the shorter the delay.
  - The lower the advskew, the higher the priority.

3. The higher-priority host’s timer expires first

  - That host sends CARP advertisements when the timer expires.
  - It assigns the virtual IP (VIP) to its interface.
  - It becomes the MASTER host.

4. The other hosts receive the advertisement

  - They detect that a higher-priority host is active.
  - They remain in BACKUP state.
  - They do not send CARP advertisements.


In CARP, we usually choose the preferred master by giving it a higher priority (lower advskew). If the master fails and two backup hosts have the same priority, they may both try to become master at the same time. This can temporarily create a split-brain situation, where both hosts start sending CARP advertisements. However, they will quickly detect each other’s advertisements. Because of small timing differences in the network, one host will effectively win and remain master, while the other will switch stay in backup mode. To avoid this situation, it is recommended to configure different priorities for each host.

Configuration

https://freebsdfoundation.org/wp-content/uploads/2022/11/zaborski_CARP.pdf




Source :

https://wxcafe.net/posts/redondance-routeurs-openbsd-freebsd/ https://freebsdfoundation.org/wp-content/uploads/2022/11/zaborski_CARP.pdf