이 문서에서는 Cisco IOS®의 다양한 킵얼라이브 메커니즘에 대해 설명합니다.
Keepalive 메시지는 물리적 또는 가상 회로를 통해 하나의 네트워크 디바이스에 의해 전송되어 이들 간의 회로가 여전히 작동함을 다른 네트워크 디바이스에 알립니다. 킵얼라이브가 일을 하려면 두 가지 필수 요소가 있습니다.
이더넷과 같은 방송 매체에서 킵얼라이브는 약간 독특합니다. 이더넷에는 가능한 인접 디바이스가 많기 때문에 keepalive는 와이어에 있는 특정 인접 디바이스의 경로를 사용할 수 있는지 확인하도록 설계되지 않았습니다. 로컬 시스템에 이더넷 와이어 자체에 대한 읽기 및 쓰기 액세스 권한이 있는지 확인하도록 설계되었습니다. 라우터는 자신을 소스 및 대상 MAC 주소로 사용하고 특수 이더넷 유형 코드 0x9000을 사용하여 이더넷 패킷을 생성합니다. 이더넷 하드웨어는 이 패킷을 이더넷 와이어로 전송한 다음 즉시 이 패킷을 다시 수신합니다. 이더넷 어댑터의 송수신 하드웨어 및 와이어의 기본 무결성을 확인합니다.

직렬 인터페이스에는 서로 다른 유형의 캡슐화가 있을 수 있으며, 각 캡슐화 유형에 따라 사용할 킵얼라이브의 종류가 결정됩니다.
라우터가 ECHOREQ 패킷을 피어로 전송하는 빈도를 설정하려면 인터페이스 컨피그레이션 모드에서 keepalive 명령을 입력합니다.
또 다른 잘 알려진 킵얼라이브 메커니즘은 HDLC를 위한 직렬 킵얼라이브이다. 시리얼 keepalive는 두 라우터 간에 왕복 전송되며 keepalive는 승인됩니다. 시퀀스 번호를 사용하여 각 킵얼라이브를 추적하면 각 디바이스는 HDLC 피어가 전송한 킵얼라이브를 수신했는지 확인할 수 있습니다. HDLC 캡슐화의 경우 세 개의 무시된 keepalive로 인해 인터페이스가 다운됩니다.
사용자가 생성 및 전송된 킵얼라이브를 볼 수 있도록 하려면 HDLC 연결에 대해 debug serial interface 명령을 활성화합니다.
Sample Output:
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
HDLC 킵얼라이브에는 작동을 확인하기 위해 3개의 조각이 포함되어 있습니다.
HDLC keepalive는 ECHOREQ 유형 keepalive이므로 keepalive 빈도가 중요하며 양쪽에서 정확히 일치하는 것이 좋습니다. 타이머가 동기화되지 않은 경우 시퀀스 번호의 순서가 흐트러지기 시작합니다. 예를 들어, 한 쪽을 10초로 설정하고 다른 쪽을 25초로 설정하면 빈도의 차이가 3의 차이로 인해 시퀀스 번호가 해제되는 데 충분하지 않은 한 인터페이스가 계속 작동 상태를 유지할 수 있습니다.
HDLC 킵얼라이브의 작동 방식을 보여주는 예시로서, 라우터 1과 라우터 2는 각각 Serial0/0과 Serial2/0을 통해 직접 연결됩니다. 인터페이스 상태를 추적하는 데 실패한 HDCL 킵얼라이브가 어떻게 사용되는지 설명하기 위해 라우터 1에서 Serial 0/0이 종료됩니다.

