이 페이지의 내용
GR(Graceful Routing Engine Switchover) 구성
요약 다음 단계와 예제를 통해 GRES(Graceful Routing Engine Switchover)를 구성하는 방법을 알아보십시오.
백업 라우터 구성이 있는 라우터에 대한 요구 사항
라우팅 엔진 구성에 명령문 또는 명령 inet6-backup-router
문이 포함된 backup-router
경우, 명령문을 사용하여 destination
백업 라우터에 대한 서브넷 주소 또는 여러 서브넷 주소를 지정할 수도 있습니다. 계층 수준에서 백업 라우팅 엔진을 위한 대상 서브넷을 [edit system (backup-router | inet6-backup-router) address]
포함합니다. 이 요구 사항은 백업 라우터 또는 inet6-backup-router
문을 포함하는 TX Matrix 라우터에 연결된 모든 T640 라우터에도 적용됩니다.
여러 정적 경로가 관리 이더넷 인터페이스에서 게이트웨이를 가리키는 백업 라우터 구성이 있는 경우, 고정 경로보다 더 구체적인 접두사를 구성하거나 계층 수준에서 retain 플래그 [edit routing-options static route]
를 포함해야 합니다.
예를 들어, 관리 목적으로 관리 이더넷 인터페이스에서 정적 경로 172.16.0.0/12를 구성하는 경우 다음과 같이 백업 라우터 구성을 지정해야 합니다.
backup-router 172.29.201.62 destination [172.16.0.0/13 172.16.128.0/13]
또한보십시오
GR(Graceful Routing Engine Switchover) 활성화
기본적으로 GRES(Graceful Routing Engine Switchover)는 비활성화되어 있습니다. GRES를 [edit chassis redundancy]
구성하려면 계층 수준에서 문을 포함합니다graceful-switchover
.
[edit chassis redundancy] graceful-switchover;
GRES를 활성화하면 명령줄 인터페이스(CLI)가 사용 중인 라우팅 엔진을 나타냅니다. 예를 들어:
{master} [edit] user@host#
GRES를 비활성화하려면 계층 수준에서 문을 삭제 graceful-switchover
하십시오 [edit chassis redundancy]
.
Graceful Restart로 Graceful Routing Engine 스위치오버 구성
GRES를 Graceful Restart와 함께 사용할 때 라우팅 엔진과 이웃 피어 '도우미' 라우터 간의 인접성이 시간 초과되면 Graceful Restart 프로토콜 확장은 피어 '도우미' 라우터에 임박한 재시작을 알릴 수 없습니다. 그런 다음 Graceful Restart가 중지되고 트래픽이 중단될 수 있습니다.
이러한 인접성을 유지하려면 IS-IS 프로토콜의 홀드 타임 을 기본값인 27초에서 40초 이상의 값으로 변경합니다.
라우팅 엔진 구성 동기화
새로 삽입된 백업 라우팅 엔진은 구성을 기본 라우팅 엔진 구성과 자동으로 동기화합니다.
GRES를 구성할 때 기본 라우팅 엔진이 이미 실행된 후 백업 라우팅 엔진을 온라인으로 가져올 수 있습니다. 두 라우팅 엔진을 동시에 시작할 필요는 없습니다.
그레이스풀 라우팅 엔진 전환을 활성화해야만 기본 라우팅 엔진의 실행 중인 Junos OS 버전을 백업 라우팅 엔진에 복사할 수 있습니다.
시스템이 ISSU 상태인 경우, 기본 라우터 엔진의 실행 중인 Junos OS 버전을 복사할 수 없습니다.
Junos OS 릴리스 14.1부터 계층 수준에서 명령문을 포함 events CHASSISD_SNMP_TRAP7 하여 기본 라우팅 엔진 구성과 백업 라우팅 엔진의 자동 동기화를 활성화할 수 있습니다 [edit event-options policy policy-name] .
CHASSISD_SNMP_TRAP7는 섀시 프로세스(섀시)가 7개의 표시된 인수-값 쌍으로 SNMP(Simple Network Management Protocol) 트랩을 생성한다는 시스템 이벤트 로깅 메시지입니다. 기본 라우팅 엔진에서 백업 라우팅 엔진으로의 자동 동기화를 트리거하는 이벤트 스크립트의 예는 다음과 같습니다.
[edit event-options] policy UPGRADE-BACKUPRE { events CHASSISD_SNMP_TRAP7; attributes-match { CHASSISD_SNMP_TRAP7.value5 matches "Routing Engine"; CHASSISD_SNMP_TRAP7.trap matches "Fru Online"; CHASSISD_SNMP_TRAP7.argument5 matches jnxFruName; } then { event-script auto-image-upgrade.slax { arguments { trap "{$$.trap}"; value5 "{$$.value5}"; argument5 "{$$.argument5}"; } } } } event-script { file auto-image-upgrade.slax; }
이 이벤트를 수신한 후 기본 라우터 엔진의 이벤트 정책이 트리거되고 경로에서 /var/sw/pkg 사용 가능한 이미지가 백업 라우터 엔진 업그레이드로 푸시됩니다. 스크립트 실행 중에 이미지는 백업 라우팅 엔진의 /var/sw/pkg 경로에 복사됩니다.
경로에서 /var/sw/pkg 이미지를 사용할 수 없는 경우 스크립트는 적절한 syslog 메시지와 함께 종료됩니다.
라우팅 엔진이 Junos OS 릴리스 13.2 이상에서 실행되는 경우, Junos 자동화 스크립트가 자동으로 동기화됩니다.
기본 라우터 엔진이 재부팅된 후 에서 /usr/libexec/scripts/event/auto-image-upgrade.slax 사용할 수 있는 이벤트 스크립트를 에 복사 /var/db/scripts/event path해야 합니다.
향상된 가입자 관리를 사용하는 MX 시리즈 라우터의 경우, GR(Graceful Routing Engine) 전환이 수행되면 새로운 백업 라우팅 엔진(이전의 기본 라우팅 엔진)이 재부팅됩니다. 이 콜드 재시작은 백업 라우팅 엔진 상태를 새로운 기본 라우팅 엔진의 상태와 재동기화하여 전환 중에 발생할 수 있는 상태의 불일치를 방지합니다.
그레이스풀 라우팅 엔진 스위치오버 작동 검증
백업 라우팅 엔진에서 GRES가 활성화되었는지 확인하려면 명령을 실행합니다 show system switchover
. 명령의 출력이 Graceful Switchover 필드가 On으로 설정되었음을 나타내면 GRES가 작동합니다. 라우팅 엔진 간의 커널 데이터베이스 및 구성 데이터베이스 동기화 상태도 제공됩니다. 예를 들어:
Graceful switchover: On Configuration database: Ready Kernel database: Ready Peer state: Steady state
백업 라우팅 엔진에서 명령을 실행해야 show system switchover
합니다. 이 명령은 기본 라우팅 엔진에서 지원되지 않습니다.
명령에 대한 show system switchover
자세한 내용은 CLI 탐색기를 참조하십시오.
Virtual Chassis에서 GR(Graceful Routing Engine Switchover) 구성
Virtual Chassis에서는 하나의 멤버 스위치에 기본 역할이 할당되고 기본 라우팅 엔진이 있습니다. 다른 멤버 스위치에는 백업 역할이 할당되며 백업 라우팅 엔진이 있습니다. GRES(Graceful Routing Engine Switchover)를 사용하면 버추얼 섀시 구성의 기본 및 백업 라우팅 엔진이 중단 없이 무중단 페일오버 솔루션인 패킷 포워딩으로 기본 엔진에서 백업으로 전환할 수 있습니다. GR(Graceful Routing Engine) 전환을 구성하면 백업 라우팅 엔진이 기본 라우팅 엔진과 자동으로 동기화되어 커널 상태 정보와 포워딩 상태를 보존합니다.
GRES(Graceful Routing Engine Switchover)를 사용하도록 Virtual Chassis 구성을 설정하려면:
구성을 커밋합니다.
명령을 사용하여 commit synchronize
다중 멤버 Virtual Chassis에 대한 구성 변경 사항을 저장하는 것이 좋습니다.
또한보십시오
느린 디스크의 경우 GR(Graceful Routing Engine) 전환 방지
예기치 않은 느린 디스크 액세스는 결함 또는 불량 섹터와 같은 다양한 이유로 발생할 수 있으며, 이로 인해 라우팅 프로세스(rpd)와 같은 프로세스의 정상적인 작동이 지연될 수 있습니다. 결국 라우터의 성능에 영향을 미칩니다. 이러한 상황에서는 일반적인 장애 조치(failover) 메커니즘이 트리거되는 데 시간이 더 오래 걸릴 수 있습니다.
주니퍼 네트웍스는 이러한 딜레마를 해결하기 위해 디스크 모니터링 데몬을 도입했습니다. 데몬은 느린 디스크 액세스를 감지하고 장애 조치(failover)를 시작합니다. 페일오버는 트래픽 영향을 최소화하고 백로그 정리를 위해 원래 기본 라우팅 엔진의 부하를 완화할 수 있습니다.
그러나 장애 조치(failover)를 원하지 않는 경우가 있습니다. 라우팅 토폴로지에 대한 일련의 업데이트로 이어질 수 있는 대규모 변경 또는 사소한 변경을 커밋할 수 있습니다. 이러한 활동으로 인해 광범위한 디스크 액세스 지연이 발생하여 장애 조치(failover)가 트리거될 수 있습니다. 이와 같이 페일오버를 트리거하지 않으려는 디스크 액세스 지연이 예상되는 경우 구성 명령을 설정하여 페일오버가 chassis redundancy failover not-on-disk-underperform
발생하지 않도록 선택할 수 있습니다. 또 다른 방법은 명령을 설정하여 디스크 모니터링 데몬을 완전히 비활성화하는 것입니다 system processes gstatd disable
.
라우팅 엔진에서 느린 디스크의 경우 페일오버를 방지하려면:
[edit chassis redundancy failover]
옵션을 설정합니다.
[edit] user@host# set chassis redundancy failover not-on-disk-underperform
또한보십시오
로컬 통계 재설정
GRES(Graceful Routing Engine) 전환을 활성화하면 기본 라우팅 엔진 구성이 복사되어 백업 라우팅 엔진에 로드됩니다. 사용자 파일, 어카운팅 정보 및 추적 옵션 정보는 백업 라우팅 엔진에 복제되지 않습니다.
GR(Graceful Routing Engine) 전환이 발생하면 프로세스 통계 및 네트워킹 통계와 같은 로컬 통계가 프로세스가 처음 온라인 상태가 된 시점부터 누적 값으로 표시됩니다. 기본 라우팅 엔진의 프로세스는 백업 라우팅 엔진의 프로세스와 다른 시간에 시작할 수 있기 때문에 동일한 프로세스에 대한 두 라우팅 엔진의 통계는 다를 수 있습니다. graceful 라우팅 엔진 전환 후에는 clear interface statistics (interface-name | all) 명령을 발행하여 로컬 통계에 대한 누적 값을 재설정하는 것이 좋습니다. 포워딩 통계는 GR(Graceful Routing Engine) 전환의 영향을 받지 않습니다.
clear 명령을 사용하여 통계 및 프로토콜 데이터베이스 정보를 지우는 방법에 대한 정보는 CLI Explorer를 참조하십시오.
clear firewall 명령은 GR(Graceful Routing Engine) 전환을 위해 활성화된 백업 라우팅 엔진에서 라우팅 엔진 필터 카운터를 지우는 데 사용할 수 없습니다.
또한보십시오
예: GRES의 Graceful Restart IS-IS 구성
이 예에서는 Graceful Restart와 함께 GRES(Graceful Routing Engine Switchover)를 성공적으로 활성화하기 위해 IS-IS(Middle System to Intermediate System) IGP(Interior Gateway Protocol)를 사용하여 라우팅 엔진의 Graceful Restart 프로토콜 확장을 구성하는 방법을 보여줍니다.
요구 사항
GRES는 다음 중 하나와 결합될 때 기본 라우팅 엔진에 장애가 발생할 경우 네트워크 트래픽 중단을 방지합니다.
그레이스풀 리스타트(Graceful Restart)
NSR(Nonstop Active Routing)
여기의 지침에 따라 GRES(Graceful Restart)를 구성하기 전에 기본적으로 비활성화되어 있는 GRES를 활성화해야 합니다. 자세한 내용은 GR(Graceful Routing Engine Switchover) 구성을 참조하십시오.
개요
라우팅 엔진과 이웃 피어 '도우미' 라우터 간의 인접성이 시간 초과되면 그레이스풀 재시작 프로토콜 확장은 피어 '도우미' 라우터에 임박한 재시작을 알릴 수 없습니다. 그런 다음 Graceful Restart가 중지되고 트래픽이 중단될 수 있습니다.
이러한 인접성을 유지하려면 IS-IS 프로토콜의 홀드 타임을 기본값인 27초에서 40초 이상의 값으로 변경합니다.
시스템이 IS-IS 대신 OSPF(Open Shortest Pathway First) 프로토콜을 사용하는 경우, 구성 정보는 예: OSPF 타이머 구성을 참조하십시오.
구성
CLI 빠른 구성
홀드 타임을 빠르게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣고, 줄 바꿈을 제거하고, 네트워크 구성과 일치시키는 데 필요한 세부 사항을 변경한 다음, 표시된 다양한 계층 수준에서 명령을 복사하여 CLI에 붙여넣습니다.
각 인터페이스는 라우팅 디바이스가 작동하는 각 수준에 대한 값을 사용하여 개별적으로 설정해야 합니다. 이 예에서는 최소 권장 값인 41초가 사용되며, 시스템의 크기와 트래픽에 따라 더 높은 값이 필요할 수 있습니다.
수준 1과 수준 2는 서로 다른 값으로 설정할 수 있습니다.
[프로토콜 편집]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[논리 시스템 논리 시스템 이름 편집}
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[논리 시스템 논리 시스템 이름 라우팅 인스턴스 라우팅 인스턴스 이름 편집]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
[routing-instances routing-instance-name 편집]
set protocols isis interface ge-1/2/0 level 1 hold-time 41 set protocols isis interface ge-1/2/0 level 2 hold-time 41
Graceful Restart를 위한 IS-IS 프로토콜 보류 시간 구성
단계별 절차
Graceful Restart를 위한 IS-IS 홀드 타임 구성:
인터페이스를 찾거나 설정합니다.
set protocols isis interface interface-name
네트워크 수준과 해당 수준의 보류 시간(초)을 설정합니다.
set protocols isis interface interface-name level 1 hold-time 41
라우팅 디바이스가 하나 이상의 레벨에서 작동하는 경우, 다른 레벨에 대한 값을 설정합니다.
set protocols isis interface interface-name level 2 hold-time 41
라우팅 디바이스 구성을 완료하면 구성을 커밋합니다.
참고:공유 네트워크의 모든 라우팅 디바이스에서 전체 구성을 반복합니다.
결과
확인
Graceful Restart를 위한 IS-IS 프로토콜 보류 시간 확인
목적
IS-IS 프로토콜 홀드 타임이 41초 이상으로 설정되어 GR(Graceful Restart)이 활성화되었는지 확인합니다.
작업
운영 모드에서 명령을 입력하여 show isis adjacency brief
구성을 확인합니다. 출력에 의도한 구성이 표시되지 않으면 이 예의 지침을 반복하여 구성을 수정하십시오.
의미
IS-IS 프로토콜 홀드 타임 값이 충분히 높으면 시스템 구성을 다시 시작할 수 있으며 라우팅 엔진에 장애가 발생하더라도 트래픽이 계속됩니다.
변경 내역 테이블
기능 지원은 사용 중인 플랫폼 및 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.