GR(Graceful Routing Switchover) 이해하기

그레이스풀 라우팅 엔진 스위치오버 개념

Junos OS 및 Junos OS Evolved의 GRES(Graceful 라우팅 엔진 Switchover) 기능을 사용하면 중복 라우팅 엔진이 있는 디바이스에서 하나의 라우팅 엔진에 장애가 발생하더라도 패킷을 계속 전달할 수 있습니다. GRES는 인터페이스 및 커널 정보를 보존하며 트래픽이 중단되지 않습니다. 그러나 GRES는 컨트롤 플레인을 보존하지 않습니다.

인접 디바이스는 디바이스가 재시작되었음을 감지하고 개별 라우팅 프로토콜 사양에 규정된 방식으로 이벤트에 대응합니다.

전환 중에 라우팅을 유지하려면 GRES를 다음 중 하나와 결합해야 합니다.

• Graceful Restart 프로토콜 확장

• NSR(Nonstop Active Routing)

기본 라우팅 엔진에 대한 모든 업데이트는 발생하는 즉시 백업 라우팅 엔진에 복제됩니다.

메모:

동기화 요구 사항 및 논리로 인해 NSR/GRES 성능은 시스템에서 가장 느린 라우팅 엔진에 의해 제한됩니다.

다음과 같은 경우 기본 역할이 백업 라우팅 엔진으로 전환됩니다.

• 기본 라우팅 엔진 커널이 작동을 멈춥니다.

• 기본 라우팅 엔진에 하드웨어 장애가 발생합니다.

• 관리자가 수동 전환을 시작합니다.

메모:

전환 중에 라우팅 프로토콜 상태 정보를 신속하게 복원하거나 보존하려면 GRES를 각각 Graceful Restart 또는 Nonstop Active Routing과 결합해야 합니다. Graceful Restart에 대한 자세한 내용은 Graceful Restart 개념을 참조하십시오. 무중단 활성 라우팅에 대한 자세한 내용은 무중단 활성 라우팅 개념을 참조하십시오.

백업 라우팅 엔진이 2초 후 기본 라우팅 엔진에서 keepalive를 수신하지 않으면 기본 라우팅 엔진에 장애가 발생한 것으로 판단합니다. 주요 역할을 맡습니다.

패킷 포워딩 엔진:

• 기존 기본 라우팅 엔진과의 원활한 연결 해제

• 새 기본 라우팅 엔진에 다시 연결합니다

• 재부팅하지 않음

• 트래픽을 방해하지 않습니다.

그러면 새로운 기본 라우팅 엔진과 패킷 포워딩 엔진이 동기화됩니다. 새로운 기본 라우팅 엔진은 패킷 포워딩 엔진 상태가 최신이 아님을 감지하면 상태 업데이트 메시지를 다시 보냅니다.

다음과 같은 GRES 동작, 권장 사항 또는 요구 사항을 확인합니다.

• Junos OS 릴리스 12.2부터 재시작 디바이스와 인접 피어 'helper' 디바이스 간의 인접성이 시간 초과되면 Graceful restart 프로토콜 확장은 피어 'helper' 디바이스에 임박한 재시작을 알릴 수 없습니다. 그러면 Graceful Restart가 중단되어 트래픽 중단을 일으킬 수 있습니다.

  이러한 인접성을 유지하려면 IS-IS 프로토콜의 을(를 hold-time ) 기본값인 27초에서 40초 이상의 값으로 변경하십시오.

• 연속적인 라우팅 엔진 전환 이벤트는 두 라우팅 엔진이 모두 작동한 후 최소 240초(4분) 간격이어야 합니다.

  디바이스에 다음과 유사한 경고 메시지가 표시되는 경우:

  그런 다음 전환을 시도하지 마십시오. 전환을 진행하기로 선택한 경우, 디바이스는 Graceful 전환에 준비되지 않은 패킷 전달 엔진만 재설정합니다. 어떤 FPC도 자발적으로 다시 시작해서는 안 됩니다. 경고가 더 이상 나타나지 않을 때까지 기다렸다가 전환을 진행하는 것이 좋습니다.

