OSPF Demand Circuit에서 계속 링크를 불러오는 이유

소개

OSPF(Open Shortest Path First) 링크가 수요 회로로 구성된 경우, OSPF Hello가 억제되고 주기적인 LSA 업데이트가 링크를 통해 플러딩되지 않습니다. 이러한 패킷은 처음 교환되거나 포함된 정보가 변경될 때만 링크를 표시합니다. 따라서 네트워크 토폴로지가 안정적일 때 기본 데이터 링크 레이어를 닫을 수 있습니다. 오름차순과 내림차순의 수요 회선은 조사해야 할 문제를 나타냅니다. 이 문서에서는 몇 가지 가능한 원인과 해결책을 제시합니다.

디맨드 회로에 대한 자세한 내용은 OSPF 디맨드 회로 기능을 참조하십시오.

사전 요구 사항

요구 사항

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

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

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

샘플 네트워크

위에서 언급한 문제는 다음과 같은 네트워크 다이어그램 및 컨피그레이션으로 설명됩니다.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf demand-circuit

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

참고: 링크의 한쪽 끝에서만 수요 회로를 구성해야 합니다. 그러나 양쪽 끝에서 이 명령을 구성해도 아무런 해가 되지 않습니다.

위 다이어그램에서 라우터 1과 2는 ISDN 링크 전체에서 OSPF Demand Circuit을 실행하고 있습니다. 라우터 1과 라우터 2 간의 링크가 계속 작동하므로 OSPF 디맨드 회로의 목적을 달성할 수 없습니다. show dialer 명령의 출력은 OSPF 멀티캐스트 Hello 패킷 때문에 링크가 시작되었음을 보여줍니다.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)

이 링크는 여러 가지 이유로 인해 표시될 수 있습니다. 아래에서는 몇 가지 일반적인 사례를 살펴보고 솔루션을 제공합니다.

이유 1: 네트워크 토폴로지 변경

OSPF 네트워크 토폴로지가 변경될 때마다 OSPF 라우터에 알림을 보내야 합니다. 이 경우 인접 디바이스에서 새 정보를 교환할 수 있도록 OSPF 디맨드 회로를 활성화해야 합니다. 새 데이터베이스가 교환되면 링크가 다시 다운될 수 있으며 인접성은 FULL 상태로 유지됩니다.

솔루션

네트워크 토폴로지가 변경되어 링크가 발생했는지 확인하려면 debug ip ospf monitor 명령을 사용합니다. 아래 그림과 같이 어떤 LSA가 변경되고 있는지 보여줍니다.

Router1# debug ip ospf monitor
OSPF: Schedule SPF in area 0.0.0.0
      Change in LS ID 192.168.246.41, LSA type R,
OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s

위의 출력은 라우터 ID가 192.168.246.41인 라우터 LSA가 변경되어 데이터베이스가 재동기화되었음을 보여줍니다. 네트워크가 안정적이면 이 디버그 출력에는 아무 것도 표시되지 않습니다.

수요 회로에서 링크 플랩이 미치는 영향을 줄이려면 수요 회로가 포함된 영역을 완전 스터브로 구성합니다. 이 기능을 사용할 수 없고 네트워크 내에 지속적인 링크 플랩이 있는 경우, 디맨드 서킷이 적합하지 않을 수 있습니다.

이유 2: 브로드캐스트로 정의된 네트워크 유형

링크에 수요 회로를 구성하는 경우 링크 유형은 point-to-point 또는 point-to-multipoint로 정의되어야 합니다. 네트워크 유형이 point-to-point 또는 point-to-multipoint가 아닌 경우 OSPF Hello가 억제되지 않으므로 다른 링크 유형이 있으면 링크가 불필요하게 표시될 수 있습니다. 다음은 라우터 1과 라우터 2의 이 문제를 설명하기 위한 샘플 컨피그레이션입니다.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf network broadcast

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 ip ospf network broadcast
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

네트워크 유형이 브로드캐스트로 정의되면 OSPF Hello는 Hello 간격마다 링크를 활성화합니다. show dialer 출력은 링크가 마지막으로 실행된 시점이 OSPF Hello 때문임을 보여줍니다.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
Interface bound to profile Di1
Current call connected 00:00:08
Connected to 57654 (R2)

