목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

표기 규칙

배경 정보

EIGRP "DUAL-3-SIA" 오류 메시지의 원인은 무엇입니까?

"DUAL-3-SIA" 문제 해결

라우터가 모든 네이버로부터 응답을 받지 못한 이유는 무엇입니까?

경로가 사라진 이유는?

관련 정보

소개

EIGRP(Enhanced Interior Gateway Routing Protocol)는 DUAL(Diffuse Update Algorithm)을 기반으로 한 향상된 거리 벡터 프로토콜입니다. 네이버의 경로 광고를 기반으로 지정된 대상에 대한 모든 루프 프리 경로를 검색할 수 있습니다(보수적으로). 대상에 대한 최상의 경로를 가진 인접 디바이스(또는 인접 디바이스)를 successor라고 합니다. 대상에 대한 루프 프리 경로가 있는 나머지 네이버를 실행 가능한 successor라고 합니다. 네트워크에서 트래픽 로드를 줄이기 위해 EIGRP는 네이버 관계를 유지하고 필요에 따라 라우팅 정보를 교환하며, 대상에 대한 모든 루프 프리 경로가 실패한 경우 쿼리 프로세스를 사용하여 대체 경로를 찾습니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서의 정보는 Cisco IOS® 소프트웨어 릴리스 12.0을 기반으로 합니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

배경 정보

유효한 successor가 있는 경로는 "passive" 상태라고 합니다. 어떤 이유로든 라우터가 후속 경로를 통해 경로를 잃고 해당 경로에 대해 실행 가능한 successor가 없는 경우 경로가 "활성" 상태로 전환됩니다. 활성 상태에서 라우터는 손실된 경로에 대한 경로를 요청하는 쿼리를 인접 디바이스로 전송합니다.

EIGRP 인접 디바이스가 경로에 대한 쿼리를 수신하면 다음과 같이 동작합니다.

- EIGRP 토폴로지 테이블에 현재 경로에 대한 항목이 포함되어 있지 않은 경우 라우터는 즉시 이 네이버를 통해 이 경로에 대한 경로가 없다는 메시지를 사용하여 쿼리에 응답합니다.

- EIGRP 토폴로지 테이블에 쿼리 라우터가 이 경로에 대한 successor로 나열되고 실행 가능한 successor가 있으면 실행 가능한 successor가 설치되고 라우터가 즉시 쿼리에 응답합니다.

- EIGRP 토폴로지 테이블에 쿼리 라우터가 이 경로에 대한 successor로 나열되고 실행 가능한 successor가 존재하지 않는 경우 라우터는 이전의 successor와 동일한 인터페이스로 전송된 인접 디바이스를 제외한 모든 EIGRP 인접 디바이스를 쿼리합니다. 라우터는 이 경로에 대해 시작된 모든 쿼리에 대한 회신을 받을 때까지 쿼리 라우터에 회신하지 않습니다.

- 이 대상에 대한 successor가 아닌 인접 디바이스에서 쿼리를 수신한 경우 라우터는 후속 정보로 응답합니다.

EIGRP "DUAL-3-SIA" 오류 메시지의 원인은 무엇입니까?

DUAL-3-SIA 오류 메시지는 EIGRP 경로가 "stuck in active"(SIA) 상태에 있음을 나타냅니다.

SIA 상태는 EIGRP 라우터가 할당된 시간(약 3분) 내에 하나 이상의 네이버로부터 쿼리에 대한 응답을 받지 못했음을 의미합니다. 이 경우 EIGRP는 응답을 보내지 않은 네이버를 지우고 활성으로 이동한 경로에 대한 DUAL-3-SIA 오류 메시지를 기록합니다.

예를 들어 다음 토폴로지를 고려하십시오.

- R2는 R1을 통해 네트워크 10.1.2.0/24에 대해 학습합니다.

- R1과 R2 간의 링크가 중단됩니다. R2는 10.1.2.0/24의 후속 제품(R1)을 찾습니다.

- R2는 EIGRP 토폴로지 테이블에서 실행 가능한 successor(실행 가능성 조건을 충족하는 경로가 10.1.2.0/24인 다른 인접 디바이스)를 확인합니다. 없습니다.

- R2는 10.1.2.0/24에서 패시브에서 액티브 상태로 전환됩니다.

- R2는 R3과 R5에 10.1.2.0/24에 대한 다른 경로가 있는지 묻는 쿼리를 보냅니다. SIA 타이머가 시작됩니다.

- R5는 EIGRP 토폴로지 테이블에서 실행 가능한 successor를 확인합니다. 없습니다.

- R5는 10.1.2.0/24에 대해 패시브에서 활성으로 전환됩니다.

- R5는 EIGRP 네이버 테이블을 확인하고 R2를 향하는 인터페이스에서만 EIGRP 네이버를 찾습니다(이전의 10.1.2.0/24의 후속 모델임).

