이더넷과 MAC 주소

앞 글의 물리 계층은 비트를 신호로 바꾸어 보낼 뿐, 비트의 나열만으로는 통신이 되지 않습니다. 어디부터 어디까지가 한 덩어리의 데이터인지, 그것을 누구에게 보내는지 알아야 합니다. 이 일을 맡는 것이 데이터 링크 계층이고, 유선 LAN에서 그 대표가 이더넷(Ethernet)입니다. 이더넷이 답하는 질문은 단순합니다. 같은 링크 안에서 이 프레임을 어느 인터페이스가 받아야 하는가입니다.

공유 매체에서 스위치로

초기의 이더넷은 동축 케이블 하나에 모든 장치를 매단 버스 구조였습니다. 모두가 같은 매체를 나누어 쓰므로 둘이 동시에 보내면 신호가 섞여 망가지는 충돌이 생기는데, 이를 다루려고 CSMA/CD(carrier sense multiple access with collision detection)라는 규칙을 썼습니다. 보내기 전에 매체가 비어 있는지 듣고(carrier sense), 여럿이 같은 매체를 쓰며(multiple access), 보내다가 충돌을 감지하면(collision detection) 멈추고 잼 신호를 보낸 뒤 무작위 시간을 기다렸다 다시 보냅니다.

지금의 이더넷은 장치마다 스위치의 포트 하나에 따로 연결되고, 송신과 수신을 동시에 하는 전이중(full duplex)으로 동작합니다. 꼬임 쌍선에서 100Mbps 이더넷(100BASE-TX)은 보내는 선 쌍과 받는 선 쌍을 따로 쓰고, 1Gbps 이더넷(1000BASE-T)은 네 쌍 모두로 동시에 보내고 받으면서 자기가 보낸 신호를 걸러 내어 상대의 신호를 읽습니다. 매체를 나누어 쓰는 상대가 없으니 충돌도 없고, 전이중 링크에서는 CSMA/CD를 쓰지 않습니다. 1Gbps 전이중 링크는 보내는 방향과 받는 방향으로 각각 1Gbps를 동시에 쓸 수 있지만, 그렇다고 한 방향으로 파일을 2Gbps로 보낼 수 있는 것은 아닙니다.

이더넷 프레임의 구조

이더넷은 데이터를 프레임(frame)으로 묶어 보냅니다.

EtherType 칸의 값이 0x0800이면 안에 IPv4가, 0x86DD이면 IPv6이, 0x0806이면 ARP가 들어 있습니다. 이 칸은 옛 IEEE 802.3 형식에서는 데이터의 길이를 나타냈는데, 두 쓰임을 가르려고 1536(0x0600) 이상이면 EtherType으로, 1500 이하이면 길이로 읽습니다. 프리앰블과 SFD는 신호를 맞추기 위한 것이어서 프레임 크기를 말할 때는 빼고, 목적지 MAC 주소부터 FCS까지를 셉니다.

그렇게 센 프레임은 최소 64바이트, 최대 1518바이트이며, VLAN 태그가 붙으면 최대 1522바이트입니다. 최소 크기는 공유 매체 시절, 보내는 쪽이 프레임을 다 보내기 전에 충돌을 알아챌 수 있도록 정한 값인데, 전이중인 지금도 프레임 형식의 일부로 남아 있습니다. 데이터 칸에 담을 수 있는 최대 크기 1500바이트가 이더넷의 MTU입니다.

점보 프레임

데이터센터에서는 MTU를 9000바이트 안팎으로 늘린 점보 프레임(jumbo frame)을 쓰기도 합니다. 아래 코드는 MTU가 1500일 때와 9000일 때를 비교합니다. 태그 없는 이더넷 헤더 14바이트와 FCS 4바이트가 프레임에서 차지하는 비율을 구하고, 데이터 칸을 MTU만큼 꽉 채운다고 보고 1GB(10^9바이트)를 보내는 데 필요한 프레임 수를 정수 나눗셈으로 셉니다. 프리앰블과 SFD는 앞에서처럼 프레임 크기에 넣지 않습니다.

