MPLS 지사 라우팅: CE가 무엇을, 누구에게 배우는가

한 지사의 호스트가 다른 지사의 서버로 연결을 열고, 두 사이트는 동일한 관리형 MPLS 레이어 3 VPN 뒤에 있습니다. 호스트는 자신의 기본 게이트웨이만 알고 그 밖의 것은 모르며, 이는 올바릅니다. 중요한 것은 로컬 고객 에지가 패킷을 자신의 공급자 에지로 넘기고, 공급자의 VPN 라우팅 상태가 이를 목적지 프리픽스를 가진 지사로 전달한다는 점입니다.

패킷 하나를 경로 전체에서 따라가는 것이 어느 부분이 고객의 책임이고 어느 부분이 서비스에 속하는지 보는 가장 빠른 방법입니다.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

각 홉의 작업이 끝나는 지점

CE-A에는 원격 LAN으로 가는 경로가 필요하며, 이 경로는 원격 지사의 WAN 주소가 아니라 자신의 로컬 공급자 연결을 가리켜야 합니다. 그런 다음 공급자가 VPN 라우팅 상태를 사용해 자체 코어를 통해 패킷을 운반하고, CE-B가 이를 목적지 LAN으로 전달합니다. 어느 시점에도 호스트가 레이블, VRF 또는 상대편의 인터넷 회선을 이해할 필요는 없습니다.

티켓에서 반복해서 나타나는 실수는 지사 A에서 지사 B의 WAN 주소를 다음 홉으로 구성하는 것입니다. 두 지사가 같은 서비스를 구매했기 때문에 이웃이어야 한다고 느껴지지만 그렇지 않습니다. 다음 홉은 실제로 보유한 라우팅 설계를 통해 도달할 수 있어야 하며, 원격 CE는 보통 관리하지 않는 장비 뒤로 여러 홉 떨어져 있습니다. 이 가정 위에 만든 정적 경로는 활성으로 표시되지만 아무것에도 해석되지 않으며, 테이블에서 올바르게 보이기 때문에 경로가 없는 것보다 더 나쁩니다.

RFC 4364는 고객 에지와 공급자 에지 사이의 교환을 공급자의 VPN 경로 배포와 분리하며, 이것이 바로 이 문서가 다루는 경계입니다. 고객의 일은 자신의 에지에 무엇을 전달할 수 있는지 알리고 서비스가 돌려주는 도달 가능성을 받아들이는 것입니다.

핸드오프가 합의해야 할 것

메커니즘은 공급자와 함께 선택하고, 공급자를 우회해서 선택하지 마십시오. 정적 경로, BGP 또는 CE와 PE 사이의 라우팅 프로토콜 합의는 모두 정당하며, OSPF에는 그러한 핸드오프를 위한 정의된 MPLS VPN 모델이 있습니다. 어느 것도 지정되지 않은 공급자 코어를 넘어 두 원격 고객 에지 사이에 OSPF 인접을 구축할 이유가 되지 않으며, 그것은 공급자가 동의하지 않았고 지원할 수 없는 설계입니다.

새 LAN을 가동하기 전에 프리픽스, CE의 로컬 다음 경로, 공급자가 수용할 광고, 공급자가 반환할 경로 네 가지를 적어 두십시오. 계약이 요구하는 필터링, 프리픽스 제한 또는 사이트 간 제한을 추가하십시오. 건전한 인접은 정보를 교환하는 통로일 뿐 특정 프리픽스가 수용되었다는 증거가 아니며, 세션이 올라가 있어도 새 서브넷이 필터 안에 있을 수 있습니다.

그런 다음 응답을 따라가십시오. 지사 B에는 소스 LAN으로 돌아가는 경로가 필요하고, 수신 측 호스트에는 자체 게이트웨이와 자체 서비스 권한이 필요합니다. CE-A에 나타나는 경로는 왕복의 절반만 설정하며, 그 절반이 ping 테스트의 한 방향은 건전해 보이는데 애플리케이션은 여전히 실패하는 이유입니다.

인수 전에 두 핸드오프를 모두 검증하십시오

두 고객 에지에서 라우팅 상태를 수집하고, 의도한 LAN 프리픽스가 VPN으로 수용되었는지 공급자와 확인한 다음, 각 방향에서 허용된 애플리케이션 하나를 테스트하십시오. 경로 테이블만으로는 애플리케이션이 작동한다는 것을 증명하지 못하며, 애플리케이션 테스트만으로는 작동하지 않을 때 어느 제어 평면이 실패했는지 알 수 없습니다.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

세 출력을 함께 읽으십시오. 첫 번째는 에지가 무엇을 믿는지, 두 번째는 무엇을 어느 피어에서 배웠는지, 세 번째는 실제로 무엇을 전달할지 말합니다. 이들 사이의 불일치는 보통 누락된 광고가 아니라 정책이나 재귀 문제이며, 공급자에게 조사를 요청하기 전에 해결할 가치가 있습니다. 이 세 출력을 통신사 통화에 가져가면 지원 엔지니어가 물었을 대부분의 질문에 답이 됩니다.

서비스가 제공하지 않는 것을 아십시오

이것은 레이어 3의 라우팅된 액세스입니다. 사무실 간 브로드캐스트를 확장하는 레이어 2 회선이 아닙니다, 따라서 검색 프로토콜, 브로드캐스트에 의존하는 애플리케이션, 공유 세그먼트 가정은 함께 이동하지 않습니다. 인쇄, 이름 탐색, 로컬 세그먼트에 의존하는 모든 것은 자체 설계가 필요합니다.

VPN 분리는 암호화도 아닙니다. 레이블 스위칭은 공급자 네트워크 내부에서 고객을 분리해 두지만, 계약이 기밀성을 요구할 때 페이로드를 기밀로 만들지는 않습니다. 그것이 중요한 곳에서는 애플리케이션이나 오버레이가 제공해야 합니다.

마지막으로 서비스 모델을 사이트의 라우팅 구성 옆에 적어 두십시오. 다음에 서브넷을 추가하는 엔지니어는 어떤 프리픽스가 광고되고, 누가 이를 수용하며, 예상 반환 경로가 무엇인지 읽을 수 있어야 합니다: BGP/MPLS IP VPN 사양 이 모든 것 뒤에 있는 모델의 참조입니다.