MPLS L3VPN 랩에서 ping이 안 되나요? 점검할 다섯 지점

고객 라우터 두 대, 프로바이더 에지 장비 한 쌍, 그리고 오류 메시지도 없이 죽는 ping. 작은 MPLS L3VPN 랩에서 장애는 거의 항상 다섯 개 점검 지점 중 하나에 있고, 각 지점에는 의존성이 동작하는지 빠졌는지를 보여 주는 명령이 있다. ping이 실패할 때마다 의존성을 순서대로 시험하지 않고 BGP를 재시작하는 것이 실수다. 곧바로 VRF 설정으로 뛰어들면 두 장비 건너의 해결되지 않은 넥스트 홉에서 시작된 문제에 한 시간을 쓸 수 있다.

목록은 아래에서 위로 진행한다. 통과한 지점은 통과한 채로 두고, 첫 번째 실패가 디버깅할 가치가 있는 곳이다.

첫째 점검 지점: PE끼리 서로 도달한다

각 PE는 상대 PE의 루프백으로 가는 경로가 필요하고, 그 경로는 실제하는 무언가를 통해 해석되어야 한다. 보통은 내부 게이트웨이 프로토콜로 도달하지만, 재귀 조회가 살아 있는 인접에 착지하기만 하면 정적 경로도 동작한다. IOS 계열 장비에서는 show ip route 10.0.0.2에 이어 show ip cef 10.0.0.2을 실행하면 프리픽스가 있는지, 해석된 인접이 있는지 알 수 있다. 뒤에 인접이 없는 테이블상의 경로는 도달 가능성이 아니다.

양방향을 확인한다. 비대칭 IGP 코스트, 잘못된 쪽의 패시브 인터페이스, 루프백을 걸러 내는 분배 목록은 각각 한 방향만 깨뜨리며, 한 방향만으로도 세션은 죽는다. 루프백은 ping이 되는데 BGP 세션이 Active에 머문다면, 다른 것을 건드리기 전에 업데이트 소스를 보라.

둘째 점검 지점: 레이블 경로가 존재한다

원격 루프백으로 가는 IP 경로는 트랜스포트가 레이블을 밀어 넣는다는 증거가 아니다. LDP 설계에서는 원격 루프백에 로컬 및 원격 바인딩이 있고, 출력 레이블이 포워딩 테이블에 나타나는지 확인한다. show mpls ldp bindings 10.0.0.2 32는 레이블 쌍을 보여 주고, show mpls forwarding-table 10.0.0.2는 라인 카드가 실제로 무엇을 넣을지 보여 준다. 두 번째 명령이 「no label」을 표시하거나 IP로 펀트하면, 트랜스포트는 설계가 가정한 방식으로 VPN 트래픽을 나르지 않는 것이다.

이 구분은 MPLS가 포워딩 상태를 목적지 프리픽스와 분리하는 방식에서 나오며, 그것이RFC 3031에 설명된 모델이다. 랩에서 LDP 대신 RSVP-TE나 BGP 인접 레이블을 쓴다면 그 메커니즘 자체의 상태를 확인하고, LDP가 모든 언더레이 레이블을 배포한다고 가정하는 것은 유령 버그를 쫓는 흔한 방법임을 알아 두라. 끊긴 레이블 경로는 보통 나중에 존재하지만 쓸 수 없는 VPN 경로로 나타난다.

셋째 점검 지점: VPN 경로가 온전히 도착했다

세션 요약이 아니라 정확한 고객 프리픽스의 VPNv4 또는 VPNv6 경로를 보라. show bgp vpnv4 unicast all 10.10.1.0/24는 라우트 디스팅기셔, 원격 PE 루프백으로 설정된 넥스트 홉, 그리고 레이블을 보여 줘야 한다. 프리픽스가 없다면 발신 PE의 익스포트 정책이나 수신 PE의 임포트 정책이 첫 용의자이고, route target이 늘 그렇듯 원인이다.

route target 검사는 BGP 수신과 별도로 읽어라. 경로가 올바른 넥스트 홉으로 도착해도 import target이 맞지 않아 VRF에 들어가지 못할 수 있다. 수신 PE에서는 show ip route vrf CUSTOMER 10.10.1.0가 의미 있는 시험이며, BGP 테이블은 경로가 컨트롤 플레인을 건넜다는 것만 증명한다.

넷째 점검 지점: 인터페이스가 VRF 안에 있다

라우트 디스팅기셔와 route target이 있는 VRF 정의는 어떤 인터페이스도 그 안으로 옮기지 않는다. CE 쪽 인터페이스에는 VRF 할당이 필요하고, show ip vrf interfaces나 show ip interface brief가 올바른 인스턴스 아래에 그것을 나열해야 한다. 복사한 설정이 가장 자주 틀어지는 지점이 여기인데, VRF 블록은 완전해 보이지만 인터페이스는 여전히 글로벌 테이블에 앉아 있기 때문이다.

그다음 PE가 로컬 고객 프리픽스를 그 VRF로 학습했는지, CE가 연결을 통해 돌아가는 경로를 갖는지 확인한다. CE의 정적 기본 경로가 PE를 가리키면 PE의 VRF에 CE LAN으로 가는 경로가 있는 한 랩에는 충분하다. 어느 한쪽이 빠지면 레이블이 붙기 전에 ping이 실패한다.

다섯째 점검 지점: 응답이 집으로 가는 길을 찾는다

두 패킷이 서로 다른 테이블을 쓰므로 전달 패킷을 추적한 다음 반환 패킷을 추적하라. 인그레스 PE에서는 고객 출발지가 VRF 안에서 원격 레이블을 가진 원격 프리픽스로 해석되어야 한다. 이그레스 PE에서는 목적지가 같은 VRF 안에서 CE 쪽 인터페이스로 해석되어야 한다. PE 자신에서 출발한 ping은 증거가 아니다: 글로벌 테이블이나 다른 출발지 주소로 나갈 수 있으므로 ping vrf CUSTOMER 10.10.2.10 source 10.10.1.1가 실행해야 할 시험이다.

호스트 방화벽, 역경로 필터링, CE 액세스 목록은 여전히 적용된다. 전달 경로가 동작하는데 응답이 죽는다면 문제는 반환 쪽의 경로나 필터이지 MPLS 트랜스포트가 아니다.

점검 지점마다 처음 실패한 의존성을 적은 한 줄 기록을 남겨라. 그 기록은 「고객이 ping을 할 수 없다」를 도달성, 레이블 상태, 경로 임포트, 인터페이스 소속, 반환 경로에 관한 구체적인 질문으로 바꾸고, 다음 디버깅 세션이 같은 다섯 명령을 같은 순서로 반복하지 않게 한다.