HEADER, FCS = 14, 4                       # 태그 없는 이더넷 헤더와 FCS

for mtu in (1500, 9000):
    frame = HEADER + mtu + FCS
    print(f"MTU {mtu}: 프레임 {frame}바이트, 이더넷의 몫 {(HEADER + FCS) / frame:.2%}, "
          f"1GB를 보내는 데 프레임 약 {10**9 // mtu:,}개")

MTU 1500: 프레임 1518바이트, 이더넷의 몫 1.19%, 1GB를 보내는 데 프레임 약 666,666개
MTU 9000: 프레임 9018바이트, 이더넷의 몫 0.20%, 1GB를 보내는 데 프레임 약 111,111개

헤더의 몫은 1% 남짓에서 0.2%로 조금 줄 뿐이지만, 같은 양을 보내는 데 필요한 프레임의 수가 6분의 1로 줄어드는 효과가 더 큽니다. 장비는 프레임마다 처리 비용을 치르므로, 프레임이 줄면 CPU와 인터럽트의 부담이 줄어듭니다. 다만 점보 프레임은 표준이 정한 하나의 크기가 없고, 경로의 모든 장비가 같은 MTU를 지원해야 합니다. 중간에 1500바이트까지만 받는 장비가 하나라도 있으면 큰 프레임은 버려집니다.

MAC 주소 읽기

MAC 주소(media access control address)는 데이터 링크 계층에서 인터페이스를 가리키는 48비트 주소로, 보통 00:1a:2b:3c:4d:5e처럼 16진수 여섯 바이트로 씁니다. 앞의 3바이트는 IEEE가 제조사에 나누어 준 OUI(organizationally unique identifier)이고, 뒤의 3바이트는 제조사가 붙인 번호입니다. 다만 요즘은 가상 머신과 컨테이너의 가상 인터페이스처럼 소프트웨어가 정한 MAC 주소도 흔하고, 스마트폰은 사생활 보호를 위해 Wi-Fi 네트워크마다 다른 무작위 MAC 주소를 쓰기도 합니다.

첫 바이트의 가장 낮은 두 비트에는 특별한 뜻이 있습니다. 가장 낮은 비트(I/G)가 0이면 인터페이스 하나를 가리키는 개별 주소, 1이면 여러 인터페이스를 가리키는 그룹 주소입니다. 그다음 비트(U/L)가 0이면 OUI로 전역에서 유일하게 관리되는 주소, 1이면 관리자나 소프트웨어가 정한 로컬 관리 주소입니다. 이 두 비트의 뜻은 IEEE의 지침에 정리되어 있습니다.

import ipaddress

def describe(mac):
    if mac.lower() == "ff:ff:ff:ff:ff:ff":
        return f"{mac}: 브로드캐스트"
    first = int(mac.split(":")[0], 16)
    kind = "그룹(멀티캐스트)" if first & 0b01 else "개별(유니캐스트)"   # I/G 비트: 첫 바이트의 가장 낮은 비트
    scope = "로컬 관리" if first & 0b10 else "전역 관리(OUI)"           # U/L 비트: 그다음 비트
    return f"{mac}: {kind}, {scope}"

def ipv4_multicast_mac(group):
    low23 = int(ipaddress.IPv4Address(group)) & 0x7FFFFF       # IP 주소의 하위 23비트만 옮긴다
    return "01:00:5e:" + ":".join(f"{b:02x}" for b in low23.to_bytes(3, "big"))

def ipv6_multicast_mac(group):
    low32 = int(ipaddress.IPv6Address(group)) & 0xFFFFFFFF     # IPv6는 하위 32비트를 옮긴다
    return "33:33:" + ":".join(f"{b:02x}" for b in low32.to_bytes(4, "big"))

for mac in ("00:1a:2b:3c:4d:5e", "02:42:ac:11:00:02", "01:00:5e:00:00:fb", "ff:ff:ff:ff:ff:ff"):
    print(describe(mac))
