BGP 스캐너 또는 라우터 프로세스로 인한 높은 CPU 문제 해결

소개

이 문서에서는 BGP 스캐너 또는 라우터를 사용할 때 CPU 판독값이 높은 원인을 해결하는 방법에 대해 설명합니다.

사전 요구 사항

요구 사항

이 문서에서는 show process cpu 명령을 해석하는 방법에 대한 지식이 필요합니다.

사용되는 구성 요소

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

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

표기 규칙

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

배경 정보

이 문서에서는 show process cpu 명령의 출력에 표시된 대로 BGP(Border Gateway Protocol) 라우터 프로세스 또는 BGP 스캐너 프로세스로 인해 Cisco IOS 라우터가 높은 CPU 사용률을 경험할 수 있는 상황에 대해 설명합니다. 높은 CPU 조건의 기간은 여러 조건, 특히 인터넷 라우팅 테이블의 크기, 특정 라우터가 라우팅 및 BGP 테이블에 보유하는 경로 수에 따라 달라집니다. show process cpu 명령은 지난 5초, 1분 및 5분 동안의 평균 CPU 사용률을 보여줍니다. CPU 사용률 수치는 제공된 로드와 관련하여 사용률을 실제로 선형 형태로 나타내지 않습니다.

다음은 몇 가지 주요 이유입니다.

• 실제 네트워크에서는 CPU가 네트워크 관리와 같은 다양한 시스템 유지 관리 기능을 처리해야 합니다.

• CPU는 주기적 및 이벤트 트리거 라우팅 업데이트를 처리해야 합니다.

• 다른 내부 시스템 오버헤드 작업(예: 리소스 가용성에 대한 폴링)이 있으며, 이는 트래픽 로드에 비례하지 않습니다.

show processes cpu 명령을 사용하여 CPU 활동의 일부 표시를 얻을 수도 있습니다.

참고: show 명령에 대한 자세한 내용은 Cisco IOS Configuration Fundamentals 명령 참조

BGP 프로세스 이해

일반적으로 Cisco IOS 프로세스는 시스템 유지 관리, 스위칭 패킷, 라우팅 프로토콜 구현과 같은 작업을 수행하는 개별 스레드 및 관련 데이터로 구성됩니다. 라우터에서 실행되는 여러 Cisco IOS 프로세스를 통해 BGP를 실행할 수 있습니다. show process cpu 사용 | include BGP 명령을 사용하여 BGP 프로세스로 인한 CPU 사용률을 확인합니다.

이 표에서는 BGP 프로세스의 기능을 나열하고 각 프로세스가 서로 다른 시간에 실행되며, 이러한 시간은 처리되는 작업에 따라 달라집니다. BGP 스캐너 및 BGP 라우터 프로세스가 많은 양의 계산을 담당하므로 이러한 프로세스 중 하나로 인해 CPU가 높게 나타날 수 있습니다. 다음 섹션에서는 이러한 프로세스에 대해 더 자세히 설명합니다.

프로세스 이름	설명	간격
BGP 열기	BGP 피어 설정을 수행합니다.	초기화 시 BGP 피어와의 TCP 연결이 설정된 경우
BGP I/O	대기열에 있고 처리된 BGP 패킷(예: UPDATES 및 KEEPALIVE)을 처리합니다.	BGP 제어 패킷이 수신되면
BGP 스캐너	BGP 테이블을 표시하고 다음 홉의 연결성을 확인합니다. 또한 BGP 스캐너는 조건 접두사를 알리고 경로 감소를 수행하는지 확인하기 위해 조건부 광고를 확인합니다. MPLS VPN 환경에서 BGP 스캐너는 특정 VPN 라우팅 및 포워딩 인스턴스(VRF)로 경로를 가져오고 내보냅니다.	1분에 한 번
BGP 라우터	최상의 BGP 경로를 계산하고 경로 이탈을 처리합니다. 또한 경로를 전송 및 수신하고, 피어를 설정하며, RIB(routing information base)와 상호 작용합니다.	초당 1회 및 BGP 피어가 추가, 제거 또는 소프트 구성된 경우.

