MPLS VPN의 RD와 RT: 고유성과 임포트 정책

두 고객 사이트가 10.20.0.0/24를 광고해도 둘 다 하나의 제공자 네트워크 안에서 유효하게 남습니다. 라우트 디스팅기셔는 그 광고들을 서로 구분해 유지하고, 라우트 타깃은 어떤 고객 VRF가 사본을 받을 수 있는지 결정합니다. 두 가지는 설정에서 나란히 나타나지만 전혀 다른 일을 합니다. 이 둘을 혼동하면 그럴듯해 보이면서도 아무것도 고치지 못하는 변경으로 이어집니다.

고객 에지에서 원격 VRF까지 라우트 하나를 따라가 보십시오 그러면 식별 정보는 라우트가 BGP에 들어가기 전에 붙고 배포 정책은 라우트가 수신 제공자 에지에 도달할 때 평가되므로 역할 분담이 구체화됩니다.

VPN-IPv4 라우트는 RD와 IPv4 프리픽스의 조합입니다

RFC 4364는 VPN-IPv4 주소 패밀리를 여덟 바이트 라우트 디스팅기셔와 그 뒤의 네 바이트 IPv4 주소로 정의합니다. RD는 고객 프리픽스 앞에 붙으므로, 서로 다른 사이트의 동일한 프리픽스 두 개는 서로 다른 두 개의 BGP 라우트가 됩니다.

이 구조가 고유성 메커니즘의 전부입니다. 제공자는 고객들이 겹치지 않는 주소 공간에 합의할 필요가 없고, 한 사이트의 라우트가 다른 사이트의 동일한 프리픽스를 조용히 대체할 수도 없습니다.

RD 형식 자체는 관리자가 선택하는 값이며, 보통 자율 시스템 번호와 로컬 번호입니다. 그 숫자 형태는 관례일 뿐이며, 우연히 같은 숫자를 쓰는 라우트 타깃과 두 필드가 의미를 공유한다는 신호가 아닙니다.

RD는 겹치는 프리픽스를 구별 가능하게 합니다

같은 프리픽스에 대한 광고 두 개를 생각해 봅시다. 사이트 A는 RD 65000:101을, 사이트 B는 RD 65000:202를 가지며 둘 다 10.20.0.0/24에 대한 것입니다. 이제 BGP에는 독립적으로 비교하고 필터링하고 선택할 수 있는 VPN-IPv4 라우트 두 개가 있습니다.

RD는 어떤 VRF가 어느 라우트를 받아야 하는지 말하지 않으며 고객이나 서비스를 식별하지도 않습니다. 그것은 라우트의 식별 필드이지 소속 목록이 아닙니다. VRF 자신의 RD가 임포트하는 라우트의 RD와 일치해야 할 의무는 없습니다.

그래서 다른 사이트의 번호에 맞추려고 RD를 바꾸는 것은 아무것도 고치지 않습니다. 반대편에서 라우트가 빠져 있다면, 숫자를 맞추는 것은 임포트 결정을 복구하는 대신 다른 식별 문제를 만듭니다.

RT는 BGP 속성이며 패킷의 태그가 아닙니다

익스포트 정책은 하나 이상의 라우트 타깃을 BGP 확장 커뮤니티 속성으로 라우트에 붙입니다. 수신 제공자 에지는 그 속성들을 각 VRF의 임포트 정책과 비교합니다. RT는 컨트롤 플레인을 통해 라우트와 함께 이동합니다. 비교는 전적으로 라우팅 정책 안에서, 어떤 고객 패킷이 전달되기 전에 일어납니다.

고객 데이터 패킷은 RT를 싣지 않습니다. 라우트가 VRF에 설치되면 전달은 그 VRF의 테이블과 아키텍처가 부여하는 MPLS 레이블 스택을 사용합니다. 제공자 에지는 고객 패킷마다 라우트 타깃을 읽지 않습니다.

라우트는 여러 RT를 실을 수 있고 VRF는 여러 개를 임포트할 수 있습니다. 설정은 흔히 짧은 블록처럼 보입니다:

vrf definition CUST-A
 rd 65000:101
 address-family ipv4
  route-target export 65000:500
  route-target import 65000:500

그 블록은 두 개의 별도 문장으로 읽으십시오. 익스포트 줄은 이 VRF를 떠나는 라우트에 무엇이 붙는지를, 임포트 줄은 이 VRF가 무엇을 고려할지를 제어합니다. 번호가 일치하면 편리하지만 필수는 아닙니다.

임포트 자격은 설치가 아닙니다

라우트는 VRF에 자격이 있어도 그 전달 테이블에 나타나지 않을 수 있습니다. 자격은 필터이고, 그다음 정상적인 BGP 결정 과정이 자격 있는 라우트를 비교해 하나를 선택합니다. 더 오래되었거나 덜 선호되는 라우트는 다른 자격 있는 경로에 질 수 있습니다.

선택된 라우트를 확인하고 임포트 정책만으로 판단하지 마십시오. RT 65000:500을 임포트하면서 10.20.0.0/24에 대한 라우트를 표시하지 않는 VRF는 라우트를 받고 선택 과정에서 거부했거나, 아예 받지 못했을 수 있습니다.

이 구분은 예상치 못한 프리픽스가 나타날 때도 중요합니다. 너무 넓은 임포트 정책은 사이트가 쓰려 하지 않은 라우트까지 끌어올 수 있고, RD의 고유성은 그것을 전혀 막지 못합니다. 배포 범위는 RT 정책의 문제입니다.

빠진 라우트를 컨트롤 플레인 순서로 추적하십시오

광고부터 시작하십시오. 출발 VRF가 의도한 RT를 익스포트하는지, 라우트가 라우트 리플렉터나 수신 PE에 VPN-IPv4 라우트로 존재하는지 확인한 뒤, 송신 측 설정이 아니라 수신된 그대로 속성을 확인합니다.

다음으로 수신 VRF의 임포트 목록과 라우트의 실제 RT 값을 비교합니다. 마지막으로 그 VRF에서 선택된 라우트와 레이블 바인딩을 살펴봅니다. 각 단계는 다른 질문에 답하며, RD로 건너뛰면 보통 잘못된 단계를 놓치게 됩니다.

정상 사이트와 장애 사이트에 대해 RD, 익스포트된 RT, 임포트된 RT, 선택된 넥스트 홉을 기록하십시오. 네 값을 나란히 두면 막연한 “VPN이 라우트를 넘기지 않는다”가 실제로 다른 컨트롤 플레인 단계로 바뀝니다.