OSPF/IS-IS 및 BGP 라우팅을 위한 Cisco IOS XR 구축 모범 사례 

 

목차

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE] 3

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE][UPDATE THE TABLE] 4

[UPDATE THE TABLE] 5

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 6

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE][UPDATE THE TABLE] 7

[UPDATE THE TABLE] 8

[UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 9

[UPDATE THE TABLE][UPDATE THE TABLE] 10

[UPDATE THE TABLE][UPDATE THE TABLE] 11

[UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 12

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 14

[UPDATE THE TABLE][UPDATE THE TABLE] 17

[UPDATE THE TABLE][UPDATE THE TABLE] 18

[UPDATE THE TABLE] 19

면책조항  

이 문서에서는 OSPF/IS-IS 및 BGP 라우팅에 대해 수립된 몇 가지 모범 사례 권장 사항을 개괄적으로 요약합니다. 이러한 권장 사항은 Cisco 검증 설계를 의미하지 않으며, 특정 운영 환경에서 구축하려면 상당한 주의와 주의가 필요합니다. 이러한 권장 사항을 구현하는 방법을 자세히 설명하는 관련 제품의 컨피그레이션 가이드 및 기술 문서와 함께 읽어야 합니다.  이 문서에서 특정 제품에 대한 컨피그레이션 가이드 및 기술 문서를 참조하는 것은 예시일 뿐입니다. 특정 제품에 대한 자세한 내용은 컨피그레이션 가이드 및 기술 문서를 참조하십시오.

소개  

이 문서에서는 IOS XR 라우팅 플랫폼을 기반으로 하는 간소화되고 효율적이며 확장 가능한 네트워크를 구축하기 위해 수립된 몇 가지 모범 사례와 권장 사항에 대해 간략하게 설명합니다. 이 문서에서는 OSPF/IS-IS 및 BGP 구축을 사용자 지정하는 데 도움이 되는 IOS XR에서 제공되는 특정 구현 기술 및 기능 지원 옵션에 대해 중점적으로 설명합니다. 

OSPF 구현  

RFC 2328에 정의된 OSPF 프로토콜은 단일 자동 시스템 내에서 라우팅 정보를 배포하는 데 사용되는 IGP입니다. OSPF는 다른 프로토콜에 비해 몇 가지 이점을 제공하지만, 확장 가능하고 내결함성 있는 네트워크를 생성하려면 적절한 설계가 필요합니다.  

OSPF에 대한 자세한 내용은 다음을 참조하십시오. 

■에 대한 TechNote:
https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/7039-1.html#anc13 

■ Configuration Guide for OSPF: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-6/routing/configuration/guide/b-routing-cg-asr9000-76x/implementing-ospf.html 

■ 명령 참조: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/711x/routing/configuration/guide/b-routing-cg-asr9000-711x/implementing-ospf.html?dtid=osscdc000283

주요 개념 

■ 계층 구조: 계층 구조 네트워크 모델은 안정적인 네트워크 인프라를 설계하는 데 유용한 상위 레벨 툴이며 복잡한 네트워크 설계 문제를 더 작고 관리하기 쉬운 영역으로 분해하는 데 도움이 됩니다.  

■ 모듈성: 네트워크의 다양한 기능을 모듈로 분할함으로써 네트워크를 훨씬 쉽게 설계할 수 있습니다. Cisco는 엔터프라이즈 캠퍼스, 서비스 블록, 데이터 센터 및 인터넷 에지를 포함한 여러 모듈을 식별했습니다.  

■ 복원력: 네트워크는 정상 및 비정상적 조건에서 모두 사용할 수 있습니다. 정상적인 조건에는 예상 트래픽 흐름, 패턴 및 유지 보수 기간과 같은 예약된 이벤트가 포함됩니다. 비정상적인 조건에는 하드웨어 또는 소프트웨어 장애, 과도한 트래픽 로드, 비정상적인 트래픽 패턴, DoS(denial-of-service) 이벤트, 기타 계획된 이벤트 또는 계획되지 않은 이벤트가 포함됩니다.   

■ 유연성: 대대적인 업그레이드(예: 주요 하드웨어 장치 교체)를 거치지 않고 네트워크의 일부를 수정하거나 새로운 서비스를 추가하거나 용량을 늘릴 수 있는 기능. 

일반적인 모범 사례로서, 네트워크 구축은 특정 경계 내의 경로 및 포워딩을 위해 도메인 내의 라우터와 관련이 있고 필요한 경로를 포함하도록 네트워크의 "span"을 고려해야 합니다. OSPF 영역을 효과적으로 사용하면 네트워크를 통해 전송되는 LSA(링크 상태 알림) 및 기타 오버헤드 트래픽의 수를 줄일 수 있습니다. 계층 구조를 생성할 때의 장점 중 하나는 이 접근 방식을 통해 각 라우터가 유지 관리해야 하는 토폴로지 데이터베이스의 크기를 관리 가능하고 라우터의 메모리 프로필을 준수할 수 있다는 것입니다.   

OSPF 도메인 및 BGP 재배포 

OSPF는 수천 개의 경로만 전달하도록 설계되었습니다. 상위 레벨에서 OSPF "영역"은 어떤 라우터든 해당 영역의 다른 모든 라우터의 라우팅 기능에 대해 알고 있는 네트워크의 섹션입니다. 이렇게 하면 어떤 장치든 문제가 있을 경우 빠른 컨버전스가 가능하지만 확장성은 저하됩니다. 따라서 OSPF는 서비스 공급자 코어에서 모든 코어 장치 간에 기본 레벨 연결을 제공하기 위해 사용되며 모든 코어 장치는 동일한 OSPF 영역 내에 구성됩니다. 이는 "언더레이" 네트워크의 표준 설계입니다.    

반면 BGP는 OSPF와 같이 대부분의 IGP보다 훨씬 많은 경로를 전달하도록 설계되었습니다. OSPF와 같은 IGP에 BGP 경로를 재배포하는 것과 관련된 위험. 서비스 공급자가 사용 사례에 따라 BGP 경로를 IGP 도메인으로 재배포해야 하는 경우 ASBR(Autonomous System Boundary Router)에서 적절한 필터링과 수신 라우터에 구성된 오버로드 보호를 사용하여 서비스 공급자가 이를 관리해야 합니다. BGP 재배포가 OSPF로 필터링되지 않으면 ASBR의 모든 OSPF 디바이스는 동시에 처리할 수 있는 용량을 훨씬 초과하는 경로를 수신하기 시작합니다. 예를 들어 Cisco IOS XR 라우터는 기본적으로 10,000개의 BGP 경로만 OSPF에 재배포되도록 허용합니다. BGP 경로가 IGP로 재배포되는 경우 IGP 설계에 따라 IGP 도메인 내의 모든 라우터가 이러한 경로를 수신할 수 있습니다. OSPF 프로토콜 RFC에 따라 OSPF로 재배포되는 모든 외부 경로는 OSPF 영역의 모든 라우터에 배포되어야 합니다.   

IGP로의 재배포 관리  

일반적인 모범 사례로서, 재배포 기능이 제공할 연결성 경로를 학습할 다른 옵션이 없을 때만 신중하게 계획적으로 재배포해야 합니다.  

일반적인 관행으로는 다음을 수행해야 합니다. 

■ 재배포 방지  

■ IGP 도메인에서 경로 이동 방지 

■ 외부 연결성을 위해 BGP 구현  

■ IGP를 사용하여 다음 홉 정보만 전달합니다(예: 루프백 0).  

OSPF 경로 재배포 제한 사항  

BGP에서 OSPF로 재배포되는 접두사의 스케일은 max-lsa(overload protection) 컨피그레이션으로 관리됩니다. 이는 OSPF 도메인에 많은 수의 경로가 유출되는 것을 방지하는 유일한 보호입니다. 단일 OSPF 영역으로 재배포하는 경우 경로 재배포에 대한 여러 보호 계층을 구현해야 합니다. 

다음은 경로 재배포를 방지하는 데 사용할 수 있는 몇 가지 옵션입니다. 

■ ACL을 사용한 재배포 필터링   

■ 재배포 제한 - 특정 수 이상의 경로가 재배포되지 않도록 하는 전역 설정입니다. 필터를 제거하면 전역 재배포 제한은 두 번째 방어선이며 코어를 보호합니다. 

■ 영역의 모든 디바이스에 대한 Max-LSA 컨피그레이션  - 위 글머리 기호에 언급된 보호가 실패할 경우 수신 라우터가 과도한 수신 LSA를 거부하도록 강제합니다.

OSPF 링크 상태 데이터베이스 오버로드 보호  

OSPF Link-State Database Overload Protection 기능은 지정된 OSPF 프로세스에 대해 자체 생성되지 않은 LSA의 수를 제한하는 OSPF 레벨의 메커니즘을 제공합니다. 네트워크의 다른 라우터가 잘못 구성된 경우, 대량의 LSA를 생성하여 대량의 접두사를 OSPF에 재배포할 수 있습니다. 이 보호 메커니즘은 라우터가 많은 LSA를 받지 못하므로 CPU 및 메모리 부족이 발생하는 것을 방지하는 데 도움이 됩니다.  

기능 동작

이 기능의 작동 방식은 다음과 같습니다. 

■ 이 기능이 활성화된 경우 라우터는 수신된(자체 생성되지 않은) 모든 LSA 수의 카운트를 유지합니다.  

■ 구성된 임계값에 도달하면 오류 메시지가 기록됩니다.  

■ 구성된 최대 수신 LSA 수를 초과하면 라우터가 새 LSA 수락을 중지합니다.   

max-lsa <max-lsa-count> <%-threshold-to-log-warning> ignore-count <ignore-count-value> ignore-time <ignore-time-in-minutes> reset-time <time-to-reset-ignore-count-in-minutes>   

OSPF 상태

수신된 LSA 수가 구성된 최대 수보다 1분 후에 더 많으면 OSPF 프로세스가 모든 인접성을 낮추고 OSPF 데이터베이스를 지웁니다. 이 상태를 ignore 상태라고 합니다. 이 상태에서는 OSPF 인스턴스에 속하는 모든 인터페이스에서 수신된 모든 OSPF 패킷이 무시되며 해당 인터페이스에서 OSPF 패킷이 생성되지 않습니다. 구성된 무시 시간 동안 OSPF 프로세스는 무시 상태로 유지됩니다(기본값은 5분). 무시 시간이 만료되면 OSPF 프로세스가 정상 작업으로 돌아오고 모든 인터페이스에 인접성을 구축합니다.   

OSPF 인스턴스가 무시 상태에서 반환되는 즉시 LSA 수가 최대 수를 초과하면 OSPF 인스턴스는 정상 상태와 무시 상태 사이에서 끊임없이 진동할 수 있습니다. 이러한 무한 진동을 방지하기 위해 OSPF 인스턴스는 무시된 상태의 횟수를 계산합니다. 이 카운터는 ignore-count라고 합니다. ignore-count(기본 ignore-count는 5)가 구성된 값을 초과하면 OSPF 인스턴스가 영구적으로 ignore 상태로 유지됩니다.   

OSPF 인스턴스를 정상 상태로 되돌리려면 clear ospf 명령을 실행해야 합니다. LSA 수가 reset-time 키워드로 구성된 시간 동안 다시 최대 수를 초과하지 않으면 ignore-count는 0으로 재설정됩니다.   

warning-only 키워드를 사용할 경우, OSPF 인스턴스는 ignore 상태로 전환되지 않습니다. LSA 카운트가 최대 수를 초과하면 OSPF 프로세스가 오류 메시지를 로깅하고 OSPF 인스턴스가 정상 상태 작업을 계속합니다.  

max-lsa에 대한 기본값은 없습니다. 제한은 구체적으로 구성된 경우에만 확인됩니다.  

max-lsa가 구성되면 다른 매개변수에 기본값이 포함될 수 있습니다.

■ %-threshold-to-log-warning 기본값 - 75%  

■ ignore-count-value - 5

■ 기본 ignore-time-in-minutes - 5분  

■ time-to-reset-ignore-count - 10분

다음은 VRF V1에서 자체 생성되지 않은 LSA 및 1000개12000 자체 생성되지 않은 LSA를 허용하도록 OSPF 인스턴스를 구성하는 방법을 보여주는 구현 예입니다.

RP/0/RSP0/CPU0:라우터# 구성  

RP/0/RSP0/CPU0:router(config)# 라우터 ospf 0   

RP/0/RSP0/CPU0:router(config-ospf)# max-lsa 12000  

RP/0/RSP0/CPU0:라우터(config-ospf)# vrf V1  

RP/0/RSP0/CPU0:router(config-ospf)# max-lsa 1000   

다음 예에서는 OSPF 인스턴스의 현재 상태를 표시하는 방법을 보여 줍니다.  

RP/0/RSP0/CPU0:router# show ospf 0  

    ID가 10.0.0.2인 라우팅 프로세스 "ospf 0"  

    NSR(Non-stop routing)이 비활성화되었습니다.  

    단일 TOS(TOS0) 경로만 지원  

    불투명 LSA 지원  

    영역 경계 라우터입니다.  

    허용되는 최대 비자체 생성 LSA 12000  

       현재 비자체 생성 LSA 수 1  

       경고 메시지에 대한 임계값 75%  

       Ignore-time 5분, 재설정-time 10분  

       Ignore-count 허용됨 5, 현재 ignore-count 0  

BGP 구현 

BGP 주소 패밀리는 BGP를 "다중 프로토콜" 라우팅 프로토콜로 만듭니다. 구현과 관리가 용이한 확장 가능한 토폴로지를 생성하는 데 주소 패밀리를 사용하는 방법을 이해하는 것이 좋습니다. 운영자는 주소군을 사용하여 EVPN, Multicast 등 다양한 기술에 대해 다양한 토폴로지를 생성할 수 있습니다.  

BGP에 대한 자세한 내용은 BGP 컨피그레이션 가이드(https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html)를 참조하십시오. 

BGP 및 BFD 

복원력 및 내결함성 네트워크 구축에 대한 고객의 기대치를 충족하려면 통신 사업자 네트워크의 BGP 통합이 중요합니다. 기본적으로 BGP의 Keepalive 타이머는 60초, Hold 타이머는 180초입니다. 이 모든 것은 지원 프로토콜의 도움이 없는 한 BGP 통합이 매우 느려진다는 것을 의미합니다. BFD BFD(Bi-directional Forwarding)는 클라이언트 프로토콜이 더 빨리 통합될 수 있도록 설계된 프로토콜 중 하나입니다. BFD를 사용하면 몇 초 내에 프로토콜을 통합할 수 있습니다.   

추가 정보

■ 이 설명서에서는 BFD에 대한 개념 및 구성 정보를 제공합니다. https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/routing/76x/b-routing-cg-ncs5500-76x/implementing-bfd.html 

■ 이 백서에서는 Cisco NCS 5500 및 Cisco Network Convergence System 500 Series 라우터에서 BFD를 사용하여 빠른 컨버전스를 구현하는 서비스 공급자 중심의 보기를 소개합니다. https://xrdocs.io/ncs5500/tutorials/bfd-architecture-on-ncs5500-and-ncs500/  

■ 번들 인터페이스에서 BFD를 사용하고 다중 경로 및 다중 홉 BFD 구현에 대한 자세한 내용은 https://xrdocs.io/ repository를 참조하십시오.  

BGP 느린 피어 감지  

저속 피어는 라우터가 업데이트 그룹에서 장기간(분 단위) 업데이트 메시지를 생성하는 속도를 따라잡을 수 없는 피어입니다. 업데이트 그룹에 느린 피어가 있으면 전송 보류 중인 형식이 지정된 업데이트 수가 증가합니다. 캐시 제한에 도달하면 그룹에 새 메시지의 형식을 지정할 할당량이 더 이상 없습니다. 새 메시지의 형식을 지정하려면 느린 피어를 사용하여 일부 기존 메시지를 전송한 다음 캐시에서 제거해야 합니다. 느린 피어보다 빠르고 서식이 지정된 메시지의 전송을 완료한 그룹의 나머지 멤버는 새로 수정된 BGP 네트워크가 알림 또는 철회 대기 중일지라도 새로 전송할 항목이 없습니다. 피어 중 하나가 업데이트 사용이 느릴 때 그룹의 모든 피어의 서식을 차단하는 이러한 효과는 "저속 피어" 문제입니다.  

BGP 테이블에서 심각한 변동(예: 연결 재설정)을 유발하는 이벤트는 업데이트 생성 속도가 잠깐 급증할 수 있습니다. 이러한 이벤트 중에 일시적으로 뒤처지지만 이벤트 후에 빠르게 복구되는 피어는 느린 피어로 간주되지 않습니다. 피어가 느린 것으로 표시되려면 더 오랜 기간(몇 분 정도)에 걸쳐 생성된 업데이트의 평균 속도를 따라잡을 수 없어야 합니다.  

BGP 느린 피어가 발생할 수 있는 원인:   

■에 대한 링크의 패킷 손실 또는 트래픽이 높습니다. 

■ BGP 피어는 CPU 측면에서 많이 로드될 수 있으므로 필요한 속도로 TCP 연결을 서비스할 수 없습니다.  

■ 이 경우 플랫폼 하드웨어 기능과 제공된 로드를 확인해야 합니다. 

■ 연결의 처리량 문제 해결  

■ BGP 느린 피어 탐지에 대한 자세한 내용은 다음을 참조하십시오. https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_ir5_j4w_p4b  

다음은 느린 피어를 관리하기 위한 몇 가지 완화 및 모범 사례입니다.   

■ 엔드 투 엔드 QoS - 혼잡 시 BGP 제어 평면 트래픽을 위해 대역폭을 예약합니다. 

■ BGP PMTUD 및/또는 TCP MSS 설정을 사용하여 올바르고 적절한 MSS/MTU 값을 사용합니다. 

■ 올바른 하드웨어를 사용하고 하드웨어와 관련된 경로 수를 최소화합니다. 

Cisco IOS XR에서는 릴리스 7.1.2부터 슬로우 피어 탐지가 기본적으로 활성화되어 있습니다. 느린 피어는 인바운드 BGP 업데이트를 수신 및 처리하고 발신자에게 업데이트를 승인하는 속도가 느린 피어입니다. 속도가 느린 피어가 다른 피어와 동일한 업데이트 그룹에 참여하는 경우 모든 피어의 업데이트 프로세스가 느려질 수 있습니다. 이 릴리스에서는 IOS XR에서 저속 피어를 탐지하면 특정 피어에 대한 세부사항이 포함된 syslog를 생성합니다.   

BGP 접두사 독립 수렴(Prefix Independent Convergence)을 사용한 빠른 수렴  

BGP 접두사의 경우 BGP PIC(Prefix Independent Convergence)를 사용하여 빠른 컨버전스를 수행합니다. 여기서 BGP는 대체 최적 경로와 기본 최적 경로를 계산하고 라우팅 테이블에 두 경로를 기본 경로와 백업 경로로 설치합니다.   

BGP next-hop remote에 연결할 수 없는 경우 BGP는 실패 후 경로를 다시 계산하는 대신 BGP PIC를 사용하여 즉시 대체 경로로 전환합니다.   

BGP next-hop 원격 PE가 활성 상태이지만 경로 장애가 있는 경우 IGP TI-LFA FRR은 대체 경로로 신속하게 재컨버전스를 처리하고 BGP는 원격 PE에 대한 IGP next-hop을 업데이트합니다.   

원격 PE에 연결할 수 없는 경우 VPN 접두사의 빠른 통합을 위해 VRF 주소군에 BGP PIC가 구성됩니다.  

BGP Prefix Independent Convergence에 대한 자세한 내용은 다음을 참조하십시오.
https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/bgp-pic.html 

 

BGP Flowspec을 사용한 BGP 보안  

BGP Flowspec은 간단히 말해 BGP 업데이트를 통해 IPv4/IPv6 트래픽 흐름 사양(소스 X, 대상 Y, 프로토콜 UDP, 소스 포트 A 등) 및 해당 트래픽에 대해 수행해야 하는 작업(예: 삭제, 폴리스 또는 리디렉션)을 수신할 수 있도록 하는 기능입니다. BGP 업데이트
내에서 Flowspec 일치 기준은 BGP NLRI로 표시되고 BGP 확장 커뮤니티는 작업을 나타냅니다.

이 기능은 RFC 5575를 기반으로 하며 DDoS 공격을 완화하는 데 사용할 수 있습니다. 네트워크 내부의 특정 호스트가 공격을 받으면 공격 트래픽을 폴리싱하거나 삭제하거나 다른 곳으로 리디렉션할 수 있도록 Flowspec 업데이트를 에지 라우터로 보낼 수 있습니다. 즉, 트래픽을 정리할 수 있는 어플라이언스로 리디렉션할 수 있습니다('불량' 트래픽은 걸러내고 '정상' 트래픽만 영향받는 호스트로 전달함).  

Flowspec이 라우터에서 수신되고 해당 라인 카드에 프로그래밍되면 해당 라인 카드의 모든 활성 L3 포트는 Flowspec 규칙에 따라 인그레스 트래픽 처리를 시작합니다.  

BGP FlowSpec 구현에 대한 자세한 내용은 다음을 참조하십시오.  

■ BGP FlowSpec 백서: https://xrdocs.io/ncs5500/tutorials/bgp-flowspec-on-ncs5500/  

■ BGP 컨피그레이션 가이드: https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/76x/b-bgp-cg-ncs5500-76x/implementing-bgp.html#concept_uqv_bxq_h2b 

 

BGP 최대 접두사 기능

Maximum-Prefix 기능은 원격 피어링 사이트의 아웃바운드 정책 변경 시, 라우터가 피어링 라우터의 리소스가 처리할 수 있는 것보다 많은 접두사를 받기 시작할 뿐 아니라 이러한 외부 접두사가 전달될 내부 BGP 피어나 리소스를 보호할 때 유용합니다. 이러한 리소스 오버헤드는 중단을 초래할 수 있습니다.

BGP maximum-prefix 기능에서는 지정된 주소 패밀리에 대해 네이버에서 받은 접두사의 수에 최대 제한을 부과합니다. 기본적으로 수신된 접두사의 수가 구성된 최대 수를 초과할 때마다 BGP 세션은 중단 알림을 네이버에 전송하고 세션이 종료됩니다. 하나의 주소군이 최대 접두사를 통과하면 전체 BGP 세션이 중단되고, 해당 BGP 세션에서 활성화된 다른 모든 주소군에 영향을 미칩니다.

이 기능은 외부 BGP 피어가 통신 사업자의 내부 인프라를 보호하는 데 일반적으로 사용됩니다. 로컬 또는 원격 네이버의 잘못된 컨피그레이션으로 인해 발생할 수 있는 라우터 리소스 고갈을 방지하기 위한 가드레일 역할을 합니다. 경로 테이블 플러딩을 유발할 수 있는 로컬 또는 원격 구성 오류를 방지하려면 maximum-prefix를 구성하는 것이 좋습니다. 또한 접두사 디어그리게이션 공격도 차단합니다.

BGP maximum-prefix 컨피그레이션은 모든 eBGP 라우터에서 명시적으로 활성화되어야 특정 네이버에서 수신해야 하는 접두사 수(고객 또는 피어링 AS)를 제한할 수 있습니다. 운영자는 사용 가능한 시스템 메모리를 주의 깊게 평가한 후 시스템이 유지할 수 있는 추가 접두사의 허용 가능한 여유를 구성하는 것이 좋습니다. 모든 라우터에 적용될 수 있는 모든 컨피그레이션에 적합한 크기는 없으며, 네트워크의 디바이스 역할에 따라 임계값을 신중하게 조정해야 합니다. 예를 들어 BGP 최대 접두사를 IBGP 인접 디바이스에 구성하려면 최대 접두사 값이 route-reflector에 구성된 인접 디바이스에 비해 route-reflector에 구성된 인접 디바이스에 더 낮아야 합니다. Route-Reflector는 여러 피어링 라우터에서 수신한 접두사를 집계한 다음 전체 테이블을 Route-Reflector-Client에 다시 광고합니다. 따라서 route-reflector는 각 개별 피어에서 수신하는 접두사보다 더 많은 접두사를 클라이언트에 알립니다. 마찬가지로, 피어링 라우터는 경로 리플렉터에 각 개별 외부 피어에서 수신한 접두사보다 더 많은 접두사를 다시 광고할 수도 있습니다.

요약하면, 프로덕션 디바이스에서 최대 접두사 임계값에 도달할 때 수행할 적절한 작업을 신중하게 검토 및 구성하는 것이 좋습니다. maximum-prefix 명령 옵션의 일부 특성은 다음과 같습니다.

• 추가 키워드 없이(예: 경고 전용 또는 재시작) BGP 세션이 최대 접두사 기능으로 명시적으로 구성된 경우 세션은 기본 동작으로 해제됩니다. 자동 복구 없이 피어 세션을 종료하는 기본 작업은 코어 내에서 중단 시간이 길어질 수 있습니다.

%ROUTING-BGP-5-ADJCHANGE_DETAIL: 인접 디바이스 10.10.10.10 Down - BGP 알림을 받았습니다. 최대 접두사 수에 도달했습니다(VRF: 기본값; AFI/SAFI: 1/1, 1/128, 2/4, 2/128, 1/133, 2/133)(AS: 65000). "

%ROUTING-BGP-5-NBR_NSR_DISABLED_STANDBY: 피어가 최대 접두사 제한을 초과하기 때문에 스탠바이 RP의 인접 디바이스 10.10.10.10에서 NSR이 비활성화되었습니다(VRF: 기본값).

• Discard extra paths 옵션을 구성하면 구성된 최대값 임계값 이상으로 네이버에서 수신한 모든 초과 접두사가 삭제됩니다. 이 삭제로 인해 세션 플랩이 발생하지 않습니다. 이 옵션의 이점으로는 BGP 프로세스 메모리 사용을 제한하고 코어 네트워크 내의 피어의 플래핑을 중지하는 것이 있습니다. 그러나 이 경우 포워딩 엔트리가 네트워크의 라우터 간에 일치하지 않게 될 수 있으므로 접두사에 대한 포워딩 루프가 폐기될 수 있습니다.
• add-path를 사용할 경우, 구성된 maximum-prefix 값은 NLRI가 접두사와 경로 특성으로 구성되므로 접두사 대신 경로에 적용됩니다. 자세한 내용은 다음 명령 참조를 참조하십시오.

https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/b-ncs5500-bgp-cli-reference/b-ncs5500-bgp-cli-reference_chapter_01.html

권장 사항: maximum-prefix 명령을 구성할 때 다음 옵션을 신중하게 평가합니다.

• 명시적 작업이 정의되지 않음: 라우터는 세션을 종료하고 운영자가 수동으로 BGP 세션을 지울 때까지 BGP 네이버 관계를 중단합니다. [clear bgp 명령]
• Restart [time-interval]: 세션을 종료하고 구성된 타이머 이후에 주기적으로 BGP 세션을 자동 재시작합니다. 원격 피어가 초과 접두사 알림을 중지하지 않으면 BGP 세션이 다시 다운될 때(따라서 주기적인 불안정이 유발됨) 성공합니다.
• Discard-extra-paths: discard-extra-paths 옵션을 사용하면 BGP 세션이 계속 작동하지만 최대 접두사 제한을 초과하는 접두사는 삭제됩니다. 이 옵션은 maximum-prefix에 도달하지 못한 다른 주소군에 영향을 주지 않으며 로컬 리소스가 소진되지 않도록 하지만, 이로 인해 접두사에 대한 포워딩 루프가 삭제될 수 있습니다. 여분의 경로 삭제 옵션은 소프트 리컨피그레이션 노브와 함께 사용할 수 없습니다.
• Warning-only: 임계값에 도달한 경우에만 경고에 기록하므로 운영자는 조건을 지우는 수동 작업을 수행할 수 있습니다.

자세한 내용은 다음과 같이 라우팅 컨피그레이션 가이드를 참조하십시오.

https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r7-3/routing/configuration/guide/b-routing-cg-asr9000-73x/implementing-BGP.html#concept_5AF38064B1D044B7B5F439C10BCF9808

모범 사례 및 권장 사항

다음 목록에서는 특정 순서 없이 나열되는 일반적인 모범 사례 및 권장 사항의 개요를 제공합니다.  

■ 시스템의 일반적인 상태에 대한 네트워크 감사 컨피그레이션 감사로 시작하여 인터페이스 컨피그레이션에서 라우팅 및 서비스로 순차적으로 이동합니다.   

■ 모니터링 전략이 마련되어 있습니다. SNMP는 표준 방식이지만, 스트리밍 텔레메트리를 사용하여 더 강력하고 기술적인 기법을 구축하는 것을 고려하십시오. IOS XR 라우터에 텔레메트리를 구현하는 모범 사례 권장 사항은 다음 백서를 참조하십시오. https://xrdocs.io/telemetry/  

OSPF  

다음은 OSPF에 대한 일반적인 모범 사례와 권장 사항입니다. 

■ OSPF의 영역 내 경로에 대한 경로 요약을 구현합니다.  

■ OSPF 내에서 라우터 ID를 OSPF 지원 루프백 주소 중 하나로 명시적으로 구성합니다.  

■ OSPF의 영역 내에서 LSA를 제한하도록 계층적 네트워크를 설계합니다. 적절한 범위(~3~4) 내에서 영역의 ABR 수를 유지하십시오.  

■ OSPF에 대한 OSPF "max-lsa" 컨피그레이션 또는 이와 동등한 기능을 구현하여 데이터베이스의 LSA를 제한하여 시스템 메모리를 효과적으로 사용합니다.   

■ BGP에서 OSPF로 배포할 수 있는 최대 경로 수를 제한합니다. IOS-XR에서 기본 제한은 10K입니다. 

■ RPL(Route Policy)을 사용하여 경로를 OSPF로 재배포합니다. 

■ 가능한 경우 영역 간 경로 및 외부 유형 5 경로를 요약합니다.   

■ 시 인증 사용   

■ 항상 NSF와 NSR을 사용합니다. 

■ 대상 대신 소스에서 재배포 필터링을 구성합니다.   

■ 경우 패시브 인터페이스를 사용합니다.   

■ OSPF는 루프백 및 라우터 인터페이스 경로만 전달해야 합니다. 다른 모든 BGP-to-OSPF 재배포를 제거하십시오.   

■ 각 기본 허브를 NSSA(고유 영역)로 이동하는 것을 고려하십시오.   

■ 빠른 장애 탐지를 위해 BFD를 사용하는 경우와 적극적인 라우팅 프로토콜 타이머를 사용하는 경우를 비교합니다.   

■ mtu-ignore 명령을 최대한 사용하지 마십시오.  

■ 레이블 없는 경로에서 트래픽을 전송하지 않도록 하려면 MPLS 환경에서 IGP-LDP 동기화를 사용하는 것이 좋습니다. 

■ 지원되는 플랫폼 한도 내에서 확장을 고려하십시오(접두사 수, 레이블 수, ECMP, 영역 수 등). 

■ 여러 지점에서 상호 재배포를 방지합니다.  

■ 각 프로토콜 또는 프로세스에 고유한 각 접두사가 해당 도메인의 프로토콜 또는 프로세스를 통해 도달할 수 있도록 관리 거리를 구성합니다.  

■ 같은 접두사가 원래 도메인으로 다시 광고되지 않도록 접두사를 제어합니다(distance 또는 prefix-list 조합 사용).   

■ OSPF 프로세스 ID는 라우터에 대한 로컬 의미가 있지만, 동일한 OSPF 도메인의 모든 라우터에 대해 동일한 프로세스 ID를 사용하는 것이 좋습니다. 따라서 컨피그레이션 일관성이 향상되고 자동 컨피그레이션 작업이 쉬워집니다.  

■ Hub-and-Spoke 환경에 OSPF를 구성할 때 라우터 수가 더 적은 OSPF 영역을 설계합니다.   

■ OSPF 도메인 전체에서 OSPF 자동 비용 참조 대역폭을 네트워크의 최고 대역폭 링크로 구성합니다.  

■ 설계의 관점에서 볼 때, 네트워크에 전파되는 계획되지 않은 또는 비인가 IGP 업데이트를 방지하려면 동일한 관리 또는 운영 제어 하에서 도메인으로 IGP 피어링을 구현하는 것이 좋습니다. 이를 통해 서비스 가용성을 높이고 오류 발생 시 쉽게 문제를 해결할 수 있습니다. 대규모 IGP 도메인이 업무상 필요한 경우 IGP 네트워크 도메인의 경로 수를 제한하기 위해 BGP를 사용할 계획입니다.  

■ 엔드 투 엔드 MPLS 연결이 필요한 경우 계층 구조/세그멘테이션을 계속 사용하고 RFC3107 BGP-LU 또는 PCE를 통한 도메인 간 경로 계산과 같은 옵션을 사용하거나 정책을 통한 재배포/유출을 마지막 수단으로 선택합니다.  

■ OSPF Shortest Path First Throttling(OSPF 최단 경로 우선 조절) 기능을 사용하여 밀리초 간격으로 SPF 스케줄링을 구성하고, 네트워크 불안정 시 SPF 계산을 잠재적으로 지연시킬 수 있습니다. 

■ OSPF SPF Prefix Prioritization 기능을 사용하면 관리자가 경로 설치 중에 중요한 접두사를 더 빠르게 통합할 수 있습니다.  

IS-IS  

다음은 IS-IS에 대한 일반적인 모범 사례와 권장 사항입니다. 

■ 플랫 단일 레벨 네트워크를 운영하는 경우 규모를 고려하십시오. 모든 라우터를 L2로만 구성합니다. 기본적으로 라우터는 L1-L2이며 L1에서 L2로 유출되는 라우팅 정보는 기본적으로 활성화되어 있습니다. 이로 인해 모든 라우터가 모든 L1 경로를 L2로 유출하여 링크 상태 데이터베이스가 비활성화될 수 있습니다.  

■ 다중 레벨(다중 영역) 네트워크를 실행하는 경우 레이어 3 토폴로지가 ISIS 계층 구조를 따르는지 확인합니다. L1 영역 사이에 백도어 링크를 만들지 마십시오.  

■ 다중 레벨(다중 영역) 네트워크를 실행하는 경우 L1 및 L2 라우터가 L1 및 L2 영역을 통해 모두 연결되어 있는지 확인합니다. 따라서 여러 물리적 또는 가상 연결이 필요하지 않습니다. L1/L2 회로로 L1 및 L2 라우터 간의 링크를 실행합니다.  

■ 다중 레벨(다중 영역) 네트워크를 실행하는 경우 요약할 수 있는 내용을 요약합니다. 예를 들어 MPLS의 경우 PE 라우터의 루프백을 영역 간에 전파해야 하지만 인프라 링크 주소는 그렇지 않습니다.  

■ 가능한 경우 적절한 주소 지정 계획을 작성하고 따르십시오. 이를 통해 요약이 가능하고 확장이 가능합니다.  

■ LSP 수명을 최대 18시간으로 설정합니다. 

■ 재배포를 방지합니다. 재배포는 복잡하며 라우팅 루프를 방지하기 위해 수동으로 관리해야 합니다. 가능한 경우 다중 영역/레벨 설계를 사용하십시오.  

■ 재배포를 사용해야 하는 경우 재배포 중에 경로 태깅을 사용하고 태그를 기준으로 필터링하여 이를 관리하십시오. 가능하면 재배포 중에 요약하십시오.  

■ 가능하면 인터페이스를 "point-to-point"로 구성합니다. 따라서 프로토콜의 성능과 확장성이 향상됩니다. 

■ 고도의 메시 토폴로지에서는 ISIS를 사용하지 마십시오. 링크 상태 프로토콜은 고도의 메시 환경에서 제대로 작동하지 않습니다.  

■ ISIS 주소군 하위 모드에서 높은 기본 측정 단위를 구성합니다. 이렇게 하면 새로 추가된 링크가 측정 단위 없이 실수로 구성된 경우 트래픽을 끌어오는 것을 방지할 수 있습니다.  

■ 연결 문제 해결에 도움이 되도록 "인접성 변경 로그"를 구성합니다.

■ ISIS 주소군 ipv4 하위 모드에서 "metric-style wide"를 사용합니다. 좁은 메트릭은 매우 유용하지 않으며 세그먼트 라우팅 또는 flex-algo와 같은 기능을 지원하지 않습니다.  

■ SR-MPLS TI-LFA를 사용하는 경우 필요할 때 ISIS가 TE 터널을 할당할 수 있도록 컨피그레이션에 "ipv4 unnumbered mpls traffic-eng Loopback0"을 추가해야 합니다.  

■ 더 빠른 기본 컨버전스가 필요한 경우가 아니면 "lsp-gen-interval" 및 "spf-interval" 컨피그레이션이 기본값으로 설정됩니다. TI-LFA 네이티브 컨버전스는 빠른 경로 재설정이 50ms 이하의 단일 토폴로지 변경을 처리하기 때문에 중요도가 높지 않습니다.  

■ "lsp-gen-interval" 또는 "spf-interval"을 수정하는 경우 50ms보다 짧은 초기 지연을 사용하지 마십시오.  

■ 대부분의 경우 빠른 경로를 지원하는 원자 변화이므로 "max-metric"보다 "set-overload-bit"가 더 좋은 선택입니다.  

■ Hello(hello-password) 및 LSP(lsp-password)에 대해 암호화 인증을 사용합니다. 키체인은 최고의 유연성을 제공하며 히트리스 키 롤오버를
수용할 수 있습니다.  

■ ISIS 프로세스 재시작 및 SMU 설치의 히트리스 인증을 위해 "nsf cisco"를 구성합니다. 이름에도 불구하고, 이는 "nsf ietf"보다 다른 공급업체와의 상호운용성을 더 잘 제공합니다. 

■ 이중 RP가 있는 플랫폼에서 RP 스위치오버를 처리하도록 "nsr"도 구성합니다.  

■ "group" 및 "apply-group" 템플릿을 사용하여 반복되는 컨피그레이션 섹션을 구성합니다. 따라서 오류가 발생하기 쉽고 필요한 경우 쉽게 변경할 수 있습니다.  

■ 다중 레벨 네트워크에서는 "전파"를 사용하여 접두사를 레벨 2에서 레벨 1로 유출해야 하는지 신중하게 고려해야 합니다. 이는 확장성을 제한할 수 있으며, 연결된 비트가 제공하는 레벨 1 기본 경로로도 충분합니다. 

■ 동일한 VRF에서 여러 ISIS 인스턴스를 사용하는 경우 고유한 "거리" 값을 구성하는 것이 좋습니다. 이렇게 하면 RIB에서 경로 설치가 좀 더 확실해집니다. 각 경로에 동일한 접두사 경로가 있을 경우 더욱 그렇습니다.  

■ 빠른 링크 다운 탐지에 BFD를 사용합니다. 이러한 기능을 제공하는 BFD로 ISIS hello-interval을 안전하게 증가시켜 확장성을 향상시킬 수 있다.  

BGP  

다음은 BGP에 대한 일반적인 모범 사례와 권장 사항입니다. 

■ 예상 규모에 따라 신중하게 조정된 타이머와 함께 NSR 및 NSF/graceful restart를 사용합니다. 

■ IBGP 피어링을 위한 물리적 인터페이스가 아닌 'always UP' 루프백 인터페이스를 사용하여 BGP를 구성합니다. 

■ 적절한 RPL 없이 BGP(high-volume) 경로를 IGP(비교적 낮은 볼륨)로 재배포하거나 그 반대로 재배포하지 마십시오. 그러면 BGP에서 IGP(OSPF/ISIS)로 재배포되는 경로의 수가 제한됩니다.   

■ 제대로 테스트된 정책(ACL) 없이 IGP 재배포에 BGP를 수행하면 라우터에서 리소스(메모리) 소진이 발생할 수 있습니다.  

■ 라우팅 테이블 크기 및 메모리 사용을 줄이기 위해 BGP에서 요약 경로를 사용합니다. 의미가 있는 경우 요약 전용 경로를 집계합니다.  

■ 특히 BGP에서 경로를 효율적으로 광고 및 수신하기 위해 경로 필터링을 사용합니다.  

■ 네트워크 확장을 위해 RR(Route-Reflector) 및 Confederation을 사용하는 것이 좋습니다.   

■ 경로 리플렉터 설계 시 고려해야 할 사항은 다음과 같습니다. 

■ Path Scale은 클라이언트/비클라이언트 수에 따라 증가합니다. 

■ 계층적 RR에서는 루프 방지 및 확장을 위해 동일한 레벨(중복 RR)에서 동일한 cluster-id를 사용합니다.  

■ 경로 내에서 MTU를 제어하거나 PMTUD 프로토콜을 사용하여 BGP MSS를 자동으로 조정합니다.  

■ 더 빠른 장애 탐지를 위해 BFD를 사용하거나 BGP 타이머를 조정합니다. 

■ BGP 스케일은 컨피그레이션 및 활용 사례에 따라 다르며 어떤 규모도 모든 경우에 적합하지 않습니다. 다음 사항에 대해 잘 알고 있어야 합니다.  

■ 경로 배율  

— 경로 확장(소프트 재구성을 통해 증가함)  

— 특성 배율  

■ 추가 경로가 구성된 경우 더 많은 메모리가 사용됩니다.  

■ 인접 디바이스 정책을 주의 깊게 이해: 

— 특히 경계 라우터의 경우 패스올(pass-all)로 인해 메모리 규모가 급증할 경우 대혼란을 일으킬 수 있습니다. 

— RPL에서 정규식 일치를 방지하는 정책 구문을 사용합니다.  

■ NSR의 경우 스탠바이 RP는 액티브 메모리보다 약 30% 더 많은 가상 메모리를 사용합니다. 스탠바이가 있는 경우 이 점을 고려하십시오. 

■ 많은 경로(버전 범프)에서 지속적으로 발생하는 문제를 주의하십시오. 그러면 업데이트 생성 메모리가 하이 워터마크로 유지될 수 있습니다. 

■ max-prefix knob로 피어를 보호합니다.  

■ 확장 및 컨버전스 목표에 따라 next-hop-trigger 지연 매개변수를 사용합니다. 

■ 네트워크 설계에서는 새 특성을 사용하지 않도록 합니다. 고유한 특성은 효율적인 패킹을 초래하고 더 많은 BGP 업데이트를 초래합니다.  

■ 네트워크 전체에서 다중 경로를 구성하면 포워딩 루프가 발생할 수 있습니다. 신중하게 사용하십시오.  

■ RR이 inline-RR이 아닌 경우(next-hop-self 아님) rib에 대한 경로 설치를 방지하려면 table-policy를 사용합니다.   

라우팅 프로세스의 시스템 메모리 모니터링

어떤 디바이스에도 무한한 리소스가 없습니다. 디바이스에 무한한 수의 경로를 전송하려면 디바이스에서 실패 방법을 선택해야 합니다. 라우터는 메모리 제한이 모두 소진될 때까지 모든 경로를 서비스하려고 시도하며, 이로 인해 모든 라우팅 프로토콜 및 프로세스가 실패할 수 있습니다.  

코어 라우터의 각 프로세스에는 "RLIMIT"가 정의되어 있습니다. "RLIMIT"는 각 프로세스가 사용하도록 허용된 시스템 메모리의 양입니다.   

이 섹션에서는 BGP 프로세스에서 사용하는 시스템 메모리를 모니터링하고 확인하는 몇 가지 표준 기술에 대해 설명합니다. 

프로세스 메모리  

프로세스에서 사용하는 메모리의 양을 표시합니다.

RP/0/RP0/CPU0:NCS-5501#show proc memory  

JID 텍스트(KB) 데이터(KB) 스택(KB) 동적(KB) 프로세스  

------ ---------- ---------- ---------- ----------- ------------------------------  

1150 896 368300 136 33462 lspv_server  

380 316 1877872 136 32775 parser_server  

1084 2092 2425220 136 31703 bgp  

1260 1056 1566272 160 31691 ipv4_rib  

1262 1304 1161960 152 28962 ipv6_rib  

1277 4276 1479984 136 21555 pim6  

1301 80 227388 136 21372 schema_server  

1276 4272 1677244 136 20743 pim  

250 124 692436 136 20647 invmgr_proxy  

1294 4540 2072976 136 20133 l2vpn_mgr  

211 212 692476 136 19408 sdr_invmgr  

1257 4 679752 136 17454 statsd_manager_g  

 

각 프로세스에는 사용하도록 허용된 최대 메모리 양이 할당됩니다. 이는 한계로 정의됩니다.  

RP/0/RP0/CPU0:NCS-5501#show proc memory detail  

JID 텍스트 데이터 스택 동적 동적 Dyn-Limit Shm-Tot Phy-Tot Process  

============================================================================================================  

1150 896K 359M 136K 32M 1024M 18M 24M lspv_server  

1084 2M 2368M 136K 30M 7447M 43M 69M bgp  

1260 1M 1529M 160K 30M 8192M 38M 52M ipv4_rib  

380 316K 1833M 136K 29M 2048M 25M 94M parser_server  

1262 1M 1134M 152K 28M 8192M 22M 31M ipv6_rib  

1277 4M 1445M 136K 21M 1024M 18M 41M pim6  

1301 80K 222M 136K 20M 300M 5M 33M schema_server  

1276 4M 1637M 136K 20M 1024M 19M 41M pim  

250 124K 676M 136K 20M 1024M 9M 31M invmgr_proxy  

1294 4M 2024M 136K 19M 1861M 48M 66M l2vpn_mgr  

211 212K 676M 136K 18M 300M 9M sdr_invmgr  

1257 4K 663M 136K 17M 2048M 20M 39M statsd_manager_g  

288 4K 534M 136K 16M 2048M 15M 33M statsd_manager_l  

...    

상위 메모리 소비자  

RP/0/RP0/CPU0:NCS-5501#show memory-top-consumer  

####################################################################  

 0/0/CPU0의 상위 메모리 소비자(2022/4/13/15:54:12)  

####################################################################  

    PID 프로세스 총(MB) 힙(MB) 공유(MB)  

   3469 fia_driver 826 492.82 321  

   4091 fib_mgr 175 1094.43 155  

   3456spp 130 9.68 124  

   4063 dpa_port_mapper 108 1.12 105  

   3457 패킷 104 1.36 101  

   5097 l2fib_mgr 86 52.01 71  

   4147 bfd_agent 78 6.66 66  

   4958 eth_intf_ea 66 4.76 61  

   4131 optics_driver 62 141.23 22  

   4090 ipv6_nd 55 4.13 49  

####################################################################  

 0/RP0/CPU0의 상위 메모리 소비자(20xx/MMM/HH:MM:SS)  

####################################################################  

    PID 프로세스 총(MB) 힙(MB) 공유(MB)  

   3581종 119 9.62 114  

   4352 dpa_port_mapper 106 2.75 102  

   4494 fib_mgr 99 7.71 90  

   3582 패킷 96 1.48 94  

   3684 parser_server 95 64.27 25  

   8144 te_control 71 15.06 55  

   8980 bgp 70 27.61 44  

   7674 l2vpn_mgr 67 23.64 48  

   8376 mibd_interface 65 35.28 28  

   3608 gsp 65 15.75 48   

총 메모리 - 사용 및 사용 가능  

시스템 구성 요소에는 사용 가능한 메모리의 양이 고정되어 있습니다.  

RP/0/RP0/CPU0:NCS-5501#show memory summary location all  

노드: node0_0_CPU0  

------------------------------------------------------------------  

 물리적 메모리: 총 8억 1,920만 개(6억 1,720만 개 사용 가능)  

 애플리케이션 메모리: 8192M(6172M 사용 가능)  

 이미지: 4M (부트램: 0M)  

 예약됨: 0M, IOMem: 0M, flashfsys: 0M  

 총 공유 창: 2억 2,600만  

노드: node0_RP0_CPU0  

------------------------------------------------------------------  

 물리적 메모리: 총 18432M(15344M 사용 가능)  

 애플리케이션 메모리: 18432M(15344M 사용 가능)  

 이미지: 4M (부트램: 0M)  

 예약됨: 0M, IOMem: 0M, flashfsys: 0M  

 총 공유 창: 1억 8,100만  

 

공유 메모리 창은 시스템의 공유 메모리 할당에 대한 정보를 제공합니다.  

RP/0/RP0/CPU0:NCS-5501#show memory summary detail location 0/RP0/CPU0  

노드: node0_RP0_CPU0  

------------------------------------------------------------------  

 물리적 메모리: 총 18432M(15344M 사용 가능)  

 애플리케이션 메모리: 18432M(15344M 사용 가능)  

 이미지: 4M (부트램: 0M)  

 예약됨: 0M, IOMem: 0M, flashfsys: 0M  

 공유 창 soasync-app-1: 243.328K  

 공유 창 soasync-12: 3.328K  

 ...  

 Shared window rewrite-db: 272.164K  

 공유 창 l2fib_brg_shm: 139.758K  

 공유 창 im_rules: 384.211K  

 공유 창 grid_svr_shm: 44.272M  

 공유 창 spp: 86.387M  

 공유 창 im_db: 1.306M  

 총 공유 창: 180.969M  

 할당된 메모리: 2.337G  

 프로그램 텍스트: 127.993T  

 프로그램 데이터: 64.479G  

 프로그램 스택: 2.034G  

시스템 RAM: 18432M( 19327352832)  

총 사용: 3억 880만(3238002688)  

 전용 사용: 0M( 0)  

 공유 사용: 3088M( 3238002688)  

 

공유 메모리 창에서 참가자 프로세스를 확인할 수 있습니다.  

RP/0/RP0/CPU0:NCS-5501#sh shmwin spp 참가자 목록  

창 "spp"에 대한 데이터:  

-----------------------------  

현재 참가자 목록:-  

이름 PID JID 인덱스  

spp 3581 113 0  

패킷 3582 345 1  

ncd 4362 432 2  

netio 4354 234 3  

nsr_ping_reply 4371 291 4  

aib 4423 296 5  

ipv6_io 4497 430 6  

ipv4_io 4484 438 7  

fib_mgr 4494 293 8  

...  

snmpd 8171 1002 44  

ospf 8417 1030 45  

mpls_ldp 7678 1292 46  

bgp 8980 1084 47  

cdp 9295 337 48  

RP/0/RP0/CPU0:NCS-5501#sh shmwin soasync-1 참가자 목록  

창 "soasync-1"에 대한 데이터:  

-----------------------------  

현재 참가자 목록:-  

이름 PID JID 인덱스    

tcp 5584 168 0        

bgp 8980 1084    

 

리소스 모니터링 및 감시  

메모리 사용률은 cXR의 시스템 워치독 및 eXR의 Resmon을 통해 모니터링됩니다.  

RP/0/RP0/CPU0:NCS-5501#show watchdog memory-state  

---- node0_RP0_CPU0 ----  

메모리 정보:  

    물리적 메모리: 18432.0MB  

    사용 가능한 메모리: 15348.0MB  

    메모리 상태: 정상  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501#show watchdog threshold memory defaults 위치 0/RP0/CPU0  

---- node0_RP0_CPU0 ----  

 기본 메모리 임계값:  

 일반: 1843MB β—10%  

 심각: 1474MB β—8%  

 중요: 921.599MB β—5%  

메모리 정보:  

    물리적 메모리: 18432.0MB  

    사용 가능한 메모리: 15340.0MB  

    메모리 상태: 정상  

RP/0/RP0/CPU0:NCS-5501#  

RP/0/RP0/CPU0:NCS-5501(config)#watchdog 임계값 메모리 부 ?  

  <5-40> 메모리 소비량(백분율)  

 

임계값을 넘으면 경고가 출력됩니다.  

RP/0/RP0/CPU0:2월 17 23:30:21.663 UTC: resmon[425]: %HA_WD-4-MEMORY_ALARM: 메모리 임계값 초과: Minor, 1840.000MB free. 이전 상태: 정상  

RP/0/RP0/CPU0: 2월 17일 23:30:21.664 UTC: resmon[425]: %HA_WD-6-TOP_MEMORY_USERS_INFO: 시스템 메모리의 상위 5개 소비자(1884160KB 무료):  

RP/0/RP0/CPU0: 2월 17일 23:30:21.664 UTC: resmon[425]: %HA_WD-6-TOP_MEMORY_USER_INFO: 0: 프로세스 이름: bgp[0], pid: 7861, 힙 사용량: 12207392kbytes.  

RP/0/RP0/CPU0: 2월 17일 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO: 1: 프로세스 이름: ipv4_rib[0], pid: 4726, 힙 사용량: 708784kbytes.  

RP/0/RP0/CPU0: 2월 17일 23:30:21.664 UTC: resmon[425]: %HA_WD-6-TOP_MEMORY_USER_INFO: 2: 프로세스 이름: fib_mgr[0], pid: 3870, 힙 사용량: 584072kbytes.  

RP/0/RP0/CPU0: 2월 17일 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO: 3: 프로세스 이름: netconf[0], pid: 9260, 힙 사용량: 553352kbytes.  

RP/0/RP0/CPU0:2월 17 23:30:21.664 UTC: resmon[425]: %HA-HA_WD-6-TOP_MEMORY_USER_INFO: 4: 프로세스 이름: netio[0], pid: 3655, 힙 사용량: 253556kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.414 PST: resmon[172]: %HA_WD-4-MEMORY_ALARM: 메모리 임계값 초과: Severe with 600.182MB free. 이전 상태: 정상  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USERS_WARNING: 시스템 메모리의 상위 5개 소비자(624654KB 무료):  

LC/0/3/CPU0: 3월 8일 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USER_WARNING: 0: 프로세스 이름: fib_mgr[0], pid: 5375, 힙 사용량 1014064 KB.  

LC/0/3/CPU0: 3월 8일 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USER_WARNING: 1: 프로세스 이름: ipv4_mfwd_partner[0], pid: 5324, 힙 사용량 185596 KB.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USER_WARNING: 2: 프로세스 이름: nfsvr[0], pid: 8357, 힙 사용량 183692 Kbytes.  

LC/0/3/CPU0:Mar 8 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USER_WARNING: 3: 프로세스 이름: fia_driver[0], pid: 3542, 힙 사용량 177552 KB.  

LC/0/3/CPU0: 3월 8일 05:48:58.435 PST: resmon[172]: %HA_WD-4-TOP_MEMORY_USER_WARNING: 4: 프로세스 이름: npu_driver[0], pid: 3525, 힙 사용량 177156 KB.   

일부 프로세스는 watchdog 메모리 상태에 따라 특정 작업을 수행할 수 있습니다. 예를 들어 BGP는 다음을 수행합니다.  

■ 상태에서 BGP는 새 피어의 전송을 중지합니다  

■ 상태의 BGP는 일부 피어를 점진적으로 낮춥니다.  

■ 상태에서 BGP 프로세스가 종료됩니다.  

메모리 상태 알림을 등록하도록 프로세스를 구성할 수 있습니다.  

Watchdog 또는 인식 프로세스 표시  

 

사용자는 watchdog 시간 초과로 인해 자동 프로세스 종료를 비활성화할 수 있습니다.  

watchdog restart memory-hog 비활성화

자세한 정보는 어디에서 찾을 수 있습니까?  

■ Cisco IOS XR 블로그 및 백서 저장소(xrdocs.io) 

■ Core Fabric Design: https://xrdocs.io/design/blogs/latest-core-fabric-hld : 이 백서에서는 코어 백본 네트워크의 최신 동향과 발전을 소개합니다.   

■ 피어링 패브릭 설계: https://xrdocs.io/design/blogs/latest-peering-fabric-hld : 이 백서는 네트워크 간소화에 중점을 둔 피어링 설계의 과제와 모범 사례 권장 사항에 대한 포괄적인 개요를 제공합니다.  

■ 컨피그레이션 가이드 참조: BGP 구현 https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5500/bgp/710x/b-bgp-cg-ncs5500-710x/implementing-bgp.html

기능 개선