[Network] 화면 없는 원격 서버에서 스위치 정체 알아내기 — LLDP·ARP 방청

서버실에 갈 수 없고, 스위치 관리 화면에도 못 들어가는 상황에서 "이 서버의 10G 케이블은 대체 어느 스위치에 꽂혀 있는가?"를 알아내야 했다. 스위치 두 대가 운용 중인데 문서에는 A 스위치라고 적혀 있었고, 실측해 보니 B 스위치였다. 이 글은 그 확인 과정에서 쓴 기법들 — 서버 쪽에서만, 패킷을 한 발도 쏘지 않고, 케이블 반대편 장비의 정체와 VLAN 소속까지 알아내는 방법 — 을 정리한 것이다.

글에 나오는 IP·MAC 주소는 모두 임의 치환값이다.

전제: 왜 서버 쪽에서만 해야 하나

운영 인프라에서 스위치 관리 접근이 없는 경우는 흔하다. 관리 IP를 모르거나, 크리덴셜이 유실됐거나, 애초에 관리 IP가 설정돼 있지 않거나. 그런데 연결 확인을 하겠다고 운영망에 뭔가를 설치하거나 설정을 바꾸는 건 더 위험하다. 여기서 쓰는 기법의 공통 원칙은 수동 방청(passive listening) 이다 — 스위치가 어차피 뿌리고 있는 프레임을 받아 읽기만 한다.

1. LLDP 방청 — lldpd 없이 tcpdump로

스위치 대부분은 LLDP(Link Layer Discovery Protocol)로 자기 정체를 30초마다 모든 포트에 광고한다. 서버에 lldpd·lldpctl이 깔려 있으면 바로 조회하면 되지만, 없어도 상관없다. LLDP는 그냥 이더넷 프레임(ethertype 0x88cc)이라 tcpdump로 직접 받으면 된다:

sudo tcpdump -i eth2 -c 1 -vv ether proto 0x88cc
# 광고 주기(통상 30초)만큼만 기다리면 한 프레임이 온다

실제로 받은 프레임(치환본):

LLDP, length 98
  Chassis ID TLV (1), length 7
    Subtype MAC address (4): e4:f0:04:xx:xx:xx
  Port ID TLV (2), length 8
    Subtype Interface Name (5): Te1/0/4
  Time to Live TLV (3), length 2: TTL 120s
  Port Description TLV (4), length 7: Te1/0/4
  System Name TLV (5), length 0

여기서 세 가지를 읽는다:

TLV	값	해석
Chassis ID	e4:f0:04:...	MAC 앞 3바이트(OUI)가 제조사 — e4:f0:04는 Dell 등록 대역
Port ID	Te1/0/4	"TenGigabitEthernet 1/0/4" — Dell Networking 계열의 포트 표기법
System Name	(비어 있음)	스위치에 호스트명이 설정돼 있지 않다는 뜻

포트 표기법 자체가 기종의 지문이다. 같은 방법으로 다른 서버의 포트를 확인했더니 이런 프레임이 왔다:

  Chassis ID TLV (1): 78:24:59:xx:xx:xx
  Port ID TLV (2), length 5
    Subtype Local (7): 1003
  System Capabilities TLV (7): [Bridge, Router]

Te1/0/4 같은 이름 대신 로컬 번호 1003(= 슬롯 1, 포트 3) — 이건 Alcatel-Lucent OmniSwitch(AOS) 계열의 방식이다. 즉 프레임 두 장만으로 "이 서버는 Dell 스위치에, 저 서버는 OmniSwitch에 꽂혀 있다"가 갈린다. 문서에는 둘 다 같은 스위치라고 적혀 있었는데, 실측이 문서를 이겼다.

OUI 조회는 로컬에서도 된다 (/usr/share/ieee-data/oui.txt가 있는 배포판) — 없으면 OUI 앞 3바이트로 IEEE 등록부를 검색하면 된다.

2. 한계: 관리 IP는 LLDP가 안 알려줄 수 있다

LLDP에는 Management Address TLV라는 선택 항목이 있어서, 잘 설정된 스위치라면 관리 IP까지 광고한다. 그런데 위 두 스위치 모두 이 TLV가 없었다 — System Name도 비어 있었다. 관리 인터페이스가 설정 안 됐거나 별도 대역에 숨어 있다는 뜻이다.