• 다음을 권장 하지 않습니다 .

  • 디바이스에서 GRES가 활성화되면 백업 라우팅 엔진에서 커밋 작업을 수행합니다.

  • 모든 시나리오에서 백업 라우팅 엔진에서 GRES를 활성화합니다.

그림 1 은 그레이스풀 라우팅 라우팅 엔진 전환의 시스템 아키텍처와 라우팅 플랫폼이 전환을 준비하기 위해 따르는 프로세스를 보여줍니다.

메모:

다음 두 가지를 모두 실행하여 GRES 준비 상태를 확인합니다.

• request chassis routing-engine master switch check 기본 라우팅 엔진의 명령

• show system switchover 백업 라우팅 엔진의 명령

GRES를 위한 전환 준비 프로세스는 다음과 같습니다.

1. 기본 라우팅 엔진이 시작됩니다.

2. 라우팅 플랫폼 프로세스(예: 섀시 프로세스 [chassisd])가 시작됩니다.

3. 패킷 포워딩 엔진이 시작되고 기본 라우팅 엔진에 연결됩니다.

4. 모든 상태 정보가 시스템에서 업데이트됩니다.

5. 백업 라우팅 엔진이 시작됩니다.

6. 시스템은 GRES가 활성화되었는지 여부를 결정합니다.

7. 커널 동기화 프로세스(ksyncd)는 백업 라우팅 엔진과 기본 라우팅 엔진을 동기화합니다.

8. ksyncd가 동기화를 완료하면 모든 상태 정보와 포워딩 테이블이 업데이트됩니다.

그림 2 는 라우팅(또는 스위칭) 플랫폼에 대한 전환의 영향을 보여줍니다.

전환 프로세스는 다음 단계로 구성됩니다.

1. 기본 라우팅 엔진의 keepalive가 손실되면 시스템은 백업 라우팅 엔진으로 graceful 전환됩니다.

2. 패킷 포워딩 엔진은 백업 라우팅 엔진에 연결되며, 이 엔진은 새로운 기본이 됩니다.

3. GRES에 속하지 않는 라우팅 플랫폼 프로세스(예: 라우팅 프로토콜 프로세스 rpd)가 다시 시작됩니다.

4. 전환 시점부터 학습된 상태 정보가 시스템에서 업데이트됩니다.

5. 구성된 경우, GR(Graceful Restart ) 프로토콜 확장은 이웃 피어 도우미 디바이스에서 라우팅 정보를 수집하고 복원합니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.

플랫폼별 GRES 동작 섹션에서 플랫폼과 관련된 참고 사항을 검토하십시오.

라우팅 엔진 전환의 효과

표 1 에는 다음과 같은 각기 다른 기능이 활성화되었을 때 라우팅 엔진 전환의 효과가 설명되어 있습니다.

• 고가용성 기능 없음

• 그레이스풀 라우팅 엔진 스위치오버

• 그레이스풀 리스타트(Graceful Restart)

• NSR(Nonstop Active Routing)

표 1: 라우팅 엔진 전환의 효과

