대상 OS: Ubuntu Server 24.04 LTS
운영하다 보면 “NIC 두 장을 묶어서(본딩) 대역폭/가용성을 올리고, 그 위에 VLAN 태그를 얹고, 일부 대역은 정적 라우트로 빼야 하는” 순간이 옵니다.
그런데 설정 자체보다 더 골치 아픈 건, 적용 후 원격 SSH가 끊기거나 예상치 못한 경로로 트래픽이 새서 장애처럼 보이는 상황이죠.
이 글은 Ubuntu 24.04에서 Netplan(기본 backend: systemd-networkd)을 기준으로 Bond+VLAN+정적 라우트를 ‘한 파일로’ 만들고,
적용/검증/롤백까지 포함해 “한 번에 끝내는” 실사용 루틴을 정리합니다.
(보안 얘기는 최소화하고, 장애 대응과 운영 동선을 중심으로 갑니다.)
---
1) 구성 목표와 가정(예시)
1. 물리 NIC 2개: eno1, eno2
- Bond 인터페이스: bond0 (mode: 802.3ad LACP)
- VLAN: bond0.110 (VLAN ID 110)
- IP: 10.110.0.10/24, GW: 10.110.0.1
- 정적 라우트: 10.200.0.0/16 → 10.110.0.254 (사내 라우터)
- DNS: 1.1.1.1, 8.8.8.8
주의: LACP를 쓰면 스위치 포트도 LACP로 묶여 있어야 합니다. 스위치가 준비되지 않았다면 mode를 active-backup으로 먼저 올려 “끊기지 않게” 가는 게 현실적입니다.
---
2) 현재 상태 파악(적용 전 2분 투자)
1. Netplan 파일과 backend 확인
ls -l /etc/netplan
grep -R "renderer" -n /etc/netplan/*.yaml || true
netplan --version2. 실제 링크 이름/드라이버 확인(예: eno1/eno2가 맞는지)
ip -br link
ethtool -i eno1 2>/dev/null || true
ethtool -i eno2 2>/dev/null || true3. 현재 라우팅/기본 게이트웨이
ip route
ip -4 route get 1.1.1.1
resolvectl status 2>/dev/null || true---
3) Netplan 구성 파일 작성(Bond + VLAN + Route)
1. 기존 파일 백업(원격 장애 대비용)
sudo mkdir -p /root/netplan-backup
sudo cp -a /etc/netplan/*.yaml /root/netplan-backup/ 2>/dev/null || true2. 새 설정 파일 작성
sudo tee /etc/netplan/01-bond-vlan-routes.yaml >/dev/null <<'YAML'
network:
version: 2
renderer: networkd
ethernets:
eno1:
dhcp4: false
optional: true
eno2:
dhcp4: false
optional: true
bonds:
bond0:
interfaces: [eno1, eno2]
parameters:
mode: 802.3ad
mii-monitor-interval: 100
lacp-rate: fast
dhcp4: false
optional: true
vlans:
bond0.110:
id: 110
link: bond0
addresses:
- 10.110.0.10/24
routes:
- to: default
via: 10.110.0.1
- to: 10.200.0.0/16
via: 10.110.0.254
nameservers:
addresses: [1.1.1.1, 8.8.8.8]
YAML3. 문법/의미 검증
sudo netplan generate
sudo netplan get | sed -n '1,200p'팁: `optional: true`는 부팅 시 링크가 늦게 올라올 때 “부팅이 멈춘 것처럼 보이는” 상황을 줄여줍니다(서버/원격 환경에서 체감이 큼).
---
4) 적용은 ‘try’부터: 끊겨도 자동 롤백되게
1. 120초 롤백 타이머로 적용
sudo netplan try --timeout 1202. 다른 터미널(또는 콘솔)에서 즉시 검증
ip -br addr
ip -d link show bond0 | sed -n '1,120p'
ip -d link show bond0.110 | sed -n '1,120p'
cat /proc/net/bonding/bond0 2>/dev/null || true
ip route
ip -4 route get 10.200.0.1
ping -c 2 10.110.0.13. DNS/리졸버 동작 확인
resolvectl query example.com 2>/dev/null || true
getent ahostsv4 example.com | head`netplan try` 화면에서 “OK”를 눌러야 확정됩니다. 원격 접속이 끊겨도 시간이 지나면 자동으로 이전 설정으로 돌아오니, 운영 환경에서는 이 습관이 거의 보험입니다.
---
5) 장애 패턴별 트러블슈팅(실전에서 자주 만나는 것들)
# A. LACP인데 bond가 UP이 안 된다
1. Bond 상태 확인(스위치 협상 문제를 가장 먼저 의심)
cat /proc/net/bonding/bond0
ip -br link show bond0- `802.3ad`에서 스위치쪽 LACP 미구성/오구성이면 bond가 애매하게 보이거나 트래픽이 한쪽으로만 가기도 합니다.
- 일단 서비스 복구가 목표면 `mode: active-backup`으로 임시 전환 후 스위치 정리를 추천합니다.
임시 전환(빠르게 살리기):
sudo sed -i.bak 's/mode: 802.3ad/mode: active-backup/' /etc/netplan/01-bond-vlan-routes.yaml
sudo netplan try --timeout 120# B. VLAN은 있는데 게이트웨이로 핑이 안 된다
1. VLAN 태그가 스위치에서 허용되어 있는지(트렁크/액세스 설정)
ip -d link show bond0.110
ping -c 2 10.110.0.12. ARP/Neighbor 확인
ip neigh show dev bond0.110게이트웨이 MAC이 안 잡히면, 서버 문제보다 스위치 포트의 VLAN 허용/Native VLAN 문제일 때가 많습니다.
# C. 정적 라우트가 먹는 것 같지만 실제 트래픽이 다른 경로로 나간다
1. 경로 결정 확인(커널이 실제로 어떤 라우트를 쓰는지)
ip -4 route get 10.200.0.1
ip rule show- 기본 라우트가 다른 인터페이스에 남아있으면(예: DHCP 받은 경로), 우선순위/메트릭 때문에 의도치 않게 “다른 길”로 갑니다.
- 불필요한 DHCP 인터페이스는 확실히 `dhcp4: false`로 꺼두는 편이 운영에 안정적입니다.
---
6) 롤백/복구 루틴(진짜 중요한 부분)
1. netplan apply 후 끊겼을 때(콘솔 접근 가능하다는 가정)
sudo cp -a /root/netplan-backup/*.yaml /etc/netplan/
sudo netplan generate
sudo netplan apply2. “어느 파일이 적용되었는지”가 헷갈릴 때
sudo netplan get
sudo networkctl status --no-pager 2>/dev/null | sed -n '1,160p'3. 최후의 수단: 특정 파일을 잠시 치우고 최소 설정으로 부팅
sudo mkdir -p /root/netplan-disabled
sudo mv /etc/netplan/*.yaml /root/netplan-disabled/
# 최소 DHCP(예: 관리용 NIC 한 장)
sudo tee /etc/netplan/99-rescue.yaml >/dev/null <<'YAML'
network:
version: 2
renderer: networkd
ethernets:
eno1:
dhcp4: true
YAML
sudo netplan apply---
7) 운영 팁: 변경을 ‘작게’ 나누면 장애가 작아진다
1. 먼저 Bond만 올리고(주소 없이) 링크가 안정적인지 확인
2. 그 다음 VLAN을 올리고 게이트웨이까지만 확인
3. 마지막에 정적 라우트/DNS를 붙여 서비스 경로 확인
이렇게 3단계로 나누면 문제가 생겨도 원인 범위가 훨씬 빨리 좁혀집니다.