두 고객이 같은 /24? VPNv4에는 RD와 레이블이 필요하다

두 테넌트가 같은 10.50.0.0/24로 지사를 번호 매기고, 변경 후 한 테넌트의 경로는 프로바이더 에지에서 사라지지만 다른 하나는 계속 동작한다. 그 티켓 뒤의 단순화는 보통 "레이블이 이미 고객을 식별한다"는 이유로 경로 구분자(RD)를 빼는 것이다. 그렇지 않다. RD와 레이블은 서로 다른 두 질문에 답하며, 그 간극은 중복 주소가 강제할 때만 드러난다.

두 개가 있어야 할 곳에 하나뿐인 경로

일반 IPv4 유니캐스트는 같은 프리픽스로 가는 두 경로를 비교해 더 나은 쪽을 설치한다. 테넌트 A의 10.50.0.0/24와 테넌트 B의 10.50.0.0/24는 하나의 키이므로 하나가 이기고 다른 하나는 백업 경로로만 살아남는다. 프로토콜은 시킨 대로 했다. 제어 평면은 서로 다른 두 경로를 하나의 식별자 아래 저장하라는 요구를 받은 것이다.

결과는 오류가 아니라 사라진 경로처럼 보인다. 경쟁에서 진 PE가 여전히 자기 테넌트를 로컬로 전달하므로 사이트 내부 핑은 성공하고 사이트 간 시험은 실패한다. 어떤 정책이든 손대기 전에 VPNv4 테이블에서 그 프리픽스의 항목을 세어 보라.

RD가 하나의 키를 둘로 만든다

여덟 바이트 경로 구분자가 IPv4 프리픽스 앞에 붙고, BGP가 운반하는 객체는 IPv4 프리픽스 대신 VPN-IPv4 주소가 된다. 두 테넌트가 같은 32비트를 가질 수 있는 것은 앞의 64비트가 다르기 때문이다. AS 기반 RD와 주소 기반 RD를 위한 형식 유형이 있고 선택은 원천 PE의 몫이다. PE가 같은 AS를 공유하면 AS 기반 RD가 흔하고, 공유하지 않으면 주소 기반이 흔하다.

RD를 멤버십 태그로 읽지 말라. 경로 대상은 가져오기와 내보내기를 제어하고 어떤 VRF가 경로를 설치할 수 있는지 결정한다. RD는 경로가 자기 정체성을 가진다는 것만 보장한다. 각 VRF에 자기 RD를 주는 것이 흔한 관행인데, 그 대응 관계를 경로 뷰어에서 읽을 수 있게 유지하기 때문이다.

레이블은 로컬 전달 명령이다

모든 광고는 MPLS 레이블도 함께 운반하며 그 의미는 이를 할당한 라우터에 한정된다. 다른 PE가 무관한 목적지에 같은 번호를 부여할 수 있다. 바로 그래서 레이블은 고객 정체성을 대신할 수 없다. 번호는 다음 홉과 이를 설치한 전달 상태 옆에서만 옳다.

할당 세분성은 구현과 설계에 따라 다르다. 어떤 플랫폼은 VRF마다 레이블 하나를 할당하고, 다른 플랫폼은 프리픽스마다 할당하며, 레이블은 고객이 아니라 전달 동작을 식별할 수도 있다. 같은 목적지에 도달하는 서로 다른 두 레이블은 모순이 아니고, 두 PE에서 같은 레이블 번호인 것도 모순이 아니다.

하나가 다른 하나를 대신할 수 없는 이유

광고를 읽는다는 것은 네 가지를 함께 보는 것이다. RD로 한정된 프리픽스, 경로 대상, 다음 홉, 레이블이다. 사용자 패킷을 읽는다는 것은 그 정보로 설치된 스택을 보는 것이다. 건강한 설계는 양쪽이 일치함을 보여 주고, 망가진 설계는 보통 한쪽은 옳고 다른 쪽은 낡아 있다. 그 비교가 정체성 문제와 전달 문제를 갈라 놓는다.

제어 평면과 데이터 평면의 정돈된 대비는 교육용 장치이지 인코딩에 대한 설명이 아니다. RFC 8277 레이블을 레이블이 붙은 NLRI 안에 넣으므로 광고 자체가 바인딩을 운반한다. 그것을 전달에 쓰는 것은 이후의 별개 단계다.

테넌트 경로가 사라지면 이 순서로 확인하라. 프리픽스에 대한 VPNv4 항목 두 개, 각 항목의 올바른 경로 대상, 해석 가능한 다음 홉, 수신 PE가 상태를 가진 레이블이다. 정체성을 전달 값으로 고치거나 그 반대로 하면 한 검사는 통과하고 다음 검사에서 실패한다.