스위치와 ARP

앞 글에서 이더넷 프레임이 MAC 주소로 전달된다는 것을 보았습니다. 그런데 LAN에는 수십, 수백 대의 장치가 연결되어 있으므로, 누군가는 어느 MAC 주소가 어느 포트에 있는지 알고 있어야 하고, 보내는 쪽은 상대의 IP 주소로 MAC 주소를 알아내야 합니다. 앞의 일은 스위치(switch)가, 뒤의 일은 ARP(address resolution protocol)가 합니다. 둘은 서로 다른 문제를 풉니다. 스위치는 이미 만들어진 프레임을 어느 포트로 내보낼지 정하고, ARP는 프레임을 만들기 전에 다음 홉의 MAC 주소를 알아냅니다.

허브와 스위치

허브는 물리 계층의 장비로, 받은 신호를 들어온 포트를 뺀 모든 포트로 그대로 되풀이합니다. MAC 주소를 보지 않으므로 모든 장치가 남의 프레임까지 받고, 대역폭도 모두가 나누어 씁니다. 스위치는 데이터 링크 계층의 장비로, 프레임의 MAC 주소를 보고 필요한 포트로만 보냅니다. 포트마다 따로 링크가 있고 전이중으로 동작하므로 충돌도 없습니다.

스위치는 출발지 주소로 배운다

스위치는 어느 MAC 주소가 어느 포트에 있는지를 MAC 주소 표(CAM 테이블)에 기록합니다. 실제 장비는 VLAN까지 함께 묶어 (VLAN, MAC 주소)를 포트에 대응시킵니다. 이 표는 관리자가 채우지 않아도 저절로 채워지는데, 스위치는 프레임이 들어올 때마다 그 프레임의 출발지 MAC 주소와 들어온 포트를 기록하기 때문입니다. 목적지 MAC 주소는 표를 찾는 데 쓰일 뿐, 배우는 데는 쓰이지 않습니다.

프레임을 받은 스위치는 목적지 MAC 주소를 표에서 찾습니다. 표에 있으면 그 포트로만 보내는 포워딩(forwarding)을 하고, 표에 없거나 브로드캐스트이면 같은 VLAN에서 들어온 포트를 뺀 모든 포트로 보내는 플러딩(flooding)을 합니다. 목적지가 들어온 포트 쪽에 있으면 아무 데도 보내지 않으며(필터링), 오랫동안 프레임이 오지 않은 항목은 정해진 시간이 지나면 지웁니다(에이징). 에이징 시간은 장비마다 다른데, 300초가 흔한 기본값입니다.

ARP: IP 주소로 MAC 주소 찾기

같은 IPv4 서브넷, 같은 VLAN에 있는 컴퓨터 A가 B에게 처음 데이터를 보내려 합니다. A는 B의 IP 주소는 알지만 MAC 주소는 모릅니다.

A는 "192.168.1.20을 쓰는 장치는 MAC 주소를 알려 달라"는 ARP 요청을 브로드캐스트로 보내고, 같은 VLAN의 모든 장치가 이를 받습니다. 그 IP 주소의 주인인 B만 자기 MAC 주소를 담은 ARP 응답을 A에게 유니캐스트로 보내고, A는 IP 주소와 MAC 주소의 짝을 ARP 캐시에 저장한 뒤 데이터를 보냅니다. 이 절차는 RFC 826에 정해져 있습니다. 다음 코드는 이 교환이 일어나는 동안 스위치의 표와 A의 ARP 캐시가 어떻게 채워지는지 함께 따라갑니다.

BROADCAST = "ff:ff:ff:ff:ff:ff"

class Switch:
    def __init__(self, ports):
        self.ports, self.table = ports, {}               # MAC 주소 표: (VLAN, MAC) -> 포트

    def receive(self, in_port, src, dst, vlan=10):
        self.table[(vlan, src)] = in_port                # 출발지 주소로 위치를 배운다
        if dst != BROADCAST and (vlan, dst) in self.table:
            return [self.table[(vlan, dst)]]             # 아는 목적지: 그 포트로만
        return [p for p in self.ports if p != in_port]   # 브로드캐스트나 모르는 목적지: 나머지 모두로

sw = Switch(ports=[1, 2, 3])                             # 포트 1에 A, 2에 B, 3에 C가 연결되어 있다
arp_cache_of_A = {}