- R5는 대체 경로가 없고 쿼리할 다른 네이버가 없기 때문에 연결할 수 없는 메시지로 응답합니다.

- R5는 10.1.2.0/24에서 active에서 passive로 전환됩니다.

- R3는 EIGRP 토폴로지 테이블에서 실행 가능한 successor를 확인합니다. 없습니다.

- R3은 10.1.2.0/24에서 패시브로 전환됩니다.

- R3는 EIGRP 네이버 테이블을 확인하고 R4를 찾습니다.

- R3은 네트워크 10.1.2.0/24에 대한 쿼리를 R4로 보냅니다. SIA 타이머가 시작됩니다.

- R4는 R3과 R4 간의 링크 문제 또는 혼잡 때문에 쿼리를 받지 않습니다. R3에서 show ip eigrp neighbor 명령 또는 show ip eigrp topology active 명령을 실행하여 이 문제를 확인할 수 있습니다. R4의 대기열 수는 평소보다 높아야 합니다.

- R2의 SIA 타이머가 약 3분에 도달합니다.

- R3는 R4에서 회신을 수신할 때까지 R2의 쿼리에 응답할 수 없습니다.

- R2는 네트워크 10.1.2.0/24에 대한 DUAL-3-SIA 오류를 기록하고 R3로 인접 디바이스 인접성을 지웁니다.

DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1:

Neighbor 10.1.4.3 (Serial0) is down: stuck in active

DEC 20 12:15:23: %DUAL-3-SIA:

Route 10.1.2.0/24 stuck-in-active state in IP-EIGRP 1.

Cleaning up

- R4에 대한 R3의 재시도 타이머가 만료됩니다.

참고: 이 이벤트는 R3의 SIA 타이머도 3분에 도달할 수 있으므로 R3에서 DUAL-3-SIA 오류도 보고하지 않습니다.

- R3는 R4로 인접 디바이스 인접성을 지웁니다.

- R3는 다음 오류를 로그에 보고합니다.

DEC 20 12:12:01: %DUAL-5-NBRCHANGE: IP-EIGRP 1:

Neighbor 10.1.5.4 (Serial1) is down: retry limit exceeded

- 이제 R3는 R2의 쿼리에 연결할 수 없는 메시지를 사용하여 응답합니다.

- R4는 다음 오류를 로그에 보고합니다.

DEC 20 12:12:06: %DUAL-5-NBRCHANGE: IP-EIGRP 1:

Neighbor 10.1.5.3 (Serial0) is down: peer restarted

참고: DUAL-5-NBRCHANGE 메시지는 EIGRP 프로세스에서 eigrp log-neighbor-changes 명령을 구성한 경우에만 표시됩니다. EIGRP SIA 문제를 해결하려면 모든 EIGRP 라우터에서 이 명령을 구성하는 것이 좋습니다. EIGRP 인접 디바이스가 재설정되는 이유 또는 어떤 라우터가 인접성을 재설정하는지 알 수 없습니다.

위에서 볼 수 있듯이, DUAL-3-SIA 오류는 다음과 같은 동시에 관련이 없지만 관련이 없는 문제로 인해 발생합니다.

1. R1과 R2 간의 인터페이스 문제로, 이로 인해 10.1.2.0/24 경로가 R2에서 사라집니다. 경로 플랩은 실제 링크 오류(예: 원격 사용자의 연결이 끊겼고 PPP 파생 호스트 경로가 제거됨)가 아닌 것으로 인해 발생했을 수 있습니다.

2. R3과 R4 간의 인터페이스, 혼잡 또는 지연 문제.

SIA 오류 메시지가 발생하면 EIGRP 라우팅 프로토콜이 지정된 경로에 대해 수렴하지 못했음을 나타냅니다. 일반적으로 이 오류는 플래핑 인터페이스, 컨피그레이션 변경 또는 다이얼업 클라이언트(경로 손실은 정상임)로 인해 발생합니다. EIGRP 프로세스가 지정된 경로에 대해 활성 상태인 동안에는 다른 대상에 대한 라우팅은 영향을 받지 않습니다. 응답하지 않은 네이버의 SIA 타이머가 만료되면 네이버가 지워집니다(EIGRP는 타이머를 초과하는 네이버의 상태를 신뢰하지 않음). 따라서 해당 인접 디바이스 이외의 토폴로지 테이블의 경로가 지워지고 다시 수렴해야 합니다. 즉, 전달 테이블은 SIA에 의해 영향을 받을 수 있으며, 네트워크가 통합되는 동안 패킷을 삭제할 수 있습니다.

"DUAL-3-SIA" 문제 해결

