VPNv4에 코어의 MPLS가 필요한가? 반드시 그렇지는 않다

BGP VPNv4는 경로 배포 컨텍스트를 협상할 뿐, 전달 경로를 협상하지 않는다. 임포트, 다음 홉 확인, 실행할 수 있는 캡슐화를 분리해서 보라.

두 라우터 사이에서 VPNv4 주소 패밀리를 켜면 경로 배포 컨텍스트만 생기고 그 이상은 아니다. 전달 경로를 설치하지 않으며, 어떤 캡슐화가 고객 패킷을 원격 엔드포인트까지 운반할지도 알려주지 않는다. 이 두 사실을 분리하면 «코어에 MPLS가 필요한가»라는 질문은 플랫폼이 지원하는 데이터 플레인에 관한 더 좁고 답할 수 있는 질문이 된다.

주소 패밀리가 실제로 협상하는 것

멀티프로토콜 BGP는 AFI 1과 SAFI 128 아래에서 VPNv4 네트워크 계층 도달 가능성 정보를 운반하며, 각 항목은 경로 구분자를 프리픽스와 레이블에 짝지어 준다. 세션은 양쪽이 그 정보를 인코딩하고 디코딩할 수 있다는 점을 협상한다. 협상하지 않는 것은 데이터 플레인이다. 이 문단 이후의 모든 것은 전달에 관한 것이며, 그중 어느 것도 세션이 올라오는 것으로 결정되지 않는다.

따라서 성공한 세션은 제어 플레인의 능력에 대한 증거이지 전달에 대한 증거가 아니다. 라우터는 수천 개의 VPNv4 항목을 보유하고도 모든 고객 패킷을 버릴 수 있으며, 두 실패 부류가 처음부터 혼동되는 이유가 바로 그것이다.

NLRI의 레이블을 보라. 이것은 VRF 내부의 프리픽스에 묶인 서비스 레이블이며, 패킷이 출구 엔드포인트에 도달하면 전달 역할을 한다. 어떤 트랜짓 장비가 그것을 읽는지는 별도의 설계 결정이다.

수신, 임포트, 전달은 세 단계다

경로를 수신하는 것, 그것을 사용할 허가를 받는 것, 그것으로 전달할 수 있는 것은 장비의 서로 다른 부분이 수행한다. BGP는 들은 것을 저장하고, 임포트 정책과 경로 대상 일치가 어느 VRF가 그것을 고려할 수 있는지 결정하며, 그다음 전달 플레인이 광고된 다음 홉을 실제로 회선에 밀어 넣을 수 있는 무언가로 해석해야 한다.

Step in the chainWhat has to be trueHow it fails quietly
NLRI exchangeBoth speakers negotiate the VPNv4 capabilitySession stays up while the family is never activated
Import eligibilityA route target on the received route matches the VRF import policyThe route exists in the table but never enters the VRF
Next-hop resolutionThe advertised next hop resolves to a usable tunnel or label pathBest path is selected, then marked unreachable or unusable
EncapsulationThe egress endpoint can decapsulate what the ingress producedPackets arrive and are discarded for a format mismatch

가장 놀라운 실패가 사는 곳은 바로 이 중간 단계다. 경로가 BGP 테이블에 존재하고 유효하며 심지어 최선일 수 있지만, 어떤 경로 대상도 임포트 목록과 일치하지 않아 VRF 경로 테이블은 비어 있을 수 있다. 프로토콜 오류가 발생하지 않았으므로 아무것도 프로토콜 오류를 기록하지 않는다.

마지막 단계에서 플랫폼 지원이 드러난다. 언더레이에서 도달 가능한 다음 홉이 자동으로 VPN 서비스 전송으로 해석되지는 않으며, 장비는 특정 터널 유형, 특정 레이블 작업 또는 둘 다를 요구할 수 있다. 해석 상태를 읽는 것이 경로 수를 읽는 것보다 더 많은 정보를 준다.

IP 코어는 결코 스위칭하지 않는 스택을 운반할 수 있다

지켜야 할 구분은 «코어가 MPLS를 실행하지 않는다»와 «서비스 어디에도 레이블이 없다» 사이에 있다. 이들은 서로 다른 주장이며, 첫 번째만 트랜짓 장비에 관한 것이다. RFC 4023은 IP 또는 GRE 터널을 통한 MPLS 운반을 정의하며, 바로 그 메커니즘이 완전한 IP 코어에서 두 번째 주장을 가능하게 한다.

customer packet + service label
  encapsulated in GRE, addressed to the egress tunnel endpoint
  forwarded by ordinary IP routers on the outer header
  decapsulated at the endpoint, label still meaningful

트랜짓 라우터는 외부 IP 목적지로 전달하며 고객 프리픽스도 네이티브 레이블 스위칭도 필요로 하지 않는다. 먼 쪽 끝에서 외부 터널이 제거되고 서비스 레이블이 다시 제 일을 한다. 코어는 불투명한 페이로드를 옮겼으며, 그것이 바로 IP 네트워크가 잘하는 일이다.

이 설계가 주지 않는 것은 보편적 보장이다. 모든 라우터가 모든 VPNv4 다음 홉을 어떤 GRE 인터페이스로든 해석한다는 증거가 아니며, 작동하는 네이티브 MPLS 구성을 삭제할 이유도 아니다. 이것은 보편적 주장에 대한 반례이며, 실무적 질문은 플랫폼에 국한된 채로 남는다. 그 질문을 프로토콜 규칙이 아니라 플랫폼 제한으로 기록하라.

박스에서 체인이 끊어질 때까지 걸어가라

수신한 경로에서 시작해 실패하는 첫 단계에서 멈춰라, 왜냐하면 앞 단계가 끊어진 동안 뒤 단계를 진단할 수 없기 때문이다. 일반적인 구현에서 네 개의 명령이 그 대부분을 다룬다.

show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_A

네 개의 독립적인 점검이 아니라 순서로 읽어라. 첫 번째는 주소 패밀리가 활성이고 피어가 경로를 교환하는지 확인하고, 두 번째는 프리픽스가 쓸 만한 다음 홉과 함께 도착했는지 보여 주며, 세 번째는 임포트 적격성을 증명하고, 네 번째는 전달 플레인이 레이블이나 터널을 연결했는지 보여 준다.

그다음 캡슐화를 견디는 MTU로 워크로드 경로를 양방향으로 시험하라. GRE는 헤더 바이트를 더하며, 작은 프로브를 통과하는 경로가 한 방향에서만 전체 크기 패킷에서 실패할 수 있고, 그것은 전송 결함이 아니라 애플리케이션 결함처럼 보인다.

두 가지 운영 메모가 고리를 닫는다. GRE는 캡슐화이지 기밀성이 아니므로, 신뢰할 수 없는 트랜짓 네트워크에는 가정이 아니라 위에 지원되는 보안 구성이 필요하다. 그리고 설계 검토 전에 플랫폼이 실제로 어떤 캡슐화를 지원하는지 기록해야 하며, 그 하나의 답이 IP 전용 코어가 유효한 선택인지 전달할 수 없는 계획인지를 결정한다.

관련 글