VRF에서 사라진 경로: 로컬, VPNv4, 아니면 포워딩 테이블인가?

VRF에 없고, VPNv4에 없으며, CEF에 설치되지 않은 프리픽스는 서로 다른 세 가지 장애입니다. 경로 대상을 편집하기 전에 테이블을 순서대로 읽으십시오.

한 고객이 경로 대상 변경 뒤 프리픽스가 사라졌다고 말하는데, 그들이 보내는 첫 스크린샷은 대개 잘못된 테이블입니다. 서로 다른 세 테이블은 서로 다른 세 질문에 답합니다. 프리픽스가 VRF 안에 있는지, VPNv4 경로로 광고되고 임포트되었는지, 그리고 포워딩 항목이 실제로 설치되었는지입니다. 순서를 벗어나 읽으면 확신에 찬 잘못된 결론이 나오며, 이 런북은 로컬 프리픽스 하나와 원격 프리픽스 하나를 세 테이블에 순서대로 통과시키고, 그것을 시작한 RT 변경에 대한 롤백 계획으로 끝납니다.

프리픽스와 그것이 속한 테이블을 지목하십시오

무엇이든 입력하기 전에 프리픽스 두 개를 적어 두십시오. 하나는 고객 사이트에 로컬이며 연결된 인터페이스나 CE 광고에서 학습됩니다. 다른 하나는 원격이고 제공자 백본을 넘어 도착해야 합니다. 둘은 같은 VRF로 서로 다른 경로를 지나며, 하나의 장애는 다른 하나에 대해 아무것도 말해 주지 않습니다.

TableQuestion it answersCommand
show ip vrf CUST-AWhich RTs are attached for import and exportRead the RT lists before anything else
show ip route vrf CUST-AIs the prefix present in this VRF at allLocal and imported routes both appear
show ip bgp vpnv4 allWas the NLRI advertised and retainedKeyed by route distinguisher
show ip cef vrf CUST-AWas a forwarding entry installedProves a usable path, not just a BGP entry

두 식별자의 구분을 분명히 유지하십시오. 이런 티켓의 혼란 대부분이 거기서 나옵니다. 경로 구분자는 VPNv4 NLRI의 일부이며, 그렇지 않으면 동일한 고객 프리픽스를 백본 전체에서 유일하게 만들기 위해 존재합니다. 경로 대상은 속성으로 실려 가는 확장 커뮤니티이고, 임포트와 익스포트 정책이 바로 그것과 일치합니다. 그것은 구분자의 두 번째 이름이 아니며 고객의 패킷에 실리지도 않습니다.

1단계: 프리픽스가 VRF에 있음을 증명하십시오

먼저 로컬 보기에서 시작하고, 다음으로 임포트를 관장하는 RT를 보십시오. 로컬 프리픽스가 여기에 없다면 상류의 무엇도 원인이 될 수 없습니다:

show ip route vrf CUST-A 172.21.4.0 255.255.255.0
show ip route vrf CUST-A | include 172.21.4.0
show ip vrf CUST-A

연결됨이나 정적으로 보이는 프리픽스는 로컬에서 학습된 것이며, 그 존재는 익스포트되었는지에 대해 아무것도 말하지 않습니다. 이것이 이 작업 흐름에서 가장 흔한 잘못된 읽기이며, 건강한 VRF 테이블은 로컬 학습에 대한 증거일 뿐입니다. 익스포트 쪽은 별개의 질문이며, 이웃 보기와 연결된 익스포트 대상이 답합니다.

여기 있는 동안 VRF의 RT 목록을 확인하십시오. 의도한 임포트 대상이 목록에 없으면 하류의 모든 것이 무의미합니다. 있긴 한데 원격 PE가 익스포트하는 것과 다르다면, 패킷 캡처를 하나도 열지 않고 장애를 찾은 것입니다.

2단계: VPNv4 테이블과 그 대상들을 읽으십시오

VPNv4 테이블은 제어 평면이 실제로 무엇을 교환했는지 보여 줍니다. 올바른 구분자 아래에서 원격 프리픽스를 찾고, 그다음 거기 붙은 커뮤니티를 보십시오:

show ip bgp vpnv4 all 10.60.9.0/24
show ip bgp vpnv4 all | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A neighbors 192.0.2.17 advertised-routes

경로 대상이 올바르지만 로컬 설치가 없는 항목은 도달 가능성이 아니라 임포트 정책이나 경로 선택을 가리킵니다. VPNv4 테이블에 아예 나타나지 않는 항목은 상류를 가리키는데, 원천 PE가 익스포트하지 않았거나 세션이 주소 패밀리를 나르지 않을 수 있습니다.

변경 도중 사람들을 헷갈리게 하는 세 번째 경우가 있습니다. 일부 플랫폼은 경로 대상 멤버십 정보를 사용해 어떤 VPN 경로를 요청하거나 유지할지 제한하므로, 필터된 한 보기에서 원격 NLRI가 없다는 것이 광고가 어디에도 없다는 증거는 아닙니다. 경로가 전 세계적으로 철회되었다고 결론 내리기 전에 필터하지 않은 테이블과 이웃의 광고 경로를 확인하십시오.

3단계: 무언가가 설치되고 레이블이 붙었는지 확인하십시오

BGP 항목은 결정이지 경로가 아닙니다. 포워딩 테이블은 패킷이 갈 곳이 있는지 알려 줍니다:

show ip cef vrf CUST-A 10.60.9.0/24
show mpls forwarding-table vrf CUST-A | include 10.60.9.0
show ip bgp vpnv4 vrf CUST-A

이웃이 해석되고 나가는 레이블이 있는 CEF 항목은 데이터 평면 트래픽이 동작해야 한다는 뜻이며, 남은 증상은 애플리케이션이나 VRF 내부 필터링에 속합니다. 다음 홉이 해석되지 않은 CEF 항목은 BGP가 건강해 보여도 레이블 경로가 불완전하다는 뜻이고, BGP 테이블 스크린샷이 변경 검토를 오도한 것이 바로 이 경우입니다.

로컬 PE가 부과하는 레이블을 원격 PE가 받기를 기대하는 레이블과 비교하십시오. 두 보기 사이의 불일치는 레이블 할당이나 세션 문제이며, 경로 대상을 몇 번을 편집해도 고쳐지지 않습니다.

선언된 범위로 RT 변경을 되돌리십시오

장애가 경로 대상 편집에서 시작되었다면, 그것을 하나의 의도된 단계로 취소하고 어떤 범위를 바꾸는지 말하십시오. 임포트 대상을 제거하면 그 VRF 안의 자격이 철회됩니다. 백본에서 VPNv4 광고가 삭제되는 것은 아니며, 일부 플랫폼에서는 경로가 테이블에 유지된 채 남습니다. 이는 다른 결과이고 사용자에게 보이는 영향은 어느 쪽을 뜻하는지에 달려 있습니다.

configure terminal
vrf definition CUST-A
 address-family ipv4
  no route-target import 65000:410
 end
clear ip bgp vpnv4 vrf CUST-A soft in

세션이 이미 프리픽스를 저장하고 있다면 인바운드 소프트 재구성이 충분하며, 업무 시간에 제공자 쪽 세션을 하드 리셋하는 것은 다른 누군가가 내릴 결정입니다. Junos에서는 동등한 확인이 VRF별 테이블과 VPN 테이블을 직접 읽고, 롤백은 명령별 취소가 아니라 commit 시점의 되돌림이므로 시작하기 전에 구성 차이를 기록하십시오.

시작했던 것과 같은 세 명령으로 같은 순서로 끝내고, 그 출력을 시각 표시와 함께 기록하십시오. RT가 틀렸고 이제 맞다고 말하는 티켓은 재사용할 수 없으며, 프리픽스가 VRF에 있고 VPNv4에 있으며 CEF에 설치되었음을 보여 주는 티켓만이 다음 사람이 대조할 수 있는 증거입니다. 처음 두 개만 바뀌었다면 변경을 끝내지 못한 것입니다.

관련 글