이 섹션에서는 SIA 문제를 해결하는 데 필요한 단계를 제공하고 SIA 문제의 일반적인 원인을 제공합니다.

SIA가 발생할 수 있는 많은 다른 방법들이 있지만, 그 문제는 항상 같은 방식으로 접근해야 한다.

SIA 오류를 트러블슈팅할 때마다 SIA의 가능한 원인을 파악하기 위해 다음 두 가지 질문에 답해야 합니다(긴급 순서로 나열됨).

1. 라우터가 모든 네이버로부터 응답을 받지 못한 이유는 무엇입니까?

2. 경로가 왜 사라졌을까?

참고: Cisco 버그 ID CSCdp33034(등록된 고객만 해당) - Cisco IOS Software 릴리스 12.1(4.4)E에 유효—SIA 문제 해결을 위해 다음과 같은 개선 사항이 적용되었습니다.

- 라우터는 SIA 이벤트의 소스에 대한 트레일을 남겨둡니다.

- SIA 이벤트의 탐지 및 수정은 실패한 링크에 푸시됩니다.

다음 명령을 사용하여 트러블슈팅에 대한 자세한 정보를 수집합니다.

- 양쪽 끝의 ip eigrp 네이버 표시

- 로그 표시 |(이중)

- ip eigrp 토폴로지 활성 표시

라우터가 모든 네이버로부터 응답을 받지 못한 이유는 무엇입니까?

안타깝게도, 이 문제는 SIA의 문제 해결 중 가장 어려운 부분입니다. 기본적으로 SIA 타이머는 3분 미만이므로 이 기간 내에 응답하지 않는 라우터를 추적해야 합니다. 이렇게 하려면 네트워크의 모든 라우터와 해당 IP 주소를 포함하는 네트워크 토폴로지 다이어그램이 있어야 합니다. 각 라우터에 대한 텔넷 비밀번호도 있어야 합니다.

이 정보를 가지고 SIA를 보고한 라우터로 이동하여 해당 경로 또는 다른 경로가 활성화되는지 확인합니다. show ip eigrp topology active 명령을 실행하여 라우터에서 어떤 경로가 활성 상태인지 확인할 수 있습니다. 이 명령은 일부 활성 경로를 나열하는 것이 정상입니다. 활성 경로가 존재한다고 해서 문제가 발생하지 않습니다. 1분 이상 활성 상태인 경로에 대해 특히 주의를 기울입니다.

R2# show ip eigrp topology active

IP-EIGRP Topology Table for process 1

Codes: P - Passive, A - Active, U - Update,

Q - Query, R - Reply, r - Reply status

A 10.1.2.0 255.255.255.0, 1 successors, FD is 2733056 1 replies,

active 0:00:38, query-origin: Multiple Origins

!--- The output above will appear on one line.

via 10.1.4.3 (Infinity/Infinity), r, Serial0, serno 1232

via 10.1.6.5 (Infinity/Infinity), Serial1, serno 1227

위의 출력에서는 EIGRP가 38초 동안 10.1.2.0/24에서 활성화되었으며, 2개의 네이버를 쿼리했으며, 여전히 10.1.4.3에서 회신을 기다리고 있음을 알려줍니다. 소문자 r은 라우터가 쿼리에 대한 회신을 기다리고 있음을 나타냅니다. 대문자 R은 이 네이버로부터 응답을 받았음을 나타냅니다. 이 명령을 실행할 때 토폴로지 테이블의 상태에 따라 "Remaining Replies"라는 별도의 섹션에서 인접 디바이스를 볼 수도 있습니다.

어떤 라우터 EIGRP가 응답을 기다리고 있는지 확인한 후 해당 라우터에 텔넷하여 어떤 EIGRP가 대기 중인지 확인할 수 있습니다. 이 프로세스는 결국 쿼리에 응답하지 않는 실제 라우터로 이어집니다. 이 라우터를 식별하면 쿼리에 응답하지 않는 이유를 해결합니다. 다음은 몇 가지 일반적인 이유에 대해 설명합니다.

이전 EIGRP 코드 사용(10.3[11], 11.0[8] 및 11.1[3] 이전 Cisco IOS 릴리스)

Cisco IOS Software 릴리스 10.3(11), 11.0(8) 및 11.1(3)에서 EIGRP가 향상되었습니다. 이러한 개선 사항 중 하나는 단일 EIGRP 프로세스가 해당 링크에 사용 가능한 대역폭의 50% 이상을 사용하지 못하도록 합니다. 이 백분율을 조정할 수 있습니다. 이 백분율은 다중 지점 인터페이스에서 다를 수 있습니다. 이러한 개선 사항에서는 속도 조절을 사용하여 EIGRP 패킷을 혼잡한 링크에서 더 안정적으로 전달할 수 있습니다. 패킷 속도 조절에 대한 자세한 내용은 Enhanced Interior Gateway Routing Protocol 백서를 참조하십시오.