특징	혜택	고려 사항
듀얼 라우팅 엔진 전용(활성화된 기능 없음)	새로운 기본 라우팅 엔진으로의 전환이 완료되면 라우팅 컨버전스가 발생하고 트래픽이 재개됩니다.	모든 물리적 인터페이스가 오프라인으로 전환됩니다. 패킷 전달 엔진이 다시 시작됩니다. 백업 라우팅 엔진이 라우팅 프로토콜 프로세스(rpd)를 다시 시작합니다. 모든 하드웨어 및 인터페이스는 새로운 기본 라우팅 엔진에 의해 검색됩니다. 전환에는 몇 분 정도 걸립니다. 디바이스의 모든 인접성은 물리적(인터페이스 알람) 및 라우팅(토폴로지) 변경을 인식합니다.
GRES 지원	전환 중에는 인터페이스 및 커널 정보가 보존됩니다. 패킷 전달 엔진이 다시 시작되지 않으므로 전환 속도가 더 빠릅니다.	새로운 기본 라우팅 엔진은 라우팅 프로토콜 프로세스(rpd)를 다시 시작합니다. 모든 하드웨어 및 인터페이스는 웜 재시작과 유사한 프로세스를 통해 획득됩니다. 모든 인접 항목은 디바이스의 상태 변경을 인식합니다.
GRES 및 NSR 지원	전환 중에는 트래픽이 중단되지 않습니다. 인터페이스 및 커널 정보는 보존됩니다.	지원되지 않는 프로토콜은 각 프로토콜에 내재된 정상적인 복구 메커니즘을 사용하여 새로 고쳐야 합니다.
GRES 및 Graceful Restart 사용	전환 중에는 트래픽이 중단되지 않습니다. 인터페이스 및 커널 정보는 보존됩니다. Graceful Restart 프로토콜 확장은 이웃 디바이스에서 라우팅 정보를 빠르게 수집하고 복원합니다.	neighbor는 Graceful Restart를 지원해야 하며 대기 간격이 필요합니다. 라우팅 프로토콜 프로세스(rpd)가 다시 시작됩니다. 특정 프로토콜의 경우, 네트워크의 중대한 변화로 인해 Graceful Restart가 중단될 수 있습니다. Junos OS 릴리스 12.2부터 재시작 디바이스와 인접 피어 'helper' 디바이스 간의 인접성이 시간 초과되면 Graceful Restart가 중단되고 트래픽 중단이 발생할 수 있습니다.

어그리게이션 서비스 인터페이스에서의 그레이스풀 라우팅 엔진 스위치

GRES(Graceful 라우팅 엔진 Switchover)가 작동 모드 명령에 의해 트리거되는 경우 디바이스는 어그리게이션 서비스 인터페이스(ASI)의 상태를 보존하지 않습니다. 예를 들어:

그러나 CLI 커밋 또는 FPC 재시작 또는 충돌에 의해 GRES가 트리거되면 백업 라우팅 엔진이 ASI 상태를 업데이트합니다. 예를 들어:

또는:

Graceful 라우팅 엔진 Switchover 플랫폼 지원

Graceful 라우팅 엔진 스위치오버를 사용하려면 시스템이 다음과 같은 최소 요구 사항을 충족해야 합니다.

• MX960 라우터—Junos OS 릴리스 8.3 이상

• MX480 라우터—Junos OS 릴리스 8.4 이상(8.4R2 권장)

• MX240 라우터—Junos OS 릴리스 9.0 이상

• PTX5000 라우터—Junos OS 릴리스 12.1X48 이상

• 듀얼 라우팅 엔진 또는 Virtual Chassis 탑재 EX 시리즈 스위치 — EX 시리즈 스위치용 Junos OS 릴리즈 9.2 이상

• Virtual Chassis의 QFX 시리즈 스위치 —QFX 시리즈용 Junos OS 릴리즈 13.2 이상

• Virtual Chassis Fabric의 EX 시리즈 또는 QFX 시리즈 스위치 —EX 시리즈 및 QFX 시리즈 스위치용 Junos OS 릴리즈 13.2X51-D20 이상

GR(Graceful 라우팅 엔진 스위치오버) 지원에 대한 자세한 내용은 다음 섹션을 참조하십시오.

Graceful 라우팅 엔진 전환 기능 지원

Graceful 라우팅 엔진 스위치오버는 릴리스 5.7 이상에서 대부분의 Junos OS 기능을 지원합니다. 특정 Junos OS 기능에는 특정 버전의 Junos OS가 필요합니다. 표 2를 참조하십시오.

표 2: Graceful 라우팅 엔진 전환 기능 지원

