ASR 9000 nV 클러스터 제거 절차

다운로드 옵션

PDF (1.0 MB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (824.5 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (525.9 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2019년 4월 5일

문서 ID:214280

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

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

소개

이 문서에서는 ASR 9000의 nV 클러스터 기능 중 일부 및 클러스터 해제 방법에 대해 설명합니다.

이 문서에 설명된 디클루터링 프로세스를 이미 결정한 Cisco 고객과 함께 실제 환경에서 절차를 테스트했습니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

IOS XR
ASR 9000 플랫폼
nV 클러스터 기능

사용되는 구성 요소

이 문서의 정보는 IOS XR 5.x를 실행하는 ASR 9000 플랫폼을 기반으로 합니다.

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

배경 정보

BU(Product Business Unit)에서 ASR 9000 플랫폼의 nV 클러스터용 EOS(End-of-Sale)를 발표했습니다. Cisco nV 클러스터의 End-of-Sale 및 End-of-Life 공지

공지사항에 나와 있듯이 이 제품을 주문할 수 있는 마지막 날짜는 2018년 1월 15일이며, nV 클러스터에서 마지막으로 지원되는 릴리스는 IOS-XR 5.3.x입니다.

주의해야 할 중요 시점은 다음 표에 나와 있습니다.

asr9k-decluster-announcement

ASR9k nV 클러스터 기본 사항 및 고려 사항

이 섹션의 목표는 이 문서의 다음 섹션을 이해하는 데 필요한 클러스터 설정 및 개념에 대한 간단한 새로고침을 제공하는 것입니다.

asr9k-decluster-steady-state

EOBC(이더넷 대역 외 채널)

이더넷 OOB(Out of Band) 채널은 두 ASR9k 섀시 간의 제어 평면을 확장하며, 서로 다른 섀시의 RSP(Route Switch Processor) 사이에 메쉬를 구축하는 4개의 인터커넥트로 구성되는 것이 좋습니다. 이 설정에서는 EOBC 링크 장애 시 추가 이중화를 제공합니다. UDLD(Unidirectional Link Detection Protocol)는 양방향 데이터 포워딩을 보장하고 링크 장애를 신속하게 탐지합니다. 모든 EOBC 링크의 오작동은 클러스터 시스템에 심각한 영향을 미치며, Split Node Scenarios(스플릿 노드 시나리오) 섹션의 뒷부분에 나오는 심각한 결과를 초래할 수 있습니다.

랙 간 링크(IRL)

랙 간 링크는 두 ASR9k 섀시 간의 데이터 플레인을 확장합니다. 이상적으로는 프로토콜 펀트와 프로토콜 주입만 IRL을 통해 패킷을 전달합니다. 단, 싱글 홈 서비스는 예외입니다. 또는 네트워크 장애 시에도 마찬가지입니다. 이론상 모든 엔드 시스템은 두 ASR9K 섀시에 대한 링크를 사용하여 듀얼 홈 방식으로 구성됩니다. UDLD는 EOBC 링크와 마찬가지로 IRL 상단에서 실행되며 링크의 양방향 포워딩 상태를 모니터링합니다.

예를 들어, LC 장애가 발생하는 경우 혼잡한 IRL이 패킷을 삭제하지 않도록 IRL 임계값을 정의할 수 있습니다. IRL 링크 수가 해당 섀시에 대해 구성된 임계값 아래로 떨어지면 섀시의 모든 인터페이스가 오류 비활성화되고 종료됩니다. 이는 기본적으로 영향을 받는 섀시를 격리하고 모든 트래픽이 다른 섀시를 통과하도록 합니다.

참고: 기본 컨피그레이션은 nv edge data minimum 1 backup-rack-interfaces와 동일합니다. 즉, IRL이 포워딩 상태에 있지 않으면 DSC(Backup Designated Shelf Controller)가 격리됩니다.

스플릿 노드 시나리오

이 하위 섹션에서는 ASR9k 클러스터를 처리할 때 발생할 수 있는 다양한 실패 시나리오를 찾을 수 있습니다.

IRL 아래로

이 시나리오는 폐기 중에 예상할 수 있는 유일한 스플릿 노드 시나리오입니다. 또는 섀시 중 하나가 IRL 임계값 아래로 떨어지고 그 결과로 격리되는 경우입니다.

EOBC 작동 중지

ASR9k의 두 섀시는 EOBC 링크에서 제공하는 확장 컨트롤 플레인이 없으면 하나의 섀시로 작동할 수 없습니다. IRL 링크를 통해 교환되는 주기적인 신호가 있으므로 각 섀시는 다른 섀시가 가동 중임을 인식합니다. 따라서 섀시 중 하나, 일반적으로 Backup-DSC가 있는 섀시가 서비스 중단 상태에서 재부팅됩니다. Backup-DSC 섀시는 IRL을 통해 Primary-DSC 섀시의 신호를 수신하는 한 부팅 루프에 남아 있습니다.

스플릿 브레인

스플릿 브레인 시나리오에서 IRL 및 EOBC 링크가 다운되었으며 각 섀시는 Primary-DSC로 선언됩니다. 인접 네트워크 디바이스에서 갑자기 IGP 및 BGP의 라우터 ID가 중복되어 네트워크에 심각한 문제가 발생할 수 있습니다.

번들

많은 고객이 에지와 코어 측에서 번들을 사용하여 ASR9K 클러스터 설정을 간소화하고 향후 대역폭 증가를 촉진합니다. 이 경우 서로 다른 섀시에 연결된 서로 다른 번들 멤버로 인해 디클러스터링 시 문제가 발생할 수 있습니다. 다음과 같은 접근 방식이 가능합니다.

섀시 1에 연결된 모든 인터페이스에 대해 새 번들을 만듭니다(Backup-DSC).
MCLAG(Multichassis Link Aggregation)를 소개합니다.

L2 도메인

액세스에서 두 독립형 섀시를 상호 연결하는 스위치가 없는 경우 클러스터를 분할하면 L2 도메인이 분리될 수 있습니다. 트래픽을 블랙홀(black hole)하지 않으려면 L2 도메인을 확장해야 합니다. 이는 이전 IRL에서 L2 로컬 연결을 구성하거나, 섀시 간 PW(Pseudo Wire)를 구성하거나, 다른 L2VPN(Layer 2 Virtual Private Network) 기술을 사용하는 경우에 가능합니다. 디클러스터링과 함께 브리지 도메인 토폴로지가 변경되므로, 원하는 L2VPN 기술을 선택할 때 가능한 루프 생성에 유의하십시오.

ASR9K 클러스터의 BVI(bridge-group virtual interface) 인터페이스에 대한 액세스에서 정적 라우팅은 이전 BVI IP 주소를 가상 IP로 사용하는 HSRP(Hot Standby Router Protocol) 기반 솔루션으로 전환될 가능성이 높습니다.

싱글 홈 서비스

싱글 홈 서비스는 디클러스터링 절차 동안 다운타임이 연장되었습니다.

관리 액세스

디클러스터링 프로세스에서 두 섀시가 격리되는 시간이 짧습니다. 적어도 예기치 않은 비대칭 라우팅을 방지하기 위해 BVI(Static Routing)에서 HSRP(Static Routing)로 전환할 때입니다.

자신을 잠그기 전에 콘솔 및 대역 외 관리 액세스 작동 방식을 확인해야 합니다.

ASR9000 Declustering 절차

초기 상태

초기 상태에서 섀시 0이(가) 활성 상태이고 섀시 1이(가) 백업이라고 가정합니다(간소화하기 위해). 실제 환경에서는 반대 방법일 수도 있고 섀시 0의 RSP1도 활성화할 수 있습니다.

asr9k-decluster-steady-state

유지 관리 기간(MW) 전 확인 목록

새 ASR9K 섀시 0 및 섀시 1 컨피그레이션을 준비합니다(Admin-Config + Config).
새로운 엔드 시스템 구성(CE(Customer Edge), FW(Firewall), 스위치 등)을 준비합니다.
새로운 코어 시스템 구성(P-노드, PE(Provider Edge) 노드, RR(Route Reflector) 등)을 준비합니다.
새 컨피그레이션을 확인하고 디바이스에 저장하고 원격으로 TFTP(Trivial File Transfer Protocol) 서버에 저장합니다.
MW를 실행하기 전/도중/후에 실행해야 하는 연결 가능성 테스트를 정의합니다.
IGP(Interior Gateway Protocol), BGP(Border Gateway Protocol), MPLS(Multiprotocol Label Switching), LDP(Label Distribution Protocol) 등의 제어 평면 출력을 비교 전/후에 수집합니다.
Cisco에서 사전 대응적 서비스 요청을 엽니다.

1단계. ASR9000 클러스터에 로그인하고 현재 컨피그레이션을 확인합니다

1. 기본 - 백업 섀시의 위치를 확인합니다. 이 예에서 기본 섀시는 0입니다.

RP/0/RSP0/CPU0:Cluster(admin)# show dsc

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

   Node        (     Seq)     Role     Serial# State

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

   0/RSP0/CPU0 ( 1279475)   ACTIVE FOX1441GPND PRIMARY-DSC <<< Primary DSC in Ch1

   0/RSP1/CPU0 ( 1223769)  STANDBY FOX1432GU2Z NON-DSC

   1/RSP0/CPU0 (       0)   ACTIVE FOX1432GU2Z BACKUP-DSC

   1/RSP1/CPU0 ( 1279584)  STANDBY FOX1441GPND NON-DSC

2. 모든 라인 카드(LC)/RSP가 "IOS XR RUN" 상태인지 확인합니다.

RP/0/RSP0/CPU0:Cluster# sh platform
Node            Type                      State            Config State
-----------------------------------------------------------------------------
0/RSP0/CPU0     A9K-RSP440-TR(Active)     IOS XR RUN       PWR,NSHUT,MON
0/RSP1/CPU0     A9K-RSP440-TR(Standby)    IOS XR RUN       PWR,NSHUT,MON
0/0/CPU0        A9K-MOD80-SE              IOS XR RUN       PWR,NSHUT,MON
0/0/0           A9K-MPA-4X10GE            OK               PWR,NSHUT,MON
0/0/1           A9K-MPA-20X1GE            OK               PWR,NSHUT,MON
0/1/CPU0        A9K-MOD80-TR              IOS XR RUN       PWR,NSHUT,MON
0/1/0           A9K-MPA-20X1GE            OK               PWR,NSHUT,MON
0/2/CPU0        A9K-40GE-E                IOS XR RUN       PWR,NSHUT,MON
1/RSP0/CPU0     A9K-RSP440-TR(Active)     IOS XR RUN       PWR,NSHUT,MON
1/RSP1/CPU0     A9K-RSP440-SE(Standby)    IOS XR RUN       PWR,NSHUT,MON
1/1/CPU0        A9K-MOD80-SE              IOS XR RUN       PWR,NSHUT,MON
1/1/1           A9K-MPA-2X10GE            OK               PWR,NSHUT,MON
1/2/CPU0        A9K-MOD80-SE              IOS XR RUN       PWR,NSHUT,MON
1/2/0           A9K-MPA-20X1GE            OK               PWR,NSHUT,MON
1/2/1           A9K-MPA-4X10GE            OK               PWR,NSHUT,MON

2단계. 스탠바이 섀시에 대한 최소 IRL 임계값 구성

스탠바이 섀시는 BACKUP-DSC가 있는 섀시이며, 서비스 중단 후 먼저 디스클러스터링됩니다. 이 예에서 BACKUP-DSC는 섀시 1에 있습니다.

이 구성에서는 IRL 수가 구성된 최소 임계값(이 경우 1) 아래로 떨어지면 지정된 랙(이 경우 백업 랙 - 섀시 1)의 모든 인터페이스가 종료됩니다.

RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge data min 1 spec rack 1
RP/0/RSP0/CPU0:Cluster(admin-config)# commit

3단계. 모든 IRL을 종료하고 섀시 1에서 오류 비활성화 인터페이스를 확인합니다.

1. 기존 IRL을 모두 종료합니다. 이 예에서는 두 섀시에서 수동 인터페이스가 종료되는 것을 볼 수 있습니다(액티브 Ten0/x/x/x 및 스탠바이 Ten1/x/x/x).

RP/0/RSP0/CPU0:Cluster(config)#

interface Ten0/x/x/x
shut
interface Ten0/x/x/x
 shut
[…]
interface Ten1/x/x/x
 shut
interface Ten1/x/x/x
shut
[…]

commit

asr9k-irl-down

2. 구성된 모든 IRL이 다운되었는지 확인합니다.

RP/0/RSP0/CPU0:Cluster# show nv edge data forwarding location

<location>의 예는 0/RSP0/CPU0입니다.

모든 IRL을 종료한 후 모든 외부 인터페이스를 error-disabled 상태로 이동하여 섀시 1을 데이터 플레인에서 완전히 격리해야 합니다.

3. 섀시 1의 모든 외부 인터페이스가 err-disabled 상태이고 모든 트래픽이 섀시 0을 통과하는지 확인합니다.

RP/0/RSP0/CPU0:Cluster# show error-disable

asr9k-decluster-irl-down-red

4단계. 모든 EOBC 링크 종료 및 상태 확인

asr9k-decluster-eobc-down

1. 모든 RSP에서 EOBC 링크를 종료합니다.

RP/0/RSP0/CPU0:Cluster(admin-config)#
nv edge control control-link disable 0 loc 0/RSP0/CPU0
nv edge control control-link disable 1 loc 0/RSP0/CPU0
nv edge control control-link disable 0 loc 1/RSP0/CPU0
nv edge control control-link disable 1 loc 1/RSP0/CPU0
nv edge control control-link disable 0 loc 0/RSP1/CPU0
nv edge control control-link disable 1 loc 0/RSP1/CPU0
nv edge control control-link disable 0 loc 1/RSP1/CPU0
nv edge control control-link disable 1 loc 1/RSP1/CPU0
commit

2. 모든 EOBC 링크가 다운되었는지 확인합니다.

RP/0/RSP0/CPU0:Cluster#
show nv edge control control-link-protocols location 0/RSP0/CPU0

이 단계를 마치면 클러스터 섀시는 제어 및 데이터 평면의 측면에서 서로 완전히 격리됩니다. 섀시 1의 모든 링크가 err-disable 상태입니다.

참고: 이제부터 컨피그레이션은 RSP 콘솔을 통해 섀시 1에서 수행해야 하며 로컬 섀시에만 영향을 미칩니다.

5단계. 섀시 1의 활성 RSP에 로그인하고 기존 컨피그레이션을 제거합니다.

섀시 1의 기존 컨피그레이션을 지웁니다.

RP/1/RSP0/CPU0:Cluster(config)# commit replace
RP/1/RSP0/CPU0:Cluster(admin-config)# commit replace

참고: 실행 중인 컨피그레이션의 컨피그레이션을 먼저 교체한 후에 관리자 실행 중인 컨피그레이션을 지워야 합니다. 이는 admin running-configuration에서 IRL 임계값을 제거하면 모든 외부 인터페이스가 "no shut"되기 때문입니다. 이 경우 중복된 라우터 ID 등으로 인해 문제가 발생할 수 있습니다.

6단계. 섀시 1을 ROMMON 모드로 부팅

1. ROMMON으로 부팅하도록 컨피그레이션 레지스터를 설정합니다.

RP/1/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all

2. 부팅 변수를 확인합니다.

RP/1/RSP0/CPU0:Cluster(admin)# show variables boot

3. 섀시 1의 두 RSP 모두 다시 로드합니다.

RP/1/RSP0/CPU0:Cluster# admin reload location all

이 단계를 마치면 일반적으로 섀시 1이 ROMMON으로 부팅됩니다.

7단계. 두 RSP의 ROMMON에서 섀시 1의 클러스터 변수 설정 해제

경고: 현장 기술자는 계속 진행하기 전에 모든 EOBC 링크를 제거해야 합니다.

팁: 시스템 클러스터 변수를 설정할 수 있는 대안도 있습니다. 섹션 부록 2: 시스템을 rommon으로 부팅하지 않고 클러스터 변수를 설정합니다.

1. 표준 절차에서는 콘솔 케이블을 섀시 1의 활성 RSP에 연결하고 클러스터 ROMMON 변수를 설정 해제하고 동기화해야 합니다.

unset CLUSTER_RACK_ID
sync

2. 구성 레지스터를 0x102로 다시 설정합니다.

confreg 0x102
reset

활성 RSP가 설정됩니다.

3. 콘솔 케이블을 섀시 1의 대기 RSP에 연결합니다. 클러스터의 모든 4개 RSP는 유지 관리 기간 동안 콘솔 액세스 권한을 가지는 것이 좋습니다.

참고: 이 단계에서 설명하는 작업은 섀시 1의 두 RSP 모두에서 수행해야 합니다. 활성 RSP를 먼저 부팅해야 합니다.

8단계. 섀시 1을 독립형 시스템으로 부팅하고 그에 따라 구성합니다

이상적으로 새 컨피그레이션 또는 여러 컨피그레이션 조각은 각 ASR9k 섀시에 저장되고 디클러스터링 이후에 로드됩니다. 올바른 컨피그레이션 구문은 이전에 Lab에서 테스트해야 합니다. 그렇지 않은 경우 먼저 콘솔 및 관리 인터페이스를 구성한 다음 VTY(Virtual Teletype)에 복사하여 붙여넣거나 TFTP 서버에서 원격으로 구성을 로드하여 섀시 1에 대한 컨피그레이션을 완료합니다.

참고: load config and commit 명령은 모든 인터페이스를 종료한 상태로 유지하여 제어된 서비스 램프업을 허용합니다. load config and commit replace는 컨피그레이션을 완전히 대체하고 인터페이스를 표시합니다. 따라서 로드 컨피그레이션을 사용하고 커밋하는 것이 좋습니다.

연결된 엔드 시스템(FW, 스위치 등) 및 코어 장치(P, PE, RR 등)의 구성을 섀시 1에 맞게 조정합니다.

9단계. 섀시 1에서 코어 서비스 복원

먼저 수동으로 코어 인터페이스의 잠금을 해제합니다.
LDP, Intermediate System to Intermediate System(IS-IS 또는 ISIS), BGP 인접성/피어링을 확인합니다.
라우팅 테이블을 확인하고 모든 접두사가 교환되었는지 확인합니다.

경고: 장애 조치로 이동하기 전에 ISIS OL(Overload) 비트, HSRP 지연, BGP 업데이트 지연 등과 같은 타이머에 유의하십시오!

asr9k-decluster-ch1-core

10단계. 장애 조치 - 섀시 0의 활성 RSP에 로그인하고 모든 인터페이스를 오류 비활성화 상태로 만듭니다.

주의: 다음 단계로 인해 서비스가 중단됩니다. 섀시 1 사우스바운드 인터페이스는 여전히 비활성화되어 있고 섀시 0은 격리되어 있습니다

asr9k-decluster-failover

기본 보류 시간은 180s(3x60)이며 BGP 통합의 최악의 경우를 나타냅니다. BGP Next-Hop Tracking과 같이 컨버전스 시간을 크게 단축하는 여러 설계 옵션 및 BGP 기능이 있습니다. Cisco IOS XR과 다르게 동작하는 코어에 서로 다른 서드파티 벤더가^있다고 가정할 경우, 결국 페일오버를 트리거하기 전에 섀시 0과 RR 간 또는 유사한 BGP 네이버의 소프트웨어 종료를 통해 수동으로 BGP 컨버전스를 가속화해야 합니다.

RP/0/RSP0/CPU0:Cluster(admin-config)# nv edge data minimum 1 specific rack 0
RP/0/RSP0/CPU0:Cluster(admin-config)# commit

모든 IRL이 중단되었으므로 섀시 0을 격리하고 모든 외부 인터페이스를 오류 비활성화 상태로 이동해야 합니다.

섀시 0의 모든 외부 인터페이스가 err-disabled 상태인지 확인합니다.

RP/0/RSP0/CPU0:Cluster# show error-disable

섀시 1이(가) 독립형 박스로 재구성되었으므로 오류가 비활성화된 인터페이스가 없어야 합니다. 섀시 1에서 유일하게 해야 할 일은 에지에서 인터페이스를 불러오는 것입니다.

11단계. 섀시 1의 South-Side 복원

1. 모든 액세스 인터페이스를 종료하지 않습니다.

asr9k-decluster-restore-south-ch1

일단 인터커넥트 링크(이전 IRL)를 종료한 상태로 유지합니다.

2. IGP 및 BGP 인접성/피어링/DB를 확인합니다. IGP와 BGP가 통합되는 동안 원격 PE의 ping에서 트래픽 손실이 발생할 수 있습니다.

12단계. 섀시 0의 활성 RSP에 로그인하고 컨피그레이션을 제거합니다.

활성 섀시의 기존 컨피그레이션을 지웁니다.

RP/0/RSP0/CPU0:Cluster(config)# commit replace
RP/0/RSP0/CPU0:Cluster(admin-config)# commit replace

참고: 먼저 running-configuration의 컨피그레이션을 교체하고, 이후에만 admin running-configuration을 지워야 합니다. 이는 admin running-configuration에서 IRL 임계값을 제거해도 모든 외부 인터페이스가 종료되지 않기 때문입니다. 이 경우 중복된 라우터 ID 등으로 인해 문제가 발생할 수 있습니다.

13단계. 섀시 0을(를) ROMMON으로 부팅

1. ROMMON으로 부팅하도록 컨피그레이션 레지스터를 설정합니다.

RP/0/RSP0/CPU0:Cluster(admin)# config-register boot-mode rom-monitor location all

2. 부팅 변수를 확인합니다.

RP/0/RSP0/CPU0:Cluster# admin show variables boot

3. 대기 섀시의 두 RSP 모두 다시 로드합니다.

RP/0/RSP0/CPU0:Cluster# admin reload location all

이 단계 후에는 일반적으로 섀시 0이 ROMMON 모드로 부팅합니다.

14단계. 두 RSP의 ROMMON에서 섀시 0의 클러스터 변수 설정 해제

1. 콘솔 케이블을 섀시 0의 활성 RSP에 연결합니다.

2. 클러스터 ROMMON 변수 설정 해제 및 동기화:

unset CLUSTER_RACK_ID
sync

3. 컨피그레이션 레지스터를 0x102로 재설정합니다.

confreg 0x102
reset

활성 RSP가 설정됩니다.

4. 콘솔 케이블을 섀시 0의 대기 RSP에 연결합니다.

참고: 이 단계에서 설명하는 작업은 섀시 1의 두 RSP 모두에서 수행해야 합니다. 활성 RSP를 먼저 부팅해야 합니다.

15단계. 섀시 0을 독립형 시스템으로 부팅하고 그에 따라 구성합니다

이상적으로 새 컨피그레이션 또는 여러 컨피그레이션 조각은 각 ASR9k 섀시에 저장되고 디클러스터링 이후에 로드됩니다. 올바른 컨피그레이션 구문은 이전에 Lab에서 테스트해야 합니다. 그렇지 않은 경우 VTY(Copy & Paste)를 통해 섀시 0의 컨피그레이션을 완료하거나 TFTP 서버에서 원격으로 컨피그레이션을 로드하기 전에 먼저 콘솔 및 관리 인터페이스를 구성합니다.

연결된 엔드 시스템(FW, 스위치 등) 및 코어 장치(P, PE, RR 등)의 구성을 섀시 0에 맞게 조정합니다.

16단계. 섀시 0의 코어 서비스 복원

먼저 수동으로 코어 인터페이스의 잠금을 해제합니다.
LDP, ISIS, BGP 인접성/피어링을 확인합니다.
라우팅 테이블을 확인하고 모든 접두사가 교환되었는지 확인합니다.

경고: 장애 조치로 이동하기 전에 ISIS OL-Bit, HSRP 지연, BGP 업데이트 지연 등의 타이머에 유의하십시오!

asr9k-decluster-ch0-core

17단계. 섀시 0의 남쪽을 복원합니다.