L3VPN 핸드오프: 사설 경로, 기본 경로, 아니면 전체 피드?

회선은 올라와 있고 VRF도 구성되어 있는데, 공급자가 나머지 설계를 좌우하는 짧은 질문을 던집니다: 고객 에지가 무엇을 받아야 하는가? 흔한 답은 세 가지이며, 어느 것도 레이블 스택이 존재한다는 사실에서 나오지 않습니다. 그것들은 트래픽이 지사에서 어디로 나가는지에 관한 서비스 결정입니다.

핸드오프를 순서대로 짚는 것이 이 일을 제대로 끝내는 가장 저렴한 방법입니다. 아무것도 일치하지 않는 트래픽에 무슨 일이 생기는지에서 시작해, 사설 프리픽스와 그 장애 동작을 적고, 그다음에야 얼마나 큰 피드를 감당할지 이야기합니다.

아무도 계획하지 않은 트래픽부터 시작하십시오

프리픽스 목록이 나오기 전에 질문 하나를 던지십시오: 패킷이 어떤 사설 경로와도 일치하지 않을 때 어디로 가야 합니까? 자체 인터넷 회선이 있는 지사는 보통 로컬 기본 경로를 유지하므로, 일반 웹 트래픽은 로컬 방화벽을 통해 나가고 공급자에게는 전혀 닿지 않습니다. 그 설계에서 VPN은 원격 사설 사이트만 운반하며, 더 구체적인 프리픽스가 선택을 담당합니다.

중앙 출구를 쓰도록 의도된 지사는 반대 경우입니다. 거기서는 기본 경로가 서비스 안쪽을 가리키고, 공급자나 중앙 사이트가 포워딩과 반환 라우팅, 그리고 모든 변환을 소유합니다. 그 소유자 없이 "VPN으로 기본 경로"라고 말하면 이름은 해석하지만 아무것도 도달하지 못하는 지사가 됩니다.

두 설계는 라우팅 장애가 어떻게 보이는지가 다르고, 그래서 짐작하는 것이 비쌉니다. 로컬 기본 경로에서는 사설 경로를 잃으면 그 트래픽이 인터넷으로 나가고, 거기서 방화벽에 버려지거나 더 나쁘게는 의도하지 않은 무언가가 응답합니다. 중앙 기본 경로에서는 같은 상실이 인터넷 접속을 완전히 없애고 티켓은 "지사 전체가 죽었다"로 들어옵니다. 어느 장애도 그 자체로 틀리지는 않지만, 판매한 서비스와 맞는 것은 하나뿐이며, BGP 구성만으로는 어느 쪽을 만들었는지 알 수 없습니다.

사설 프리픽스를 장애 상황과 함께 적으십시오

지사가 도달해야 할 프리픽스를 나열하고 그중 어느 것이 요약되었는지 적으십시오. 한 비트라도 넓은 집계는 알 수 없는 목적지를 VPN으로 끌어들이며, 이는 먼 쪽이 그것을 실제로 소유하고 포워딩할 때만 괜찮습니다.

다음으로 사설 서비스가 실패할 때의 의도된 동작을 설명하십시오. 유지된 폐기 경로는 트래픽을 허가되지 않은 경로에서 떼어 두고 깔끔하고 예상된 중단을 만듭니다. 플로팅 기본 경로는 백업 경로로 옮겨 가용성을 유지할 수 있지만, 그 백업 경로가 그 트래픽을 운반하도록 허가된 경우에만 그렇습니다.

가용성과 허용된 폴백을 핸드오프 문서에서 두 개의 별도 요구 사항으로 유지하십시오. 둘을 합쳐 버리는 팀은 합의된 정책이 구현되었는지 확인하는 대신 지사가 죽었어야 하는지를 두고 다툽니다.

CE가 실제로 설치한 것을 확인하십시오

구성 의도와 포워딩 상태는 자주 어긋나므로 검증은 인시던트 리뷰가 아니라 핸드오프에 속합니다. IOS-XE 고객 에지에서 아래 세 명령은 서로 다른 세 가지 질문에 답합니다: 무엇이 제시되었고, 무엇이 수락되었고, 실제로 무엇이 쓰이는가입니다.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

세 명령 모두 한 달 뒤가 아니라 핸드오프 당일, 아직 누군가 합의 내용을 기억할 때 실행하십시오. 첫 번째 출력은 soft-reconfiguration inbound 또는 저장된 route refresh에 의존하며, 둘 다 없으면 CE는 거부한 것을 보여줄 수 없습니다. 두 번째는 정책 적용 후 수락된 경로와 최선 경로를 보여줍니다. 세 번째는 기본 경로가 실제로 어디로 가는지 알려 주며, 그것이 핸드오프 전체에서 가장 유용한 한 줄입니다.

사이트가 이중 홈이라면 두 번째 CE에서도 같은 점검을 실행하십시오. 두 에지 사이의 비대칭 수락은 "한 서버에서는 되고 다른 서버에서는 안 된다"의 흔한 원인이며, 대칭으로 보이는 구성 차이에서는 보이지 않습니다.

더 큰 피드를 가정하지 말고 자격을 따지십시오

때때로 고객은 정책 라우팅이나 프리픽스로 조향하는 중앙 출구를 위해 VRF 안에서 인터넷 경로 정보를 정말로 필요로 합니다. 그것은 진술하고 범위를 정하고 값을 매겨야 할 요구 사항이지 숨은 기본 경로가 아닙니다. RIB와 FIB를 위한 메모리, 업데이트를 위한 CPU, 필터 유지보수, 그리고 그 결과 테이블의 소유자가 함께 따릅니다.

용량 논쟁은 양쪽 방향으로 틀립니다. 전체 테이블은 VRF 안에서 금지되지 않으며 무료도 아닙니다. 마찬가지로 오래된 경로 수에서 오늘의 비용을 추론할 수 없고, 더 작은 레이블 할당이 경로 저장 비용을 없애지도 않습니다.

BGP/MPLS IP VPN 명세는 VPN 서비스 자체 옆에서 여러 인터넷 접속 방식을 논의하며 모든 고객에게 전체 테이블이나 기본 경로를 의무라고 선언하지 않는데, "표준 관행"이라는 주장이 나올 때 가리킬 만한 절이 바로 그것입니다: RFC 4364.

핸드오프를 마무리할 때 광고된 집합, 수신된 집합, 선택된 집합을 합의된 출구 정책 옆에 기록하고, 사설 목적지 하나, 의도된 공용 목적지 하나, 경로 상실 사례 하나를 시험하십시오. 그 세 시험의 서명된 기록은 대부분의 네트워크가 무엇을 하는지에 관한 어떤 진술보다 많은 논쟁을 끝냅니다.