신청	Junos OS 릴리스
LACP(Link Aggregation Control Protocol)를 사용하는 어그리게이션 이더넷 인터페이스 및 어그리게이션 SONET 인터페이스	6.2
ATM(Asynchronous Transfer Mode) VC(Virtual Circuit)	6.2
논리적 시스템 메모: Junos OS 릴리스 9.3 이상에서는 논리적 라우터 기능의 이름이 논리적 시스템으로 변경되었습니다.	6.3
멀티 캐스트	6.4(TX Matrix 라우터의 경우 7.0)
멀티링크 포인트-투-포인트 프로토콜(MLPPP) 및 멀티링크 프레임 릴레이(MLFR)	7.0
자동 보호 스위칭(APS) - 현재 활성 인터페이스(지정된 작업 인터페이스 또는 지정된 보호 인터페이스)는 라우팅 엔진 전환 중에 활성 인터페이스로 유지됩니다.	7.4
Point-to-multipoint Multiprotocol Label Switching MPLS LSP(전송 전용)	7.4
압축된 실시간 전송 프로토콜(CRTP)	7.6
가상 프라이빗 LAN 서비스(VPLS)	8.2
IEEE 802.3ah에 의해 정의된 이더넷 OAM(Operation, Administration, and Management)	8.5
확장 DHCP 릴레이 에이전트	8.5
IEEE 802.1ag에 의해 정의된 이더넷 OAM	9.0
멀티서비스의 패킷 게이트웨이 제어 프로토콜(PGCP) 프로세스(pgcpd) T640 라우터의 500 PIC입니다.	9.0
가입자 액세스	9.4
레이어 2 서킷 및 LDP 기반 VPLS 유사 회선 이중화 구성	9.6

다음 제약 조건은 Graceful 라우팅 엔진 전환 기능 지원에 적용됩니다.

• 그레이스풀 라우팅 엔진 스위치오버 및 어그리게이션 이더넷 인터페이스가 동일한 시스템에서 구성된 경우, 어그리게이션 이더넷 인터페이스에 고속 폴링 LACP를 구성해서는 안 됩니다. 고속 폴링이 구성되면 라우팅 엔진 기본 역할 전환 중 원격 엔드에서 LACP 폴링 시간이 초과됩니다. LACP 폴링 시간이 초과되면 어그리게이션 링크 및 인터페이스가 비활성화됩니다. 라우팅 엔진 주요 역할 변경은 표준 및 저속 LACP 폴링이 절차 중에 시간 초과되지 않을 만큼 충분히 빠릅니다.

  메모:

  MACSec 세션은 Graceful 라우팅 엔진 전환 시 플랩됩니다.

  Junos OS 릴리스 13.2부터 GR(Graceful 라우팅 엔진 스위치오버)이 발생해도 VRRP 상태는 변경되지 않습니다. VRRP는 PPM 위임이 활성화된 경우(기본)에만 그레이스풀 라우팅 엔진 스위치오버에 의해 지원됩니다.

그레이스풀 라우팅 엔진 스위치오버 및 가입자 액세스

그레이스풀 라우팅 엔진 스위치오버는 현재 동적 DHCP 및 동적 PPPoE 가입자 액세스와 직접 관련된 대부분의 기능을 지원합니다. 또한 Graceful 라우팅 엔진 스위치오버는 DHCP 액세스 모델 및 가입자 액세스에 사용되는 PPPoE 액세스 모델에 대한 통합 ISSU(in-service software upgrade)를 지원합니다.

메모:

가입자 관리를 위해 graceful 라우팅 엔진 switchover가 활성화되면, 라우터의 모든 라우팅 엔진은 안정적인 운영을 위해 동일한 양의 DRAM을 가져야 합니다.

Graceful 라우팅 엔진 Switchover PIC 지원

그레이스풀 라우팅 엔진 스위치오버는 이 섹션에 나열된 서비스 PIC를 제외한 대부분의 PIC에서 지원됩니다. PIC는 적절한 버전의 Junos OS를 실행하는 지원되는 라우팅 플랫폼에 있어야 합니다. FPC 유형, FPC/PIC 호환성 및 FPC가 특정 PIC를 지원한 초기 Junos OS 릴리스에 대한 자세한 내용은 라우터 플랫폼의 PIC 가이드를 참조하십시오.

서비스 PIC에 대한 그레이스풀 라우팅 엔진 전환 지원에는 다음과 같은 제약 조건이 적용됩니다.

