Junos 멀티 액세스 사용자 플레인의 GRES

Junos 다중 액세스 사용자 플레인의 경우, GRES 전환은 PFCP KeepAlive 프로토콜을 보호합니다. 새로운 기본 라우팅 엔진 피어 keepalives에 응답하기 시작합니다.

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

기본 역할은 다음의 경우 백업 라우팅 엔진 스위치합니다.

• 기본 라우팅 엔진 커널이 작동을 중단합니다.

• 주요 라우팅 엔진 하드웨어 장애를 경험합니다.

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

참고:

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

백업 라우팅 엔진 2초 후에 기본 라우팅 엔진 keepalive를 수신하지 않으면 기본 라우팅 엔진 실패한 것으로 결정됩니다. 기본 역할을 맡습니다.

패킷 전달 엔진:

• 이전 기본 라우팅 엔진 원활하게 연결 해제

• 새로운 기본 라우팅 엔진 다시 연결

• 재부팅하지 않음

• 트래픽 인터럽트 안 않음

그런 다음 새로운 기본 라우팅 엔진 및 패킷 전달 엔진 동기화됩니다. 새로운 기본 라우팅 엔진 패킷 전달 엔진 상태가 최신 상태가 아님을 감지하면 상태 업데이트 메시지를 다시 보냅니다.

참고:

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

라우터 또는 스위치에 유사한 Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset 경고 메시지가 표시되는 경우, 전환 시도를 하지 마십시오. 전환을 진행하기로 선택한 경우 Graceful Switchover를 수행할 준비가 되지 않은 패킷 전달 엔진만 재설정됩니다. 어떤 FPC도 자발적으로 다시 시작해서는 안 됩니다. 경고가 더 이상 나타나지 않을 때까지 기다린 다음 전환으로 진행하는 것이 좋습니다.

참고:

• 라우터 또는 스위치에서 GRES가 활성화된 경우 백업 라우팅 엔진 커밋 작업을 수행 하지 않는 것이 좋습니다.

• 어떤 시나리오에서도 백업 라우팅 엔진 GRES를 활성화하지 않는 것이 좋습니다.

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

참고:

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

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

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

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

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

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

3. 패킷 전달 엔진 시작하고 기본 라우팅 엔진 연결합니다.

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

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

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

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

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

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

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

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

2. 패킷 전달 엔진 새로운 기본이 되는 백업 라우팅 엔진 연결합니다.

3. GRES의 일부가 아닌 라우팅 플랫폼 프로세스(예: 라우팅 프로토콜 프로세스 rpd) 재시작.

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

5. 구성된 경우 Graceful Restart 프로토콜 확장은 이웃 피어 도우미 라우터로부터 라우팅 정보를 수집하고 복원합니다.

참고:

향상된 가입자 관리를 사용하는 MX 시리즈 라우터의 경우 Graceful 라우팅 엔진 전환이 수행되면 새로운 백업 라우팅 엔진(이전의 기본 라우팅 엔진)가 재부팅됩니다. 이 콜드 재시작은 백업 라우팅 엔진 새 기본 라우팅 엔진 상태로 재동기화하여 전환 중에 발생할 수 있는 상태의 불일치를 방지합니다.

참고:

Junos 다중 액세스 사용자 플레인 구성에서 모바일 에지 구성이 커밋되고 GRES를 활성화하거나 비활성화해야 하는 경우 전체 섀시의 재부팅이 필요합니다.

참고:

Junos 멀티 액세스 사용자 플레인에서 세션 상태가 아닌 ESTABLISHED모든 가입자 세션인 Graceful Restart는 해당 가입자를 로그아웃하고 상태를 정리합니다. SAEGW-C는 이 세션을 재설정해야 합니다.

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

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