태그 없는 액세스 포트를 올바른 EVPN VNI에 매핑하기

태그 없는 호스트 프레임은 액세스 포트에서 분류된 뒤 VTEP가 VNI로 전달합니다. 인그레스, 이그레스, 서비스 모델을 따로 확인하세요.

일반적인 이더넷 호스트는 태그 없는 프레임을 보내며, EVPN 패브릭은 그 프레임을 올바른 테넌트 서비스로 전달해야 합니다. 액세스 포트가 프레임을 로컬 세그먼트로 분류하고, VTEP가 그 세그먼트를 VNI에 매핑하며, 원격 연결 지점이 호스트가 기대하는 형태로 프레임을 제시합니다. VLAN과 VNI는 이 경로의 서로 다른 부분을 식별하며 같은 번호를 공유할 필요가 없습니다. 아래 runbook을 순서대로 실행하세요. 어느 단계에서든 오류가 나면 증상은 같습니다. 즉 보내지만 아무것도 받지 못하는 호스트입니다.

프레임 하나를 패브릭 전체에서 추적하기

단순한 VLAN 기반 서비스라면 예시 경로는 다음과 같습니다.

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

VLAN과 VNI 번호는 예시일 뿐 규칙이 아닙니다. 로컬 VLAN은 한 대의 스위치에 존재하는 인그레스 분류입니다. L2VNI는 두 VTEP가 모두 이해하는 오버레이 서비스 식별자입니다. 오버레이 규격 RFC 8365는 서비스 식별자를 호스트 연결 방식과 분리하고, VLAN 기반, 번들, VLAN 인지의 세 가지 형태를 제시합니다.

인그레스 분류 구성하기

호스트에는 주소가 있는데 아무것도 도달하지 못하고, 포트 자체는 보입니다. 포트가 실제로 어느 연결 모드에 있는지 판단하세요. 태그 없는 프레임을 전달하는 액세스 포트인지, native VLAN이 있는 trunk인지 확인하고 바로 그 모드를 명시적으로 설정합니다. 태그 없는 프레임은 여전히 이름이 붙은 로컬 세그먼트 안에서 포트를 떠납니다. 그 세그먼트는 플랫폼의 부작용이 아니라 결정입니다. 포트의 실행 중 구성을 열어 실제로 가진 분류를 읽으세요. 한 번도 설정하지 않은 벤더 기본값을 믿지 마세요.

일반적인 스위치에서는 모드 변경과 액세스 VLAN 할당, 이어서 포트가 실제로 up이고 그 상태인지 확인하는 순서입니다. 포트가 trunk라면 태그 없는 프레임은 native VLAN이 처리하며, 그것은 다른 구성이고 실패 방식도 다릅니다. 계속하기 전에 모드와 VLAN을 모두 기록하세요.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

VTEP와 VNI 매핑 구성하기

VTEP가 VXLAN 캡슐화와 VNI를 추가합니다. 호스트는 그 헤더를 생성하지 않으며 서비스가 존재한다는 사실을 알 필요도 없습니다.

플랫폼이 지원하는 명령 형식으로 로컬 VLAN을 L2VNI에 매핑하고, 그 매핑을 서비스 양 끝에서 일관되게 유지하세요. 테넌트 L2VNI와 서브넷 간 라우팅에 쓰는 L3VNI는 서로 다른 객체이며, 번호를 섞으면 L2 경로는 건드리지 않은 채 라우팅이 깨집니다. 또한 원격 VTEP로 가는 정상 언더레이 경로는 구성의 또 다른 계층에 속한다는 점도 기억하세요.

매핑이 틀리면 프레임은 그래도 패브릭으로 들어가 그저 잘못된 서비스에 떨어집니다. 그래서 이 확인은 링크 확인이 아니라 서비스 확인입니다.

이그레스 제시 구성하기

원격 쪽에서는 받은 서비스를 호스트가 기대하는 형태로 되돌려야 합니다. 액세스 포트의 순수 이더넷, 관리하는 trunk의 특정 태그, 그리고 선택한 서비스 모델에 맞는 내부 태그 처리입니다. 오버레이를 탓하기 전에 trunk의 허용 VLAN 목록을 확인하세요. 이그레스 trunk가 허용하지 않는 태그는 오버레이가 이미 일을 마친 뒤에 버려집니다. 원격 호스트가 기대하는 것이 다이어그램에서 가정한 제시가 아니라 실제로 받는 제시인지 확인하세요.

내부 태그가 남는지는 선택한 서비스 모델의 속성이므로, 어떤 글도 일반적으로 제거나 유지를 약속할 수 없습니다. 한 가지 동작을 가정한 설계와 다른 동작을 구현한 플랫폼은 링크 테스트는 통과하고 애플리케이션에서 실패합니다.

로컬 MAC 학습, EVPN 서비스 경로, 원격 연결 매핑을 함께 읽고, ping만이 아니라 애플리케이션이 필요로 하는 이웃 탐색을 구동하세요. 다른 브리지 도메인에서 학습된 MAC 주소는 그곳에서는 완전히 유효하지만 잘못된 서비스를 가리킬 수 있습니다.

호스트 한 쌍으로 검증하기

호스트 한 쌍을 먼저 올리고 두 번째 쌍을 추가하기 전에 전체 경로를 증명하세요. 그런 다음 두 VTEP의 상태를 읽고 같은 서비스 식별자가 양 끝에 나타나는지 확인합니다.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

각 끝마다 네 가지 값을 적으세요. 포트 제시, 로컬 세그먼트, L2VNI, 그리고 이그레스의 반대 방향 제시입니다. 그 기록이 있으면 다음 엔지니어는 호스트가 단순한 태그 없는 연결을 쓰는데 패브릭이 테넌트 서비스를 전달하는 이유를 볼 수 있습니다. 변경이 실패하면 포트를 이전 VLAN으로 되돌리고 같은 쌍을 다시 테스트하세요. 롤백이 추측이 아니라 알려진 상태가 됩니다.

관련 글