조용한 EVPN 호스트는 끝내 해결되지 않습니다: ARP를 따라 바인딩까지 가십시오

엔드포인트가 연결되어 있고 포트도 살아 있는데 모니터링 호스트는 여전히 도달하지 못합니다. 누군가 반대편에서 ping을 실행하면 동작하기 시작하고, 그래서 문제는 간헐적으로 보이고 fabric은 결백해 보입니다. 이 패턴이 조용한 호스트의 특징입니다. 전송이 드물기 때문에 연결 상태보다 fabric의 탐색과 갱신 동작이 더 중요합니다. 대상 IP, MAC, 브리지 도메인을 하나 정하고 다음 확인 응답 교환을 추적하십시오.

다음 ARP 또는 ND 교환을 추적하십시오

IPv4라면 요청하는 호스트의 ARP 교환을 지켜보고, IPv6라면 Neighbor Solicitation과 Advertisement를 추적하십시오. 요청이 의도한 로컬 세그먼트와 의도한 VNI로 들어가는지 확인하십시오. 올바른 브리지 도메인에 결코 도달하지 않는 요청에는 어떤 프록시도 응답할 수 없습니다.

다음으로 fabric이 대상에 대해 무엇을 아는지 보십시오. MAC만 있는 경로는 Layer 2 목적지를 식별할 수 있지만 프록시에는 아직 그에 대한 IP-to-MAC 바인딩이 없습니다. 이들은 별개의 레코드이며, 하나를 확인해도 다른 하나에 대해서는 아무것도 알 수 없습니다.

유효한 바인딩이 있으면 프록시는 정책에 따라 응답할 수 있지만, 그 바인딩의 MAC에는 여전히 활성 전달 경로가 필요합니다. 바인딩이 없으면 요청은 플러딩 또는 복제 경로를 통해 엔드포인트의 연결에 도달해야 응답에서 무언가를 배울 수 있습니다.

일치해야 하는 두 레코드

MAC 경로는 이더넷 주소가 어디에 있는지 답합니다. 프록시 테이블은 어느 IP가 어느 MAC에 매핑되는지 답합니다. 최근에 말하지 않은 호스트는 완전히 좋은 MAC 경로를 가지면서 사용할 수 있는 프록시 항목이 없을 수 있고, 그것이 바로 건강한 연결에서 확인 실패를 만드는 상태입니다.

원격 연결에서 엔드포인트가 실제로 교환을 받고 응답하는지 확인하십시오. 그 응답은 로컬 학습과 해당 EVPN 광고를 갱신하므로 수동 ping이 문제를 고치는 것처럼 보입니다. fabric이 기다리던 트래픽을 당신이 만든 것입니다. 수정이 지속되지 않는 이유도 같습니다. 갱신된 항목이 만료되면 엔드포인트는 다시 조용해집니다. 예약된 ping은 증상만 다루고 설계의 틈을 감춥니다.

응답 후에는 선택된 경로와 설치된 전달 상태를 요청자 쪽으로 되짚어 가십시오. 확인 성공과 전달 성공은 별개의 사건이며, 이를 혼동하는 티켓은 당신을 잘못된 계층으로 보냅니다.

표준이 실제로 가정하는 것

RFC 9161 은 동적 프록시 학습과 알 수 없는 ARP 및 ND 요청의 기본 플러딩을 설명합니다. 그 플러딩의 완전한 억제는 학습이나 프로비저닝 가정이 그것을 안전하게 만드는 배포로 제한되며, 이는 대부분의 구성 안내서가 시사하는 것보다 좁은 조건입니다.

새로 발견된 엔드포인트를 기대하는 fabric에는 그 요청을 위한 동작하는 경로가 필요합니다. 누군가 BUM 트래픽을 줄이려고 알 수 없는 요청 플러딩을 껐다면, 조용한 호스트가 그 비용을 치르는 집단이며 증상은 몇 주 뒤 간헐적 도달성 불만으로 나타납니다.

억제 설정을 fabric이 무엇을 알겠다고 약속하는지에 대한 진술로 읽으십시오. 바인딩을 공급하는 것이 아무것도 없다면 그 약속은 드문 송신자에게 사실이 아닙니다. 구성된 억제를 그것을 공급해야 하는 프로비저닝 시스템과 비교하십시오. 둘이 일치하지 않으면 fabric은 구성대로 동작하는 것이고, 고쳐야 할 것은 기대입니다.

갱신, 에이징, 그리고 정적 대안

표준은 동적 항목이 만료되기 전에 지원되는 갱신 프로브를 설명합니다. 응답은 관련 브리지와 프록시 상태를 갱신하며, 응답이 없으면 제거와 경로 철회로 이어질 수 있습니다. 이것은 모든 타이머를 늘려 억제할 버그가 아닙니다.

에이징 타이머를 무기한 늘리는 것은 보이는 실패를 오래된 실패로 바꾸는 것입니다. fabric은 호스트가 떠난 위치를 계속 광고합니다. 구현의 문서화된 제어를 사용하고 엔드포인트가 말할 것으로 합리적으로 기대되는 빈도에 맞는 수명을 선택하십시오.

알려지고 관리되는 엔드포인트에는 정적 또는 컨트롤러가 프로비저닝한 바인딩이 정당한 두 번째 모델입니다. 교체와 이동을 처리할 소유자가 필요합니다. 호스트가 다른 포트로 옮겨가도 프로비저닝된 레코드는 스스로 갱신되지 않기 때문입니다.

다음 티켓 전에 기록할 것

바인딩의 출처, 마지막 갱신 시각, 현재 위치, 철회 이벤트를 MAC 경로 옆에 두십시오. 그 기록은 티켓이 실제로 묻는 질문에 답합니다. 애플리케이션이 탐색을 기다리는지, 오래된 상태에 의존하는지, 아니면 확인에 성공한 뒤 전달에 실패하는지.

그다음 세 가지 중 무엇을 운영할지 정하십시오. 플러딩을 동반한 탐색, 현실적인 수명의 갱신, 소유자를 둔 프로비저닝은 모두 옹호할 수 있습니다. 하나를 위해 구성되었으면서 다른 것처럼 행동하기를 기대받는 fabric이 바로 조용한 호스트가 사라지는 곳입니다.