steps = [
    ("A의 ARP 요청(B의 MAC은?)", 1, "MAC-A", BROADCAST),
    ("B의 ARP 응답", 2, "MAC-B", "MAC-A"),
    ("A가 B에게 보내는 데이터", 1, "MAC-A", "MAC-B"),
]
for name, port, src, dst in steps:
    out = sw.receive(port, src, dst)
    if name == "B의 ARP 응답":
        arp_cache_of_A["192.168.1.20"] = "MAC-B"        # A는 응답으로 IP와 MAC의 짝을 배운다
    learned = {mac: p for (vlan, mac), p in sw.table.items()}
    print(f"{name}: 포트 {port} -> 포트 {out}, 스위치의 표 {learned}")
print("A의 ARP 캐시:", arp_cache_of_A)

A의 ARP 요청(B의 MAC은?): 포트 1 -> 포트 [2, 3], 스위치의 표 {'MAC-A': 1}
B의 ARP 응답: 포트 2 -> 포트 [1], 스위치의 표 {'MAC-A': 1, 'MAC-B': 2}
A가 B에게 보내는 데이터: 포트 1 -> 포트 [2], 스위치의 표 {'MAC-A': 1, 'MAC-B': 2}
A의 ARP 캐시: {'192.168.1.20': 'MAC-B'}

브로드캐스트인 ARP 요청은 B와 C 모두에게 퍼졌고, 스위치는 그 출발지로 A가 포트 1에 있다는 것을 배웠습니다. B의 응답이 들어오자 스위치는 B가 포트 2에 있다는 것도 배웠고, 목적지 A의 위치를 이미 알기에 포트 1로만 보냈습니다. 같은 교환으로 A의 ARP 캐시에는 IP와 MAC의 짝이, 스위치의 표에는 MAC과 포트의 짝이 채워지지만, 두 표는 서로 다른 장비에 있고 쓰임도 다릅니다. C는 요청을 받았지만 자기 IP 주소를 묻는 것이 아니므로 대답하지 않습니다.

다른 네트워크로 보낼 때

목적지가 다른 네트워크에 있으면 ARP로 최종 목적지의 MAC 주소를 찾지 않습니다. 같은 링크에 있지 않은 상대의 MAC 주소는 알아도 쓸 데가 없기 때문입니다. 대신 라우팅 표에서 그 목적지로 가는 다음 홉, 대개는 기본 게이트웨이를 고르고, ARP로 그 게이트웨이의 MAC 주소를 알아내 프레임의 목적지로 씁니다. ARP 캐시는 한동안 유지되므로, 같은 상대에게 계속 보낼 때는 요청을 되풀이하지 않습니다.

ip neigh show                    # ARP 캐시: IP, 장치, MAC 주소, 상태
sudo arping -c 3 192.168.1.1     # 이 IP에 ARP 요청을 직접 보내 응답을 확인(패킷을 보낸다)
sudo ip neigh flush dev eth0     # 이 인터페이스의 ARP 캐시 비우기(실습용)

ip neigh가 보여 주는 상태 가운데 REACHABLE은 최근에 상대가 응답해 확인된 항목, STALE은 확인한 지 시간이 지나 다음에 쓸 때 다시 확인할 항목, FAILED는 물어도 응답이 없던 항목입니다. 장애를 진단할 때 게이트웨이가 FAILED라면, IP 설정보다 먼저 같은 링크에서 게이트웨이에 닿는지부터 확인해야 합니다.

묻지 않았는데 보내는 ARP

Gratuitous ARP는 아무도 묻지 않았는데 자기 IP 주소와 MAC 주소의 짝을 알리는 ARP입니다. RFC 5227은 이것을 ARP Announcement라고 부르고, 주소를 쓰기 전에 그 주소를 쓰는 다른 장치가 있는지 확인하는 ARP Probe와 구분합니다. ARP Probe는 출발지 IP 주소 칸을 0으로 채운 요청이라 짝을 알리지 않고 IP 주소의 충돌만 찾아냅니다. ARP Announcement는 네트워크 카드를 바꾸었거나 가상 IP가 다른 서버로 옮겨 갔을 때 다른 장치들의 ARP 캐시를 한꺼번에 갱신합니다.

