RSVP-TE 터널은 작동하지만 고객 L3VPN에는 경로가 없습니다
전송과 서비스는 별개의 결정입니다. 레이블 스택을 읽고, 다음 홉 해석과 VRF 연결을 따로 확인한 뒤 실제 고객 흐름 하나를 시험하십시오.
고객이 VPN 중단을 보고하고 전송 팀이 터널은 정상이라고 보고할 때 두 팀 모두 옳을 수 있습니다. 트래픽 엔지니어링된 LSP와 MPLS L3VPN은 서로 다른 질문에 답하는데, 하나는 레이블이 붙은 패킷을 코어 너머로 옮기고 다른 하나는 패킷이 어느 라우팅 컨텍스트에 속하는지 결정합니다. 둘을 혼동하면 각 측이 서로 다른 객체를 측정하고 있고 두 측정 모두 유효하기 때문에 논쟁이 맴돌게 됩니다.
전송은 작동하고 서비스는 중단된 상태가 정상입니다
LSP가 설정되어 트래픽을 운반하고 모든 모니터링 시스템에 보이더라도 고객 서비스는 사용할 수 없는 상태로 남을 수 있습니다. 이 조합에 모순은 없는데, 터널은 원격 프리픽스가 존재하는지, 가져오기 정책이 이를 수락했는지, 연결 회선이 프레임을 통과시키는지에 대해 의견이 없기 때문입니다.
혼동을 보통 드러내는 증상은 비대칭인데, PE 루프백에서의 핑은 성공하는데 고객 LAN의 호스트는 아무것도 받지 못하거나 그 반대입니다. 이론을 세우기 전에 어떤 주소가 작동했는지 적어 두십시오. 두 개의 서로 다른 객체를 시험하고 있다는 것을 알아차렸다면, 다음 단계는 누구의 그래프가 맞는지 논쟁하는 것이 아니라 레이블 스택을 읽는 것입니다. 두 주소, 두 소유자, 그리고 보통 서로가 무언가를 망가뜨렸다고 믿는 두 명의 다른 사람입니다.
스택을 두 가지 책임으로 읽으십시오
아래 레이블은 서비스에 속하고 위 레이블은 경로에 속합니다. RFC 4364는 그 순서를 간단히 설명하는데, 먼저 VPN 경로 레이블이 부과되고, 그다음 그 레이블이 붙은 패킷이 BGP 다음 홉을 향해 터널링되며, 바로 그곳에서 트래픽 엔지니어링 터널이 자기 레이블을 위에 얹습니다.
| Object | Decision it encodes | Who owns it |
|---|---|---|
| Attachment and VRF | Which customer context receives the arriving packet | Edge configuration |
| VPN route and service label | Which remote forwarding context handles the destination | BGP VPN signalling |
| Transport LSP and tunnel label | How the core carries the packet to the BGP next hop | RSVP-TE or another tunnel mechanism |
원격 PE에서 서비스 레이블이 처리를 선택하며, 이는 VRF 조회일 수도 연결 결정일 수도 있습니다. 그 레이블은 코어만 통과하는 레이블로 바꿀 수 없으며, 둘이 같은 인터페이스의 같은 스택에 나타나더라도 서로 교환할 수 없습니다.
RSVP 성공이 증명하는 것과 증명하지 않는 것
RSVP-TE는 리소스 예약이 있든 없든 명시적으로 라우팅된 LSP를 설정하며, 이는 패킷이 코어를 통과하는 경로에 대한 구체적이고 유용한 보장입니다. 이것은 고객 경로에 대한 진술이 아니며, 설정된 터널 이름은 경로가 전혀 아닙니다.
RSVP의 존재도 종단 간 성능을 약속하지 않습니다. 하나의 LSP에 대한 대역폭 예약은 연결 회선, 고객 자체의 액세스 회선, 또는 원격 에지의 큐 동작에 대해 아무것도 말하지 않습니다. 이를 보장으로 취급하면 아무도 묻지 않은 질문에 자신감 있는 답을 내놓게 됩니다. 요구 사항이 정말로 대역폭 약속이라면, 그것을 실제로 강제하는 조각들로 조립해야 하며, LSP는 그 사슬의 중간일 뿐입니다.
순서대로 확인한 뒤 멈추십시오
전송에서 바깥으로 작업하고 실패하는 첫 단계에서 멈추십시오, 이후의 모든 단계는 이전 단계가 유지되었다고 가정하기 때문입니다. 먼저 LSP가 설정되었는지, 그리고 서비스 프리픽스의 전달 항목이 실제로 그것을 가리키는지 확인하십시오. 그다음 VPN 경로가 올바른 테이블에 있는지, 레이블 바인딩이 있는지, 가져오기 정책이 이를 수락했는지 확인하십시오. 그다음 연결을 확인하십시오: 인터페이스, 캡슐화, 그리고 해당되는 경우 그 계약에 속한 VLAN 식별자입니다.
show mpls lsp
show mpls forwarding-table 10.60.0.0 24
show bgp vpnv4 unicast vrf CUSTOMER 10.60.0.0/24
show ip vrf detail CUSTOMER명령 구문은 플랫폼에 따라 다르므로 그 네 줄을 스크립트가 아니라 네 가지 질문으로 취급하십시오. 중요한 점은 각각이 서로 다른 객체를 심문한다는 것이며, 그래서 실패가 특정 소유자를 가리키게 됩니다.
허용된 요청 하나를 따라가고 좋은 증거를 보존하십시오
정책이 허용하는 실제 고객 요청 하나와 그 응답으로 마무리하십시오. 종단 간 작동하는 흐름 하나는 한 페이지의 카운터 판독값보다 더 많은 것을 해결하며, 각 부분을 개별적으로가 아니라 조합을 시험합니다.
이후 단계가 실패하면 전송을 다시 구축하는 대신 성공한 LSP 관찰을 보존하십시오. 작동하는 터널을 다시 구축해도 없는 원격 프리픽스, 잘못된 VRF 연결, 목적지 액세스 규칙을 고칠 수 없으며, 전송이 건강하다고 처음 알려 준 증거를 파괴합니다.