계정이 있습니까?

  •   맞춤형 콘텐츠
  •   제품 및 지원

계정이 필요하십니까?

계정 만들기

OSPF 인접 디바이스가 Exstart/Exchange 상태로 유지되는 이유는 무엇입니까?

다운로드 옵션

  • PDF     (240.9 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (91.2 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (104.6 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2020년 11월 17일 (화)
문서 ID:13684
번역에 관하여

이 번역에 관하여

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

    소개

    인접성 형성의 OSPF 상태는 Down, Init, Attempt, 2-way, Exstart, Exchange, Loading 및 Full입니다. OSPF(Open Shortest Path First) 인접 디바이스가 exstart/exchange 상태로 중단된 이유는 여러 가지가 있을 수 있습니다. 이 문서에서는 OSPF 인접 디바이스 간의 MTU 불일치로 인해 Exstart/Exchange 상태가 되는 것에 초점을 맞춥니다. OSPF 트러블슈팅에 대한 자세한 내용은 Troubleshooting OSPF(OSPF 트러블슈팅)를 참조하십시오.

    사전 요구 사항

    요구 사항

    이 문서의 독자는 기본 OSPF 작업 및 컨피그레이션, 특히 OSPF 네이버 상태에 대해 잘 알고 있어야 합니다.

    사용되는 구성 요소

    이 문서의 정보는 다음 소프트웨어 및 하드웨어 버전을 기반으로 합니다.

    • Cisco 2503 라우터

    • 두 라우터에서 실행되는 Cisco IOS® Software 릴리스 12.2(24a)

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

    표기 규칙

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

    Exstart 상태

    두 개의 OSPF 인접 라우터가 양방향 통신을 설정하고 다중 액세스 네트워크에서 DR/BDR 선택을 완료하면 라우터는 기존 상태로 전환됩니다. 이 상태에서 인접 라우터는 마스터/슬레이브 관계를 설정하고 DBD 패킷을 교환하는 동안 사용할 초기 DBD(데이터베이스 설명자) 시퀀스 번호를 결정합니다.

    Exchange 상태

    마스터/슬레이브 관계가 협상되면(라우터-ID가 가장 높은 라우터가 마스터가 됨) 인접 라우터가 교환 상태로 전환됩니다. 이 상태에서 라우터는 전체 링크 상태 데이터베이스를 설명하는 DBD 패킷을 교환합니다. 라우터는 또한 네이버에서 최신 LSA(link-state advertisement)를 요청하는 링크 상태 요청 패킷을 전송합니다.

    OSPF 인접 디바이스는 일반 OSPF 인접성 구축 프로세스 중에 exstart/exchange 상태를 통해 전환되지만 OSPF 인접 디바이스가 이 상태로 유지되는 것은 정상적이지 않습니다. 다음은 OSPF 인접 디바이스가 이 상태에서 고착되는 가장 일반적인 이유입니다. 다른 OSPF 상태에 대한 자세한 내용은 OSPF 인접 디바이스 상태를 참조하십시오.

    Exstart/Exchange 상태에 있는 인접 디바이스

    이 문제는 Cisco 라우터와 다른 벤더의 라우터 간에 OSPF를 실행하려고 할 때 가장 자주 발생합니다. 인접 라우터 인터페이스의 MTU(Maximum Transmission Unit) 설정이 일치하지 않을 때 문제가 발생합니다. MTU가 더 높은 라우터가 인접 라우터에 설정된 MTU보다 큰 패킷을 전송하면 인접 라우터는 패킷을 무시합니다.0 이 문제가 발생하면 show ip ospf neighbor 명령의 출력에 아래와 유사한 출력이 표시됩니다.

    이 섹션에서는 이 문제의 실제 재현에 대해 설명합니다.

    12a_01.gif

    위 토폴로지의 라우터 6 및 라우터 7은 프레임 릴레이를 통해 연결되고 라우터 6은 OSPF에 재배포된 5개의 고정 경로로 구성됩니다. 라우터 6의 직렬 인터페이스에는 기본 MTU가 1500이고 라우터 7의 직렬 인터페이스에는 MTU가 1450입니다. 각 라우터 컨피그레이션은 아래 표에 나와 있습니다(필요한 컨피그레이션 정보만 표시됨).

    라우터 6 컨피그레이션 라우터 7 컨피그레이션 
    interface Serial2

!--- MTU sets to it's default value of 1500.

no ip address
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
ip address 170.170.11.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0 255.255.255.0 Null0
ip route 192.79.35.0 255.255.255.0 Null0
ip route 192.79.36.0 255.255.255.0 Null0
ip route 192.79.37.0 255.255.255.0 Null0
ip route 192.79.38.0 255.255.255.0 Null0
    		 
    !
interface Serial0
mtu 1450
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ANSI

!
interface Serial0.6 point-to-point
ip address 170.170.11.7 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110!
!

router ospf 7
network 170.170.11.0 0.0.0.255 area 0

    각 라우터에 대한 show ip ospf neighbor 명령 출력은 다음과 같습니다.

    router-6# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.7      1   EXCHANGE/  -    00:00:36    170.170.11.7    Serial2.7
router-6#

router-7# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.6      1   EXSTART/  -     00:00:33    170.170.11.6    Serial0.6
router-7#

    이 문제는 라우터 6이 교환 상태에서 1450바이트(라우터 7의 MTU)보다 큰 DBD 패킷을 전송할 때 발생합니다. OSPF 인접성 프로세스를 보려면 각 라우터의 debug ip packet 및 debug ip ospf adj 명령을 사용합니다. 1~14단계에서 라우터 6 및 7의 출력은 다음과 같습니다.

    1. 라우터 6 디버그 출력:

      ***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, 
STATE OF NEIGHBOR IS DOWN
00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
Serial2.7 is dead
00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
Serial2.7 is dead, state DOWN

    2. 라우터 7 디버그 출력:

      OSPF NOT ENABLED ON ROUTER7 YET

    3. 라우터 6 디버그 출력:

      ***ROUTER6 SENDING HELLOS
00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), len 64, sending broad/multicast, proto=89
00:04:03: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 64, sending broad/multicast, proto=89

    4. 라우터 7 디버그 출력:

      OSPF NOT ENABLED ON ROUTER7 YET

    5. 라우터 7 디버그 출력:

      ***OSPF ENABLED ON ROUTER7, BEGINS SENDING 
HELLOS AND BUILDING A ROUTER LSA
00:17:44: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 64, sending broad/multicast, proto=89
00:17:44: OSPF: Build router LSA for area 0, 
router ID 170.170.11.7, seq 0x80000001

    6. 라우터 6 디버그 출력:

      ***RECEIVE HELLO FROM ROUTER7
00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
Len 64, rcvd 0, proto=89
00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from 
Serial2.7 170.170.11.7
00:04:04: OSPF: End of hello processing

    7. 라우터 6 디버그 출력:

      ***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID 
IN THE HELLO PACKET
00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

    8. 라우터 7 디버그 출력:

      ***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES 
STATE TO 2WAY
00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from 
Serial0.6 170.170.11.6
00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on 
Serial0.6, state 2WAY

    9. 라우터 7 디버그 출력:

      ***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD
00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32
00:17:53: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:17:53: OSPF: End of hello processing

    10. 라우터 6 디버그 출력:

      ***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET 
CHANGES STATE TO 2-WAY
00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
Serial2.7, state 2WAY

    11. 라우터 6 디버그 출력:

      ***ROUTER6 SENDS DBD PACKET TO ROUTER7 
(MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE)
00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
seq 0xE44 opt 0x2 flag 0x7 Len 32
00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 52, sending broad/multicast, proto=89
00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

    12. 라우터 7 디버그 출력:

      ***RECEIVE ROUTER6'S INITIAL DBD PACKET 
(MTU MISMATCH IS RECOGNIZED)
00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 
seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU

    13. 라우터 6 디버그 출력:

      ***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH 
LSA HEADERS, 
SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)
00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

    14. 라우터 7 디버그 출력:

      ***NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, 
RETRANSMIT
00:17:54: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [1]

    이 시점에서 라우터 6은 라우터 7에서 초기 DBD 패킷을 계속 승인하려고 합니다.

    00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 170.170.11.7 area 0 from
Serial2.7 170.170.11.7
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

    라우터 7의 DBD 패킷이 라우터 7 MTU에 비해 너무 크기 때문에 라우터 7은 라우터 6에서 ACK를 받지 않습니다. 라우터 7은 DBD 패킷을 반복적으로 재전송합니다.

    0:17:58: IP: s=170.170.11.7 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [2]

00:18:03: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 170.170.11.6 area 0 from
Serial0.6 170.170.11.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [3]

00:18:08: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

    라우터 6에는 더 높은 MTU가 있으므로 라우터 7에서 DBD 패킷을 계속 수락하고 승인하려고 시도하며 EXCHANGE 상태로 유지됩니다.

    라우터 7에는 더 낮은 MTU가 있으므로 라우터 6의 ACK와 함께 DBD 패킷을 무시하고 초기 DBD 패킷을 계속 재전송하며 EXSTART 상태로 유지됩니다.

    위의 몇 가지 단계를 살펴보겠습니다. 9단계와 11단계에서 라우터 7과 라우터 6은 마스터/슬레이브 협상의 일부로 플래그 0x7이 설정된 첫 번째 DBD 패킷을 전송합니다. 마스터/슬레이브 결정 후 라우터 7이 더 높은 라우터 ID로 마스터로 선택됩니다. 13단계와 14단계의 플래그는 라우터 7이 마스터(플래그 0x7)이고 라우터 6은 슬레이브(플래그 0x2)임을 명확하게 보여줍니다.

    10단계에서 라우터 6은 라우터 7 초기 DBD 패킷을 수신하고 상태를 2방향으로 전환합니다.

    12단계에서 라우터 7은 라우터 6 초기 DBD 패킷을 수신하고 MTU 불일치를 인식합니다. 라우터 6에는 DBD 패킷의 인터페이스 MTU 필드에 인터페이스 MTU가 포함되어 있으므로 라우터 7에서는 MTU 불일치를 인식할 수 있습니다. 라우터 6 초기 DBD는 라우터 7에서 거부됩니다. 라우터 7은 초기 DBD 패킷을 재전송합니다.

    13단계에서는 슬레이브로 라우터 6이 라우터 7 시퀀스 번호를 채택하고 LSA의 헤더를 포함하는 두 번째 DBD 패킷을 전송하여 패킷의 크기를 늘리는 것을 보여줍니다. 그러나 라우터 7은 라우터 7 MTU보다 크므로 이 DBD 패킷을 수신하지 못합니다.

    13단계 후 라우터 7에서는 계속해서 초기 DBD 패킷을 라우터 6으로 재전송하는 반면 라우터 6에서는 마스터 시퀀스 번호 뒤에 오는 DBD 패킷을 계속 전송합니다. 이 루프는 무한정 계속되므로 두 라우터가 Exstart/Exchange 상태에서 전환되지 않습니다.

    솔루션

    이 문제는 MTU가 일치하지 않아 발생하므로 라우터 MTU를 인접 디바이스 MTU와 일치하도록 변경하는 것이 해결됩니다. Cisco IOS는 LAN 인터페이스(예: 이더넷 또는 토큰 링)에서 물리적 MTU의 변경을 지원하지 않습니다. Cisco 라우터와 LAN 미디어를 통한 다른 벤더 라우터 간에 문제가 발생하면 다른 벤더 라우터에서 MTU를 조정합니다.

    참고: Cisco IOS Software Release 12.0(3)에서는 인터페이스 MTU 불일치 탐지를 도입했습니다. 이 탐지는 OSPF가 OSPF RFC 2178, 부록 G.9에 따라 DBD 패킷에 인터페이스 MTU를 광고하는 것을 포함합니다. 라우터가 라우터가 수신할 수 있는 것보다 큰 MTU를 광고하는 DBD 패킷을 수신하면 라우터는 DBD 패킷을 무시하며 인접 상태는 exstart로 유지됩니다. 이렇게 하면 인접성이 형성되지 않습니다. 이 문제를 해결하려면 MTU가 링크의 양쪽 끝에서 동일한지 확인합니다.

    Cisco IOS Software 12.01(3)에서 ip ospf mtu-ignore interface configuration 명령도 도입되어 MTU 불일치 탐지를 끕니다. 그러나 이 다이어그램에서 볼 수 있듯이 이는 드문 경우에만 필요합니다.

    12b.gif

    위 다이어그램은 라우터 2의 FDDI 인터페이스에 연결된 RSM(Route Switch Module)이 있는 Cisco Catalyst 5000의 FDDI(Fiber Distributed Data Interface) 포트를 보여줍니다. RSM의 VLAN(Virtual LAN)은 MTU가 1500이고 라우터의 FDDI 인터페이스에는 MTU45가 있습니다. 00. 스위치의 FDDI 포트에서 패킷이 수신되면 백플레인으로 이동하며 스위치 자체 내에서 FDDI에서 이더넷 변환/조각화가 발생합니다. 이는 유효한 설정이지만 MTU 불일치 탐지 기능이 있는 경우 라우터와 RSM 간에 OSPF 인접성이 형성되지 않습니다. FDDI와 이더넷 MTU가 다르므로 이 ip ospf mtu-ignore 명령은 RSM의 VLAN 인터페이스에서 유용하므로 OSPF가 MTU 불일치 탐지를 중지하고 인접성을 형성합니다.

    MTU 불일치는 OSPF 인접 디바이스가 Exstart/Exchange 상태로 고착되는 유일한 이유는 아니지만 가장 일반적입니다. 이 문제는 DBD 패킷을 성공적으로 교환할 수 없어 가장 자주 발생합니다. 그러나 근본 원인은 다음 중 하나일 수 있습니다.

    • MTU 불일치

    • 유니캐스트가 손상되었습니다. exstart 상태에서 라우터는 마스터와 슬레이브를 선택하기 위해 네이버에 유니캐스트 패킷을 전송합니다. 포인트-투-포인트 링크가 없는 한 멀티캐스트 패킷을 전송합니다. 가능한 원인은 다음과 같습니다.

      • ATM(Asynchronous Transfer Mode) 또는 Frame Relay 환경의 VC(Virtual Circuit) 매핑이 매우 중복되는 네트워크입니다.

      • MTU 문제, 즉 라우터는 특정 길이의 패킷만 ping할 수 있습니다.

      • 액세스 목록에서 유니캐스트 패킷을 차단하고 있습니다.

      • NAT가 라우터에서 실행되고 있으며 유니캐스트 패킷을 변환하고 있습니다.

    • PRI와 BRI/다이얼러 간의 네이버입니다.

    • 두 라우터 모두 동일한 라우터 ID(잘못 구성)를 가지고 있습니다.

    또한 OSPF RFC 2328, 섹션 10.3에서는 이러한 이벤트(내부 소프트웨어 문제로 인해 발생할 수 있는 이벤트)에 대해 Exstart/exchange 프로세스가 시작되었다고 설명합니다.

    • 시퀀스 번호 불일치

      • 예기치 않은 DD 시퀀스 번호

      • "I" 비트가 예기치 않게 설정되었습니다.

      • 옵션 필드가 DBD 패킷에서 수신한 마지막 옵션 필드와 다름

    • 잘못된 LSReq

      • 인접 디바이스가 교환 프로세스 중에 인식할 수 없는 LSA를 전송합니다.

      • 교환 프로세스 중에 네이버가 LSA를 요청했는데 찾을 수 없습니다.

    OSPF가 네이버를 형성하지 않을 경우, 문제를 해결하기 위해 위에 언급한 물리적 미디어 및 네트워킹 하드웨어 등의 요소를 고려하십시오.

    관련 정보

    Revision History

    Revision Publish Date Comments
    1.0
    17-Nov-2020
    Initial Release

    이 문서가 도움이 되셨습니까?

    Feedback피드백

    지원 문의

    관련 지원 커뮤니티 토론

    시스코 소개
    문의하기
    시스코와 협력하기