투명 OPNsense 브리지에서 LACP 불안정 디버깅
Source: Dev.to
나는 UniFi Dream Machine Pro와 LAN의 나머지 부분 사이에 투명 OPNsense 브리지(링크)를 두고 있다. 이 브리지는 Layer 3에서는 의도적으로 아무 일도 하지 않는다: UDM이 라우팅, DHCP, DNS, 방화벽 정책, WAN 처리, VLAN 정의 등을 모두 담당한다. OPNsense는 와이어 안에 Layer 2 버프 역할을 한다.
흥미로운 점은 그 버프 양쪽 모두가 LACP(링크)를 사용한다는 것이다.
이 설정에 대한 구축/구성 가이드는 여기서 이미 작성했다: Building a Transparent LAGG (LACP) Bridge with OPNsense, UDM, and UniFi - A Practical Guide. 해당 글에서는 브리지를 어떻게 만들었는지, LAGG 장치를 어떻게 설정했는지, 방화벽을 투명하게 유지하고 싶었던 이유를 설명한다.
이 글은 이야기의 다른 절반이다: 그런 설정이 눈에 띄지 않게 실패했을 때 무슨 일이 일어나는지.
깨끗한 장애가 아니다. “네트워크가 다운됐다”는 순간도 아니다. 단지 모든 것이 뭔가 이상하게 느껴질 정도의 불안정함만 있다.
1. 토폴로지와 장애 표면
토폴로지는 다음과 같다:
+----------------------+
| UniFi Dream Machine |
| kantharos-udm-pro |
+----------+-----------+
|
LACP aggregate, 2 x 1G
|
OPNsense lagg0
"ingresslagg"
igc1 + igc2, LACP
|
+----------v-----------+
| OPNsense bridge0 |
| "laggbridge" |
+----------+-----------+
|
OPNsense lagg1
"egresslagg"
igc4 + igc5, LACP
|
LACP aggregate, 2 x 1G
|
+----------v-----------+
| UniFi USW-Lite-16 |
| downstream LAN |
+----------------------+
OPNsense에서 관련된 인터페이스는 다음과 같다:
igc1 + igc2 -> lagg0 -> ingresslagg -> toward UDM
igc4 + igc5 -> lagg1 -> egresslagg -> toward USW
lagg0 + lagg1 -> bridge0 -> laggbridge브리지는 FreeBSD 브리지이며, 집합은 LACP를 사용하는 FreeBSD lagg(4)(링크) 인터페이스다. OPNsense는 이를 Interfaces > Devices(링크) UI를 통해 노출한다.
건강한 OPNsense 상태는 다음과 같다:
laggproto lacp
status: active
laggport: igcX flags=
laggport: igcY flags=세 개의 멤버 상태가 의미한다:
- ACTIVE: 멤버가 LACP 번들에 참여하고 있다.
- COLLECTING: 멤버가 트래픽을 수신할 수 있다.
- DISTRIBUTING: 멤버가 트래픽을 전송할 수 있다.
LACP 링크에서는 캐리어만으로는 충분하지 않다. 케이블이 링크를 표시하더라도 멤버가 COLLECTING·DISTRIBUTING 하지 않으면 집합에 정상적으로 참여하고 있지 않은 것이다.
투명 브리지에서는 이 구분이 평소보다 더 중요하다. OPNsense는 문제를 우회해서 라우팅하지 않는다. 두 집합 링크 사이에 Ethernet 프레임을 전달할 뿐이며, 이는 OPNsense 브리지 문서에서 설명하는 Layer 2 포워딩·MAC 학습과 동일하다. 하나의 LACP 멤버가 오작동하면 증상이 전체 Layer 2 구간에 퍼질 수 있다.
2. 증상: 불안정, 중단은 아님
장애는 깔끔한 중단 형태로 나타나지 않았다.
LAN 전체가 한 번에 죽고 그대로 머무는 지점도 없었다. 대신 네트워크가 불안정해졌다:
- 트래픽이 느려졌다
- 클라이언트가 일관되지 않게 동작했다
- 관리 세션이 끊기기 쉬웠다
- UniFi와 OPNsense가 항상 같은 상태를 보여주지는 않았다
- 투명 브리지 아래에서 LACP 상태가 변했다
- 브리지는 부분적으로 살아있고 부분적으로는 망가진 듯 보였다
바로 이런 종류의 결함이 LACP를 짜증나게 만든다.
단일 Ethernet 케이블이라면 물리적 장애는 보통 명확하다. 링크가 끊기고, 포트가 다운되고, 장치가 사라진다.
하지만 LACP에서는 하나의 멤버가 약해지면서도 논리적 집합은 여전히 존재한다. Link Aggregation Group(링크)의 목적은 여러 풀‑듀플렉스 포인트‑투‑포인트 링크를 하나의 논리적 링크로 취급하는 것이지만, 물리 멤버는 여전히 아래에 존재한다. 일부 트래픽은 살아남고, 일부는 불량 멤버에 닿으며, 일부 흐름은 멈추고, 일부는 재시도하고, 또 일부는 정상적으로 동작한다. 사용자 입장에서는 “네트워크가 이상하다”는 증상만 남게 되며, 이는 인프라 문제를 진단할 때 가장 쓸모 없는 문장 중 하나다.
그 원인은 해싱이다. LACP는 일반적인 디스크 스트라이프처럼 하나의 흐름을 모든 케이블에 나눠서 전송하지 않는다. FreeBSD 핸드북에서는 Ethernet 프레임 순서 때문에 두 스테이션 간 트래픽은 같은 물리 링크에 머무르고, 전송 알고리즘은 흐름을 구분해 집합 전체에 균형을 맞추려 한다고 설명한다. 장치와 설정에 따라 해시가 Layer 2, Layer 3, 혹은 Layer 4 필드를 사용할 수 있다. 내 OPNsense 설정에서는 LAGG 해시가 Layer 2였다:
laggproto lacp lagghash l2단순화된 모델:
flow A -> member 1 -> works
flow B -> member 2 -> stalls
flow C -> member 1 -> works
flow D -> member 2 -> retries이렇게 되면 혼잡, DNS 문제, Wi‑Fi 문제, 컨트롤러 이상, 방화벽 지연 등처럼 보이는 장애 모드가 생성된다. 문제의 원인이 집합 내부의 물리 멤버라는 것을 바로 알기 어렵다.
핵심 함정은 다음과 같다: 부분적인 LACP 실패가 일반적인 네트워크 성능 저하로 가장할 수 있다.
3. OPNsense 증거: 번들이 실제로 플래핑하고 있었다
가장 강력한 증거는 OPNsense 시스템 로그 파일( /var/log/system/system_20260605.log)에 있었다. 두 구간이 특히 중요했다:
2026-06-05 02:26:32-02:28:01 UTC
2026-06-05 20:08:27-21:22:31 UTC첫 번째 구간 (02:26 ~ 02:28)
igc1 and igc2 went down/up repeatedly
lagg0: link state changed to DOWN
lagg0: link state changed to UP
igc4/igc5: Interface stopped DISTRIBUTING, possible flapping두 번째 구간 (20:08 ~ 21:22)
20:08:27 lagg1 went DOWN
20:10:19 lagg1 came UP
20:19:12 lagg1 went DOWN again
20:24-20:41 igc4/igc5 continued bouncing
20:26:47 lagg0 dropped
20:34:36 lagg0 came back
21:05:10 lagg1 dropped again
21:05:44 lagg1 came back
21:22:28 lagg0 detached during final bypass/reset activity
21:22:31 lagg1 detached during final bypass/reset activity가장 유용한 문구는 다음과 같다:
Interface stopped DISTRIBUTING, possible flapping이는 애플리케이션 레이어의 증상이 아니다. DNS도 아니고, IP 라우팅 문제도 아니며, 방화벽 규칙도 아니다. 링크 집합 계층에서 LACP 멤버 상태가 변했음을 의미한다. 간단히 정리한 [LACP](https://