PPP 문제 해결 순서도
목차
소개
이 흐름도는 여러 Access 기술 솔루션에 널리 사용되는 PPP(Point-to-Point Protocol)의 문제를 해결하는 데 도움이 됩니다.
아래 표시된 순서도와 샘플 출력에서 레거시 DDR(Dialer-on-Demand Routing)을 사용하여 다른 BRI(Integrated Services Digital Network) PPP 연결을 설정했습니다. 그러나 Dialer Rotary-Group, Dialer Profile 또는 PPP over Serial 링크를 사용할 때 PPP 연결이 있는 다른 라우터(예: 지사)에 대한 연결에도 동일한 트러블슈팅 단계가 적용됩니다.
Point-to-Point 프로토콜 및 Cisco IOS® 소프트웨어에서 지원되는 기능에 대한 자세한 내용은 Cisco Learning Connection(등록된 고객만 해당)을 참조하고 교육 검색 필드에서 ppp 키워드를 사용하여 검색하십시오.
PPP 협상의 여러 단계 및 디버그 ppp 협상의 출력에 대한 자세한 설명은 PAP(PPP 비밀번호 인증 프로토콜 구성 및 문제 해결)를 참조하십시오.
사전 요구 사항
요구 사항
다음 전제 조건을 충족해야 합니다.
-
디버그 ppp 협상 및 디버그 ppp 인증을 활성화합니다.
-
디버그 ppp 협상 출력을 읽고 이해해야 합니다. 자세한 내용은 디버그 ppp 협상 출력 이해를 참조하십시오.
-
PPP 인증 단계는 LCP(Link Control Protocol) 단계가 완료되고 "open" 상태가 될 때까지 시작되지 않습니다. 디버그 ppp 협상이 열려 있음을 나타내지 않는 경우 계속하기 전에 이 문제를 해결하십시오.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
용어
로컬 컴퓨터(또는 로컬 라우터): 디버깅 세션이 현재 실행 중인 시스템입니다. 한 라우터에서 다른 라우터로 디버그 세션을 이동할 때 "로컬 시스템"이라는 용어를 다른 라우터에 적용합니다.
피어: 포인트-투-포인트 링크의 다른 끝입니다. 따라서 이 장치는 로컬 시스템이 아닙니다.
예를 들어 RouterA에서 debug ppp negotiation 명령을 실행하는 경우 이는 로컬 시스템이고 RouterB는 피어입니다. 그러나 디버깅을 RouterB로 전환하면 로컬 시스템이 되고 RouterA가 피어가 됩니다.
참고: 로컬 시스템과 피어라는 용어는 클라이언트-서버 관계를 의미하지 않습니다. 디버그 세션이 실행되는 위치에 따라 다이얼인 클라이언트는 로컬 컴퓨터 또는 피어일 수 있습니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
플로우 차트 문제 해결
이 문서에는 문제 해결에 도움이 되는 몇 가지 순서도 포함되어 있습니다.
참고: 문제를 성공적으로 해결하려면 이러한 순서도에 표시된 단계를 건너뛰지 마십시오.
PPP LCP(Link Control Protocol) 단계
PPP 연결에 사용되는 비동기 모뎀
이 섹션에서는 비동기 모뎀을 PPP 연결에 사용하는 방법에 대해 설명합니다. 로컬 라우터에서 나가는 LCP 프레임이 표시되지만 들어오는 LCP 프레임은 없습니다.
이 경우 문제는 두 가지 가능성 중 하나로 인해 발생할 수 있습니다.
-
로컬 라우터와 원격 라우터의 모뎀이 모두 켜지지만 PPP는 원격 라우터에서 시작되지 않습니다. 이 문제를 해결하려면 모뎀이 제대로 교육되지만 PPP가 모뎀 문제 해결 문서의 섹션을 시작하지 않습니다.
-
로컬 라우터와 원격 라우터의 모뎀이 모두 정상적으로 작동하며 PPP가 두 라우터에서 시작되지만 통화는 즉시 중단됩니다. 이렇게 하면 원격 라우터에서 수신 LCP 프레임을 받을 가능성이 사라집니다. 이 문제를 해결하려면 모뎀이 정상으로 연결되고 PPP가 시작되지만 나중에 통화는 모뎀 문제 해결 문서의 섹션을 삭제합니다.
모뎀 문제 해결에 대한 자세한 내용은 모뎀 문제 해결 을 참조하십시오.
PPP 발신 LCP 옵션
아래 순서도는 LCP 단계 중에 협상할 수 있는 가장 일반적인 PPP LCP 매개변수 중 몇 가지를 강조 표시합니다. 이 흐름도는 PPP 로컬 컴퓨터가 PPP 원격 피어와 협상하지 않는 LCP 매개변수를 찾는 데 도움이 됩니다.
PPP 인증 단계
Point-to-Point 프로토콜은 네트워크 보안을 강화하기 위해 네트워크 사용자에게 보안 데이터 전송을 보장하는 선택적 단계를 제공합니다. 일부 링크에서는 네트워크 레이어 프로토콜 패킷을 교환하기 전에 PPP 피어가 자신을 인증하도록 요구하는 것이 좋을 수 있습니다. PPP 구현의 경우 기본적으로 인증 단계는 선택 사항입니다. PPP 네트워크 관리자가 PPP 피어가 특정 인증 프로토콜을 사용하도록 하려면 PPP LCP 단계 동안 해당 인증 프로토콜 사용을 요청해야 합니다. 즉, 사용된 인증 프로토콜은 두 PPP 피어 간에 협상된 PPP LCP 옵션 중 하나여야 합니다.
이 단계에서는 인증 단계에서 PPP LCP, 인증 프로토콜 및 링크 품질 모니터링 패킷만 허용됩니다. 이 섹션의 문제 해결 단계를 따르기 전에 PPP LCP 협상 매개변수로 이 단계에서 문제가 없는지 확인합니다.
PPP 인증 단계 문제에 대한 자세한 문제 해결 정보는 PPP 문제 해결(CHAP 또는 PAP) 인증 순서도를 참조하십시오.
PPP NCP 협상
협상되는 데이터에는 NCP(Network Control Protocol)가 크게 다르지만, 사용 중인 프로토콜에 관계없이 대화의 전체 구조가 유사합니다. 이 섹션에서는 IP(IPCP) NCP 프로토콜 협상만 다룹니다.
아래 출력은 PPP NCP 협상 중 성공한 IP 협상에 대한 디버그 출력을 보여줍니다.
As4 PPP: Phase is UP As4 IPCP: O CONFREQ [Not negotiated] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) As4 IPCP: I CONFREQ [REQsent] id 1 len 28 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFREJ [REQsent] id 1 len 10 As4 IPCP: CompressType VJ 15 slots CompressSlotID (0x0206002D0F01) As4 CCP: I CONFREQ [Not negotiated] id 1 len 15 As4 CCP: MS-PPC supported bits 0x00000001 (0x120600000001) As4 CCP: Stacker history 1 check mode EXTENDED (0x1105000104) As4 LCP: O PROTREJ [Open] id 3 len 21 protocol CCP As4 LCP: (0x80FD0101000F12060000000111050001) As4 LCP: (0x04) As4 IPCP: I CONFACK [REQsent] id 1 len 10 As4 IPCP: Address 10.1.2.1 (0x03060A010201) %LINEPROTO-5-UPDOWN: Line protocol on Interface Async4, changed state to up As4 IPCP: I CONFREQ [ACKrcvd] id 2 len 22 As4 IPCP: Address 0.0.0.0 (0x030600000000) As4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) As4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) As4 IPCP: O CONFNAK [ACKrcvd] id 2 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: I CONFREQ [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) ip_get_pool: As4: validate address = 10.1.2.2 ip_get_pool: As4: using pool default ip_get_pool: As4: returning address = 10.1.2.2 set_ip_peer_addr: As4: address = 10.1.2.2 (3) is redundant As4 IPCP: O CONFACK [ACKrcvd] id 3 len 22 As4 IPCP: Address 10.1.2.2 (0x03060A010202) As4 IPCP: PrimaryDNS 10.2.2.3 (0x81060A020203) As4 IPCP: SecondaryDNS 10.2.3.1 (0x83060A020301) As4 IPCP: State is Open As4 IPCP: Install route to 10.1.2.2
IPCP가 NCP 협상 단계에서 열린 상태로 전환되지 않음
PPP 링크 안정성 문제
아래 순서도에 나와 있는 것처럼, 이 시점에서는 링크가 작동하여 패킷을 전달하지만, 제대로 작동하지 않습니다.
IP PPP 링크를 통해 패킷을 라우팅할 수 없음
아래 출력은 show caller user와 show ip interface brief 명령 출력을 보여 줍니다. 통화가 성공적으로 종료되고 PPP 연결을 통해 원격 피어로 IP 패킷을 전송할 수 있습니다.
maui-soho-01#show caller user maui-soho-02 detail User: maui-soho-02, line BR0:1, service PPP Active time 00:02:21, Idle time 00:00:57 Timeouts: Absolute Idle Limits: - 00:02:00 Disconnect in: - 00:01:02 PPP: LCP Open, CHAP (local <--> local), IPCP LCP: -> peer, AuthProto, MagicNumber <- peer, AuthProto, MagicNumber NCP: Open IPCP IPCP: <- peer, Address -> peer, Address Dialer: Connected to #, inbound Idle timer 120 secs, idle 57 secs Type is ISDN, group BRI0 IP: Local 10.0.1.1/24, remote 10.0.1.2 Counts: 123 packets input, 3246 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 119 packets output, 2940 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets maui-soho-01#show ip interface brief Interface IP-Address OK? Method Status Protocol BRI0 10.0.1.1 YES NVRAM up up BRI0:1 unassigned YES unset up up BRI0:2 unassigned YES unset down down Ethernet0 172.22.53.160 YES NVRAM up up Serial0 unassigned YES NVRAM administratively down down
IP 풀 오류
기타 PP 링크 안정성 문제
IP Layer 2 바인딩 실패
관련 정보
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
1.0 |
18-Dec-2007 |
최초 릴리스 |
피드백