BGP 스캐너로 인한 높은 CPU

BGP 스캐너 프로세스로 인해 CPU가 높으면 대규모 인터넷 라우팅 테이블을 전달하는 라우터에서 짧은 기간 동안 CPU를 사용할 수 있습니다. 1분에 한 번, BGP 스캐너는 BGP RIB 테이블을 살펴보고 중요한 유지 관리 작업을 수행합니다. 이러한 작업에는 라우터의 BGP 테이블에서 참조되는 next-hop에 대한 검토와 next-hop 디바이스에 연결할 수 있는지 확인하는 작업이 포함됩니다. 따라서 큰 BGP 테이블은 산책하고 검증하는 데 상당한 시간이 소요됩니다.

BGP Scanner 프로세스는 전체 BGP 테이블을 통해 실행되므로 CPU 조건이 높은 기간은 인접 디바이스 수와 인접 디바이스당 학습된 경로 수에 따라 달라집니다. 이 정보를 캡처하려면 show ip bgp summary 및 show ip route summary 명령을 사용합니다. BGP 스캐너 프로세스는 BGP 테이블을 확인하여 데이터 구조를 업데이트하고 경로 재배포를 위해 라우팅 테이블을 확인합니다. (이 경우 라우팅 테이블은 라우팅 정보 베이스(RIB)라고도 하며, 이 경우 라우터는 provide ip route 명령을 실행할 때 출력됩니다.) 두 테이블 모두 라우터의 메모리에 개별적으로 저장되며, 크기가 크고 CPU 사이클을 사용할 수 있습니다.

debug ip bgp updates 명령의 다음 샘플 출력은 BGP 스캐너의 실행을 캡처합니다.

router# 
2d17h: BGP: scanning routing tables 
2d17h: BGP: 10.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 10.0.0.0 update run completed, ran for 0ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
2d17h: BGP: 10.1.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 10.1.0.0 update run completed, ran for 4ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
router#

BGP 스캐너가 실행되는 동안 우선 순위가 낮은 프로세스는 CPU에 액세스하기 위해 더 오랜 시간을 기다려야 합니다. 우선 순위가 낮은 프로세스는 ping과 같은 ICMP(Internet Control Message Protocol) 패킷을 제어합니다. 라우터로 전송되거나 라우터에서 시작된 패킷은 ICMP 프로세스가 BGP 스캐너 뒤에서 기다려야 하므로 예상 레이턴시보다 더 높은 지연을 경험할 수 있습니다. 이 주기는 BGP 스캐너가 일정 시간 동안 실행되어 자신을 일시 중지한 다음 ICMP가 실행되는 것입니다. 반면 라우터를 통해 전송되는 ping은 CEF(Cisco Express Forwarding)를 통해 전환해야 하며 추가 레이턴시가 발생하지 않아야 합니다. 레이턴시의 주기적인 급격한 증가를 해결할 경우 라우터를 통해 전달된 패킷의 전달 시간을 라우터의 CPU에서 직접 처리한 패킷과 비교합니다.

참고: 레코드 경로와 같은 IP 옵션을 지정하는 Ping 명령도 CPU에서 직접 처리해야 하며 이로 인해 전달 지연이 더 길어질 수 있습니다.

show 프로세스 사용 | include bgp scanner 명령을 사용하여 CPU 우선순위를 확인합니다. 다음 샘플 출력의 Lsi 값은 L을 사용하여 낮은 우선순위 프로세스를 참조합니다.

6513#show processes | include BGP Scanner
 172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

BGP 라우터 프로세스로 인한 높은 CPU

BGP 라우터 프로세스는 작업을 확인하기 위해 초당 한 번 실행됩니다. BGP 컨버전스는 첫 번째 BGP 피어가 설정된 시간과 BGP가 통합된 시점 사이의 기간을 정의합니다. 가능한 최단 컨버전스 시간을 보장하기 위해 BGP 라우터는 모든 여유 CPU 사이클을 사용합니다. 그러나 시작 후 CPU를 간헐적으로 중단하거나 일시 중단합니다.

