VXLAN에서 MPLS IP VPN으로: VNI는 MPLS 레이블이 아니다
두 캡슐화 모두 레이블을 운반하므로 팀은 VNI를 MPLS 레이블에 매핑하려 합니다. 대신 라우티드 핸드오프나 지원되는 게이트웨이를 사용하십시오.
두 기술 모두 패킷 앞에 식별자를 놓기 때문에 VNI를 MPLS 레이블로 매핑하면 두 네트워크가 합쳐질 것처럼 결론은 뻔해 보이지만, 그런 매핑은 지원되는 작업으로 존재하지 않습니다. 식별자가 의미하는 바가 다르고 서로 다른 제어 평면이 이를 생성하기 때문입니다. VNI는 오버레이 내부의 VXLAN 세그먼트를 식별하고, MPLS 레이블은 레이블 스위칭 경로를 따라가는 포워딩 처리를 식별합니다. 도메인을 연결하는 것은 라우팅 결정이지 숫자의 변환이 아닙니다.
신화: 둘 다 레이블을 쓰니 매핑하자
표면적 유사성은 실제이면서 오해를 부릅니다. VXLAN은 헤더에 24비트 VNI를 담고, MPLS는 레이블 스택을 담으므로 경계 장비에서 한 값을 다른 값으로 다시 쓸 수 있어 보입니다.
이 발상을 무너뜨리는 것은 값 주변의 모든 것입니다. VNI는 EVPN 제어 평면과 언더레이 터널 끝점이 해석합니다. 레이블은 MPLS 포워딩 평면이 경로를 따라 부여합니다. 어느 쪽도 상대방의 식별자를 자기 것으로 받아들이는 절차를 정의하지 않았습니다.
각 측이 실제로 전달하는 것
패브릭 쪽에서 경계 장비는 VXLAN 터널을 종단하고, VNI를 테넌트 VRF에 매핑하고, 패킷을 일반 IP로 라우팅합니다. 프로바이더 쪽에서 PE는 고객 경로를 VRF로 받아들이고, MPLS 레이블 스택을 부여하고, IP VPN을 통해 전달합니다.
이 핸드오프가 RFC 4364에서 잘 알려진 모델입니다: 고객 에지는 프로바이더 에지와 IP 경로를 교환하고, 각 도메인은 자기 캡슐화를 소유합니다. 패킷이 PE에 도달할 때쯤 VNI는 사라져 있으며, 바로 그 점이 이 모델이 동작하는 이유입니다.
제어 평면이 합쳐지지 않는 이유
EVPN Type 5는 오버레이 넥스트 홉을 가진 IP 프리픽스 경로를 운반하고, VPN-IPv4 광고는 다른 주소 패밀리에 속합니다. 양쪽에서 같아 보이는 라우트 타깃은 한 패밀리를 다른 패밀리로 변환하지 않으며 경계를 넘는 넥스트 홉을 해석하지 않습니다.
통합 게이트웨이는 플랫폼이 필요한 캡슐화와 경로 패밀리 간 인터워킹을 구현할 때만 두 역할을 모두 수행할 수 있습니다. 이 능력은 정확한 하드웨어와 릴리스에 대해 검증해야 하며, 제품 패밀리 이름에서 추론해서는 안 됩니다.
이 경계에서 두 가지 가정이 더 무너집니다. MPLS IP VPN은 라우티드 도달성을 제공할 뿐 Ethernet 세그먼트가 아니므로, 브로드캐스트를 확장하려면 대신 지원되는 레이어 2 서비스가 필요합니다. 또한 두 캡슐화 모두 바이트를 소비하므로 실효 MTU는 어느 언더레이가 시사하는 것보다 작습니다.
라우티드 핸드오프 또는 통합 게이트웨이를 선택하십시오
테넌트에 IP 도달성이 필요하고 프로바이더가 이미 CE 쪽 서비스를 제공한다면 라우티드 핸드오프를 선택하십시오. 소유 관계가 깔끔해집니다: 패브릭이 VXLAN과 EVPN을, 프로바이더가 MPLS와 VPN을, 경계가 VRF 대 인터페이스 매핑을 소유합니다. 단일 링크로 충분하다고 가정하지 말고 연결 규모, 주소 지정, 장애 조치를 프로바이더와 함께 계획하십시오.
통합 게이트웨이는 운영하는 플랫폼이 두 역할을 모두 지원하고 인터워킹을 시험할 수 있을 때만 선택하십시오. 장비 절감은 실질적이지만, 두 제어 평면이 합의해야 하는 유일한 지점이 한 장비가 되는 운영 위험도 실질적입니다.
테넌트별로 기록할 것
연결, 수용 및 내보낸 프리픽스, 넥스트 홉 해석 방법, 경계나 프로바이더 링크 장애 후 예상되는 동작을 담은 테넌트별 기록을 유지하십시오. 두 캡슐화 경계와 귀환 경로의 MTU 예산도 포함하십시오, 정방향이 동작한다는 것만으로는 거의 아무것도 증명하지 못하기 때문입니다.
그 기록이 라우팅과 캡슐화 가정이 같다고 가장하지 않고 두 관리 도메인을 잇는 것입니다. 나중에 누군가 VNI를 그냥 레이블로 만들 수 있는지 묻는다면, 문서는 논쟁이 아니라 설계로 답합니다.