솔루션

이 문제를 해결하려면 네트워크 유형을 point-to-point 또는 point-to-multipoint로 변경합니다. 여기서는 네트워크 유형 브로드캐스트를 제거하므로 기본적으로 point-to-point로 구성됩니다.

interface BRI1/1
 ip address 192.158.254.13 255.255.255.252

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

네트워크 유형을 point-to-point 또는 point-to-multipoint로 변경하면 링크에서 OSPF Hello가 억제되고, 디맨드 서킷 링크의 플래핑이 중지됩니다.

이유 3: 하나 이상의 라우터가 수요 회로를 인식하지 못함

OSPF 도메인에 있는 하나 이상의 라우터가 디맨드 회로를 이해하지 못할 경우 주기적인 LSA 새로 고침이 발생합니다. 이 문제를 해결하는 방법은 이 문서의 When a Periodic LSA Refresh Sent Over an OSPF Demand Circuit? 섹션을 참조하십시오.

이유 4: 호스트 경로가 OSPF 데이터베이스에 재배포됨

다음 네트워크 다이어그램을 예로 들어 보겠습니다.

라우터 1과 라우터 2 간의 링크는 131.108.1.0/24이며, 라우터 1과 라우터 2 간에 디맨드 회로가 구성됩니다. 라우터 1이 RIP(Routing Information Protocol) 경로를 OSPF로 재배포하고 있습니다.

router ospf 1
 redistribute rip subnets
 network 131.108.1.0 0.0.0.255 area 1
!
router rip
 network 131.108.0.0

링크 캡슐화 유형이 PPP이므로 두 라우터는 아래에 표시된 것처럼 링크의 다른 쪽에 대한 호스트 경로를 설치합니다.

Router1# show ip route 131.108.1.2
Routing entry for 131.108.1.2/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via BRI1/1
      Route metric is 0, traffic share count is 1

IGRP(Interior Gateway Routing Protocol) 및 RIP는 클래스 기반 라우팅 프로토콜이므로 컨피그레이션의 network 문은 클래스 기반 네트워크인 131.108.0.0에 사용됩니다. 이 때문에 131.108.1.2/32의 호스트 경로는 RIP에서 시작된 것으로 간주되며 아래와 같이 외부 경로로서 OSPF에 재배포됩니다.

Router1# show ip ospf database external 131.108.1.2

       OSPF Router with ID (131.108.3.1) (Process ID 1)


                Type-5 AS External Link States

  LS age: 298
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 131.108.1.2 (External Network Number )
  Advertising Router: 131.108.3.1
  LS Seq Number: 80000001
  Checksum: 0xDC2B
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

링크가 중단되면 /32가 사라지고 OSPF는 이를 토폴로지 변경으로 인식합니다. 수요 회로는 링크를 다시 불러와 /32 마스크의 MAXAGE 버전을 인접 디바이스로 전파합니다. 링크가 작동하면 /32 마스크가 다시 유효하게 되므로 LSA 기간이 재설정됩니다. 그런 다음 링크의 데드 타이머가 시작된 후 링크가 다시 다운됩니다. 이 과정이 반복되고 수요 회로 링크가 계속 플래핑됩니다. 이 문제를 해결하기 위한 방법은 아래와 같이 세 가지로 나누어 볼 수 있다.

해결 방법 1: no peer neighbor-route 명령 사용

Demand Circuit을 실행 중인 BRI 인터페이스에서 no peer neighbor-route를 구성합니다. 이렇게 하면 /32 마스크가 설치되지 않습니다. 아래 표시된 컨피그레이션은 라우터 1에서만 사용할 수 있지만 일관성을 위해 양쪽에서 이 명령을 구성하는 것이 좋습니다.

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

해결 방법 2: route-map 명령 사용

RIP에서 OSPF로 재배포할 경우 route-map 명령과 deny /32를 사용하여 OSPF 데이터베이스에 삽입되지 않도록 합니다. 이 컨피그레이션 명령은 재배포를 수행하는 라우터에서만 필요합니다(이 예에서는 라우터 1).