컨버전스 시간은 BGP 라우터가 총 시간이 아니라 CPU에 얼마나 오래 소요되는지를 직접 측정하는 것입니다. 이 절차에서는 BGP 컨버전스 중에 높은 CPU 조건을 표시하고 BGP 접두사를 2개의 외부 BGP(eBGP) 피어와 교환합니다.

1. 테스트를 시작하기 전에 정상 CPU 사용률에 대한 기준을 캡처합니다.

   router#show process cpu
     CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. 테스트가 시작되면 CPU 사용률이 100%에 달합니다. show process cpucommand는 높은 CPU 조건이 다음 출력에서 139(BGP 라우터의 Cisco IOS 프로세스 ID)로 표시된 BGP 라우터에 의해 발생함을 보여줍니다.

   router#show process cpu
     CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%
   
   !--- Output omitted.
   
   139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. 현재 show ip bgp 요약의 여러 출력을 모니터링하고 캡처할 수 있으며 show process cpu 명령을 사용할 수 있습니다. show ip bgp summary 명령은 BGP 인접 디바이스의 상태를 캡처합니다.

   router#show ip bgp summary
     Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
     10.0.0.0    4  64512  309453  157389    19981    0  253 22:06:44 111633
     10.1.0.0  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. 라우터가 BGP 피어와의 접두사 교환을 완료하면 CPU 사용률 속도는 정상 수준으로 돌아갑니다. 계산된 1분 5분 평균도 안정화될 수 있으며 5초 속도보다 긴 기간 동안 정상 수준보다 더 높은 수준을 표시할 수 있습니다.

   router#show process cpu
     CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. 이전 show 명령의 캡처된 출력을 사용하여 BGP 통합 시간을 계산합니다. 특히 show ip bgp summary 명령의 Up/Down< /strong> 열을 사용하고 높은 CPU 조건의 시작 및 중지 시간을 비교합니다. 일반적으로 BGP 컨버전스는 대형 인터넷 라우팅 테이블을 사용할 때 몇 분 정도 걸릴 수 있습니다. 교체됨

참고: 디바이스의 높은 CPU는 BGP 테이블이 불안정하기 때문일 수도 있습니다. 라우터가 라우팅 테이블의 복사본 2개를 수신하면, 하나는 ISP와의 EBGP 피어링에서, 다른 하나는 네트워크의 IBGP 피어링에서 수신됩니다. 근본 원인은 디바이스의 메모리 양입니다. Cisco에서는 인터넷 라우팅 테이블 사본 하나에 최소 1Gig의 RAM을 권장합니다. 이러한 불안정성을 피하려면 디바이스에서 RAM을 늘리거나 접두사를 필터링하여 BGP 테이블과 해당 테이블에 사용된 메모리가 경감되도록 합니다.

성능 향상

인터넷 라우팅 테이블의 경로 수가 증가함에 따라 BGP가 통합하는 데 걸리는 시간도 늘어납니다. 일반적으로 컨버전스는 모든 경로 테이블을 일관성 상태로 가져오는 프로세스로 정의됩니다. BGP는 다음 조건이 충족되면 컨버지드(converged)로 간주됩니다.

• 모든 경로가 수락되었습니다.

• 모든 경로가 라우팅 테이블에 설치되었습니다.

• 모든 피어의 테이블 버전은 BGP 테이블의 테이블 버전과 같습니다.

• 모든 피어의 InQ 및 OutQ는 0입니다.

이 섹션에서는 BGP 컨버전스 시간을 단축하기 위해 BGP 컨버전스 시간을 단축하기 위해 일부 Cisco IOS 성능을 개선하여 BGP 프로세스로 인해 CPU 상태가 크게 감소한다고 설명합니다.

TCP 피어 연결 대기열

이제 BGP는 OutQs가 완전히 소모될 때까지 BGP OutQ에서 각 피어의 TCP 소켓까지 데이터를 공격적으로 대기시킵니다. 이제 BGP가 더 빠른 속도로 전송되므로 BGP는 더 빠르게 통합됩니다.

BGP 피어 그룹

