VRF별 레이블인가, 프리픽스별 레이블인가? 진짜 용량 청구서

두 설계가 같은 제공자 코어에서 같은 고객 프리픽스를 광고한다. 하나는 프리픽스마다 레이블을 할당하고, 다른 하나는 VRF 전체에 레이블 하나를 할당하며, 두 번째는 모든 슬라이드에서 더 저렴해 보인다. 레이블 수는 실제이지만, 보통 가장 먼저 바닥나는 예산은 아니다. 둘 중 하나를 고르는 일은 하나가 아니라 네 가지 자원을 세는 일이며, 그중 레이블이 가장 작다.

선택은 레이블을 제거한 뒤 출구 라우터가 패킷으로 무엇을 해야 하는지에도 달려 있다. 결정을 이끌어야 하는 것은 레이블 산술이 아니라 그 기능적 차이다.

각 할당이 실제로 절약하는 것

프리픽스별 할당은 포워딩 정보를 레이블에 담는다. 출구 라우터는 목적지 조회 없이 패킷을 올바른 인접으로 곧장 보낼 수 있으며, 그래서 대규모 VRF 경로 집합에 잘 확장되고, 그래서 모든 VRF에서 광고된 모든 프리픽스마다 레이블 하나를 소비한다. VRF별 할당은 예컨대 Junos vrf-table-label처럼 라우팅 인스턴스마다 레이블 하나를 광고하고 그 레이블로 VRF 테이블을 선택한다. 그런 다음 라우터는 테이블 안에서 IP 조회를 수행한다.

그것은 튜닝 노브가 아니라 실제 아키텍처 차이다. VRF별 레이블링은 더 작은 레이블 공간과 더 단순한 레이블 광고를 주지만, 조회 한 번과 목적지에 대해 아무것도 말하지 않는 레이블을 대가로 치른다. 프리픽스별 레이블링은 출구 라인 카드에 더 많은 정보를 미리 주고, 운반하는 경로에 비례해 레이블을 소비한다.

레이블 장부는 작은 쪽이다

MPLS 레이블은 유한하지만, 레이블 공간은 일반 서비스 제공자가 몇 천 개의 프리픽스로 고갈시키지 않을 만큼 크다. VRF별 레이블링이 실제로 도움이 되는 곳은 하드웨어 레이블 테이블이 작은 플랫폼이거나, 하나의 VRF가 전체 인터넷 피드를 운반해 프리픽스별 레이블이 경로 수만큼 레이블 수요를 늘리는 설계다. 이것들은 실제 제약이며, 이 기능이 존재하는 이유이기도 하다. 그중 어느 것도 테이블의 프리픽스 수에 관한 것이 아니다.

고르기 전에 서비스와 전송 모두의 레이블을 세라. VRF별 설계도 루프백과 경로의 모든 홉에 전송 레이블이 필요하고, 인접 상태도 필요하다. 설계 개요가 서비스 레이블만 센다면, 절감은 잘못된 장부에서 측정되고 있다.

경로 피드는 레이블보다 메모리를 먼저 쓴다

받은 모든 경로는 VRF가 레이블 하나를 쓰든 만 개를 쓰든 제어 평면 메모리, 업데이트 처리, 수렴 시간을 소비한다. VRF 안의 전체 인터넷 피드가 비싼 이유는 BGP 경로, RIB, FIB 항목, 그리고 그 뒤의 요동이며, 테이블 앞의 레이블 때문이 아니다. 같은 피드는 그 테넌트 안에서 경로 누출이나 정책 실수의 영향 범위도 키운다.

그러니 고객이 실제로 무엇을 요구하는지 물어라. 계약이 사설 사이트와 기본 출구라면, 전체 테이블은 요구 사항을 더하지 않고 비용만 더한다. 그것은 상업적 질문이며, 이전 설계에서 물려받은 가정이 아니라 서면 답변을 받을 자격이 있다. 서비스가 정책이나 로컬 출구 선택을 위해 피드가 정말 필요하다면, 자체 용량 예약과 자체 장애 동작을 갖춘 명시적 항목으로 만들어라.

VRF별 레이블링이 올바른 기본값일 때

플랫폼이 지원된다고 문서화하고, VRF 경로 수가 많고, 출구 조회 비용이 트래픽 프로파일에 허용될 때 좋은 기본값이다. 포워딩에서 마지막 마이크로초를 짜내는 것보다 운영 단순성이 더 중요할 때도 자연스러운 선택이다. 테넌트마다 레이블 하나가 프리픽스마다 레이블 하나보다 설명하고 감사하기 쉽기 때문이다.

플랫폼 문서가 이 기능을 특정 하드웨어나 릴리스 제약에 묶거나, 설계가 출구에서 프리픽스별 포워딩 결정에 의존할 때는 잘못된 기본값이다. 동작을 가정하기 전에 플랫폼 자체의 statement 참조를 읽어라. Junos 명령은 문서화되어 있지만, 실제 배포를 결정하는 것은 그 주변의 하드웨어와 릴리스 한계다.

변호할 수 있는 예산

용량 근거를 다섯 개의 별도 숫자로 세워라. 수신 경로, 선택된 경로, 설치된 포워딩 항목, 서비스 레이블, 전송 레이블이다. 여기에 넥스트 홉과 인접 상태, 테넌트 수, 이중화 모델을 더하라. 단일 VRF의 정상 경로 스냅숏은 규모 수치가 아니며, 명목상의 레이블 공간 크기는 사용 가능한 하드웨어 테이블이 아니다.

그다음에는 정상 상태뿐 아니라 장애 모드에도 합의하라. 피드가 절반 늘어날 때, 테넌트가 두 번째 VRF를 추가할 때, 또는 테이블 크기를 바꾸려고 플랫폼 재부팅이 필요할 때 무슨 일이 일어나는가. 그 질문들을 견디는 예산은 종이에서만 통하는 레이블 수보다 값어치가 있다.

출구 동작과 플랫폼 한계로 할당을 고르고, 그다음 경로 피드를 명시적 서비스 결정으로 만들어라. 레이블은 설계의 보이는 부분이고, 경로는 매일 값을 치러야 하는 부분이다.