• Adaptive Services, Multiservices 및 Tunnel Services PIC가 구성된 라우터의 계층 수준에서 문을 [edit chassis redundancy] 포함 graceful-switchover 하고 구성을 성공적으로 커밋할 수 있습니다. 그러나 멀티서비스 PIC의 레이어 2 서비스 패키지와 확장 프로바이더 및 SDK 애플리케이션을 제외한 이러한 PIC의 모든 서비스는 전환 중에 재설정됩니다.

• Graceful 라우팅 엔진 스위치오버는 모니터링 서비스 PIC 또는 멀티링크 서비스 PIC에서 지원되지 않습니다. 이러한 PIC 유형 중 하나가 구성된 라우터의 계층 수준에서 문을 [edit chassis redundancy] 포함 graceful-switchover 하고 명령을 실행 commit 하면 커밋이 실패합니다.

• Graceful 라우팅 엔진 스위치오버는 모니터링 서비스 애플리케이션을 위해 구성된 멀티서비스 400 PIC에서 지원되지 않습니다. 명령문을 포함 graceful-switchover 하면 커밋이 실패합니다.

메모:

지원되지 않는 PIC가 온라인이면 Graceful 라우팅 엔진 전환을 활성화할 수 없습니다. GR(Graceful 라우팅 엔진 스위치오버)이 이미 활성화되어 있는 경우, 지원되지 않는 PIC는 온라인에 접속할 수 없습니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인할 수 있습니다.

다음 표를 사용하여 플랫폼에 대한 플랫폼별 동작을 검토합니다.

플랫폼	차이점
MX 시리즈	MX 시리즈 라우터에서 GRES를 수행할 때, 새로운 기본 라우팅 엔진에서 작동 모드 명령을 실행하여 clear synchronous-ethernet wait-to-restore 복원 대기 타이머를 삭제해야 합니다. 이는 운영 모드 명령이 로컬 라우팅 엔진에서만 wait-to-restore 타이머를 지우기 때문입니다 clear synchronous-ethernet wait-to-restore . 향상된 가입자 관리를 사용하는 MX 시리즈 라우터의 경우, Graceful 라우팅 엔진 전환이 수행되면 새로운 백업 라우팅 엔진(이전의 기본 라우팅 엔진)이 재부팅됩니다. 이 콜드 재시작은 백업 라우팅 엔진의 상태를 새로운 기본 라우팅 엔진의 상태와 재동기화하여 전환 중에 발생할 수 있는 상태의 불일치를 방지합니다. 분산 PPM(주기적 패킷 관리)이 활성화된 MX 시리즈 라우터는 graceful 라우팅 엔진 스위치오버를 구성할 수 있으며 동일한 디바이스에서 빠른 폴링 LACP를 위해 어그리게이션 이더넷 인터페이스를 구성합니다. Graceful 라우팅 엔진 스위치오버는 플랫폼별 GRES 동작에 표시된 것과 같이 적절한 버전의 Junos OS를 실행하는 MX 시리즈 5G 유니버설 라우팅 플랫폼의 모든 DPC(Dense Port Concentrator)를 지원합니다.
PTX 시리즈	Junos OS Evolved를 실행하는 PTX10004, PTX10008 및 PTX10016 디바이스에서 GRES는 기본적으로 활성화되며 비활성화할 수 없습니다.
QFX 시리즈	중복 라우팅 엔진이 있는 QFX10000 라인의 스위치에서 GRES를 통한 무중단 라우팅을 활성화할 경우, 계층 수준에서 명령문을 [edit routing-options] 구성하는 nsr-phantom-holdtime seconds 것이 좋습니다. 이렇게 하면 전환 중에 트래픽 손실을 방지하는 데 도움이 됩니다. 이 명령문을 구성하는 경우, 지정된 보류 시간 간격이 만료될 때까지 전환 중에 가상 IP 주소가 커널에 남아 있습니다. 간격이 만료되면 디바이스는 해당 라우팅 테이블에 해당 경로를 추가합니다. 이더넷 VPN(EVPN)-VXLAN 환경에서는 300초(5분)의 홀드 타임 값을 지정하는 것이 좋습니다. 이 옵션은 중복 라우팅 엔진이 없고 GRES를 지원하지 않는 QFX10002 스위치에는 적용되지 않습니다.