노트북 홈서버 k3s 구축기 - 번외. e1000e NIC hang

0. 먼저 — 내 네트워크 골목의 구조 

홈랩을 진행하던 도중 장애가 발생했다. 데스크탑에서 서버로의 ssh, proxmox web, argocd web이 전부 다운되었다. 그래서 서버가 죽었나 싶어서 닫혀있던 노트북을 열고 root로 진입해보니 pve(내가 만든 proxmox 호스트 - .200)는 잘 살아있었고, pve에서 201,202,203으로도 접근이 잘 되었다. 근데 왜 데스크탑에서 연결이 갑자기 한순간에 다 끊어졌을까.

 

이 장애는 "안에서는 되는데 밖에서만 안 된다"는 모양이었다. 그래서 원인을 이해하려면, 3부에서 세운 네트워크 구조를 먼저 알아야 한다. 3부에서 깐 배선을 한 장으로 요약하면:

                      공유기 (TP-Link, 192.168.0.1)
                          │  (유선)
                     노트북 유선 NIC = nic0 (내장 Intel, 드라이버 e1000e)
                          │
                     ┌──  vmbr0 (Proxmox 가상 스위치)  ──┐
                     │                                    │
             Proxmox 호스트(.200)              k3s VM  .201 · .202 · .203

핵심 세 가지(3부에서 정한 것):

• 노트북에 유선 랜은 하나뿐이고, 그게 내장 Intel NIC(nic0, 드라이버 e1000e)다. 3부 설치 때 관리 인터페이스로 이걸 고정했다.
• Proxmox는 vmbr0라는 가상 스위치를 만들어, 그 위에 호스트 자신(.200)과 VM 세 대(.201~203)를 다 물린다. 그 가상 스위치의 "바깥 포트"에 물리 NIC(nic0)을 꽂아 진짜 네트워크로 내보낸다. 그래서 공유기 눈에는 노트북 1대로만 보인다.
• 데스크탑(콘솔, 192.168.0.x)은 같은 공유기 골목에 있고, 여기서 kubectl·SSH·Proxmox 웹UI로 서버를 관리한다.

이 구조에서 "밖으로 나가는 유일한 길이 nic0"라는 게 이 사건의 전부다.

---

1. 증상 — 갑자기 다 안 닿는다

평소처럼 데스크탑에서 클러스터를 만지려는데, 전부 막혔다.

# kubectl
Unable to connect to the server: dial tcp 192.168.0.201:6443: connect: no route to host

# SSH
ssh: connect to host 192.168.0.201 port 22: Connection timed out