print("224.0.0.251 ->", ipv4_multicast_mac("224.0.0.251"))
print("ff02::1     ->", ipv6_multicast_mac("ff02::1"))

00:1a:2b:3c:4d:5e: 개별(유니캐스트), 전역 관리(OUI)
02:42:ac:11:00:02: 개별(유니캐스트), 로컬 관리
01:00:5e:00:00:fb: 그룹(멀티캐스트), 전역 관리(OUI)
ff:ff:ff:ff:ff:ff: 브로드캐스트
224.0.0.251 -> 01:00:5e:00:00:fb
ff02::1     -> 33:33:00:00:00:01

02:42:ac:11:00:02는 첫 바이트가 0x02라 U/L 비트가 1인 로컬 관리 주소입니다. Docker Engine 28 이전에는 컨테이너에 02:42 뒤에 IPv4 주소를 붙인 이런 모양의 주소를 주었고, 28부터는 I/G 비트를 0, U/L 비트를 1로 두고 나머지 비트를 무작위로 채운 주소를 줍니다. 모든 비트가 1인 ff:ff:ff:ff:ff:ff는 같은 링크의 모두를 가리키는 브로드캐스트 주소입니다. IP 멀티캐스트는 정해진 규칙으로 MAC 주소로 바뀌는데, IPv4는 01:00:5e 뒤에 IP 주소의 하위 23비트를, IPv6는 33:33 뒤에 하위 32비트를 붙입니다. 로컬 네트워크의 기기를 찾는 mDNS가 쓰는 224.0.0.251이 01:00:5e:00:00:fb가 되는 것이 그 예입니다.

Linux에서는 다음 명령으로 인터페이스의 MAC 주소를 보고 바꿀 수 있습니다. 바꾸는 명령은 실습용 환경에서만 쓰고, 출발지 주소에는 개별 주소만 써야 합니다.

ip -br link                                           # 인터페이스마다 상태와 MAC 주소
sudo ip link set dev eth0 address 02:42:ac:11:00:02   # 로컬 관리 주소로 바꾸기(실습용)

예시에서 새 주소로 쓴 02:42:ac:11:00:02는 앞에서 본 로컬 관리 주소라서, 제조사가 장치에 붙인 주소와 겹치지 않습니다. 드라이버에 따라서는 인터페이스를 먼저 내려야(ip link set dev eth0 down) 주소가 바뀌기도 합니다. 이렇게 바꾼 주소는 설정 파일에 적지 않는 한 재부팅하면 원래 주소로 돌아갑니다.

더 깊이: 네트워크마다 달라지는 휴대전화의 MAC 주소

스마트폰의 무작위 MAC 주소는 앞에서 본 두 비트를 그대로 활용합니다. Android의 문서에 따르면 Android 10부터는 Wi-Fi에 접속할 때 기본으로 무작위 MAC 주소를 쓰는데, U/L 비트를 1로, I/G 비트를 0으로 두고 나머지 46비트를 무작위로 채웁니다. 그래서 무작위 주소는 제조사의 OUI와 겹치지 않는 로컬 관리 개별 주소가 됩니다. 기본 방식에서는 이 주소가 네트워크 프로필마다 하나씩 정해져, 공장 초기화를 하기 전까지 같은 네트워크에서는 같은 값을 씁니다.

애플 기기도 iOS 14 이상에서 네트워크마다 다른 주소를 쓰는 비공개 Wi-Fi 주소(private Wi-Fi address)를 씁니다. 애플의 안내에 따르면 iOS 18부터는 바뀌지 않는 고정(Fixed)과 2주마다 바뀌는 순환(Rotating)을 고를 수 있고, 보안이 약하거나 없는 새 네트워크에 접속할 때는 순환이 기본입니다. Android도 12부터는 일부 경우에 접속할 때마다 주소를 다시 고를 수 있는 비영속 무작위화(non-persistent randomization)를 씁니다.

