Gratuitous ARP

일반 ARP의 경우 Request를 전송하고 Response를 기다리는 방식이지만

GARP는 Response가 없다.

GARP가 사용되는 사례는 아래와 같다.

• 1. IP 설정시 동일한 네트워크에 중복된 IP가 있는지 검사할 때
• 이중화 절체시 인근 스위치 및 host 들이 경로를 절체시킬 수 있도록 자신의 MAC 주소를 알려줄 때

첫 번째 예시

첫 번째 예시를 살펴보자.

테스트 환경의 경우 윈도우에서 IP를 설정하던, 라우터 장비에서 인터페이스에 IP를 설정하던 동일하다.

IP를 입력하는 순간 동일한 IP를 사용하는지 확인하기 위해 GARP가 Broadcast로 전송된다.

위 그림은 라우터 인터페이스의 IP를 1.1.12.1로 지정한 후

no shut으로 인터페이스를 활성화한 직후 발생한 GARP의 패킷을 와이어샤크로 떠본 것이다.

패킷을 보면 Sender IP와 Target IP가 동일한 것을 볼 수 있는데

이는 동일 네트워크에 있는 모든 노드들이 이 패킷을 수신하여 자신의 IP와 비교 후 다르다면 무시하고, 동일하다면 GARP를 Broadcast하여 중복되었음을 알려준다.

아래 그림의 경우 중복된 IP가 동일 네트워크에 존재할 때 발생한 GARP 패킷이다.

그리고 라우터 장비에서는 아마 아래와 같이 Duplicate address 로그가 계속해서 뜰 것이다.

여기서 주의깊게 봐야할 점은 IP가 중복되어 발생하는 GARP도 Broadcast 방식 이라는 점이다.

만약 Host A가 1.1.1.1 이라는 IP를 기존에 사용하고 있다고 가정해보자.

여기서 Host B가 IP를 1.1.1.1로 설정한다면 Host B에서 먼저 중복된 IP를 검색하는 GARP를 Broadcast로 전송하고 Host A에서는 중복이 발생했다는 의미로 GARP를 다시 Broadcast로 전송한다.

그렇다면 두 번째 발생하는 GARP의 경우 Unicast를 사용하는 것이 아닌 Broadcast를 사용하는 이유는 무엇일까?

이는 동일 네트워크 상의 다른 모든 노드들의 ARP 테이블을 정상적으로 다시 Refresh 시켜주기 위함이다.

처음 Host B에서 Host A로 GARP를 Broadcast하면 이를 수신한 모든 노드들은 자신의 ARP 테이블을 Host B의 Mac 주소로 등록시켜 버린다.

이런 문제점을 보완하기 위해 IP 중복이 발생한 경우에도 GARP는 Broadcast로 모든 노드들에게 전송시켜주는 것이다.

두 번째 예시

이번에는 두 번째 예시를 살펴보자.

아래 그림과 같이 VRRP나 HSRP와 같이 L3 장비가 이중화 되어있는 구성에서

평상시 R1이 Active, R2가 Standby로 동작할 때

스위치의 MAC 테이블을 확인해보면 목적지 0000.0c07.ac01에 대해서는 F0/1로 포워딩하도록 지정되어 있을 것이다.

이후 R1에서 R2로 Active가 절체되는 순간 R2는 GARP를 Broadcast 한다.

GARP를 수신한 스위치에서는 목적지 0000.0c07.ac01 주소에 대한 포워딩 인터페이스를 F0/1에서 F0/2로 변경하게 되는 것이다.

아래의 사진은 Active 절체시 R2에서 발생한 GARP 패킷을 캡쳐한 것이다.

마무리

참고로 이중화 절체시 발생하는 GARP는 꼭 네트워크 장비에서만 발생하는 것은 아니다.

서버 장비에서도 OS 설정에 따라 발생 할 수도 있다.

관련 예시로 이중화로 동작 중인 SUN 서버에서 이중화 절체시 IP가 중복되는 문제점을

서버 절체시 GARP를 전송하도록 OS 커널단에서 수정하여 해당 문제를 해결할 수 있었다고 한다.