BGP 컨피그레이션을 간소화하는 데 도움이 되지만 BGP 피어 그룹도 확장성을 향상시킬 수 있습니다. 모든 피어 그룹 구성원은 공통 아웃바운드 정책을 공유해야 합니다. 따라서 동일한 업데이트 패킷을 각 그룹 멤버에 전송할 수 있으며, 이렇게 하면 BGP가 피어에 경로를 광고하는 데 필요한 CPU 주기 수가 줄어듭니다. 즉, 피어 그룹을 사용하는 경우 BGP는 피어 그룹 리더에서만 BGP 테이블을 표시하고 아웃바운드 정책을 통해 접두사를 필터링하며 피어 그룹 리더에게 보내는 업데이트를 생성합니다. 그러면 리더는 업데이트를 동기화된 그룹 멤버에 복제합니다. 피어 그룹이 없으면 BGP는 모든 피어에 대해 테이블을 살펴보고, 아웃바운드 정책을 통해 접두사를 필터링하고, 하나의 피어에만 전송되는 업데이트를 생성해야 합니다.

경로 MTU 및 ip tcp path-mtu-discovery 명령

모든 TCP 세션은 단일 패킷으로 전송할 수 있는 바이트 수의 제한에 의해 제한됩니다. MSS(Maximum Segment Size)라고 하는 이 제한은 기본적으로 536바이트입니다. 다시 말해, TCP는 패킷을 IP 레이어로 전달하기 전에 전송 큐의 패킷을 536바이트 청크로 분할합니다. show ip bgp neighbors 사용 | include max data 명령을 사용하여 BGP 피어의 MSS를 표시합니다.

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

536바이트 MSS의 장점은 대부분의 링크에서 1500바이트 이상의 MTU를 사용하므로 패킷이 대상에 대한 경로를 따라 IP 디바이스에서 프래그먼트화될 가능성이 없다는 것입니다. 단점은 패킷이 작을수록 오버헤드를 전송하는 데 사용되는 대역폭의 양이 증가한다는 것입니다. BGP는 모든 피어에 TCP 연결을 구축하므로 536바이트 MSS는 BGP 컨버전스 시간에 영향을 줍니다.

해결책은 ip tcp path-mtu-discovery 명령을 사용하여 PMTU(Path MTU) 기능을 활성화하는 것입니다. 이 기능을 사용하여 프래그먼트화해야 하는 패킷을 생성하지 않고 MSS 값의 크기를 동적으로 결정할 수 있습니다. PMTU는 TCP가 TCP 세션의 모든 링크 중에서 가장 작은 MTU 크기를 결정할 수 있도록 합니다. 그런 다음 TCP는 이 MTU 값(IP 및 TCP 헤더의 경우 공간 제외)을 세션의 MSS로 사용합니다. TCP 세션이 이더넷 세그먼트만 통과하는 경우 MSS는 1460바이트입니다. POS(Packet over SONET) 세그먼트만 통과하는 경우 MSS는 4430바이트입니다. MSS가 536바이트에서 1460 또는 4430바이트로 증가하면 TCP/IP 오버헤드가 줄어들어 BGP가 더 빠르게 통합됩니다.

PMTU를 활성화한 후 다시 show ip bgp neighbors를 사용합니다. | include max data 명령을 사용하여 피어당 MSS 값을 확인합니다.

Router#show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

인터페이스 입력 대기열 증가

BGP가 수천 개의 경로를 여러 피어로 광고하는 경우 TCP는 짧은 기간 내에 수천 개의 패킷을 전송해야 합니다. BGP 피어는 이러한 패킷을 수신하고 TCP 확인을 광고하는 BGP 스피커에 보냅니다. 그러면 BGP 스피커가 짧은 시간 내에 TCP ACK의 플러드를 수신하게 됩니다. ACK가 경로 프로세서에 비해 너무 높은 속도로 도달하면 패킷은 인바운드 인터페이스 대기열에서 백업됩니다. 기본적으로 라우터 인터페이스는 입력 대기열 크기(75개 패킷)를 사용합니다. 또한 BGP UPDATES와 같은 특수 제어 패킷은 SPD(Selective Packet Discard)가 있는 특수 대기열을 사용합니다. 이 특수 대기열은 100개의 패킷을 포함합니다. BGP 컨버전스가 발생하면 TCP ACK는 입력 버퍼링의 175개 지점을 빠르게 채울 수 있으며 도착한 새 패킷은 삭제해야 합니다. 15개 이상의 BGP 피어가 있고 전체 인터넷 라우팅 테이블을 교환하는 라우터에서는 분당 인터페이스당 10,000개 이상의 삭제를 볼 수 있습니다. 다음은 재부팅 후 15분 후에 라우터에서 출력되는 예입니다.