먼저 /32 마스크와 일치하는 액세스 목록을 만들어야 합니다. 그런 다음 이 액세스 목록을 경로 맵에 적용하고 아래와 같이 재배포 명령을 적용할 때 경로 맵을 사용합니다.

R1# configure terminal
R1(config)# access-list 1 deny host 131.108.1.2
R1(config)# access-list 1 permit any

R1# configure terminal
R1(config)# route-map rip-ospf
R1(config-route-map)# match ip address 1

R1(config)# router ospf 1
R1(config-router)# redistribute rip subnets route-map rip-ospf

솔루션 3: 다른 주요 네트워크 사용

RIP 또는 OSPF 도메인에 다른 주 네트워크를 사용합니다. 이 아이디어는 PPP 캡슐화 하에 링크가 나타날 때 링크의 다른 쪽에 대한 호스트 경로를 설치하도록 수요 회로 링크에 다른 주요 네트워크를 구축하는 것입니다. 호스트 경로가 RIP에서 사용되는 것과 다른 주 네트워크에 있는 경우, RIP는 주 네트워크에 대한 네트워크 명령문이 없기 때문에 이 PPP 설치 호스트 경로를 소유하지 않습니다. 아래 네트워크 다이어그램은 예를 보여줍니다.

이제 RIP 도메인은 141.108.0.0 네트워크 아래에 있고 OSPF 도메인(및 수요 회로 링크)은 131.108.0.0 네트워크 아래에 있습니다.

이유 5: 비동기 인터페이스를 통해 OSPF Demand Circuit이 구성되었습니다.

비동기식(비동기) 인터페이스를 통해 수요 회로를 구성한 다음 레이어 2가 다운되면 실제 물리적 인터페이스가 다운됩니다. 그러면 OSPF 데이터베이스의 변경이 트리거되며 비동기 인터페이스가 다시 백업하여 데이터베이스를 교환합니다. 레이어 2가 다시 다운되고, 이로 인해 데이터베이스의 변경이 다시 트리거되므로 이 프로세스는 계속 반복됩니다.

다음 시나리오는 위의 문제를 재현하는 데 사용됩니다.

위 시나리오에서는 다음 컨피그레이션이 사용됩니다.

interface Async 1
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 async default routing
 async mode dedicated
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Async 1
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 async default routing
 async mode dedicated
 ppp authentication chap callin
!
 dialer-list 2 protocol ip permit
!  
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

OSPF 기본 네트워크 유형은 비동기 인터페이스의 포인트-투-포인트이지만, 여전히 수요 회로는 링크를 계속 가동합니다.

Rouer1# show ip ospf interface Async1
 Async1 is up, line protocol is up (spoofing)
   Internet Address 192.158.254.13/32, Area 1
   Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869
   Transmit Delay is 1 sec, State POINT_TO_POINT,
   Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
    Hello due in 00:00:02
   Index 1/2, flood queue length 0
   Next 0x0(0)/0x0(0)
   Last flood scan length is 0, maximum is 1
   Last flood scan time is 0 msec, maximum is 0 msec
   Neighbor Count is 0, Adjacent neighbor count is 0
   Suppress hello for 0 neighbor(s)

솔루션

수요 회로가 링크를 계속 가동하는 이유는 유휴 시간 제한이 만료된 후 레이어 2가 다운되면 전체 인터페이스가 다운되기 때문입니다. 그러나 BRI 또는 PRI의 경우 채널 중 하나가 다운되면 인터페이스가 계속 가동 상태로 유지됩니다(스푸핑 모드). 이 문제를 해결하려면 다이얼러 인터페이스를 구성해야 합니다. 다이얼러 인터페이스는 다운되지 않기 때문입니다. 다이얼러 인터페이스는 스푸핑 모드에서 작동 상태로 유지됩니다.

interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 ppp authentication callin
!
dialer-list 2 protocol ip permit
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

다이얼러 인터페이스는 다운되지 않으므로 비동기 인터페이스가 다운될 때 발생하는 문제가 발생하지 않습니다.

이유 6: OSPF Demand Circuit Configured Over a Multilink PPP

