QFX MAC 가 EVPN 에는 나타나지만 포워딩 테이블에는 나타나지 않는 이유

EVPN 데이터베이스에서 MAC 을 찾는다는 것은 그것이 경로로 광고되었거나 수신되었다는 증거일 뿐, 그 이상은 아니다. 포워딩 테이블은 나중에 프로그래밍되는 별개의 구조이므로, 모든 프로토콜이 올바르게 동작하는데도 같은 MAC 이 한쪽에는 있고 다른 쪽에는 없을 수 있다. 이 두 출력을 서로의 사본으로 취급하면 실제 격차가 임포트 정책이나 해결되지 않은 다음 홉인데도 엔지니어들은 BGP 장애를 쫓게 된다. 물어야 할 질문은 패브릭이 MAC 을 아는지가 아니라 어느 단계에서 전달이 멈췄는지이다.

서로 다른 질문에 답하는 두 테이블

Junos EVPN 에서 데이터베이스는 인스턴스별 MAC 주소를 각각이 어떻게 도착했는지와 함께 나열한다: 액세스 포트에서 학습한 것, Type 2 경로로 수신한 것, 멀티호밍 그룹의 일부로 표시된 것이다. Juniper 의 show evpn database 참조 는 보기를 읽을 수 있게 만드는 MAC 별 및 인스턴스별 필터를 다룬다. 이것은 인스턴스와 MAC 을 키로 한 컨트롤 플레인 요약이며, 하드웨어가 프레임을 스위칭하는 테이블이 아니다.

스위칭 테이블이 바로 그 포워딩 상태다. 두 출력 모두 VLAN 또는 VNI 컨텍스트 옆에 MAC 을 나열하며, 그래서 줄마다 비교되고, 그래서 그 비교가 오해를 부른다. 데이터베이스 항목은 경로가 존재하고 인스턴스에 수락되었음을 말하지만, 플랫폼이 그것을 포워딩용으로 설치했는지는 말하지 않는다.

Type 2 경로는 MAC, 선택적 IP, 레이블 또는 VNI, 경로 구분자, 그리고 원격 VTEP 를 지명하는 다음 홉을 운반한다. 케이블과 그 경로 사이에서 네 가지가 깨질 수 있다: 호스트가 학습되지 않거나, 경로가 광고되지 않거나, 임포트에서 거부되거나, 다음 홉이 해결되지 않는다. 각 실패는 서로 다른 테이블 집합을 채운 채 남기며, 그래서 이 순서를 진단할 수 있다.

로컬 학습은 여전히 먼저 일어난다

흔한 가정은 EVPN 이 MAC 학습을 넘겨받으므로 데이터베이스가 비어 있으면 오버레이 문제라는 것이다. 로컬 학습은 여전히 액세스 쪽에서 동작하며, VXLAN 이 존재하기 전과 똑같다: 스위치는 허용된 프레임의 소스 MAC 을 올바른 VLAN 과 서비스에서 학습하고, 그다음에야 그것을 위한 Type 2 를 생성한다. 관련 프레임을 보내지 않은 호스트는 광고할 것이 없다. VLAN 멤버십, 필터 또는 집계의 다운된 멤버 때문에 프레임이 버려지는 호스트는 오버레이 관점에서 똑같아 보인다.

어태치먼트에서 시작해 읽기 전용 명령으로 앞으로 나아가라. 목표는, 결코 도착하지 않은 프레임을 하류의 무엇도 보상하지 않기 때문에, 호스트의 프레임이 의도한 서비스를 통과했음을 증명하는 것이다.

show interfaces ge-0/0/1.0
show ethernet-switching interface ge-0/0/1.0
show lacp interfaces ae0

