목차

소개

사전 요구 사항

요구 사항

사용되는 구성 요소

표기 규칙

샘플 네트워크

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

솔루션

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

솔루션

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

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

솔루션 1:no peer neighbor-route 명령 사용

솔루션 2:route-map 명령 사용

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

이유 5:비동기 인터페이스를 통해 OSPF Demand Circuit 구성

솔루션

이유 6:멀티링크 PPP를 통해 OSPF Demand Circuit 구성

솔루션

관련 정보

소개

OSPF(Open Shortest Path First) 링크가 디맨드 회로로 구성되면 OSPF Hello가 억제되고 정기적인 LSA 새로 고침이 링크를 통해 플러딩되지 않습니다.이러한 패킷은 처음 교환되거나 포함된 정보가 변경된 경우에만 링크를 표시합니다.따라서 네트워크 토폴로지가 안정적일 때 기본 데이터 링크 레이어를 닫을 수 있습니다.작동 및 중단되는 수요 회로는 조사해야 하는 문제를 나타냅니다.이 문서에서는 몇 가지 가능한 원인을 설명하고 솔루션을 제공합니다.

수요 회로에 대한 자세한 내용은 OSPF Demand Circuit Feature를 참조하십시오.

사전 요구 사항

요구 사항

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

사용되는 구성 요소

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

표기 규칙

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

샘플 네트워크

위에 언급된 문제는 다음 네트워크 다이어그램 및 컨피그레이션에 설명되어 있습니다.

라우터 1

라우터 2

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 디맨드 회로를 실행하고 있습니다.라우터 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 디맨드 회로를 생성해야 합니다.새 데이터베이스가 교환되면 링크가 다시 다운되고 인접성이 전체 상태로 유지됩니다.

솔루션

네트워크 토폴로지의 변경으로 인해 링크가 시작되었는지 확인하려면 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

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

수요 회로의 링크 플랩의 영향을 줄이려면 수요 회로가 포함된 영역을 완전히 stub로 구성합니다.이를 수행할 수 없고 네트워크 내에 지속적인 링크 플랩이 있는 경우, 수요 회로는 적합하지 않을 수 있습니다.

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

링크에서 수요 회로를 구성할 때 링크 유형을 포인트 투 포인트 또는 포인트-투-멀티포인트로 정의해야 합니다.다른 링크 유형에서는 네트워크 유형이 point-to-point 또는 point-to-multipoint 이외의 다른 유형일 경우 OSPF Hello가 억제되지 않으므로 링크가 불필요하게 나타날 수 있습니다.다음은 라우터 1 및 2에서 이 문제를 설명하기 위한 샘플 컨피그레이션입니다.

라우터 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로 변경하십시오.여기서는 네트워크 유형 브로드캐스트를 제거하므로 기본적으로 포인트투포인트로 구성됩니다.

라우터 1

라우터 2

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 새로 고침이 발생합니다.OSPF Demand Circuit를 통해 전송되는 주기적 LSA 새로 고침은 언제입니까? 를 참조하십시오.이 문제를 해결하는 방법을 알아보려면 이 문서의 섹션을 참조하십시오.

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

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

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

라우터 1

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 명령 사용

디맨드 회로를 실행 중인 BRI 인터페이스에서 피어 네이버 라우트를 구성하지 않습니다.이렇게 하면 /32 마스크가 설치되지 않습니다.라우터 1에서만 아래에 표시된 컨피그레이션을 사용할 수 있지만, 일관성을 위해 양쪽에서 이 명령을 구성하는 것이 좋습니다.

R1# configure terminal

R1(config)# interface BRI1/1

R1(config-if)# no peer neighbor-route

솔루션 2:route-map 명령 사용

RIP에서 OSPF로 재배포할 때 route-map 명령을 사용하고 /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가 다시 다운되면 데이터베이스에서 변경 사항이 다시 트리거되므로 이 프로세스는 계속 반복됩니다.

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

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

라우터 1

라우터 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 기본 네트워크 유형은 비동기 인터페이스의 포인트 투 포인트(point-to-point)이지만, 여전히 디맨드 회로는 링크를 계속 표시합니다.

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의 경우 채널 중 하나가 중단되어도 인터페이스가 계속 작동(스푸핑 모드)됩니다. 이 문제를 해결하려면 다이얼러 인터페이스가 중단되지 않으므로 구성해야 합니다.다이얼러 인터페이스는 스푸핑 모드에서 작동 상태로 유지됩니다.

라우터 1

라우터 2

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:멀티링크 PPP를 통해 OSPF Demand Circuit 구성

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

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

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

라우터 1

라우터 2

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 인터페이스의 출력에 현재 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에서 수요 회로가 발생합니다.링크가 계속 플래핑되면 링크가 추가되거나 멀티링크 PPP 번들에서 삭제될 때마다 비용이 변경되므로 디맨드 회로 플래핑(demand circuit)이 계속 플래핑될 수 있습니다.

솔루션

PPP 멀티링크는 OSPF에서 지원되지만, 번들 내의 모든 링크가 작동 중인 한 디맨드 회로는 안정적입니다.링크가 중단되는 즉시, 연결된 IP 주소가 없어도 OSPF 비용 계산에 영향을 주며, 이로 인해 OSPF는 SPF를 실행하여 최상의 경로를 재계산합니다.이 문제를 해결하기 위해 유일한 솔루션은 다음 명령을 사용하여 OSPF 비용을 수동으로 구성하는 것입니다.

라우터 1

라우터 2

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