다중 링크 PPP 기능은 여러 WAN 링크가 있는 경우 로드 밸런싱을 위해 사용할 수 있습니다. OSPF의 관점에서 기억해야 할 한 가지 중요한 점은 멀티링크 PPP의 대역폭입니다. 여러 링크가 결합되면 멀티링크 인터페이스의 대역폭이 변경됩니다.

다음 시나리오는 위의 문제를 재현하는 데 사용됩니다.

위 시나리오에서는 다음 컨피그레이션이 사용됩니다.

interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

다음 출력은 멀티링크 PPP에 세 개의 직렬 인터페이스가 함께 번들링되어 있음을 보여줍니다.

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 3 active, 0 inactive (max not set, min not set) 
     Serial1/0/0:0, since 00:05:35, no frags rcvd 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd

인터페이스 대역폭은 링크의 집계 대역폭을 나타내며, 이 대역폭은 OSPF 비용 계산에 사용됩니다.

Router1# show interface multilink 1 
Multilink1 is up, line protocol is up 
  Hardware is multilink group interface 
  Internet address is 192.168.254.1/24 
  MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec, 
     reliability 255/255, txload 3/255, rxload 3/255 
  Encapsulation PPP, loopback not set 
  Keepalive set (10 sec) 
  DTR is pulsed for 2 seconds on reset 
  LCP Open, multilink Open 
  Open: IPCP 
  Last input 00:00:00, output never, output hang never 
  Last clearing of "show interface" counters 00:06:39 
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 
  Queueing strategy: fifo 
  Output queue :0/40 (size/max) 
  5 minute input rate 241000 bits/sec, 28 packets/sec 
  5 minute output rate 241000 bits/sec, 28 packets/sec 
     6525 packets input, 9810620 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     6526 packets output, 9796112 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     0 carrier transitions

show ip ospf interface의 출력은 현재 OSPF 비용인 16을 보여줍니다.

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16
       Transmit Delay is 1 sec, State POINT_TO_POINT,
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
        Hello due in 00:00:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

이제 링크가 중단되고 로그에서 해당 내용을 확인할 수 있습니다.

Router1# show log | include down 
 
%LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down

대역폭을 다시 확인하면 이전에 본 것과 다를 것입니다. 이제 3968이 표시되며, 하나의 인터페이스가 중단되었기 때문에 번들에는 3개가 아닌 2개의 인터페이스만 있습니다. 인터페이스 아래는 여전히 작동 중입니다.

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 2 active, 1 inactive (max not set, min not set) 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd 
     Serial1/0/0:0 (inactive)

또한 PPP 멀티링크가 계속 표시되지만 링크 하나가 다운되어 OSPF 비용이 25로 변경됩니다

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25
       Transmit Delay is 1 sec, State POINT_TO_POINT,
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
        Hello due in 00:00:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

이렇게 하면 SPF 계산이 트리거되고 OSPF가 수요 회로를 불러옵니다. 링크가 계속 플래핑되면 수요 회로가 계속 플래핑되는 것을 볼 수 있습니다. 링크가 추가되거나 multilink PPP 번들에서 삭제될 때마다 비용이 변경되기 때문입니다.

솔루션

PPP 멀티링크는 OSPF에서 지원되지만, 번들 내의 모든 링크가 가동 상태를 유지하는 한, 수요 회로는 안정적입니다. 링크가 중단되는 즉시, 연결된 IP 주소가 없어도 OSPF 비용 계산에 영향을 미칩니다. 따라서 OSPF는 SPF를 실행하여 최상의 경로를 다시 계산합니다. 이 문제를 해결하려면 다음 명령을 사용하여 OSPF 비용을 수동으로 구성하는 방법밖에 없습니다.

interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

이 명령은 멀티링크 PPP 번들에 추가되거나 삭제되는 링크가 있을 때마다 OSPF 비용에 영향을 주지 않도록 합니다. 이렇게 하면 PPP 멀티링크를 통해 OSPF 디맨드 회로가 안정됩니다.

관련 정보

• OSPF 지원 페이지
• Technical Support - Cisco Systems