두 라우터가 하나의 가상 IP를 나누어 맡는 VRRP에서도, 맡은 라우터가 바뀌면 새 라우터가 Gratuitous ARP를 보냅니다. RFC 9568에 따르면 이때 가상 IP에 붙은 가상 MAC 주소는 그대로이고, 스위치가 그 MAC 주소가 이제 새 라우터 쪽 포트에 있다는 것을 배우는 것이 핵심입니다.

더 깊이: Linux의 ARP 캐시는 얼마나 오래, 얼마나 많이 기억하나

Linux는 ARP 캐시의 동작을 /proc/sys/net/ipv4/neigh/ 아래의 값으로 조절합니다. arp(7)에 따르면 상대를 확인한 항목은 base_reachable_time_ms(기본 30000ms)의 절반에서 1.5배 사이의 무작위 시간 동안 유효합니다. 이 시간 안에 TCP의 확인 응답처럼 위 계층이 상대가 살아 있다는 신호를 주면 유효 기간이 늘어나므로, 활발히 통신하는 상대에게는 ARP를 다시 묻지 않습니다.

유효 기간이 지난 항목은 오래된(stale) 상태가 될 뿐 바로 지워지지 않습니다. 그 상대에게 보낼 데이터가 생기면 delay_first_probe_time(기본 5초)만큼 기다린 뒤, 알고 있던 MAC 주소로 유니캐스트 확인을 ucast_solicit(기본 3)번까지 보냅니다. ip neigh의 STALE 항목이 지워지지 않고 그대로 쓰이는 이유가 이것이며, 확인 요청은 보낼 데이터가 있을 때만 나갑니다. 커널 문서에 따르면 유니캐스트 확인에 이어 보내는 브로드캐스트 확인의 수 mcast_resolicit는 기본값이 0이어서, 유니캐스트 확인에도 답이 없으면 그 항목은 확인에 실패한 것으로 끝납니다.

캐시의 크기에도 한도가 있습니다. 항목이 gc_thresh1(기본 128)보다 적으면 정리하지 않고, gc_thresh2(기본 512)를 넘은 상태가 5초 넘게 이어지면 정리를 시작하며, gc_thresh3(기본 1024)는 강제 상한입니다. 그래서 같은 링크의 수많은 VM이나 컨테이너와 통신하는 호스트라면 이 값부터 확인해야 합니다.

루프를 막는 STP

스위치 하나가 고장 나도 네트워크가 멈추지 않도록 스위치끼리 여러 경로로 연결하면, 이번에는 루프가 생깁니다. 이더넷 프레임에는 IP의 TTL 같은 수명이 없어서, 브로드캐스트 프레임 하나가 고리를 따라 끝없이 돌며 스위치마다 복제되는 브로드캐스트 폭풍(broadcast storm)이 일어나 몇 초 만에 네트워크가 마비됩니다.

STP(spanning tree protocol) 계열의 프로토콜은 스위치끼리 BPDU라는 메시지를 주고받아 루트 스위치를 정하고, 루프를 만드는 일부 포트를 막아 루프 없는 트리를 만듭니다. 그림의 정상 상태에서 S3의 대기 포트를 막지 않고 열면 S1, S2, S3를 도는 고리가 생깁니다. 쓰던 링크가 끊기면 프로토콜이 다시 계산해 막아 두었던 포트를 열어 다른 루프 없는 경로를 만드는데, 전통적인 STP는 이렇게 다시 수렴하는 데 30초에서 50초쯤 걸렸고, 이를 개선한 RSTP는 조건이 맞으면 몇 초 안에 수렴합니다. 여러 VLAN마다 다른 트리를 쓰는 MSTP도 있습니다.

링크를 묶는 LAG

링크 집선(link aggregation, LAG)은 스위치 사이의 물리 링크 여러 개를 하나의 논리 링크로 묶어 대역폭을 늘리고, 링크 하나가 끊겨도 나머지로 통신을 이어 가게 합니다. 양쪽 장비는 LACP라는 프로토콜로 어느 링크를 묶을지 협상하며, 이는 IEEE 802.1AX 표준에 정해져 있습니다.

LAG는 프레임을 링크들에 번갈아 보내지 않고, 흐름마다 주소와 포트를 해시해 링크 하나를 고릅니다. 한 흐름의 패킷들을 여러 링크로 나누어 보내면 도착 순서가 뒤바뀔 수 있기 때문입니다.

import zlib