k3s 노드(.201)만이 아니라 Proxmox 웹UI(https://192.168.0.200:8006)도 안 열렸다. 선은 안 건드렸는데.

이때 머릿속에 스치는 건 최악들이다 — 서버가 죽었나? 디스크가 나갔나? 침해인가? 근데 여기서 답으로 점프하면 안 된다. "어디가 문제인가"를 한 번에 반씩 좁혀 내려가야 한다.

 

---

2. 반씩 좁히기 (1) — 클러스터냐, 호스트냐

.201(k3s 노드)도 .200(Proxmox 호스트)도 안 된다. 노드 하나만 문제면 다른 노드는 됐을 텐데, 호스트까지 안 되니 "한 대"가 아니라 "그 위 전부"가 안 닿는 것이다.

 

여기서 구조(§0)가 값을 한다 — .200은 노트북 본체(Proxmox 호스트)고, .201~203은 그 위 VM이다. 호스트가 안 닿으면 그 위 VM도 다 같이 안 닿는다. 그러니 문제는 k3s가 아니라 노트북 본체 쪽으로 좁혀진다.

 

no route to host라는 에러도 힌트다 — 이건 "상대가 응답을 거부했다"가 아니라 "상대 기계로 가는 길 자체가 없다"(호스트가 꺼졌거나 네트워크에서 사라짐)는 신호다.

 

→ 좁혀진 것: k3s 문제 아님. 노트북 본체가 통째로 안 닿는다.

---

3. 반씩 좁히기 (2) — 호스트가 죽었나, 네트워크만 죽었나

노트북 본체로 걸어가 콘솔에 직접 로그인해 봤다.

root@pve:~#

잘 들어가진다. 서버는 켜져 있고 OS도 멀쩡하다. 그러면 "기계가 죽은" 게 아니라 "네트워크로만 못 닿는" 것이다. 여기서 최악의 시나리오(디스크·침해)는 일단 배제된다.

 

→ 좁혀진 것: 호스트는 살아 있다. 네트워크 도달성 문제다.

 

---

4. 반씩 좁히기 (3) — 어느 쪽이 끊겼나 (세 번의 ping)

네트워크가 문제면, 끊긴 지점이 호스트 쪽인지 · 데스크탑 쪽인지 · 그 사이(공유기)인지를 갈라야 한다. 세 군데를 찔러 본다.

 

① 호스트 → VM (.200에서 .201로 SSH) — 된다.
vmbr0(가상 스위치) 내부는 살아 있다는 뜻이다. 물리 NIC을 거치지 않고 소프트웨어 스위치 안에서만 오가는 길이라, 여기가 되는 건 "내부는 정상"의 증거다.

 

② 호스트 → 공유기 (.200에서 .1로 ping) — 안 된다.

root@pve:~# ping -c2 192.168.0.1
(응답 없음)

 

③ 데스크탑 → 공유기 (.167에서 .1로 ping) — 된다.

세 결과를 겹치면 답이 나온다:

경로	결과	뜻
호스트 → VM (vmbr0 내부)	O	가상 스위치 내부 정상
데스크탑 → 공유기	O	공유기·데스크탑은 멀쩡
호스트 → 공유기	X	호스트가 밖으로 못 나간다

공유기는 살아 있고(데스크탑이 닿으니까), vmbr0 내부도 살아 있는데(호스트↔VM 되니까), 오직 호스트에서 공유기로 나가는 업링크(상위 망으로 나가는 연결)만 죽었다. 

 

Proxmox의 가상 스위치인 vmbr0의 바깥 포트로 물린 nic0이 문제다.

 

→ 좁혀진 것: 호스트의 업링크(nic0 → 공유기) 구간이 끊겼다.

 

---

5. 물리냐 데이터냐 — carrier와 ARP

업링크가 죽었다니, 제일 먼저 의심할 건 "선이 빠졌나"다. 근데 확인해 보면 선은 멀쩡하다.

root@pve:~# ip -br link
lo          UNKNOWN
nic0        UP           ← 유선 NIC (밖으로 나가는 길)
wlp0s20f3   DOWN         ← WiFi (안 씀)
vmbr0       UP           ← 가상 스위치
tap201i0    UNKNOWN      ┐
tap202i0    UNKNOWN      ├ VM 3대가 붙은 가상 포트
tap203i0    UNKNOWN      ┘

root@pve:~# ethtool nic0 | grep -i link
        Link detected: yes

• ip -br link: 리눅스 네트워크 도구(ip)로 포트(인터페이스) 자체를 보는 것(link). 짧게 한 줄씩(-br). 
• ethtool nic | grep -i link: nic 하드웨어에 직접 물어봐서(ethtool nic), link가 든 줄만 검색 - 물리적 선이 연결 되어있나

 

nic0은 UP, Link detected: yes. 선은 물리적으로 붙어 있다. 여기서 개념 하나가 필요하다.

 

carrier(링크) ≠ 데이터 흐름

• carrier = "선이 전기적으로 연결됐다." NIC과 공유기가 서로 "우리 연결됨"을 확인한 상태. 랜포트 LED가 켜지는 게 이거다.
• 데이터가 흐른다 = 실제로 프레임(데이터 조각)이 오간다. carrier가 있어도 이게 따로 안 될 수 있다.

전화선 비유를 AI가 들어줬다. —

carrier는 수화기를 들었을 때 "뚜—" 하는 다이얼톤이다(선은 살아 있다).

데이터는 실제 통화다. 다이얼톤은 들리는데 통화가 안 되는 상태 = carrier 있는데 데이터 안 감. 지금이 딱 그거다.

 

 

그러면 이제 데이터가 실제로 가는지를 봐야 한다. 그 지표가 ARP다.

 

ARP — IP를 실제 주소(MAC)로 바꾸는 과정

같은 골목(랜-192.168.0.~)에서 IP로 통신하려면, 그 IP의 MAC 주소(하드웨어 주소)가 필요하다. IP는 "이름", MAC은 "실제 집주소"라고 보면 된다. 이름만으론 택배를 못 보낸다 — 집주소를 알아야 보낸다.

 

그 집주소를 알아내는 게 ARP(Address Resolution Protocol)다. - 주소 해석 프로토콜.

 

공유기가 만든 사설망에 대고 "192.168.0.1(공유기) 가진 놈 누구야? MAC 알려줘"라고 외치고(브로드캐스트), 공유기가 "나야, 내 MAC은 이거야"라고 답하면, 그제서야 프레임을 보낼 수 있다.

 

서버에서 직접 ARP 결과를 봤다.

root@pve:~# ip neigh show 192.168.0.1
192.168.0.1 dev vmbr0 FAILED

 

• ip neigh show " 192.168.0.1 ": 같은 사설망에 있는 주소(공유기가 제공하는)에 즉, L2에 있는 기기들(공유기, VM, 데스크탑) 중 공유기 주소(192.168.0.1)의 MAC을 보여줘

FAILED — 공유기의 MAC을 못 얻었다. "공유기 누구야?"라고 외쳤는데 답이 안 온 것이다. 즉 프레임이 서버에서 공유기까지 건너가지 못한다.

정리하면 — carrier(불)는 켜졌는데, ARP는 실패한다. 선은 붙었지만 실제 데이터는 한 발짝도 못 나간다. 모순이 아니라, 이 둘이 서로 다른 층이라서 이렇게 갈린다. 원인은 "선"이 아니라, 그 위 어딘가에서 데이터가 얼어붙은 것이다.

(브리지 설정도 의심해 ip link show master vmbr0로 확인했지만, nic0은 정상적으로 vmbr0에 물려 있었다. 브리지 문제도 아니다.)

 

→ 좁혀진 것: 물리 선은 정상(carrier yes), 그런데 데이터가 안 감(ARP FAILED). 그 사이 어딘가에서 프레임이 멈춘다.

 

---

6. 근본 원인 — NIC이 멈췄다 (dmesg)

"선은 붙었는데 데이터가 멈춘다"의 답은 커널 로그에 있다. dmesg를 봤더니 같은 줄이 수십 번 찍혀 있었다.

• dmesg: 커널이 남긴 로그를 화면에 뿌려주는 명령어

root@pve:~# dmesg -T | grep -iE "e1000e|nic0|hang|link" | tail
... e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang:      (34번 반복)
... e1000e 0000:00:1f.6 nic0: NIC Link is Down
... vmbr0: port 1(nic0) entered disabled state
... e1000e 0000:00:1f.6 nic0: NIC Link is Up 1000 Mbps Full Duplex
... vmbr0: port 1(nic0) entered forwarding state

e1000e 0000:00:1f.6 nic0 — 3부에서 고정했던 그 내장 Intel NIC(PCI 주소 00:1f.6, 드라이버 e1000e)다. 그리고 Detected Hardware Unit Hang. 이걸 이해하려면 두 개념이 필요하다.

NIC "hang"이 뭐냐

NIC 안에는 패킷을 실제로 처리하는 회로(엔진)가 있다. 컴퓨터가 보낼 프레임들을 NIC의 송신 큐(TX queue, 보낼 것 대기줄)에 넣으면, NIC 엔진이 거기서 하나씩 꺼내 선으로 밀어낸다.

 

hang = 그 엔진이 멈춰버린 것. 큐에서 프레임을 안 꺼내고 얼어붙어, 대기줄에 쌓이기만 하고 밖으로 하나도 안 나간다. NIC은 전원 들어와 있고 링크(carrier)도 붙어 있는데, 처리 회로만 멈춘 상태다.

 

Detected Hardware Unit Hang은 드라이버(e1000e)가 "NIC 처리 회로가 큐를 안 비우고 멈췄다"를 감지해 찍는 메시지다. 34번 반복 = 34번 감시하는 동안 계속 멈춰 있었다는 뜻. 그래서 ARP 프레임조차 못 나갔고(§5의 FAILED), carrier만 켜진 채 데이터가 정지했던 것이다.

 

AI가 우편 분류기로 비유해줬다. — NIC은 편지를 in-tray(큐)에서 꺼내 밖으로 보내는 자동 기계다. hang은 그 기계 모터가 잼(jam) 걸려 멈춘 것. 전원은 켜졌는데(불) 편지가 안 나간다.

 

왜 하필 이 NIC이 멈췄나 — 오프로드 버그

큰 데이터는 그대로 못 나가고 작은 프레임(약 1500바이트씩)으로 쪼개야 한다. 이 쪼개는 일을 보통은 CPU가 하는데, 성능을 위해 NIC 하드웨어한테 떠넘기는 기능이 있다 — 이걸 오프로드(TSO: TCP Segmentation Offload 등)라고 한다. "큰 덩어리 줄 테니 네가 쪼개서 보내" 하고 NIC에 통째로 넘기는 것이다.

 

문제는 Intel e1000e 계열(I219/I218) 칩의 그 쪼개기 하드웨어에 결함이 있다는 점이다. 특정 상황에서 큰 덩어리를 쪼개다가 엔진이 잼(hang) 걸린다. 그게 Hardware Unit Hang의 정체 — 쪼개다가 멈춘 것이다. 널리 알려지고 문서화된 버그다.

 

(참고로 4부에서 "USB 자동절전 차단"을 해뒀지만, 그건 외장 SSD(USB)를 위한 거였다. 이 NIC은 USB가 아니라 노트북 내장 이라 절전과 무관하다. 실제로 확인해도 usbcore.autosuspend는 -1(꺼짐), sleep 타깃은 masked(차단)로 이미 다 막혀 있었다. 그래서 전력관리가 아니라 드라이버 버그가 원인이라는 게 분명해진다.)

 

→ 근본 원인: Intel e1000e NIC의 세그멘테이션 오프로드 버그로 인한 TX hang.

---

7. 해결 — 오프로드를 끈다

https://forum.proxmox.com/threads/intel-nic-e1000e-hardware-unit-hang.106001/

[SOLVED] - Intel NIC e1000e hardware unit hang

 

 

원인이 "NIC이 쪼개다가 멈춘다"이니, 해결은 "NIC 말고 CPU가 쪼개게" 바꾸는 것이다. 그러면 버그난 쪼개기 회로를 아예 안 쓴다.

# 문제 오프로드 끄기 (CPU가 쪼개도록)
ethtool -K nic0 tso off gso off gro off

이렇게 하면 CPU가 미리 1500바이트짜리로 쪼개 넘겨주고, NIC은 밀어내기만 한다 → 불량 쪼개기 회로를 안 쓰니 잼이 안 난다. 대가는 CPU가 쪼개기를 대신 하는 것뿐인데, 기가비트 홈랩에선 체감이 없다.

 

재부팅해도 유지되게 udev 규칙으로 못 박는다.

echo 'ACTION=="add", SUBSYSTEM=="net", KERNEL=="nic0", RUN+="/sbin/ethtool -K nic0 tso off gso off gro off"' \
  > /etc/udev/rules.d/70-nic0-offload.rules
udevadm control --reload

 

적용됐는지 확인.

root@pve:~# ethtool -k nic0 | grep -iE "tcp-segmentation|generic-segmentation|generic-receive"
tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off

셋 다 off. 이 시점부터 hang은 안 난다. 데스크탑에서 kubectl·SSH·Proxmox 웹UI가 전부 다시 붙었다.

---

8. 정리 — 이 장애에서 남는 것

결과부터 — 클러스터·VM·데이터는 한 번도 죽지 않았다. 죽은 건 데스크탑에서 서버로 가는 네트워크 경로 하나(내장 NIC의 드라이버 버그)뿐이었다. 처음엔 "서버가 나갔나, 침해인가" 싶던 게, 층층이 좁히니 "NIC 드라이버 quirk"까지 내려왔다.

디버깅 방법으로 남는 것:

• 한 번에 반씩 좁힌다. 클러스터냐 호스트냐 → 호스트가 죽었냐 네트워크냐 → 어느 쪽이 끊겼냐. 답으로 점프하지 않고 매 단계에서 절반을 배제한다.
• 아래 층부터 위로 본다. 물리(선/carrier) → 데이터(ARP) → 드라이버(dmesg). 밑이 안 되면 위는 볼 필요도 없다.
• carrier(불) ≠ 데이터. 랜포트 불이 켜졌다고 통신되는 게 아니다. ethtool의 Link detected와 ip neigh의 상태를 나눠 봐야 "선인지 데이터인지"가 갈린다.
• 원인은 결국 로그(dmesg)가 말해줬다. 증상만 쫓지 말고, 커널이 남긴 기록을 봐야 근본이 나온다.

개념 흐름으로 남는 것:

• 기계가 네트워크에 붙는 길 = NIC(부품) → 드라이버(그걸 굴리는 SW) → vmbr0(가상 스위치, 호스트·VM·NIC을 묶음). 그래서 밖은 막혀도 호스트↔VM은 됐다.
• carrier vs 데이터 / IP·MAC·ARP — 불 켜졌는데 왜 안 됐나.
• hang(엔진 잼)·오프로드·Intel e1000e 버그 — 왜 멈췄고 왜 오프로드를 끄면 낫나.

홈랩을 켜놓고 운영한다는 건, 이런 물리·드라이버 층의 quirk를 만나 밑단부터 짚어 내려가는 일이기도 하다. 이번엔 그게 오래된 Intel NIC 하나였다.

 

---

9. 후속 — 며칠 후, 같은 자리가 또 끊겼다

며칠 후 데스크탑에서 같은 증상이 났다. kubectl은 no route to host, 공유기(.1)는 응답하고 호스트(.200)·VM(.201–203)은 전부 무응답 — 같은 분기다. 이번엔 좁히기가 빨랐다. 콘솔에서 dmesg를 보니 같은 줄이 다시 쌓여 있었다.

• dmesg: 커널이 남긴 로그를 화면에 뿌려주는 명령어

[Sun Aug  2 14:54:04 2026] e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang:
(약 5분 동안 164회)

같은 hang이다. 그런데 오프로드 상태를 확인하니 이야기가 달랐다.

 

root@pve:~# ethtool -k nic0 | grep -E "tcp-segmentation|generic-segmentation|generic-receive"
tcp-segmentation-offload: on
generic-segmentation-offload: on
generic-receive-offload: on

꺼 뒀던 셋이 전부 도로 켜져 있다. 그리고 uptime이 이유를 말해줬다 — 하루 전에 재부팅이 있었다.(노트북 전원 나가서 서버도 꺼져버려서 다시킴)

 

끈 날        ethtool로 off → hang 멈춤
하루 전      재부팅 → 오프로드가 기본값(on)으로 복귀
오늘 14:54   켜진 오프로드로 같은 버그 → hang 164회

hang이 "다시" 난 게 아니라, 처방이 사라진 자리에서 원래 병이 그대로 난 것이다. 왜 처방이 사라졌는지를 이해하려면, 그때 쓴 도구 둘의 정체부터 갈라야 한다.

 

ethtool이 고치는 것은 파일이 아니라 메모리다

• ethtool: 리눅스 환경에서 네트워크 카드(NIC)의 상태를 조회하고 하드웨어 설정을 변경하는 데 쓰는 명령어 도구

드라이버에는 조절 손잡이가 여럿 있다 — 속도, 각종 오프로드의 켜고 끄기, 통계. ethtool은 그 손잡이를 만지는 명령줄 도구다(-k 소문자는 보기, -K 대문자는 바꾸기).

성질이 하나 있다. ethtool은 지금 떠 있는 드라이버의 상태만 바꾼다. 어떤 파일에도 기록되지 않는다. 재부팅하면 드라이버가 새로 뜨면서 공장 기본값 — 오프로드 전부 켜짐 — 으로 돌아온다. 오프로드를 끈 그 명령은 살아 있는 드라이버의 값을 바꾼 것뿐이었고, 재부팅과 함께 증발했다. 메모리니까, 재부팅하면 그 값은 유지되지 않는다.

 

그 증발을 막으라고 심은 것이 udev 규칙이었다

• udev: 리눅스 커널을 위한 장치 관리자. /dev 디렉터리의 장치 파일을 동적으로 생성하고 관리하며, USB 등 장치 연결 이벤트를 처리.

리눅스에서 장치가 꽂히거나 부팅 중에 발견되면, 커널이 "장치가 나타났다(add)"는 이벤트를 쏜다. udev는 그 이벤트를 받아 반응하는 상주 서비스고, 반응 내용은 규칙 파일(/etc/udev/rules.d/*.rules)에 "이런 조건의 장치가 이런 이벤트를 내면 → 이걸 해라" 꼴로 적는다. USB를 꽂으면 장치 파일이 생기는 것, 이 NIC이 nic0이라는 고정 이름을 갖는 것 — 전부 udev가 규칙대로 반응한 결과다.

그래서 만든 규칙이 "이름이 nic0인 장치가 나타나면(add) → ethtool로 오프로드를 꺼라( NIC 말고 CPU가 쪼개게 )"였다. 부팅마다 자동으로 다시 꺼지게 하려는 의도였다.

 

불발 — add 순간엔 nic0이라는 이름이 없다

부팅 로그가 불발의 이유를 말해준다.

root@pve:~# journalctl -b | grep -iE "renamed" | head -2
Aug 01 11:46:08 pve kernel: e1000e 0000:00:1f.6 eno0: renamed from eth0
Aug 01 11:46:08 pve kernel: e1000e 0000:00:1f.6 nic0: renamed from eno0

부팅 때 이 NIC은 eth0이라는 임시 이름으로 태어나, eno0을 거쳐 nic0이 된다. 이 개명은 이름 고정용 설정(/usr/local/lib/systemd/network/50-pmx-nic0.link — 3부에서 이름을 고정할 때 생긴 파일)을 읽은 udev가, add 이벤트를 처리하는 과정에서 수행한다.

여기서 순서가 갈린다. add 이벤트가 접수되는 순간의 이름은 eth0이고, nic0은 그 이벤트 처리의 결과물이다. 그런데 규칙의 조건은 "이름이 nic0인 장치가 나타나면"이었다 — 나타나는 순간엔 그 이름이 아직 없다. 조건이 성립하는 순간 자체가 존재하지 않는다.

 

[add 이벤트]   이름 = eth0
    ├─ 심어둔 규칙: "nic0이면 실행" → eth0이라 불일치, 통과
    ├─ .link 처리: "nic0으로 개명" 결정
[처리 끝]      이름 = nic0        ← 이제야 nic0인데, 이벤트는 끝났다

개명됐다고 add 이벤트가 다시 오지도 않는다 — 접수는 한 번이다. 그래서 이 규칙은 문법이 맞았을 뿐 단 한 번도 실행된 적이 없다. hang이 없던 나흘은 규칙이 지켜준 게 아니라, 손으로 끈 라이브 상태가 재부팅 전까지 살아 있었던 것뿐이다. "적용했다"와 "재부팅을 견딘다"는 서로 다른 검증인데, 끈 날에는 앞엣것만 하고 뒤엣것을 했다고 믿었다.

 

교체 — 이름이 확정된 뒤에 도는 층으로

같은 명령을, 실행이 보장되는 자리로 옮긴다. Proxmox가 네트워크를 올릴 때 읽는 설정(/etc/network/interfaces)의 해당 인터페이스 구절에 건다.

iface nic0 inet manual
        post-up /sbin/ethtool -K nic0 tso off gso off gro off

post-up은 "이 인터페이스를 올린 직후 실행"이다. 네트워크를 올리는 것은 장치 접수·개명이 모두 끝난 뒤의 일이라, 그 시점엔 nic0이라는 이름이 확정돼 있다. 같은 ethtool 한 줄인데, 어느 층의 어느 시점에 거느냐가 실행 여부를 갈랐다.

이번엔 심고 끝내지 않고 실행되는 것까지 확인한다 — 재부팅 없이 설정 재적용으로 태워 본다.

 

root@pve:~# ifreload -a
root@pve:~# ethtool -k nic0 | grep -E "tcp-segmentation|generic-segmentation|generic-receive"
tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off

안 먹는 게 실증된 udev 규칙은 지운다(rm /etc/udev/rules.d/70-nic0-offload.rules) — 남겨두면 다음에 또 "돼 있겠지"로 속는다.

남은 검증이 하나 있다 — 실제 재부팅 통과. 이번 일의 교훈이 정확히 "같겠지를 검증으로 치지 마라"이므로, 다음에 호스트를 재부팅할 일이 있을 때 이 세 값이 off로 올라오는지 확인하는 것까지가 마무리다.

이 후속에서 남는 것:

• 검증에는 층위가 있다. "지금 적용됐다" → "올라올 때마다 적용된다"(ifreload) → "재부팅을 넘는다"(실부팅). 셋은 각각 따로 확인해야 하는 다른 사실이다.
• 조건이 맞는 설정과 실행된 설정은 다르다. 설정을 넣었으면 실행된 흔적(여기서는 부팅 직후의 ethtool 상태)까지 봐야 한다.
• 이름에도 층이 있다. eth0 → eno0 → nic0 — 한 장치가 부팅 중 이름을 두 번 갈아입고, 어느 층의 이름으로 조건을 걸었느냐가 규칙의 생사를 갈랐다.