대역폭 인터페이스 컨피그레이션 매개변수가 없거나 잘못되었습니다.

인터페이스 또는 하위 인터페이스에 대해 bandwidth 문이 제대로 구성되지 않은 경우 EIGRP가 EIGRP 데이터 패킷을 제대로 페이징할 수 없습니다. 직렬 인터페이스에 대한 bandwidth 매개 변수의 기본값은 T1 또는 1500kbps입니다. T1이 아닌 직렬 인터페이스(분수 또는 채널화된 T1 인터페이스 포함)의 경우 인터페이스의 클럭 속도를 기반으로 올바른 대역폭을 반영하도록 이 매개변수를 수동으로 설정해야 합니다. EIGRP 경로 선택에 영향을 미치려면 bandwidth 매개 변수를 사용하지 마십시오.

경로 선택에 영향을 미치도록 구성된 잘못된 대역폭

이중 경로의 경우 라우팅 프로토콜이 다른 경로 대신 하나의 경로를 선택하도록 하는 일반적인 방법은 인터페이스에서 대역폭 매개변수를 수정하는 것입니다. 한 인터페이스에서 인위적으로 낮은 대역폭 값을 구성하면 라우팅 프로토콜이 해당 인터페이스의 경로를 사용하지 못하게 됩니다. EIGRP 패킷 속도 조절에도 이 대역폭 설정을 사용하므로 EIGRP에서는 이 방법을 사용하지 않아야 합니다. 인터페이스별로 EIGRP 경로 선택에 영향을 미치려면 지연 인터페이스 컨피그레이션 매개변수를 사용합니다.

대역폭 매개변수가 인터페이스 또는 하위 인터페이스에 대해 실제 사용 가능한 대역폭으로 설정되어 있는지 항상 확인해야 합니다.

EIGRP 라우팅 루프

라우팅 루프를 사용하면 SIA 오류가 발생할 수도 있습니다. show ip eigrp topology active 명령을 사용하여 이 문제를 식별할 수 있습니다. 응답하지 않는 EIGRP 쿼리의 순환 패턴이 나타나는 경우 라우팅 루프 문제로 이 문제를 계속 해결합니다.

일치하지 않는 기본 및 보조 주소

---

R1

---

interface Ethernet0

ip address 10.1.1.1 255.255.255.0

ip address 10.2.1.1 255.255.255.0 secondary

!

---

R2

---

interface Ethernet0

ip address 10.2.1.2 255.255.255.0

!

위의 예에서 R1은 R2에서 EIGRP hello 패킷을 수신하고 R2를 EIGRP 네이버로 표시합니다. 그러나 R2는 R1의 hello 패킷이 R2가 인식하는 서브넷이 아닌 10.1.1.1에서 소싱되기 때문에 R1을 인접 디바이스로 보지 않습니다. 이후 버전의 Cisco IOS Software에서 R2는 공통 서브넷 오류에 없는 네이버를 반환합니다. 이 오류는 R1에서 R2로 전송된 쿼리에 응답하지 않기 때문에 SIA를 발생시킵니다. R1이 R2를 인접 디바이스로 계속 지우는지 확인하려면 show ip eigrp neighbor 명령을 사용합니다.

리소스가 제한된 라우터

CPU, 메모리 또는 버퍼와 같은 시스템 리소스가 부족하면 라우터가 쿼리에 응답하거나 어떤 유형의 패킷도 처리하지 못하게 할 수도 있습니다. 리소스 문제를 식별하려면 영향을 받는 라우터를 ping하고 다른 라우터 리소스 문제인 것처럼 문제를 해결합니다.

경로가 사라진 이유는?

다음은 플래핑 경로의 몇 가지 일반적인 원인입니다.

- 플랩 링크.

show interface 명령을 사용하여 증가하는 "interface reset" 또는 "carrier transitions" 카운터를 찾습니다.

- 성능이 저하된 WAN 링크.

show interface 명령을 사용하여 증가하는 "입력 오류" 또는 "출력 오류" 카운터를 찾습니다.

- 전화 접속 PPP 링크로 생성된 호스트 경로를 요약하도록 구성되지 않은 Cisco AS5800과 같은 전화 접속 서버.

기본적으로 PPP 연결은 PPP 링크의 원격 측에 대해 32비트 호스트 경로를 설치합니다. 이러한 경로가 집계되지 않으면 모든 전화 접속 사용자가 연결을 끊을 때 EIGRP가 활성화됩니다.

관련 정보

- EIGRP 트러블슈팅

- Enhanced Interior Gateway Routing Protocol 백서

- EIGRP(Enhanced Interior Gateway Routing Protocol) 지원 페이지

- Technical Support - Cisco Systems