BGP가 프리픽스를 배웠지만 트래픽은 여전히 터널을 비켜 간다

지사 게이트웨이는 BGP 테이블에 클라우드 프리픽스를 보여 주고 공급자와의 세션도 맺어져 있는데, 그 프리픽스로 향하는 사용자 요청은 여전히 잘못된 인터페이스로 나갑니다. 모니터링이 암시하는 것처럼 무언가가 고장 난 것은 아닙니다. “BGP가 배웠다”는 것은 제어 평면에 관한 진술이기 때문입니다. 그 테이블과 패킷 사이에는 네 개의 별개 전이가 있고, 흐름은 그중 정확히 하나에서 멈춥니다. 게이트를 순서대로 짚어 보고 처음 실패하는 곳에서 멈추십시오.

첫 번째 게이트: 이웃이 실제로 보낸 것

요약된 형태가 아니라 수신된 그대로의 프리픽스에서 시작하십시오. BGP 테이블에서 정확한 네트워크와 마스크를 찾아 다음 홉, AS 경로, 그리고 가져오기 정책이 일치시킬 수 있는 커뮤니티를 기록합니다. 대시보드의 요약 경로는 그 특정 프리픽스가 한 번도 수락되지 않았다는 사실을 감출 수 있습니다.

가져오기 정책은 경로가 오류도 없이 사라지는 흔한 지점입니다. 프리픽스 목록, 커뮤니티 필터, 수신 경로 맵은 세션이 올라가고 건강한 상태에서도 업데이트를 버릴 수 있습니다. 그래서 초록색 이웃 표시등은 거의 아무것도 증명하지 못합니다. 로그 한 줄이 없다고 해서 결정이 없었던 것은 아닙니다. 대개는 설정된 그대로 조용히 결정이 내려졌다는 뜻입니다.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

출력은 그 순서대로 읽으십시오. 처음 두 명령은 정보가 도착했는지와 피어가 무엇을 보냈다고 주장하는지를 알려 주고, 마지막 두 명령은 무언가가 경로 테이블과 전달 테이블에 도달했는지를 알려 줍니다. 첫 명령에 있고 세 번째에 없는 프리픽스는 선택이나 설치의 문제이지 연결성 문제가 아닙니다.

두 번째 게이트: 선택, 그다음 설치

BGP는 최선의 경로를 고르지만 고른 경로가 자동으로 설치되지는 않습니다. 다음 홉이 해석되어야 하고, 다른 경로 원천이 더 나은 관리 거리로 그 프리픽스를 이미 소유하고 있을 수 있습니다. 이전 작업에서 남은 정적 경로는 유효한 BGP 경로를 손쉽게 이기고 트래픽을 다른 곳으로 보냅니다.

RFC 4271은 세 가지 개념을 분리해 둡니다. 피어가 보낸 것, 이 스피커가 최선으로 고른 것, 그리고 앞으로 광고할 것입니다. 이것은 개념적 역할이지 공급자가 반드시 노출해야 하는 세 개의 물리적 데이터베이스가 아닙니다. 그러나 바로 그 분리 때문에 “BGP에 있다”는 불완전한 답이 됩니다.

어떤 라우팅 컨텍스트를 읽고 있는지도 확인하십시오. 사용자의 인터페이스가 속하지 않은 VRF에 설치된 경로는 그 사용자의 패킷에는 보이지 않으며, 테이블은 내내 올바르게 보입니다.

세 번째 게이트: 이 흐름에 적용되는 조회

이제 경로를 묻는 것을 멈추고 패킷을 물어보십시오. 사용자의 출발지 주소, 목적지, 프로토콜, 포트, 수신 인터페이스를 기록하십시오. 각각이 서로 다른 정책을 선택할 수 있기 때문입니다. 그런 다음 일반 경로 테이블이 아니라 그 조합에 적용되는 조회를 보십시오.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

여기서 가장 흔한 의외의 요소는 더 구체적인 프리픽스이고, 두 번째는 정책 경로입니다. 둘 다 보고 있던 집계를 덮어쓰며, 어느 것도 BGP 테이블 요약에는 나타나지 않습니다.

게이트웨이 자체에서 보낸 핑은 사용자 세션에 대한 증거가 아닙니다. 출발지 주소가 다르고, 정책 경로가 다르며, 결과도 다른 경우가 많습니다. 애플리케이션이 쓰는 것과 같은 출발지로 시험하거나, 그 시험이 다른 질문에 답한다는 점을 받아들이십시오.

네 번째 게이트: 경로의 먼 쪽 절반

로컬 조회가 정말 터널을 선택했다면, 패킷은 여전히 보호 정책에 수락되고 전달 규칙에 허용되며 반대편의 무언가가 응답해야 합니다. 주소 쌍을 포함하지 않는 암호화 ACL은 터널이 올라가 있다고 보고하는 동안 트래픽을 버리며, 이는 라우팅 장애와 구별할 수 없는 시간 초과를 만듭니다.

돌아오는 경로는 나가는 경로만큼 중요합니다. 클라우드 쪽은 지사 출발지에 어떻게 도달할지 알아야 합니다. 경로를 통해서든, 의도적으로 구성한 변환을 통해서든 마찬가지입니다. 비대칭 반환 경로는 한 방향으로만 시험한 설계에서 흔합니다.

새로 승인된 연결을 세 가지 관찰과 대조하십시오. 일치한 로컬 정책, 움직인 터널 카운터, 그리고 보이는 경우 먼 쪽의 수신입니다. 카운터가 움직이지 않으면 경로 테이블이 무엇이라 하든 패킷은 터널에 들어가지 않았습니다. 움직이는데 아무것도 도착하지 않으면 먼 쪽이 버리거나 잘못 라우팅하는 것입니다. 이 두 결과는 전혀 다른 팀으로 이어집니다.

실패한 전이의 이름을 붙이십시오

결과를 다섯 상태 중 하나로 적으십시오. 수신되지 않음, 정책에 수락되지 않음, 선택되지 않음, 설치되지 않음, 또는 이 흐름과 일치하지 않음. 로컬 경로는 올바른데 먼 쪽이 응답할 수 없는 경우를 위한 여섯 번째를 더하십시오. 그 문장이 산출물이며, 설정된 이웃의 스크린샷보다 훨씬 유용합니다.

승인 계획에는 부정 시험도 남기십시오. 터널을 지나서는 안 되는 목적지를 변경 후에 확인합니다. 좋은 경로만 증명하는 점검 목록은 다음 유지보수 시간에 누군가 추가하는 넓은 정책 규칙을 잡아내지 못합니다.