이럴 때 서버들의 ARP 캐시를 뒤져보는 보조 수단이 있다:

ip neigh | grep -i "e4:f0:04\|78:24:59"   # 스위치 chassis MAC의 OUI로 검색

스위치 관리 IP가 서버들과 같은 대역에 있다면 언젠가 ARP를 주고받았을 것이고, 캐시에 흔적이 남는다. 여기서도 안 나오면 — 관리 IP는 정말로 도달 불가능한 곳에 있고, 남은 수단은 시리얼 콘솔뿐이다. (RJ45 콘솔 포트 + USB 시리얼 케이블. 스위치의 show vlan 같은 설정 원본은 결국 이 경로로만 볼 수 있었다.)

3. 무IP 포트의 VLAN 소속 판정 — ARP 방청

케이블이 어느 스위치에 꽂혔는지 알았으면, 다음 질문은 "그 포트는 어느 VLAN(어느 망)에 속해 있나"다. 포트에 IP를 붙여 보기 전에도 알 수 있다 — 그 포트로 흘러들어오는 브로드캐스트를 들으면 된다:

sudo tcpdump -i eth2 -c 20 -nn arp

ARP, Request who-has 10.100.0.116 tell 10.100.0.102, length 46
ARP, Request who-has 10.100.0.116 tell 10.100.0.102, length 46
...

브로드캐스트는 같은 L2(같은 VLAN) 안에서만 돈다. 10.100.0.x 대역의 ARP가 들린다는 것 자체가 이 포트가 그 망의 untagged 멤버라는 직접 증거다. 태그드 VLAN이 지나가는 트렁크 포트라면 tcpdump 출력에 vlan <id>가 붙어서 오므로 구분된다(tcpdump -e vlan으로 태그를 명시적으로 볼 수 있다).

이 방청은 부수입도 있다. 위 출력에서 10.100.0.102가 10.100.0.116을 계속 찾는데 응답이 없다 — 저 주소의 장비가 죽어 있거나 해당 포트가 내려가 있다는 신호다. 케이블 확인을 하러 갔다가 다른 노드의 장애 의심 정황을 덤으로 얻었다.

4. 응용: 스위치 두 대가 한 패브릭인지 판정

두 스위치의 관계도 서버 쪽에서 증명할 수 있었다. 논리는 이렇다:

컨트롤러 노드 ──(OmniSwitch 포트 1005)──> OmniSwitch ──?──> Dell 스위치 ──(Te1/0/4)──> 새 서버

1. 컨트롤러 노드의 LLDP를 확인한다 → OmniSwitch 포트 1005에 꽂혀 있다.
2. 새 서버(Dell 스위치 Te1/0/4)에서 ARP를 방청한다 → 컨트롤러 노드가 보낸 ARP가 들린다.
3. 결론: 두 스위치는 업링크로 연결된 하나의 L2다. 컨트롤러의 브로드캐스트가 Dell 스위치의 이 포트까지 흘러왔으니까.

즉 "스위치가 다르다 = 망이 다르다"가 아니었다. 이 인프라에서 망 분리는 스위치 단위가 아니라 포트 그룹(untagged VLAN 멤버십) 단위로 일어나고 있었고, 그 매핑의 원본은 스위치 설정 안에만 있다.

정리

질문	도구	근거 프레임
케이블 반대편이 어떤 장비인가	tcpdump ether proto 0x88cc	LLDP Chassis ID(OUI)·Port ID 표기법
그 포트는 어느 망 소속인가	tcpdump arp	브로드캐스트가 들리는 대역 = untagged VLAN
스위치 관리 IP는 무엇인가	LLDP Mgmt TLV → ip neigh → 시리얼 콘솔	순서대로 폴백
두 스위치가 같은 L2인가	위 둘의 조합	반대쪽 노드의 ARP 수신 여부

전부 root 권한의 tcpdump 하나로 끝났고, 프레임을 한 발도 보내지 않았다. 운영망에서 "조회는 하되 아무것도 바꾸지 않는다"는 제약이 있을 때, 스위치는 이미 충분히 많은 것을 스스로 말하고 있다 — 듣는 쪽 도구만 있으면 된다.