이 문서에서는 라인 프로토콜 상태가 "down"인 POS(Packet over SONET) 라우터 인터페이스의 문제를 해결하는 방법에 대해 설명합니다.
또한 회선 프로토콜이 다운되었음을 확인하는 데 도움이 될 뿐 아니라 PPP(Point-to-Point Protocol) 및 HDLC(high-level data link control) 캡슐화에 대한 문제를 해결하는 데 사용할 show 및 debug 명령을 설명합니다. 또한 문서화된 랩 설정을 기반으로 일반적인 트러블슈팅 시나리오를 소개합니다.
문서의 목적상 show interface pos의 출력은 이 출력과 같습니다. 디스플레이 및 주석에서 강조 표시된 부분을 확인합니다.
RTR12410-2#show interface pos 6/0 POS6/0 is up, line protocol is down !--- The line protocol is down . Hardware is Packet over SONET MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 Encapsulation HDLC, crc 32, loopback not set !--- The loopback has not been set. Keepalive set (10 sec) !--- The keepalive is set as every ten seconds. Scramble disabled Last input never, output 00:00:05, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 0 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 parity 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 3 packets output, 1074 bytes, 0 underruns 0 output errors, 0 applique, 1 interface resets 0 output buffer failures, 0 output buffers swapped out 2 carrier transitions
Cisco IOS® Command Reference는 라인 프로토콜 필드 상태가 "라인 프로토콜을 처리하는 소프트웨어 프로세스에서 라인을 사용 가능으로 간주하는지(즉, keepalive가 성공적인지) 또는 관리자가 중단했는지"를 나타냅니다.
show interface pos 출력의 다른 중요한 필드는 다음과 같습니다.
Encapsulation(캡슐화) - 인터페이스에 할당된 캡슐화 방법입니다.
loopback - 루프백이 설정되었는지 여부를 나타냅니다.
keepalive - keepalive가 설정되었는지 여부를 나타냅니다.
이 다이어그램은 POS 인터페이스에 사용되는 프로토콜 스택을 보여줍니다.
POS 인터페이스는 HDLC, PPP 및 프레임 릴레이와 같은 다중 캡슐화를 지원합니다. 따라서 SONET을 통한 패킷은 SONET을 통한 PPP 또는 SONET을 통한 HDLC가 더 정확합니다. 이 문서에서는 프레임 릴레이 캡슐화를 다루지 않습니다.
PPP와 HDLC는 밀접한 관련이 있으며 다음과 같은 특징을 공유합니다.
헤더 및 트레일러가 있는 프레이밍 구조를 제공합니다. 트레일러에서 오류 검사를 제공합니다.
수신자에 대해 패킷 및 프레임이 시작되고 끝나는 위치를 정확히 정의하는 프레임 설명을 제공합니다. HDLC 및 PPP에서, 프레임 묘사는 특별한 인터프레임 필 패턴 또는 유휴 패턴에 의해 제공된다. 패턴은 0x7E 또는 0111 1110입니다.
최소 및 최대 패킷 길이를 정의합니다.
IP 패킷을 전송하고 수신자가 도착 프레임 내에서 패킷의 정확한 유형을 결정할 수 있는 방법을 제공합니다.
그러나 밀접하게 관련되어 있지만 PPP와 HDLC는 동일하지 않으며 라인 프로토콜 문제를 해결하기 위해 서로 다른 debug 명령을 사용합니다.
다양한 debug privileged EXEC 명령의 출력은 여러 인터네트워킹 이벤트에 대한 프로토콜 상태 및 네트워크 활동과 관련된 진단 정보를 제공합니다.
주의: 디버깅 출력은 CPU 프로세스에서 높은 우선순위가 할당되므로 시스템을 사용할 수 없게 만들 수 있습니다. 따라서 debug 명령은 특정 문제를 트러블슈팅하거나 시스코 기술 지원 담당자와 트러블슈팅 세션을 진행하는 동안에만 사용합니다. 또한 네트워크 트래픽이 적고 사용자 수가 적은 기간에는 debug 명령을 사용하는 것이 좋습니다. 이러한 기간 동안 디버깅하면 debug 명령 처리 오버헤드의 증가가 시스템 사용에 영향을 미칠 가능성이 줄어듭니다. debug 명령을 사용하는 것을 마치면 특정 no debug 명령 또는 no debug all 명령으로 비활성화해야 합니다.
이러한 debug 명령은 POS 인터페이스 문제를 해결할 때 유용합니다. 이러한 각 명령의 기능 및 출력에 대한 자세한 내용은 Cisco Debug Command Reference 발행물을 참조하십시오.
debug serial interface(디버그 시리얼 인터페이스) - HDLC 킵얼라이브 패킷이 증가하고 있는지 확인합니다. 그렇지 않은 경우 인터페이스 카드 또는 네트워크에 타이밍 문제가 있을 수 있습니다.
debug ppp negotiation - PPP 시작 중에 전송된 PPP 패킷을 표시합니다. 여기서 PPP 옵션이 협상됩니다.
debug ppp packet - 전송 및 수신된 PPP 패킷을 표시합니다. 이 명령은 하위 레벨 패킷 덤프를 표시합니다.
debug ppp errors(디버그 ppp 오류) - PPP 연결 협상 및 작업과 관련된 PPP 오류(예: 잘못된 프레임 또는 잘못된 프레임)를 표시합니다.
자세한 내용은 직렬 회선 문제 해결을 참조하십시오.
HDLC는 POS 라우터 인터페이스의 기본 캡슐화 유형입니다. HDLC는 국제 표준이지만 공급업체 구현은 하나 이상의 필드 또는 헤더 또는 트레일러의 크기와 형식이 다양합니다. SONET을 정의하는 Telecordia GR-253 사양에서는 HDLC-over-SONET 매핑에 대해 설명합니다(문제 3, 섹션 3.4.2.3, pp.3-59 참조). 이는 HDLC 프레임이 SONET 프레임과 바이트 정렬되도록 지정하고, 자체 동기화 스크램블러, CRC(Cyclic Redundancy Check), HDLC 플래그 패턴의 사용을 프레임 채우기로 지정하여 도착하는 HDLC 프레임의 변수 특성을 고려하도록 지정합니다.
show interface pos 명령이 HDLC 캡슐화를 통해 회선 및 프로토콜이 다운된 것을 표시할 경우 debug serial interface 명령을 사용하여 연결 실패의 원인으로 회선 문제를 격리할 수 있습니다. HDLC는 keepalive를 사용하고 디버그 출력에 세 카운터의 값을 보고합니다.
myseq - 라우터가 keepalive 패킷을 원격 라우터에 전송할 때마다 1씩 증가합니다.
mineseen - mineseen 카운터 값은 원격 라우터가 라우터로부터 받음을 확인한 마지막 myseq 시퀀스 번호를 나타냅니다. 원격 라우터는 이 값을 사용자가 확인한 카운터에 저장하고 그 값을 keepalive 패킷에서 라우터로 전송합니다.
yourseen - 원격 라우터의 keepalive 패킷에서 라우터가 수신한 myseq 시퀀스 번호의 값을 반영합니다.
mineseq, yourseen 및 myseen 필드의 keepalive 값이 각 후속 출력 행에서 증가하지 않으면 연결의 한쪽 끝에 문제가 있습니다. myseq 및 minesine 필드의 값 차이가 3을 초과하면 회선이 다운되고 인터페이스가 재설정됩니다.
이는 keepalive가 양쪽에서 제대로 수신된 경우 HDLC 연결에 대한 debug serial interface 명령의 샘플 출력입니다.
hswan-12008-2a#debug serial interface Serial network interface debugging is on hswan-12008-2a# Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, changed state to up !--- Local router sees a remote keepalive with a sequence number of 1. Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up !--- Keepalives are sent every 10 seconds by default. !--- Both sides report incrementing sequence numbers.
원격 인터페이스가 종료되고 로컬 인터페이스에서 3개 이상의 keepalive가 누락된 경우 HDLC 연결에 대한 debug serial interface 명령의 샘플 출력입니다.
hswan-12008-2a# Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, changed state to down !--- The local router has failed to receive three keepalives and !--- brings down the line protocol. Note the difference between !--- "myseq 195" and "mineseen 192". Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, changed state to up !--- After you execute the no shut command on the remote router, !--- the local router receives a keepalive again and brings up !--- the line protocol. Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up !--- After the shut/no shut, the remote router re-initialized its !--- sequence number.
RFC 1661은 PPP를 프로토콜로 정의합니다.
POS 인터페이스는 레이어 2의 데이터 캡슐화를 위해 RFC 1662에 지정된 대로 HDLC(High-Level Data Link Control) 유사 프레이밍에서 PPP를 지원합니다. 이 그림에는 HDLC 유사 프레이밍의 PPP에 대한 프레임 형식이 나와 있습니다.
RFC 2615는 SONET 또는 SDH 링크를 통한 PPP 캡슐화를 사용하도록 지정합니다. PPP는 포인트-투-포인트 링크에서 사용하도록 설계되었으며 링 토폴로지에서도 포인트-투-포인트 회로로 프로비저닝되는 SONET 또는 SDH 링크에 적합합니다.
PPP는 포인트-투-포인트(point-to-point) 링크를 시작할 때 여러 단계를 거치게 되며 상태 다이어그램으로 그릴 수 있습니다. 캐리어 감지 또는 네트워크 관리자 컨피그레이션과 같은 외부 이벤트가 물리적 레이어를 사용할 준비가 되었음을 나타낼 경우 PPP는 링크 설정 단계로 진행합니다. 이 단계로 전환하면 LCP(Link Control Protocol)에 대한 UP 이벤트가 생성되는데, 이는 여러 기능을 제공합니다. 한 가지 기능은 링크가 제대로 작동하고 있을 때와 실패하고 있을 때의 결정입니다. Point-to-Point 링크를 통해 통신을 설정하려면 먼저 PPP 링크의 각 끝에서 LCP 패킷을 전송하여 데이터 링크를 구성하고 테스트해야 합니다.
그런 다음 PPP는 NCP(Network Control Protocol) 패킷을 전송하여 하나 이상의 네트워크 레이어 프로토콜을 선택하고 구성해야 합니다. 선택한 각 네트워크 레이어 프로토콜이 구성되면 각 네트워크 레이어 프로토콜의 데이터그램을 링크를 통해 전송할 수 있습니다.
다음 표에는 세 가지 LCP 패킷 클래스가 나열되어 있습니다.
LCP 패킷 클래스 | LCP 패킷 유형 | 목적 |
---|---|---|
링크 컨피그레이션 | Configure-Request, Configure-Ack, Configure-Nak 및 Configure-Reject | 링크를 설정하고 구성하는 데 사용됩니다. |
링크 종료 | Terminate-Request 및 Terminate-Ack | 링크를 종료하는 데 사용됩니다. |
링크 유지 관리 | Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply 및 Discard-Request | 링크를 관리하고 디버깅하는 데 사용됩니다. |
LCP는 구성 패킷의 교환을 통해 연결을 설정하는 데 사용됩니다. Configure-Ack 패킷이 전송 및 수신되면 이 교환이 완료되고 LCP Opened 상태가 시작됩니다.
이 샘플 출력은 POS 인터페이스의 LCP 링크 컨피그레이션 스테이지를 캡처합니다.
4d01h: PO3/1 LCP: State is Open 4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP (0x639FCAD8) id 0 (0s.) queued 1/1/2 4d01h: PO3/1 PPP: Phase is UP 4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 4d01h: PO3/1 IPCP: Address 172.16.1.1 (0x0306AC100101) 4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 4d01h: PO3/1 IPCP: Address 172.16.1.2 (0x0306AC100102) 4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 4d01h: PO3/1 IPCP: Address 172.16.1.2 (0x0306AC100102) 4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 4d01h: PO3/1 IPCP: Address 172.16.1.1 (0x0306AC100101) 4d01h: PO3/1 IPCP: State is Open 4d01h: PO3/1 IPCP: Install route to 172.16.1.2 4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, changed state to up
참고: PPP 캡슐화를 사용하여 구성된 POS 인터페이스는 PPP 세션을 계속 설정하려고 시도합니다. 따라서, 당신은 지속적인 문제가 있을 때, 심지어 섬유가 제거되었을 때, 주기적으로 라인 프로토콜이 간략히 올라오는 것을 볼 수 있다.
LCP Echo-Request 및 Echo-Reply 패킷은 링크의 양방향에 대해 레이어 2 루프백 메커니즘을 제공합니다. LCP Opened 상태에서 Echo-Request를 수신하면 Echo-Reply를 전송해야 한다.
RFC 1661의 이 다이어그램은 PPP 킵얼라이브 패킷의 형식을 보여줍니다.
이러한 LCP 패킷에는 다음과 같은 키 필드가 포함됩니다.
Code(코드) - Echo-Request의 경우 9이고 Echo-Reply의 경우 10입니다.
Identifier(식별자) - 전송 시 Identifier(식별자) 필드는 Data(데이터) 필드의 내용이 변경될 때마다 그리고 이전 요청에 대한 유효한 응답이 수신될 때마다 변경되어야 합니다. 재전송의 경우 식별자는 변경되지 않을 수 있습니다. 수신 시 Echo-Request의 Identifier 필드가 Echo-Reply 패킷의 Identifier 필드에 복사됩니다.
Magic-Number—Magic-Number 필드는 4옥텟이며, 루프백 상태의 링크를 탐지하는 데 도움이 됩니다. Magic-Number 컨피그레이션 옵션이 성공적으로 협상될 때까지 Magic-Number는 0으로 전송되어야 합니다. 자세한 설명은 RFC 1661의 Magic-Number 컨피그레이션 옵션을 참조하십시오.
Data(데이터) - Data(데이터) 필드는 0개 이상의 옥텟이며, 발신자가 사용할 해석되지 않은 데이터를 포함합니다. 데이터는 임의의 이진 값으로 구성될 수 있다. 필드의 끝은 길이로 표시됩니다.
keepalive가 활성화된 경우 debug ppp 협상의 예는 다음과 같습니다.
4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 4d01h: PO3/1 LCP: Received id 1, sent id 1, line up
PPP는 언제든지 링크를 종료할 수 있습니다. 가능한 트리거로는 캐리어 손실, 인증 실패, 링크 품질 실패, 유휴 기간 타이머 만료 또는 링크의 관리 종료가 있습니다.
LCP는 종료 패킷을 사용하여 링크를 닫습니다. Terminate-Request의 발신자는 Terminate-Ack을 수신한 후 또는 Restart 카운터가 만료된 후에 연결을 끊어야 합니다. Terminate-Request의 수신자는 피어의 연결을 끊을 때까지 기다려야 하며, Terminate-Ack을 전송한 후 적어도 하나의 Restart 시간이 경과할 때까지 연결을 끊으면 안 됩니다.
Terminate LCP 패킷에는 다음 키 필드가 포함됩니다.
Code(코드) - Terminate-Request의 경우 5이고 Terminate-Ack의 경우 6입니다.
Identifier(식별자) - 전송 시 Identifier(식별자) 필드는 Data(데이터) 필드의 내용이 변경될 때마다, 그리고 이전 요청에 대한 유효한 응답이 수신될 때마다 변경되어야 합니다. 재전송의 경우 식별자는 변경되지 않을 수 있습니다. 수신 시, Terminate-Request의 Identifier 필드는 Terminate-Ack 패킷의 Identifier 필드에 복사된다.
Data 필드는 0개 이상의 옥텟이며, 발신자가 사용할 해석되지 않은 데이터를 포함합니다. 데이터는 임의의 이진 값으로 구성될 수 있다. 필드의 끝은 길이로 표시됩니다.
다음은 TERMREQ 패킷을 수신할 때 디버그 ppp 협상 출력의 예입니다.
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 4d01h: PO3/1 IPCP: State is Closed 4d01h: PO3/1 PPP: Phase is TERMINATING 4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 4d01h: PO3/1 LCP: MRU 1500 (0x010405DC) 4d01h: PO3/1 LCP: MagicNumber 0x00000002 (0x050600000002) 4d01h: PO3/1 LCP: Dropping packet, state is TERMsent !--- While in the TERMsent state, PPP should drop all other packets. 4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, changed state to down
이 섹션에서는 PPP 캡슐화를 사용하는 POS 링크의 샘플 트러블슈팅 시나리오에 대해 설명합니다. 다음과 같은 컨피그레이션을 사용합니다.
라우터 A 컨피그레이션 |
---|
interface POS1/0 ip address 1.1.1.6 255.255.255.0 no ip directed-broadcast encapsulation ppp crc 16 clock source internal |
라우터 B 컨피그레이션 |
---|
interface POS2/0 ip address 1.1.1.5 255.255.255.0 no ip directed-broadcast encapsulation ppp crc 16 |
참고: 이러한 디버깅은 백투백 랩 설정에서 두 라우터에 캡처되었습니다. 따라서 클럭킹은 한쪽에서는 internal로 설정되고 다른 쪽 끝에서는 default로 설정됩니다.
이 출력은 LCP의 링크 설정 단계 동안 디버그 ppp 협상을 통해 캡처된 패킷 교환을 보여줍니다.
라우터 A 디버그 출력 |
---|
Router A Debug Output (1) !--- The router sends an outgoing confreq. hswan-12008-2a# *Nov 7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up *Nov 7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line *Nov 7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open *Nov 7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 *Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) |
(4) !--- Router A receives an incoming confreq from router B. *Nov 7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 *Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) |
(5) !--- Router A responds with a confack and receives a !--- confack from Router B. The LCP state is open. *Nov 7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 *Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) *Nov 7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 Nov 7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) *Nov 7 08:27:00: PO1/0 LCP: State is Open *Nov 7 08:27:00: PO1/0 PPP: Phase is UP |
(7) !--- Router A begins the IPCP stage and negotiates an IP address. !--- In this setup, the peer router already has an address and !--- sends it in a confreq. If the peer router accepts the address, !--- it responds with a confack. *Nov 7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 *Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) *Nov 7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 *Nov 7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 *Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) *Nov 7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 *Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) *Nov 7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 *Nov 7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 *Nov 7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 *Nov 7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) *Nov 7 08:27:00: PO1/0 IPCP: State is Open *Nov 7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 *Nov 7 08:27:00: PO1/0 CDPCP: State is Open *Nov 7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5 *Nov 7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, changed state to up |
라우터 B 디버그 출력 |
---|
(2) !--- Router B receives an incoming confrq from Router A. hswan-12008-2b# Nov 7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) Nov 7 10:29:19.043: PO2/0 IPCP: State is Closed Nov 7 10:29:19.043: PO2/0 CDPCP: State is Closed Nov 7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING Nov 7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING |
(3) !--- Router B sends its own LCP confreq. Nov 7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) |
(6) !--- Router B responds with a confack and receives a confack from Router A. The LCP state is open. Nov 7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 Nov 7 10:29:19.043: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.043: PO2/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) Nov 7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6 Nov 7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 Nov 7 10:29:19.047: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 10:29:19.047: PO2/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2) Nov 7 10:29:19.047: PO2/0 LCP: State is Open Nov 7 10:29:19.047: PO2/0 PPP: Phase is UP |
(8) !--- Router B also begins the IPCP stage and negotiates an IP address. Nov 7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 Nov 7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 Nov 7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 Nov 7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 Nov 7 10:29:19.047: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 10:29:19.047: PO2/0 IPCP: State is Open Nov 7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 Nov 7 10:29:19.047: PO2/0 CDPCP: State is Open Nov 7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6 *Nov 7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, changed state to up |
이 출력은 링크가 설정되는 동안 debug ppp 패킷으로 캡처된 패킷 교환을 보여줍니다. 이 디버그는 PPP 패킷의 프로토콜 필드 값을 캡처합니다. RFC 1661은 Protocol 필드를 1 또는 2개의 옥텟으로 정의합니다. 이 필드의 값은 패킷의 Information 필드에 캡슐화된 데이터그램을 식별합니다.
"0***"에서 "3***" 범위의 프로토콜 필드 값은 특정 패킷의 네트워크 레이어 프로토콜을 식별하고, "8***"에서 "b***" 범위의 값은 연결된 NCP(Network Control Protocol)에 속하는 패킷이 있는 경우 이를 식별합니다. "c***"에서 "f***" 범위의 프로토콜 필드 값은 패킷을 링크 계층 제어 프로토콜(예: LCP)로 식별합니다. 공급업체별 가치도 다양합니다. PPP 프로토콜 필드 값의 전체 목록을 보려면 여기를 클릭하십시오.
라우터 A 디버그 출력 |
---|
(1) *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 !--- 0xC021 identifies LCP. *Nov 7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 *Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) *Nov 7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z *Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) *Nov 7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 *Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) *Nov 7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 *Nov 7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 !--- 0x8021 identifies IPCP, PPP internet protcol control protocol. *Nov 7 10:19:58: PO1/0 LCP: MRU 4470 (0x01041176) *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 !--- 0x8207 identifies Cisco discovery protocol control. *Nov 7 10:19:58: PO1/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) *Nov 7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 *Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) *Nov 7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 *Nov 7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet *Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) *Nov 7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 *Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105) *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 *Nov 7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 *Nov 7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 *Nov 7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 *Nov 7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 *Nov 7 10:19:58: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106) *Nov 7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 *Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 !--- 0x0207 identifies Cisco Discovery Protocol (CDP). *Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 *Nov 7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 *Nov 7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, changed state to up |
(3) !--- ECHOREQand ECHOREP packets for PPP keepalives use packet type values !--- of 0xC021. *Nov 7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 *Nov 7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 *Nov 7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C *Nov 7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C *Nov 7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 *Nov 7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 *Nov 7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 *Nov 7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up |
라우터 B 디버그 출력 |
---|
(2) Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 Nov 7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) Nov 7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 Nov 7 12:22:16.947: PO2/0 LCP: MRU 4470 (0x01041176) Nov 7 12:22:16.947: PO2/0 LCP: MagicNumber 0x269933F4 (0x0506269933F4) Nov 7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 Nov 7 12:22:16.947: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 Nov 7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 Nov 7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.6 (0x030601010106) Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 Nov 7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 Nov 7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 Nov 7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 Nov 7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 Nov 7 12:22:16.951: PO2/0 IPCP: Address 1.1.1.5 (0x030601010105) Nov 7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 Nov 7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, changed state to up |
(4) !--- ECHOREQ and ECHOREP packets for PPP keepalives use packet type !--- values of 0xC021. Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 Nov 7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 Nov 7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 Nov 7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C Nov 7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up Nov 7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 |
PPP 또는 HDLC 캡슐화가 포함된 POS 인터페이스는 링크 장애를 경고하는 두 가지 메커니즘을 지원합니다. 레이어 2 킵얼라이브 및 SONET 레이어 경보 keepalive는 고유한 SONET 경보 구조보다 문제를 보고하는 데 시간이 더 오래 걸립니다. 그러나 레이어 2 keepalive는 SONET 레벨 경보처럼 framer에서 framer로 연결되는 경로가 아니라 라인 카드 CPU에서 라인 카드 CPU로 연결되는 경로를 확인하기 때문에 유용합니다. PPP는 LCP가 즉시 중단되기 때문에 상태 변경을 연결하는데 더 빠르게 반응한다. 이와 달리 HDLC는 킵얼라이브를 시간 초과해야 합니다.
두 라우터 간의 백투백(back-to-back) 설정에서 파이버 선 중 하나를 풀면 레이어 1 연결이 끊어지고 두 POS 인터페이스 모두 상태가 중단/중단으로 변경됩니다. 그러나 두 라우터 POS 인터페이스가 SONET/SDH 장비를 사용하여 Telco 클라우드 전반에 연결할 경우 레이어 1 손실 정보가 원격 끝으로 전파되지 않습니다. 이 컨피그레이션에서는 keepalive가 링크를 차단하는 메커니즘입니다.
이 설정을 고려하십시오.
다음은 SDHb에서 SDHa로의 링크에서 전송 파이버 가닥을 당길 때 발생하는 일입니다.
라우터 7507a는 어떠한 킵얼라이브도 수신하지 않습니다.
라우터 7507b는 수신 파이버가 여전히 작동하기 때문에 7507a의 keepalive를 확인합니다. 디버그 시리얼 인터페이스를 사용하여 확인합니다.
또는 이 테스트를 수행할 때 SONET 경보를 표시하는 show controller pos 명령을 실행합니다. 라우터 7507a에서는 경로 경보 신호(P-AIS)를, 7507b에서는 경로 원격 결함 신호(P-RDI)를 확인해야 합니다.
show interfaces pos 명령의 출력에 직렬 회선은 가동 중이지만 회선 프로토콜이 다운된 것으로 표시되면 루프백 테스트를 사용하여 문제의 원인을 확인합니다. 먼저 로컬 루프 테스트를 수행한 다음 원격 테스트를 수행합니다. 지침은 Cisco 라우터의 루프백 모드 이해를 참조하십시오.
참고: 루프백을 사용할 경우 캡슐화를 PPP에서 HDLC로 변경합니다. PPP로 구성된 인터페이스의 라인 프로토콜은 모든 LCP 및 NCP 세션이 성공적으로 협상된 경우에만 나타납니다.
APS(Automatic Protection Switching)용으로 구성된 POS 인터페이스는 인터페이스가 작업 채널이 아닌 보호 채널인 경우 회선 프로토콜을 중단합니다. 이 샘플 토폴로지를 고려하십시오.
이 샘플 로그 출력은 GSRb의 POS 1/0 인터페이스의 파이버 케이블이 제거된 후에 캡처되었습니다. APS 전환이 발생할 경우 두 인터페이스의 라인 프로토콜 상태가 변경됩니다. OSPF(Open Shortest Path First) 인접성 상태의 변화도 확인합니다. (자세한 내용은 APS 기술 지원 페이지를 참조하십시오.)
*Sep 5 17:41:46: %SONET-4-ALARM: POS1/0: SLOS *Sep 5 17:41:46: %SONET-4-ALARM: POS2/0: APS enabling channel *Sep 5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect *Sep 5 17:41:46: %SONET-4-ALARM: POS1/0: APS disabling channel *Sep 5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, changed state to up *Sep 5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, changed state to down *Sep 5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down *Sep 5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 from FULL to DOWN, Neighbor Down: Interface down or detached *Sep 5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 from LOADING to FULL, Loading Done
PPP 캡슐화를 사용하는 POS 인터페이스에서 APS를 구성하지 마십시오. PPP가 APS를 인식하지 못합니다. APS 선택 취소로 인해 인터페이스가 작동/작동 중지된 경우 PPP는 인터페이스 재설정을 시도하고 PPP 협상 패킷을 계속 전송합니다.
또한 불필요한 회선 프로토콜 플랩을 방지하려면 keepalive를 비활성화합니다. keepalive는 대부분의 POS 라우터 하드웨어에서 자동으로 비활성화됩니다.
APS 작동 또는 보호 모드의 Cisco 12000 Series POS 인터페이스는 APS가 비활성화된 경우(루프백의 경우에도) 업/다운 상태에서 고착될 수 있습니다. 동일한 슬롯에 삽입된 다른 카드에서 이 문제가 발생합니다. 올바른 라인 프로토콜 상태를 복원하려면 카드를 새 슬롯으로 이동합니다. 이 문제는 Cisco IOS Software Release 12.0(19)S(Cisco 버그 ID CSCdt43759)(등록된 고객만 해당)에서 해결됩니다.
해결 방법으로 다음 단계를 사용합니다.
aps protect 명령을 구성합니다.
aps force 1 명령을 실행합니다.
no aps protect 명령을 구성합니다.
POS 인터페이스에서 라인 프로토콜 문제를 해결할 때 다음 사항에 유의하십시오.
PA-POS 인터페이스는 캡슐화가 PPP에서 HDLC로 변경된 후 계속 재설정될 수 있습니다. 이 문제는 Cisco 버그 ID CSCdk30893(등록된 고객만)의 PA-POS에 대해 보고되며, PPP 및 HDLC 캡슐화를 지원하는 다양한 인터페이스에 대해 Cisco 버그 ID CSCdk1877(등록된 고객만) 및 Cisco 버그 ID CSCdk13757(등록된 고객만)에서 해결됩니다. 캡슐화를 변경했을 때 PPP가 완전히 종료되지 않은 경우 문제가 발생합니다.
HDLC 캡슐화 및 킵얼라이브로 구성된 POS 인터페이스는 원격 엔드로부터 킵얼라이브가 수신되지 않을 때 라인 프로토콜을 중단하기보다는 반복적인 인터페이스 플랩을 거칩니다. 이 문제는 Cisco 버그 ID CSCdp86387(등록된 고객만 해당)에서 해결됩니다.
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
30-Dec-2001 |
최초 릴리스 |