주소가 바뀌면 MAC 주소로 기기를 알아보던 장비는 같은 기기를 새 기기로 봅니다. 공유기의 MAC 필터링이나 DHCP의 고정 주소 예약이 기대한 대로 동작하지 않는 이유가 여기에 있을 수 있습니다. 두 운영체제 모두 사용자가 네트워크마다 이 기능을 끌 수 있게 하고, 애플은 기관의 Wi-Fi 보안 방식을 비공개 주소에 맞게 고쳐야 할 수도 있다고 안내합니다.

IP 주소와 MAC 주소의 역할

MAC 주소는 같은 링크 안에서 프레임을 받을 다음 인터페이스를 가리키고, IP 주소는 네트워크를 건너 최종 목적지 호스트를 가리킵니다.

그림의 R-왼쪽과 R-오른쪽은 한 라우터의 서로 다른 인터페이스입니다. PC가 보낸 프레임은 목적지 MAC 주소가 R-왼쪽이고, 라우터가 다음 링크로 보내는 새 프레임은 출발지가 R-오른쪽, 목적지가 서버의 MAC 주소입니다. 그동안 IP 패킷의 출발지와 목적지는 PC와 서버로 그대로입니다. 택배에 비유하면 IP 주소는 송장에 적힌 최종 주소이고, MAC 주소는 구간마다 바뀌는 배송 기사의 다음 행선지입니다.

유니캐스트, 브로드캐스트, 멀티캐스트

브로드캐스트는 같은 링크의 모든 장치가 받아서 처리해야 하므로, 장치가 많아질수록 모두의 부담이 됩니다. 수천 대가 한 링크에 있으면 브로드캐스트만으로도 상당한 트래픽이 생기는데, 이것이 3장 4편의 VLAN으로 링크를 나누는 이유입니다. 멀티캐스트도 스위치가 누가 그룹에 가입했는지 엿보는 IGMP 스누핑을 하지 않으면 브로드캐스트처럼 모든 포트로 퍼집니다.

정리

• 초기 이더넷은 공유 매체에서 CSMA/CD로 충돌을 다루었고, 지금의 이더넷은 스위치와 전이중으로 충돌 없이 동작합니다.
• 이더넷 프레임은 목적지와 출발지 MAC 주소, EtherType, 데이터, FCS로 이루어지며, 최소 64바이트, 최대 1518바이트이고 MTU는 1500바이트입니다.
• 점보 프레임은 프레임의 수를 줄여 처리 부담을 덜지만, 경로의 모든 장비가 같은 MTU를 지원해야 합니다.
• MAC 주소의 첫 바이트에서 I/G 비트는 개별과 그룹을, U/L 비트는 전역 관리와 로컬 관리를 가리킵니다.
• MAC 주소는 링크마다 바뀌는 다음 홉의 주소이고 IP 주소는 끝까지 가는 주소이며, 브로드캐스트는 같은 링크의 모두에게 부담을 줍니다.

연습 문제

1. 02와 03의 차이

목적지 MAC 주소가 02:42:ac:11:00:02인 프레임과 03:42:ac:11:00:02인 프레임은 각각 어떤 주소로 해석되나요? 두 주소 모두 U/L 비트가 1인데 해석이 갈리는 이유를 첫 바이트의 비트로 설명하세요.

2. 멀티캐스트 주소가 겹치는 경우

IPv4 멀티캐스트 그룹 224.1.1.1과 225.1.1.1은 각각 어떤 MAC 주소로 바뀌나요? 두 그룹을 같은 링크에서 쓰면 어떤 일이 생길 수 있나요?

3. 점보 프레임을 켠 뒤 생긴 일

서버 두 대의 MTU를 9000으로 바꾸었더니 작은 요청은 잘 가는데, 큰 파일을 보낼 때만 연결이 멈춥니다. 두 서버 사이에는 MTU 설정을 바꾸지 않은 스위치가 하나 있습니다. 무슨 일이 일어나고 있을 가능성이 크고, 어떻게 확인할 수 있나요?

다음 글 스위치와 ARP에서는 스위치가 MAC 주소를 학습해 프레임을 전달하는 방법과, IP 주소로 MAC 주소를 알아내는 ARP의 동작을 살펴봅니다.