MPLS 네트워크의 경로 추적

다운로드 옵션

PDF (515.6 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (437.5 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (461.8 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2018년 9월 25일

문서 ID:200510

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서에서는 MPLS(Multiprotocol Label Switching) 네트워크의 ICMP(Internet Control Message Protocol) 역추적 동작 및 LSP 추적과의 빠른 비교에 대해 설명합니다.

배경 정보

IP 환경에서는 패킷을 수신할 때 어떤 노드든 TTL(Time To Live)이 만료되면 "TTL Exceeded" ICMP 오류 메시지(Type=11, Code=0)를 생성하여 패킷 소스 주소로 전송해야 합니다.이 개념은 1부터 시작하여 순차적으로 TTL로 UDP 패킷을 전송하여 소스에서 대상으로의 IP 경로를 추적하기 위해 활용됩니다. 이 기능에 대한 매우 기본적인 요구 사항은 다음과 같습니다.

패킷의 소스 주소는 전송 노드에서 연결할 수 있습니다.
ICMP는 경로를 따라 필터링되지 않음

MPLS 환경에서 트랜짓 공급자 LSR이 항상 소스 주소에 연결할 수 없는 경우가 있으며 MPLS 도메인에서 ICMP 처리를 위한 몇 가지 개선 사항이 필요할 수 있습니다.

MPLS 네트워크의 ICMP Traceroute

최상위 레이블에서 TTL=1을 사용하여 패킷을 수신하는 LSR의 기본 동작은 패킷을 삭제하고 ICMP 오류 메시지를 트리거하는 기존 IP 동작을 따릅니다.ICMP 메시지를 소스로 라우팅하려면 LSR에서 다음을 수행합니다.

수신 패킷에서 레이블 스택을 버퍼링합니다(TTL=1로 수신된 패킷).
소스가 있는 ICMP 오류 메시지를 고유한 주소로, 수신 패킷에서 소스 주소로 생성합니다.
레이블 스택(1단계에서 먼저 버퍼링된) 아래쪽의 모든 레이블을 TTL=255와 함께 추가합니다(위쪽 레이블 제외).
버퍼된 레이블 스택에서 상위 레이블을 가져오고 로컬 LFIB 조회를 수행하여 교체할 레이블과 연결된 다음 홉을 가져옵니다.
TTL=255로 새 레이블을 스택 상단에 추가하고 전송합니다.

이 접근 방식을 사용하면 ICMP 오류 메시지가 전송 LSR에서 이그레스 LER로 이동한 다음 인그레스 LER에서 실제 소스로 돌아옵니다.

PE에서 원격 PE로 트리거된 ICMP 추적

다음은 ICMP 추적이 동일한 MPLS 도메인 내에서 PE에서 원격 PE로 트리거되는 경우의 동작을 설명하는 간단한 예입니다.

이 토폴로지에서 ICMP traceroute가 R2에서 10.1.4.4으로 트리거되면 첫 번째 패킷은 TTL이 1인 상태로 전송됩니다. 패킷을 수신할 때 R3는 TTL을 0으로 줄이고 ICMP 생성 메커니즘을 트리거합니다.

R3는 레이블 스택을 버퍼링하고 ICMP 오류 메시지를 생성하고 버퍼에서 들어오는 레이블 스택을 ICMP 페이로드에 포함합니다.또한 레이블이 지정된 패킷의 수신 인터페이스의 소스 주소, 목적지 주소를 레이블이 지정된 패킷의 소스로 IP 헤더를 채웁니다.TTL은 255로 설정되어 있습니다. 이제 버퍼에서 레이블 스택을 푸시하고 상위 레이블에서 포워딩 작업을 위해 LFIB 테이블을 협의합니다.이 토폴로지에서는 수신된 레이블 스택이 17입니다. LFIB 테이블에서 조회를 수행할 때 레이블 17은 레이블 16으로 교체되고 다음 R6로 전달됩니다. 그러면 R6은 맨 위 레이블을 팝업하고 R4로 전달되며, 그러면 IP는 패킷을 다시 R2로 전달합니다.

R2의 traceroute 출력에 표시될 수 있듯이, 수신 레이블은 경로를 따라 각 홉에 의해 나열됩니다.

CE에서 원격 CE로 트리거된 ICMP 추적

다음은 MPLS 도메인을 통해 CE에서 원격 CE로 ICMP 추적이 트리거되는 경우의 동작을 설명하는 간단한 예입니다.

이 토폴로지에서 ICMP traceroute가 R1(CE)에서 192.168.5.5(원격 CE)로 트리거되면 첫 번째 패킷은 TTL 1로 전송됩니다. 이는 정상적인 IP 패킷이므로 R2는 ICMP를 생성하고 R1로 직접 전송하는 일반적인 동작을 따릅니다. TTL=2로 전송된 두 번째 패킷은 R3에서 만료됩니다.

R3는 레이블 스택을 버퍼링하고 ICMP 오류 메시지를 생성하고 버퍼에서 들어오는 레이블 스택을 ICMP 페이로드에 포함합니다.또한 레이블이 지정된 패킷의 수신 인터페이스의 소스 주소, 목적지 주소를 레이블이 지정된 패킷의 소스로 IP 헤더를 채웁니다.TTL은 255로 설정되어 있습니다. 이제 버퍼에서 레이블 스택을 푸시하고 상위 레이블에서 포워딩 작업을 위해 LFIB 테이블을 협의합니다.위의 토폴로지에서 수신된 레이블 스택은 {17, 18}입니다.최상위 레이블에 대해 LFIB 테이블에서 조회를 수행하면 17이 레이블 16으로 교체되고 다음 R6으로 전달됩니다. R6은 상위 레이블을 팝업하고 R4로 전달합니다. R4는 VRF 레이블을 사용하여 VRF를 식별하고 패킷을 다시 R1로 전달합니다.

R1의 traceroute 출력에 나와 있듯이, 경로를 따라 각 홉에 의해 수신 레이블 스택이 나열됩니다.

MPLS 네트워크의 MPLS LSP Traceroute

ICMP 기반 traceroute와 달리 LSP traceroute는 RFC4379에 정의된 장비를 사용합니다. IP/UDP 캡슐화를 사용하며 요청의 대상 주소가 루프백 주소(127.0.0.0/8 범위)로 설정됩니다. 동일한 MPLS 도메인 내에서 LSP Ping이 트리거되어야 하므로 Initiator에 직접 회신이 전송됩니다.

LSR에서 LSP traceroute("traceroute mpls ipv4 <FEC>")가 트리거되면, 검증할 FEC에 대한 세부 정보는 TLV에 MPLS 에코 요청의 "Target FEC Stack"으로 포함됩니다.이 메시지는 1부터 시작하여 레이블 스택의 TTL과 함께 순차적으로 전송됩니다. 패킷을 수신하는 모든 트랜짓 LSR이 만료되면 목적지 주소는 루프백 주소이므로 IP 패킷을 처리합니다.MPLS OAM 처리를 위해 CPU에 펀트합니다.

응답자는 선택적으로 FEC 검증을 수행합니다. 수신한 MPLS 에코 요청의 레이블 스택에서 레이블을 가져오고 대상 FEC 스택 TLV에서 FEC 세부 정보를 가져와서 로컬 제어 평면 정보에 대해 동일한 레이블을 검증합니다.추적의 경우 Responder는 TLV에 DSMAP(Downstream Mapping) TLV로 발신 레이블 및 다운스트림 네이버 주소와 같은 다운스트림 정보를 포함합니다. DSMAP은 DSMAP보다 유연하므로 DMAP에서 더 이상 사용되지 않습니다.

PE에서 원격 PE로 트리거된 LSP 추적

이 토폴로지에서 LSP 추적은 LSP를 10.1.4.4/32으로 검증하기 위해 R2에서 트리거됩니다. 레이블의 TTL은 1에서 설정됩니다. LSP를 수신하는 경우 OAM 처리를 위해 CPU로 전환됩니다.

R3는 MPLS Echo Reply with DSMAP TLV와 함께 발신 레이블 16을 전송하고 다운스트림 인접 디바이스 세부 정보와 같은 추가 정보를 사용하여 R2에 다시 회신합니다.ICMP 메시지와 달리 MPLS 에코 응답은 responder R3에서 Initiator R2로 직접 전달됩니다.

R2의 LSP traceroute 출력에 나와 있듯이, 나가는 레이블 스택은 경로를 따라 각 홉별로 나열됩니다.이는 출력에 나열된 레이블이 수신 레이블 스택인 ICMP 기반 traceroute와 다릅니다.

CE에서 원격 CE로 트리거된 LSP 추적

이는 PE-CE 간에 MPLS가 활성화된 CSC와 같은 시나리오에서 적용할 수 있습니다.다음과 같이 Carrier MPLS 도메인을 통해 CE에서 원격 CE로 LSP 추적을 실행하는 데 두 가지 문제가 있습니다.

LSP 에코 응답이 개시자에게 직접 전송됩니다.따라서 응답자는 Initiator에 연결할 수 있어야 합니다.위의 토폴로지에서 R3은 VRF에 있으므로 R1에 연결할 수 없습니다.
레이블 스택의 각 레이블에 대해 검증을 위해 대상 FEC 스택에 관련 FEC 세부사항이 포함되어야 합니다.개시자가 포함하는 FEC는 1이고 PE는 2개의 레이블을 푸시합니다.위 토폴로지에서 R1은 FEC={192.168.5.5/32}으로 MPLS 에코 요청을 전송하고 스택에 레이블 28을 포함합니다.R2는 레이블 28을 {17, 27}과(와) 교체하므로 R3은 스택에 2개의 레이블이 있는 요청을 받고 TLV 혼동 FEC 검증에서는 1FEC를 받습니다.

RFC6424는 문제 2를 해결하기 위한 "FEC 스택 변경 TLV"의 개념을 정의합니다. 이 TLV는 후속 에코 요청에 개시자가 포함할 수 있는 PUSH/POP로 관련 FEC와 함께 회신에 포함됩니다.

draft-ietf-mpls-lsp-ping-relay-reply는 TLV에서 릴레이 노드 주소 스택을 전달하는 개념을 정의합니다. 이 개념은 Initiator에 연결할 수 없는 경우에도 Responder가 응답을 릴레이하는 데 사용할 수 있습니다.

이 두 가지 문제는 현재 Cisco IOS®에서 지원되지 않으므로 CE에서 원격 CE로의 LSP 추적은 인그레스 PE 및 원격 CE만 나열합니다.완전성만을 위해 포함되어 있습니다.