Router#show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

hold-queue in 명령을 사용하여 인터페이스 입력 큐 깊이를 늘리면 삭제된 TCP ACK의 수를 줄이는 데 도움이 되므로 BGP가 통합해야 하는 작업 양이 줄어듭니다. 일반적으로 값 1000은 입력 대기열 삭제로 인해 발생하는 문제를 해결합니다.

참고: 입력 대기열 증가에서 약간의 지연을 추가할 수 있으므로 이 설정을 신중하게 사용합니다.

Cisco IOS의 추가 개선 사항

Cisco IOS에는 업데이트 패킹 및 복제를 개선하기 위해 BGP 피어 그룹 코드에 대한 몇 가지 최적화가 포함되어 있습니다. 이러한 개선 사항을 검토하기 전에 업데이트 포장 및 복제를 자세히 검토하십시오.

BGP 업데이트는 특성의 조합을 공유하는 특성(예: MED = 50 및 LOCAL_PREF = 120)과 NLRI(Network Layer Reachability Information) 접두사 목록으로 구성됩니다. BGP가 단일 업데이트에서 나열할 수 있는 NLRI 접두사가 많을수록 오버헤드(예: IP, TCP, BGP 헤더)가 감소하므로 BGP가 더 빠르게 통합될 수 있습니다. 업데이트 패킹은 NLRI를 BGP 업데이트로 포장하는 것을 의미합니다. 예를 들어 BGP 테이블에 15,000개의 고유한 특성 조합이 있는 100,000개의 경로가 있는 경우 NLRI의 효율성이 100%인 경우 BGP는 15,000개의 업데이트만 전송해야 합니다.

참고: 포장 효율성이 0%이면 BGP가 이 환경에서 100,000개의 업데이트를 전송해야 합니다.

show ip bgp peer-group 명령을 사용하여 BGP 업데이트의 효율성을 확인합니다.

피어 그룹 멤버가 동기화된 경우 BGP 라우터는 피어 그룹 리더에 맞게 형식이 지정된 업데이트 메시지를 가져와 멤버에 대해 복제합니다. 업데이트를 다시 포맷하는 것보다 피어 그룹 구성원의 업데이트를 복제하는 것이 훨씬 효율적입니다. 예를 들어 피어 그룹에 20명의 멤버가 있고 모든 멤버가 100개의 BGP 메시지를 수신해야 한다고 가정합니다. 100% 복제는 BGP 라우터가 피어 그룹 리더에 대해 100개의 메시지를 포맷하고 해당 메시지를 다른 19개의 피어 그룹 멤버에 복제한다는 것을 의미합니다. 복제 개선을 확인하려면 show ip bgp peer-group 명령에 표시된 대로 복제된 메시지 수를 형식이 지정된 메시지 수로 비교합니다. 이러한 개선으로 컨버전스 시간이 크게 달라지고 BGP에서 더 많은 피어를 지원할 수 있습니다.

예를 들어, show ip bgp peer-group 명령을 사용하여 업데이트 포장 및 업데이트 복제의 효율성을 확인합니다. 다음 출력은 6개의 피어 그룹, 6번째 피어 그룹(eBGP 피어) 및 6번째 피어 그룹(iBGP) 피어의 100개의 피어를 각각 20개의 피어로 구성된 컨버전스 테스트입니다. 또한 사용된 BGP 테이블에는 36,250개의 특성 조합이 있었습니다.

show ip bgp peer-group의 다음 샘플 출력 |Cisco IOS 12.0(18)S를 실행하는 라우터에 복제된 명령을 포함시키면 다음 정보가 표시됩니다.

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

