Underlay를 탓하기 전에 EVPN 라우터 MAC을 확인하세요

같은 VXLAN 패킷에 두 개의 MAC 주소가 나타나지만, 그중 목적지 호스트의 것은 하나뿐입니다. EVPN VXLAN IP-VRF 간 설계에서 안쪽 목적지 MAC은 출구 라우터가 광고하는 라우터 MAC이고, 바깥쪽 목적지 MAC은 다음 underlay 링크에서 패킷을 전달하는 쪽의 것입니다. 이 둘을 혼동하면 없는 장애를 underlay에서 찾게 됩니다. 점검은 순서대로 하세요.

각 단계는 질문 하나에 답하며, 첫 답이 이후 단계가 관련 있는지를 결정합니다.

1. 프리픽스 경로와 그 커뮤니티를 읽습니다

패킷 캡처가 아니라 경로에서 시작하세요:

show bgp l2vpn evpn route type prefix 10.20.0.0/24

Type 5 경로는 IP 프리픽스를 광고합니다. 인터페이스 없는 IP-VRF 모델에서는 L3 VNI와 확장 라우터 MAC 커뮤니티도 함께 실어 나르며, 바로 이 커뮤니티가 출구 라우팅 종단점을 식별합니다. MAC이 프리픽스 NLRI에 내장되어 있다고 가정하지 말고 커뮤니티를 읽으세요. 실제로 내장되어 있지 않기 때문입니다. 경로가 있고 커뮤니티가 붙어 있다면 제어 평면은 이미 제 몫을 한 것입니다.

2. 어떤 포워딩 모델을 쓰는지 확인합니다

인터페이스 없는 모델과 overlay 인덱스 재귀는 서로 다른 지원 구성입니다. 인터페이스 없는 모델은 패킷을 라우팅하고, 원격 라우팅 종단점을 위한 안쪽 프레임을 만든 뒤 출구 VTEP 쪽으로 캡슐화합니다.

overlay 인덱스 재귀에서는 인그레스 라우터가 포워딩하기 전에 다음 홉을 해석하는 추가 조회가 필요합니다. 두 모델 모두 유효하며, 적용할 절차는 패브릭이 어느 쪽을 쓰는지에 달려 있습니다. 직접 다음 홉 논리를 다른 방식으로 만든 패브릭에 적용하면 캡처에서는 맞아 보이고 설계 검토에서는 틀린 결론이 나옵니다.

3. MAC에는 서로 다른 두 역할이 있습니다

안쪽 목적지 MAC은 출구 라우터가 광고하는 라우터 MAC입니다. 바깥쪽 목적지 MAC은 로컬 전달의 다음 홉이며, underlay 라우터일 수 있고 홉마다 바뀔 수 있습니다. 둘이 다른 것은 정상이고, 둘이 같다는 것은 요구 사항이 아니라 우연입니다. 안쪽에는 섀시 같은 주소가, 바깥쪽에는 물리적인 다음 홉 주소가 찍힌 캡처는 바로 의도된 캡슐화를 보여 줍니다.

4. 섀시에서 파생된 값은 구현 선택으로 다룹니다

플랫폼이 광고하는 라우터 MAC을 시스템이나 섀시 식별자에서 파생할 수 있으며, 이는 프로토콜 규칙이 아니라 구현 결정입니다. 주소 형식에서 무언가를 읽어 내기 전에 벤더의 할당과 이중화 모델을 확인하세요.

둘 다 표준을 지키는 두 구현이 서로 다르게 보이는 라우터 MAC을 광고할 수 있습니다. 그래서 벤더 간 비교로 얻을 수 있는 결론은 거의 없습니다.

5. 상태가 어긋나기 전에는 아무것도 바꾸지 않습니다

검토에서는 선택된 프리픽스 경로, 그 확장 커뮤니티, BGP 다음 홉, L3 VNI, 그리고 그 결과로 나타나는 포워딩 상태를 비교하세요. 그다음 캡처의 안쪽과 바깥쪽 헤더에 표시를 하세요.

이 다섯이 일치하면 이상해 보이는 MAC은 제 역할을 하고 있는 것이므로, 바꾸면 주소 지정 오류를 고치는 대신 라우팅 종단점을 깨뜨리게 됩니다. 일치하지 않으면 어느 필드가 틀렸는지 이제 알고 있으므로, 변경은 추측이 아니라 표적화된 것이 됩니다. EVPN IP 프리픽스 명세 는 그 논의에서 인용할 참고 문헌입니다. 모델과 값을 실어 나르는 커뮤니티를 모두 설명하기 때문입니다.