MPLS VPN에서의 IPv6: 하나가 아닌 세 가지 선택
고객 VPN 경로, PE 간 BGP 세션, 코어 전송은 별개의 결정이다. 세션은 한 주소 패밀리로 동작하면서 다른 패밀리를 실을 수 있다.
설계 검토에서 “IPv6 BGP 위에서 IPv6 L3VPN을 돌려라”라고 말하면, 그 한 문장 안에 세 가지 별개의 결정이 숨어 있다. 어떤 프리픽스가 고객의 VPN에 속하는지, 어떤 주소가 제공자 에지 사이의 라우팅 세션을 나르는지, 어떤 코어가 레이블이 붙은 패킷을 옮기는지는 각각 독립적인 선택이다. 모두 IPv6일 수도, 섞여 있을 수도 있으며, 섞는 것은 의도적으로 허용된다. 이 셋을 풀어내는 일이 모호한 요구사항을 플랫폼으로 시험할 수 있는 무언가로 바꾼다.
세 가지 일을 분리하라
첫 번째 일은 고객 경로, 즉 하나의 VPN 라우팅 컨텍스트에 속하고 다른 어떤 컨텍스트로도 새어 나가면 안 되는 IPv6 프리픽스다. 두 번째는 그 프리픽스를 교환하는 제공자 에지 라우터 사이의 라우팅 연결이다. 세 번째는 레이블이 붙은 고객 패킷을 코어를 지나 원격 에지까지 나르는 전송이다. 그중 하나만 이름 붙이는 것은 아직 설계가 아니다.
| Job | The question it answers | What confusion looks like |
|---|---|---|
| Customer VPN routes | Which IPv6 prefixes belong to each VPN context, and how are they kept apart? | Prefixes leak into the global table and between customers |
| PE-to-PE BGP session | Which addresses carry the routing connection between the two edges? | A session-family mismatch gets chased as a core transport fault |
| Transport to the remote PE | How does the chosen core move the labelled packet to the far edge? | A route is present and unforwardable in the same moment |
각 일에는 고유한 주소 패밀리와 고유한 고장 방식이 있고, 대개 팀도 따로 있다. 표가 유용한 이유는 설계 문서의 한 문장이 세 줄을 하나로 눌러 버리는 경향이 있기 때문이다.
경로의 패밀리는 IPv6 유니캐스트가 아니라 VPN-IPv6다
RFC 4659 BGP/MPLS IPv6 VPN 패밀리를 정의하며, 그 소속은 IPv6라는 단어가 시사하는 것보다 구체적이다. 그곳의 경로는 IPv6 프리픽스에 결합된 경로 구분자이고 AFI 2와 SAFI 128 아래에서 인코딩된다. 보통의 IPv6 유니캐스트는 다른 패밀리이므로 looking glass에서 프리픽스처럼 보이는 광고가 같은 객체가 아닐 수도 있다. 패밀리를 잘못 읽는 것이 이 설계가 어긋나는 첫 번째 길이다.
차이는 경로가 무언가를 하기 전에 올바른 VPN 컨텍스트에 들어가야 하는 에지에서 드러난다. 프리픽스를 받았다는 것은 교환이 일어났음을 증명할 뿐 설치에 대해서는 아무 말도 하지 않는다. 그 간극이 세션은 살아 있는데 고객은 여전히 어둠 속에 있다는 전형적인 보고를 만든다.
세션은 VPN과 다른 패밀리로 동작할 수 있다
두 에지 사이의 BGP 연결이 VPN 자체의 패밀리를 쓰도록 강제하는 것은 아무것도 없다. 명세는 IPv4나 IPv6 세션을 허용하고, IPv6 VPN 전송 자체가 두 코어 유형 위에서 정의된다. 따라서 IPv6 세션은 자기가 나르는 것의 패밀리에 대해 아무 말도 하지 않으며 데이터 평면도 고르지 않는다. 세 개의 독립된 비트이고, 설계는 셋을 각각 따로 담아야 한다.
이는 자유롭게 해 주는 동시에 같은 숨에 잘못 읽기 쉽다. IPv6 고객 경로는 IPv4 주소의 세션 위에 올 수 있고, IPv4 경로는 IPv6 세션 위에 올 수 있으며, 그 조건은 플랫폼이 그 조합을 지원하고 다음 홉이 해석되는 것이다. 일어나서는 안 되는 것은 세션이 페이로드를 암시하게 두는 일이며, 설계 문서에서든 나중에 서비스를 입증하는 모니터링에서든 마찬가지다.
IPv4 코어에서 다음 홉은 고유한 인코딩을 가진다
VPN 아래의 코어가 IPv4이면, 경로는 인그레스 에지가 곧바로 쓸 수 있는 다음 홉으로 나타나지 않는다. IPv4로 매핑된 IPv6 형태로 도착하며, 아래 전송이 IPv4일 때 명세가 이그레스 에지를 표현하는 방식이 그것이다. 그러면 인그레스 라우터는 그 매핑된 주소를 코어를 건너 실제로 도달할 수 있는 무엇으로 바꿔야 하고, 해석이야말로 조용히 실패하는 단계다.
이것은 장비 사이에 복사할 문자열이 아니라 포워딩 의존성으로 읽어야 한다. 실제로 운영하는 플랫폼에서 광고된 다음 홉이 쓸 수 있는 경로로 해석되는지, 레이블 스택이 받아들여지는지, 목적지가 의도한 VPN 컨텍스트에 들어가는지를 확인하라. 어느 하나라도 어긋나면 건강해 보이면서 아무것도 포워딩하지 않는 세션이 남으므로, 이 점검은 나중의 장애가 아니라 인수 시험에 속한다.
요구사항을 네 줄로 써라
시험할 가치가 있는 요구사항은 VPN 패밀리, 세션 전송, 다음 홉 인코딩, 코어 구성이라는 네 가지를 지목한다. 이어서 교환, 설치, 레이블 해석, 되돌아오는 경로를 거쳐 끝에서 끝까지 따라갈 고객 프리픽스 하나를 지목한다. “IPv6 BGP를 지원한다”는 네 가지 중 어느 것도 덮지 못하고 불일치가 실제로 어디에 있는지를 감춘다.
VPN-IPv6 교환 없이 건강한 세션은 불완전하고, 포워딩이 동작하지 않는 채 받은 VPN 경로도 똑같이 불완전하다. 이 둘을 별도의 인수 항목으로 두면 실패하는 항목이 이미 적혀 있으므로 다음 트러블슈팅 대화가 짧아진다.