각 피어 그룹의 복제 속도를 계산하려면 복제된 업데이트 수를 포맷된 업데이트 수로 나눕니다.

1668500/836500 = 1.99 145000/105000 = 1.38 1844500/660500 = 2.79 14990000/6560000 = 2 1 2003750/501250 = 3.99 1214785/2476715 = 4.89

• BGP가 완벽하게 복제되면 피어 그룹에 20개의 피어가 있으므로 eBGP 피어 그룹은 각각 복제 속도가 19입니다. 업데이트는 피어 그룹 리더에 맞게 포맷된 다음 다른 19개 피어에 복제됩니다. 이는 최적의 복제 속도를 19로 제공합니다. iBGP 피어 그룹에 이상적인 복제 속도는 100개의 피어가 있으므로 99입니다.
• BGP 패키지 업데이트가 완벽하게 이루어지면 36,250개의 업데이트만 포맷됩니다. BGP 테이블의 특성 조합 수이므로 각 피어 그룹에 대해 36,250개의 업데이트만 생성해야 합니다. iBGP 피어 그룹만 약 2,500,000개의 업데이트를 포맷하는 반면 eBGP 피어 그룹은 각각 500,000개에서 1,000,000개의 업데이트를 생성합니다.

Cisco IOS 12.0(19)S를 실행하는 라우터에서 ip bgp peer-group 방법 | include replicatedcommand는 다음 정보를 제공합니다.

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

참고: 업데이트 포장이 가장 적합합니다. 정확히 36,250개의 업데이트가 각 피어 그룹에 대해 포맷됩니다. 688750/36250 = 19 688750/36250 = 19 68750/36250 = 19 688750/36250 = 19668 750/36250 = 19 3588750/36250 = 99

참고: 업데이트 복제도 완벽합니다.

문제 해결 절차

BGP 스캐너 또는 BGP 라우터로 인한 높은 CPU의 문제를 해결하려면 다음 절차를 사용합니다.

• BGP 토폴로지에 대한 정보를 수집합니다. BGP 피어 수 및 각 피어가 광고하는 경로 수를 결정합니다. 높은 CPU 조건의 지속 시간이 환경에 따라 적절합니까?

• 높은 CPU가 발생하는 시기를 확인합니다. BGP 테이블의 정기적인 워크로드가 일치합니까?

• 높은 CPU가 인터페이스 플랩을 따랐습니까? 댐프닝이 활성화된 경우 show ip bgp dampening flap-statistics 명령을 사용할 수 있습니다.

• 라우터를 통해 ping한 다음 라우터에서 ping합니다. ICMP 에코는 낮은 우선 순위 프로세스로 처리됩니다. Ping 및 Traceroute 명령 이해에서 자세한 내용을 설명합니다. 일반 포워딩에 영향을 미치지 않는지 확인합니다.

• 인바운드 및 아웃바운드 인터페이스에서 고속 스위칭 및/또는 CEF가 활성화되었는지 확인할 때 패킷이 빠른 포워딩 경로를 따를 수 있는지 확인해야 합니다. 인터페이스에 no ip route-cache cef 명령 또는 전역 컨피그레이션에 no ip cef 명령이 표시되지 않는지 확인합니다. 전역 컨피그레이션 모드에서 CEF를 활성화하려면 ip cef 명령을 사용합니다.

• 대부분의 경우 이러한 상황으로 이어지는 오버로드된 디바이스 때문에 플랫폼 확장을 확인합니다. 또한 라우터에 사용 가능한 올바른 TCAM(ternary content addressable memory) 공간이 있는지 확인했습니다.

• 라우터에서 충분한 메모리를 확인합니다. 권장 사항에 따라 전체 인터넷 라우팅 테이블을 전송하는 BGP 피어당 Cisco IOS 공간에 최소 1GB의 DRAM을 할당해야 합니다. 여기에 언급된 DRAM 공간은 BGP에 필요한 메모리입니다. 라우터에서 실행되는 다른 기능에는 추가 공간이 필요할 수 있습니다.

관련 정보

• IP 라우팅 지원 페이지
• Technical Support - Cisco Systems