하나의 EVPN 테넌트에서 여러 route distinguisher가 표시되는 이유
한 테넌트의 두 RD는 충돌이 아닙니다. CLI 출력에서 경로를 생성한 MAC-VRF 또는 IP-VRF까지 추적한 다음 RT 가져오기와 VNI를 확인하세요.
한 테넌트에 대해 EVPN 테이블을 필터링하면 경로가 서로 다른 두 개의 route distinguisher를 갖습니다. 첫 반응은 구성 충돌이지만 그 반응은 대개 틀립니다. 테넌트 이름은 비즈니스 레이블이며 제어 평면의 단일 객체가 아니므로, 그 안의 브리징 컨텍스트와 라우팅 컨텍스트는 별도 식별자로 정당하게 광고할 수 있습니다. 경로를 하나씩 출력에서 그것을 생성한 로컬 서비스 객체까지 거슬러 올라가면 두 번째 RD는 더 이상 실수처럼 보이지 않습니다.
혼란스러웠던 출력에서 시작하세요
전체 테이블 대신 경로 하나를 고르세요. 경로 유형, RD, 내보낸 route target, 다음 홉을 기록합니다. 이 네 필드만으로 어떤 로컬 객체가 광고했는지, 어떤 원격 정책이 가져와야 하는지 식별할 수 있습니다.
NX-OS 스타일 장비에서는 세부 보기를 다음 명령으로 얻습니다: show bgp l2vpn evpn route-type 2 detail 또는 show bgp l2vpn evpn route-type 5 detail. Junos에서는 같은 정보가 다음에 있습니다: show route table bgp.evpn.0 detail. 구문은 달라도 필드는 같습니다.
표시된 모든 숫자를 같게 만드는 것으로 시작하지 마세요. RD를 같게 만드는 것이 바로 작동 중인 fabric에서 가져오기 정책을 깨뜨리는 변경입니다.
각 식별자에 역할을 부여하세요
| Identifier | Question it answers | Where it is used |
|---|---|---|
| Route distinguisher | Which distinct route context contributed this advertisement? | Makes otherwise identical prefixes unique in BGP |
| Route target | Which importing service policy should receive the route? | Extended community matched by import policy |
| VNI | Which VXLAN service context carries the traffic? | Data plane encapsulation and mapping |
MAC-VRF는 브리징 서비스를 위한 MAC 전달 정보를 보관합니다. IP-VRF는 라우팅되는 서비스를 위한 IP 라우팅 컨텍스트를 제공합니다. 테넌트는 둘 다 포함할 수 있으므로 구성 오류 없이도 한 테넌트가 둘 이상의 RD를 만들 수 있습니다.
RFC 7432는 광고하는 MAC-VRF의 RD를 해당 EVPN NLRI에 할당하고 같은 PE의 MAC-VRF 사이에서 서로 다른 RD를 요구합니다. route-target 절차는 별개입니다. 하나 이상의 RT 속성을 허용하고 멤버십은 가져오기 정책에 의존합니다. 공유 멤버십을 만드는 것은 RD의 동일성이 아니며, 그렇게 다루는 것이 이 혼란의 뿌리입니다.
광고에서 가져오기까지 경로 하나를 따라가세요
경로를 한 방향으로 따라갑니다. 경로 유형, 생성한 서비스, RD, 내보낸 RT, 그리고 수신 PE의 가져오기 정책을 확인합니다. 각 단계는 서로 다른 질문에 답하며, 어느 단계에서든 실패는 반대편에서 같은 프리픽스가 빠진 것처럼 보입니다.
경로가 있으면 설치된 전달 컨텍스트와 VNI 매핑을 살펴보세요. 양쪽 끝에서 VNI가 일치한다는 것은 데이터 평면이 동의한다는 뜻이며, 제어 평면이 의도한 정책으로 경로를 가져왔다는 뜻은 아닙니다.
경로가 원격 PE에 나타나는데 트래픽이 흐르지 않는다면 문제는 EVPN을 넘어섰습니다. route target을 다시 편집하기 전에 VNI-VLAN 또는 VNI-VRF 바인딩과 underlay 경로를 확인하세요. 매핑에서 시작해 underlay로, 그다음에야 제어 평면으로 가세요. 데이터 평면 장애를 쫓느라 route-target 변경을 되돌리는 것은 작동하는 가져오기를 깨뜨리는 확실한 방법입니다.
레이어 3 프리픽스도 여전히 EVPN 경로입니다
EVPN 테이블의 IP 프리픽스는 일반 IPv4-unicast BGP가 아닙니다. EVPN IP Prefix 경로는 그 자체의 경로 유형이며, MAC/IP와 IP 프리픽스 광고는 EVPN 주소 패밀리를 통해 전달되며, RFC 7432는 이를 AFI 25와 SAFI 70으로 식별합니다.
이 구분은 EVPN 테이블의 경로를 유니캐스트 테이블의 경로와 비교할 때 중요합니다. 같은 목적지를 설명하면서도 서로 다른 정책으로 생성, 필터링, 가져오기될 수 있습니다. 하나를 다른 하나의 증거로 읽는 것이 바로 올바른 fabric이 마이그레이션 중에 깨진 것처럼 보이는 이유입니다.
숫자를 비교하기 전에 벤더의 유도를 확인하세요
RFC 9136은 EVPN을 IP Prefix 경로로 확장하고 적용되는 RD가 MAC-VRF와 IP-VRF 중 어느 컨텍스트에서 오는지 규정합니다. 그래서 같은 출력의 L2 서비스 레이블과 라우팅되는 서비스 레이블은 속한 객체를 기준으로 읽어야 하며, 테넌트마다 하나의 RD로 축소해서는 안 됩니다.
RD와 RT의 자동 유도는 벤더별입니다. 사용 중인 공식에 대해서는 배포된 벤더의 참조 문서를 읽으세요. 한 스위치에서 본 자동 생성 값은 보편적인 인코딩이 아니며, 두 벤더의 숫자를 비교해도 거의 아무것도 증명하지 못합니다.
시작했던 경로에 대한 서면 추적으로 마무리하세요. 유형, 생성 객체, RD, 내보낸 RT, 가져오기 정책, 설치된 VNI입니다. 여섯 개 필드면 다음에 티켓을 읽는 사람에게 광고를 설명할 수 있고, 그중 어느 것도 테넌트의 숫자를 맞추라고 요구하지 않습니다.