LINKS = 3                                            # 1Gbps 링크 세 개를 묶은 LAG

def pick_link(src_ip, dst_ip, src_port, dst_port):
    key = f"{src_ip}:{src_port}-{dst_ip}:{dst_port}".encode()
    return zlib.crc32(key) % LINKS                   # 흐름의 주소와 포트로 해시해 링크를 고른다

flows = [("10.0.0.5", "10.0.1.9", 50000 + i, 443) for i in range(6)]
for flow in flows:
    print(f"흐름 {flow[0]}:{flow[2]} -> {flow[1]}:{flow[3]}  링크 {pick_link(*flow)}")
print("같은 흐름을 다시 보내도:", {pick_link(*flows[0]) for _ in range(5)})

흐름 10.0.0.5:50000 -> 10.0.1.9:443  링크 1
흐름 10.0.0.5:50001 -> 10.0.1.9:443  링크 0
흐름 10.0.0.5:50002 -> 10.0.1.9:443  링크 2
흐름 10.0.0.5:50003 -> 10.0.1.9:443  링크 0
흐름 10.0.0.5:50004 -> 10.0.1.9:443  링크 0
흐름 10.0.0.5:50005 -> 10.0.1.9:443  링크 2
같은 흐름을 다시 보내도: {1}

같은 흐름은 언제나 같은 링크로 가므로, 1Gbps 링크 셋을 묶어도 TCP 연결 하나는 1Gbps를 넘지 못합니다. 흐름이 여섯 개여도 해시에 따라 링크 0에 셋이 몰리고 링크 1에는 하나만 가듯 고르게 나뉘지 않을 수 있습니다. LAG는 흐름이 많을 때 전체 처리량을 늘려 주는 기술이지, 하나의 흐름을 빠르게 해 주는 기술이 아닙니다.

정리

• 스위치는 프레임의 출발지 MAC 주소와 들어온 포트로 MAC 주소 표를 채우고, 목적지가 표에 있으면 그 포트로만, 없거나 브로드캐스트이면 나머지 모든 포트로 보냅니다.
• ARP는 같은 링크에서 IP 주소로 MAC 주소를 알아내며, 요청은 브로드캐스트로, 응답은 유니캐스트로 오가고 결과는 ARP 캐시에 저장됩니다.
• 다른 네트워크로 보낼 때는 최종 목적지가 아니라 다음 홉인 게이트웨이의 MAC 주소를 ARP로 찾습니다.
• Gratuitous ARP(RFC 5227의 ARP Announcement)는 IP와 MAC의 짝이 바뀐 것을 알리며 VRRP 같은 이중화에 쓰이고, 주소의 충돌은 그보다 먼저 보내는 ARP Probe로 확인합니다.
• STP는 일부 포트를 막아 루프를 없애고, LAG는 흐름마다 해시로 링크를 골라 여러 링크를 함께 씁니다.

연습 문제

1. 스위치의 표만 비었을 때

본문의 교환이 끝난 뒤, A의 ARP 캐시는 그대로인데 스위치의 MAC 주소 표만 모두 지워졌습니다. A가 B에게 데이터 프레임을 하나 보내면 ARP 요청이 먼저 필요한가요? 스위치는 무엇을 새로 배우고, 프레임을 어느 포트로 내보내나요?

2. 인터넷으로 나가는 첫 패킷

IP 주소가 192.168.1.10/24이고 기본 게이트웨이가 192.168.1.1인 PC가 8.8.8.8에 처음 패킷을 보냅니다. PC는 누구의 MAC 주소를 ARP로 묻고, 프레임과 IP 패킷의 목적지 주소는 각각 무엇이 되나요? 게이트웨이가 ARP에 대답하지 않으면 어떻게 되나요?

3. 링크를 묶었는데 빨라지지 않는다

1Gbps 링크 셋을 LAG로 묶은 두 스위치 사이에서, 서버 하나가 다른 서버 하나로 큰 파일을 TCP 연결 하나로 보내는데 1Gbps를 넘지 못합니다. 고장일까요? 처리량을 늘리려면 어떻게 해야 하나요?

다음 글 VLAN과 2계층 보안에서는 하나의 스위치에서 네트워크를 논리적으로 나누는 VLAN과, ARP와 스위치를 노리는 데이터 링크 계층의 공격과 방어를 살펴봅니다.