라우터 1
Router1#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.1/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]
17:21:09.685: Serial0/0: HDLC myseq 0, mineseen 0*, yourseen 1, line up
17:21:19.725: Serial0/0: HDLC myseq 1, mineseen 1*, yourseen 2, line up
17:21:29.753: Serial0/0: HDLC myseq 2, mineseen 2*, yourseen 3, line up
17:21:39.773: Serial0/0: HDLC myseq 3, mineseen 3*, yourseen 4, line up
17:21:49.805: Serial0/0: HDLC myseq 4, mineseen 4*, yourseen 5, line up
17:21:59.837: Serial0/0: HDLC myseq 5, mineseen 5*, yourseen 6, line up
17:22:09.865: Serial0/0: HDLC myseq 6, mineseen 6*, yourseen 7, line up
17:22:19.905: Serial0/0: HDLC myseq 7, mineseen 7*, yourseen 8, line up
17:22:29.945: Serial0/0: HDLC myseq 8, mineseen 8*, yourseen 9, line up
Router1 (config-if)#shut
17:22:39.965: Serial0/0: HDLC myseq 9, mineseen 9*, yourseen 10, line up
17:22:42.225: %LINK-5-CHANGED: Interface Serial0/0, changed state
to administratively down
17:22:43.245: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0,
changed state to down
라우터 2
Router2#show interfaces serial 0/0/0
Serial0/0/0 is up, line protocol is up (connected)
Hardware is HD64570
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, rely 255/255, load 1/255
Encapsulation HDLC, loopback not set, keepalive set (10 sec)
[output is omited]
17:21:04.929: Serial2/0: HDLC myseq 0, mineseen 0, yourseen 0, line up
17:21:14.941: Serial2/0: HDLC myseq 1, mineseen 1*, yourseen 1, line up
17:21:24.961: Serial2/0: HDLC myseq 2, mineseen 2*, yourseen 2, line up
17:21:34.981: Serial2/0: HDLC myseq 3, mineseen 3*, yourseen 3, line up
17:21:45.001: Serial2/0: HDLC myseq 4, mineseen 4*, yourseen 4, line up
17:21:55.021: Serial2/0: HDLC myseq 5, mineseen 5*, yourseen 5, line up
17:22:05.041: Serial2/0: HDLC myseq 6, mineseen 6*, yourseen 6, line up
17:22:15.061: Serial2/0: HDLC myseq 7, mineseen 7*, yourseen 7, line up
17:22:25.081: Serial2/0: HDLC myseq 8, mineseen 8*, yourseen 8, line up
17:22:35.101: Serial2/0: HDLC myseq 9, mineseen 9*, yourseen 9, line up
17:22:45.113: Serial2/0: HDLC myseq 10, mineseen 10*, yourseen 10, line up
17:22:55.133: Serial2/0: HDLC myseq 11, mineseen 10, yourseen 10, line up
17:23:05.153: HD(0): Reset from 0x203758
17:23:05.153: HD(0): Asserting DTR
17:23:05.153: HD(0): Asserting DTR and RTS
17:23:05.153: Serial2/0: HDLC myseq 12, mineseen 10, yourseen 10, line up
17:23:15.173: HD(0): Reset from 0x203758
17:23:15.173: HD(0): Asserting DTR
17:23:15.173: HD(0): Asserting DTR and RTS
17:23:15.173: Serial2/0: HDLC myseq 13, mineseen 10, yourseen 10, line down
17:23:16.201: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial2/0,
changed state to down
Router2#
17:23:25.193: Serial2/0: HDLC myseq 14, mineseen 10, yourseen 10, line down
PPP 킵얼라이브는 HDLC 킵얼라이브와 조금 다릅니다. HDLC와 달리 PPP keepalive는 ping에 가깝습니다. 양측 모두 한가할 때 서로 핑할 수 있다. 적절한 협상 작업은 항상 이 "ping"에 응답하는 것입니다. 따라서 PPP keepalive의 경우 빈도나 타이머 값은 로컬에만 해당되며 다른 쪽에 영향을 주지 않습니다. 한 쪽에서 킵얼라이브를 해제하더라도 킵얼라이브 타이머가 있는 쪽의 에코 요청에 계속 응답합니다. 그러나, 그것은 결코 그것의 어떤 것도 시작하지 않을 것입니다.
사용자가 전송된 PPP 킵얼라이브를 볼 수 있도록 하려면 PPP 연결에 대해 debug ppp packet 명령을 활성화합니다.
17:00:11.412: Se0/0/0 LCP-FS: I ECHOREQ [Open] id 32 len 12 magic 0x4234E325
및 수신된 응답:
17:00:11.412: Se0/0/0 LCP-FS: O ECHOREP [Open] id 32 len 12 magic 0x42345A4D
PPP 킵얼라이브에는 세 가지가 있습니다.
PPP 캡슐화의 경우 5개의 무시된 keepalive로 인해 인터페이스가 다운됩니다
GRE 터널 킵얼라이브 메커니즘은 이더넷 또는 직렬 인터페이스와는 약간 다릅니다. 원격 라우터가 GRE keepalive를 지원하지 않는 경우에도 원격 라우터에서 킵얼라이브 패킷을 수신하고 시작할 수 있는 기능을 제공합니다. GRE는 IP 내부 IP를 터널링하는 패킷 터널링 메커니즘이므로 GRE IP 터널 패킷을 다른 GRE IP 터널 패킷 내부에 구축할 수 있습니다. GRE keepalive의 경우 발신자는 원래 keepalive 요청 패킷 내부에 keepalive 응답 패킷을 미리 구축하므로 원격 단은 외부 GRE IP 헤더의 표준 GRE 역캡슐화만 수행한 다음 내부 IP GRE 패킷을 전달하면 됩니다. 이 메커니즘은 keepalive 응답이 터널 인터페이스가 아닌 물리적 인터페이스를 포워드아웃하도록 합니다. GRE 터널 킵얼라이브의 작업에 대한 자세한 내용은 GRE 킵얼라이브 작업 방법을 참조하십시오.
IKE(Internet Key Exchange) 킵얼라이브는 VPN 피어가 작동 중이며 암호화된 트래픽을 수신할 수 있는지 여부를 확인하는 데 사용되는 메커니즘입니다. VPN 피어는 일반적으로 다시 연결되지 않으므로 인터페이스 keepalive는 VPN 피어의 상태에 대한 충분한 정보를 제공하지 않으므로 인터페이스 keepalive 외에 별도의 암호화 keepalive가 필요합니다.
Cisco IOS 디바이스에서 IKE 킵얼라이브는 DPD(Dead Peer Detection)라는 독점적 방법을 사용하여 활성화됩니다. 게이트웨이가 피어에 DPD를 전송하도록 하려면 글로벌 컨피그레이션 모드에서 다음 명령을 입력합니다.
crypto isakmp keepalive seconds [retry-seconds] [ periodic | on-demand ]
keepalive를 비활성화하려면 이 명령의 "no" 형식을 사용합니다. 이 명령의 각 키워드가 수행하는 작업에 대한 자세한 내용은 crypto isakmp keepalive를 참조하십시오. 더 세부적으로, 킵얼라이브는 ISAKMP 프로파일 아래에서 구성할 수도 있습니다. 자세한 내용은 ISAKMP 프로파일 개요 [Cisco IOS IPsec]를 참조하십시오.
하나의 VPN 피어가 NAT(Network Address Translation) 뒤에 있는 시나리오의 경우 NAT-Traversal이 암호화에 사용됩니다. 그러나 유휴 기간 중에는 업스트림 디바이스의 NAT 항목이 시간 초과될 수 있습니다. 이렇게 하면 터널을 시작할 때 문제가 발생할 수 있으며 NAT가 양방향이 아닙니다. NAT keepalive는 두 피어 간의 연결 중에 동적 NAT 매핑을 활성 상태로 유지하기 위해 활성화됩니다. NAT 킵얼라이브는 암호화되지 않은 페이로드가 1바이트인 UDP 패킷입니다. 현재 DPD 구현은 NAT 킵얼라이브와 유사하지만 약간의 차이가 있습니다. DPD는 피어 상태를 탐지하는 데 사용되지만 IPsec 엔터티가 지정된 기간에 패킷을 보내거나 받지 않은 경우 NAT 킵얼라이브가 전송됩니다. 유효한 범위는 5~3600초입니다.
이 기능에 대한 자세한 내용은 IPsec NAT 투명성을 참조하십시오.