그레이스풀 라우팅 스위치오버 이해하기

그레이스풀 라우팅 엔진 전환 개념

Junos OS 및 Junos OS Evolved의 그레이스풀 라우팅 엔진 스위치오버(GRES) 기능을 사용하면 중복 라우팅 엔진이 있는 디바이스가 하나의 라우팅 엔진에 장애가 발생하더라도 패킷을 계속 전달할 수 있습니다. 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부터 재시작 디바이스와 인접 피어 '도우미' 디바이스 간의 인접성이 시간 초과되면, 그레이스풀 재시작 프로토콜 확장은 임박한 재시작에 대해 피어 '도우미' 디바이스에 알릴 수 없습니다. 그러면 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. 기본 라우팅 엔진의 keepalives가 손실되면 시스템은 백업 라우팅 엔진으로 정상적으로 전환됩니다.

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

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

4. 전환 지점에서 학습한 상태 정보는 시스템에서 업데이트됩니다.

5. 구성된 경우, 그레이스풀 재시작 프로토콜 확장은 인접 피어 도우미 디바이스에서 라우팅 정보를 수집하고 복원합니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오.

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

라우팅 엔진 전환의 효과

표 1 은 다른 기능이 활성화되었을 때 라우팅 엔진 전환의 효과를 설명합니다.

• 고가용성 기능 없음

• 그레이스풀 라우팅 엔진 전환

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

• NST(Nonstop Active Routing)

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

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

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

GRES(Graceful 라우팅 엔진 스위치오버)가 운영 모드 명령에 의해 트리거되면, 디바이스는 ASI(Aggregated Services Interface)의 상태를 보존하지 않습니다. 예를 들면 다음과 같습니다.

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

또는:

그레이스풀 라우팅 엔진 전환 플랫폼 지원

그레이스풀 라우팅 엔진 전환을 활성화하려면 시스템이 다음의 최소 요구 사항을 충족해야 합니다:

• 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 이상

그레이스풀 라우팅 엔진 전환 지원에 대한 자세한 내용은 다음 섹션을 참조하십시오.

그레이스풀 라우팅 엔진 전환 기능 지원

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

표 2: 그레이스풀 라우팅 엔진 전환 기능 지원

신청	Junos OS 릴리스
LACP(Link Aggregation Control Protocol) 및 어그리게이션 SONET 인터페이스를 사용하는 어그리게이션 이더넷 인터페이스	6.2
ATM(Asynchronous Transfer Mode) 가상 서킷(VC)	6.2
논리적 시스템 참고: Junos OS 릴리스 9.3 이상에서 논리적 라우터 기능은 논리적 시스템으로 이름이 변경되었습니다.	6.3
멀티캐스트	6.4(TX Matrix 라우터의 경우 7.0)
MLPPP(Multilink Point-to-Point Protocol) 및 MLFR(Multilink Frame Relay)	7.0
자동 보호 스위칭(APS) - 현재 활성 인터페이스(지정된 작동 인터페이스 또는 지정된 보호 인터페이스)는 라우팅 엔진 전환 중에 활성 인터페이스로 유지됩니다.	7.4
Point-to-multipoint Multiprotocol Label Switching MPLS LSP(전송 전용)	7.4
CRTP(Compressed Real-Time Transport Protocol)	7.6
가상 프라이빗 LAN 서비스(VPLS)	8.2
IEEE 802.3ah에 정의된 이더넷 운영, 관리 및 관리(OAM)	8.5
확장된 DHCP 릴레이 에이전트	8.5
IEEE 802.1ag에 정의된 이더넷 OAM	9.0
멀티서비스 500 T640 라우터의 패킷 게이트웨이 제어 프로토콜(PGCPD) 프로세스(PGCPD).	9.0
가입자 액세스	9.4
레이어 2 서킷 및 LDP 기반 VPLS 유사 회선 중복 구성	9.6

그레이스풀 라우팅 엔진 전환 기능 지원에는 다음과 같은 제약이 적용됩니다.

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

  참고:

  MACSec 세션은 그레이스풀 라우팅 엔진 전환 시 플랩됩니다.

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

그레이스풀 라우팅 엔진 전환 및 가입자 액세스

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

참고:

가입자 관리를 위해 그레이스풀 라우팅 엔진 스위치오버가 활성화되면, 안정적인 작동을 위해서는 라우터의 모든 라우팅 엔진에 동일한 양의 DRAM이 있어야 합니다.

그레이스풀 라우팅 엔진 스위치오버 PIC 지원

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

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

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

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

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

참고:

지원되지 않는 PIC가 온라인 상태일 때, 그레이스풀 라우팅 엔진 전환을 활성화할 수 없습니다. 그레이스풀 라우팅 엔진 전환이 이미 활성화된 경우, 지원되지 않는 PIC는 온라인으로 전환될 수 없습니다.

기능 탐색기를 사용하여 특정 기능에 대한 플랫폼 및 릴리스 지원을 확인하십시오.

다음 표를 사용하여 플랫폼의 플랫폼별 동작을 검토하십시오.

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