번들이 올라와 있는 것보다 선택된 LACP 멤버가 더 중요한데, 이는 집계가 한 멤버에서 올라와 있어도 호스트 트래픽이 다운되거나 차단된 링크로 해시될 수 있기 때문이다. 인터페이스 카운터는, 결코 전송하지 않는 호스트와 분류로 프레임이 버려지는 호스트가 같은 빈 테이블을 남기기 때문에, 조용한 호스트와 드롭하는 호스트를 구분한다.

원격 MAC 이 사라지는 곳

원격 MAC 은 반대 방향에서, 그것도 조용히 실패한다. Type 2 경로가 도착하지만, 경로 대상과 VNI 가 로컬 구성과 일치할 때만 인스턴스로 들어가고, 다음 홉이 도달 가능한 VTEP 로 해결될 때만 사용할 수 있게 된다. 경로 대상 불일치는 어떤 인스턴스도 요청하지 않는 유효한 경로를 BGP 테이블에 남긴다.

세 가지 보기를 순서대로 읽어라: 경로 존재, 데이터베이스 항목, 포워딩 항목이다. 아래 명령은 각 단계에서 같은 MAC 을 질의하며, 예시 주소는 출력을 비교 가능하게 유지한다.

show evpn database instance blue mac-address 02:00:00:00:00:5c extensive
show route table bgp.evpn.0 | match 02:00:00:00:00:5c
show route table bgp.evpn.0 | match 02:00:00:00:00:5c extensive

그 출력은 세 가지 별개의 질문에 답한다. bgp.evpn.0 에 경로가 있지만 데이터베이스 항목이 없으면 임포트 정책, 경로 대상 또는 인스턴스 구성을 가리킨다. 데이터베이스 항목이 있지만 포워딩 항목이 없으면 플랫폼 프로그래밍을 가리키며, 이는 다른 에스컬레이션 경로에 속한다. 다음 홉이 해결되지 않는 활성 경로는 전송 또는 레이블 문제이며, 아무리 MAC 을 디버깅해도 고쳐지지 않는다.

그것을 고친 재부팅은 거의 아무것도 증명하지 못한다

재시작이 증상을 사라지게 하면 구성이 건전할 것이라는 결론으로 끌리기 쉽다. 재부팅은 모든 테이블을 처음부터 다시 프로그래밍하므로, 오래된 항목이 정책 오류를 가리고 있던 경우도 숨기며, 장애는 보통 다음 변경, 링크 플랩 또는 경로 철회에서 돌아온다.

어떤 유지보수 창이든 그 전에 재시작이 무엇을 지울지 기록하라. 이 세 명령이면 전후를 비교하기에 충분하고, 장비에서 아무것도 바꾸지 않는다.

show evpn database instance blue
show route table bgp.evpn.0
show version

그 출력을 날짜와 소프트웨어 빌드와 함께 보관하라. 같은 재시작이 예전에도 효과가 있었다는 나중의 보고는 증거가 아니라 단서이며, 차이는 누군가 이전 출력을 보관했을 때만 보인다.

대부분의 사례를 정리하는 네 가지 관찰

네 가지 관찰로 거의 모든 사례를 다룰 수 있다: 어태치먼트와 그 서비스, 예시 값으로서의 MAC, 경로와 데이터베이스의 상태, 사용 중인 빌드다. 분명히 예시임을 알 수 있는 MAC 을 골라 아무도 운영 주소로 착각하지 않게 하라: 첫 옥텟 02 은 로컬 관리 유니캐스트 주소를 표시하고, 나머지 옥텟은 자유이며, 따라서 02:00:00:00:00:5c 는 안전한 자리 표시자다.

그다음에는 답이 실패한 단계를 가리키게 하라. 어태치먼트에서 학습이 없으면 액세스 쪽이고, 데이터베이스 항목이 없는 경로는 임포트이며, 포워딩 상태가 없는 데이터베이스 항목은 프로그래밍이다. 무엇이든 수집한 출력을 호스트, 인터페이스, 서비스, 빌드와 함께 넘겨 다음 엔지니어가 질의를 반복하는 대신 경로를 재현할 수 있게 하라.