Junos Node Slicing 업그레이드

Junos Node Slicing은 세 가지 유형의 소프트웨어 구성 요소로 구성됩니다.

JDM(Juniper Device Manager) 패키지
게스트 네트워크 기능(GNF)을 위한 Junos OS 이미지
기본 시스템용 Junos OS 패키지(BSYS)

허용된 소프트웨어 버전 범위 내에 있는 한 이러한 각 구성 요소를 독립적으로 업그레이드할 수 있습니다(자세한 내용은 다중 버전 소프트웨어 상호 운용성 개요 참조). 모두 함께 업그레이드할 수도 있습니다.

참고:

업그레이드 프로세스를 시작하기 전에 참조를 위해 JDM, GNF VM 및 BSYS 구성을 저장합니다.
라인 카드에서 BIOS 업그레이드를 실행하려면 Junos 노드 슬라이싱 구성을 비활성화하여 라우터가 독립형 모드인지 확인해야 합니다.

외부 서버 모델에 대한 JDM 업그레이드
Podman 기반 배포를 지원하도록 JDM 업그레이드(23.2R1)
섀시 내 모델을 위한 JDM 업그레이드
GNF 및 BSYS 업그레이드
WRL 9 기반 VM 호스트를 지원하도록 JDM 업그레이드 - 섀시 내 모델

외부 서버 모델에 대한 JDM 업그레이드

두 서버 모두에서 다음 작업을 수행하여 JDM을 업그레이드합니다.
1. 새 JDM 패키지(RPM 또는 Ubuntu)를 호스트의 디렉터리(예: / var/tmp)에 복사합니다.
2. 다음 명령을 사용하여 JDM을 중지합니다.
3. 업그레이드 명령을 실행하여 JDM 패키지를 업그레이드합니다.
  
  JDM RHEL 패키지를 업그레이드하는 경우 다음 명령을 사용합니다.
  JDM Ubuntu 패키지를 업그레이드하는 경우 다음 명령을 사용합니다.
  참고:
  - JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.
  - JDM을 업그레이드하기 전에 두 JDM 배포가 동기화되어 있는지 확인하십시오. 이는 다음을 의미합니다.
    
    지정된 GNF에서 실행되는 Junos는 두 서버 모두에서 동일한 SMBIOS 버전을 지원해야 합니다.
    
    업그레이드하기 전에 모든 GNF가 두 서버에 모두 존재하는지 확인하십시오.
  - 두 JDM 서버를 모두 업그레이드한 후 새 GNF를 구성하기 전에 실행해야 commit synchronize 합니다. server1에서 새 GNF를 실행하고 commit synchronize 생성하지 않으면 나중에 server0에서 server1로 수행할 수 commit synchronize 없습니다.
  - 두 JDM을 모두 업그레이드해야 합니다.
  참고 항목:
  - RHEL(외부 서버 모델)을 실행하는 x86 서버에 JDM RPM 패키지 설치
  - Ubuntu 20.04를 실행하는 x86 서버에 JDM Ubuntu 패키지 설치(외부 서버 모델)

Podman 기반 배포를 지원하도록 JDM 업그레이드(23.2R1)

Junos OS 릴리스 23.2R1부터 외부 서버 기반 Junos 노드 슬라이싱은 Pod Manager 도구(podman)를 사용하여 JDM(Juniper Device Manager) 구축을 지원합니다. RHEL(Red Hat® Enterprise Linux®) 9 이상 버전을 실행하는 서버만 podman을 지원합니다.

23.2R1 이전의 Junos 릴리스에서는 외부 서버 기반 Junos 노드 슬라이싱이 RHEL 7.3을 지원했으며, 이는 JDM을 구축하기 위해 libvirt의 lxc 드라이버(libvirt-lxc)를 제공했습니다.

참고:

JDM 업그레이드 중에 JDM 구성을 백업해야 하는 경우 먼저 디바이스에 Junos 버전 23.1R1 이상을 설치해야 합니다. JDM 구성(request system save state path 및 )을 백업 및 request system restore state path복원하는 명령은 Junos 버전 23.1R1 이상에서만 사용할 수 있기 때문입니다.

libvirt-lxc 기반 JDM을 podman 기반 버전으로 업그레이드하려면 두 서버 모두에서 아래 단계를 수행합니다.

두 서버에서 JDM에 의해 생성된 임의의 MAC 접두사가 동일한지 확인합니다.
JDM 구성을 /host/tmp/ 폴더에 백업합니다.
이 단계는 JDM 구성 및 random-mac-prefix 값을 백업합니다. MAC 접두사는 비면허 게스트 네트워크 기능(GNF)과 연관된 MAC 주소의 일부를 구성합니다.
각 서버에서 JDM을 제거합니다. 자세한 내용은 Junos 노드 슬라이싱 관리를 참조하십시오.
호스트 OS를 RHEL 9로 업그레이드합니다.
podman 기반 JDM을 설치합니다. 이것은 일반적인 설치 프로세스입니다. JDM을 설치하려면 RHEL(외부 서버 모델)을 실행하는 x86 서버에 JDM RPM 패키지 설치에 제공된 단계를 사용합니다.

JDM 백업을 복원합니다.

두 서버에서 위의 단계를 수행한 후 두 서버에서 JDM에 의해 생성된 임의의 MAC 접두사가 동일한지 확인합니다.

참고:

JDM을 libvirt-lxc 기반 버전에서 podman 기반 버전으로 업그레이드하기 전에는 GNF를 백업할 수 없습니다. JDM을 업그레이드한 후 GNF를 새로 구성해야 합니다.

섀시 내 모델을 위한 JDM 업그레이드

두 라우팅 엔진의 BSYS 인스턴스에서 다음 작업을 수행하여 JDM을 업그레이드합니다.
1. 새 JDM RPM 패키지를 디렉터리(예: / var/tmp)에 복사합니다.
2. 다음 명령을 실행하여 JDM을 중지합니다.
3. 다음 예제에 표시된 명령을 사용하여 섀시 내 Junos 노드 슬라이싱을 위한 JDM RPM 패키지를 설치합니다.
  참고:
  JDM 업그레이드는 실행 중인 GNF에 영향을 주지 않습니다.

참고:

섀시 내 모델에 맞게 JDM을 업그레이드하기 위해 기존 JDM 소프트웨어를 제거할 필요가 없습니다. 기존 JDM을 제거하면 게스트 네트워크 기능(GNF)에 영향을 미칠 수 있습니다.

GNF 및 BSYS 업그레이드

GNF 및 BSYS 패키지는 독립형 MX 시리즈 라우터에서 Junos OS를 업그레이드하는 것과 동일한 방식으로 업그레이드할 수 있습니다.

업그레이드를 수행할 때 모든 GNF가 온라인 상태인지 확인합니다. 이는 GNF 및 BSYS 업그레이드 프로세스 모두 다중 버전 검사(이 가이드의 뒷부분에서 설명)를 트리거하고, 모든 GNF는 다중 버전 확인 단계에서 온라인 상태여야 하며, 실패하면 업그레이드가 종료되기 때문입니다. GNF가 종료된 상태로 유지되는 경우 BSYS CLI에서 구성을 비활성화해야 하며, 이 경우 특정 GNF에 대한 멀티버전 검사를 건너뜁니다.

참고:

force JDM CLI 명령을 request virtual-network-functions vnf-name add-image new-image-name force사용하여 기존 GNF 이미지를 새 이미지로 덮어쓸 수 있는 옵션도 사용할 수 있습니다. 이는 GNF 이미지가 부팅되지 않는 드문 상황에서 유용할 수 있습니다. 예를 들어, Ctrl-C를 눌러 진행 중이던 이전 add-image 작업을 갑자기 종료한 경우 옵션을 사용하여 force 정리를 수행할 수도 있습니다(예: request virtual-network-functions vnf-name delete-image image-name force).

WRL 9 기반 VM 호스트를 지원하도록 JDM 업그레이드 - 섀시 내 모델

라우팅 엔진에서 Junos OS 19.3R1 이상을 실행하려면 JDM을 19.3R1 이상으로 업그레이드해야 합니다.

참고:

19.3R1 이전에 릴리스된 Junos OS 버전은 WRL6 버전의 VM 호스트 소프트웨어를 사용합니다. Junos OS 19.3R1은 WRL9 버전의 VM 호스트 소프트웨어를 제공합니다. VM 호스트 버전을 확인하려면 BSYS VM에서 Junos CLI 명령을 show vmhost version사용합니다.

다음 단계를 사용하여 JDM을 업그레이드합니다.

각 GNF에서 라우팅 엔진 1(re1)에서 실행되는 백업 GNF에 기본 역할을 할당합니다.

re0에서 먼저 JDM에서 GNF를 중지한 다음 BSYS에서 JDM 자체를 중지합니다.

re0 VM 호스트 버전이 Junos OS 19.3R1 이상인지 확인합니다. VM 호스트 버전을 확인하려면 Junos CLI 명령을 show vmhost version사용합니다.

다음 Junos CLI를 사용하여 VM 호스트 소프트웨어를 업그레이드할 수 있습니다.
자세한 내용은 VM 호스트의 설치, 업그레이드, 백업 및 복구를 참조하세요.
재부팅 후 re0이 백업되면 새 JDM RPM 패키지(19.3R1 이상)를 디렉토리(예: /var/tmp)에 복사합니다.
re0에 새 JDM RPM 패키지를 설치한 다음 JDM을 시작합니다.
re0의 GNF는 이 단계 후에 자동으로 시작됩니다.
라우팅 엔진 1(r1)에서 1단계부터 5단계까지 반복합니다.
request server authenticate-peer-server 두 라우팅 엔진의 JDM에서 명령을 실행합니다.
re0 JDM에서 구성한 set system commit synchronize 다음 적용합니다 commit .

참고:

JDM 소프트웨어 버전 19.3R1은 Junos OS 버전 19.3R1 뿐만 아니라 19.3R1 이전의 Junos OS 버전에서도 실행할 수 있습니다.

외부 서버 모델에 대한 JDM 다운그레이드

참고:

단일 서버 기반 Junos 노드 슬라이싱 설정에 설치된 JDM(Juniper Device Manager)은 다운그레이드할 수 없습니다.

다음 단계를 사용하여 JDM을 다운그레이드합니다.

server1에서 실행되는 백업 GNF에 기본 역할을 할당합니다.

server0에서 모든 GNF를 중지하고 구성을 삭제합니다 commit synchronize .

server0에서 JDM을 중지하고 설치 제거합니다.

참고:

Ubuntu를 사용하는 경우 명령을 dpkg --purge jns-jdm 사용하여 JDM을 제거합니다.

server0에서 JDM의 대상 버전을 설치합니다.

루트 인증 또는 인터페이스와 routing-options를 사용하여 JDM을 구성합니다.

server0 JDM에서 JDM 버전과 호환되는 GNF 이미지 버전을 추가합니다.

GNF 버전이 JDM 버전과 호환되지 않는 경우 다음 오류 메시지가 표시됩니다.

GNF가 server0 JDM에 나타날 때까지 기다리십시오.
기본 라우팅 엔진(server1에서 실행되는 GNF)에서 커밋 동기화를 수행합니다.
server0 JDM에서 실행 중인 GNF에 기본 역할을 할당합니다.
서버 1에서 2-5단계를 반복합니다.
request server authenticate-peer-server 두 서버 모두에서 명령을 실행합니다.
적용 show server connections all-servers 하고 문제가 표시되지 않는지 확인합니다.
server0 JDM에서 구성한 set system commit synchronize 다음 적용합니다 commit .
명령을 show virtual-network-functions all-servers 사용하여 GNF가 실행되는지 확인합니다.

섀시 내 모델에 대한 JDM 다운그레이드

참고:

단일 라우팅 엔진 기반 Junos 노드 슬라이싱 설정에 설치된 JDM(Juniper Device Manager)은 다운그레이드할 수 없습니다.

다음 단계를 사용하여 JDM을 다운그레이드합니다.

라우팅 엔진 1(re1)에서 실행되는 백업 GNF에 기본 역할을 할당합니다.

re0에서 모든 GNF를 중지하고 구성을 삭제합니다 commit synchronize .

re0에서 JDM(BSYS 기본)을 제거합니다.

re0에서 JDM의 대상 버전(예: 18.3R1)을 설치합니다.

re0에서 server1에서 실행 중인 것과 동일한 버전의 GNF를 배포합니다.

GNF 버전이 JDM 버전과 호환되지 않는 경우 다음 오류 메시지가 표시됩니다.

다음 명령을 사용하여 GNF 버전을 확인할 수 있습니다.

re1에서 1단계부터 5단계까지 반복합니다.
request server authenticate-peer-server 두 라우팅 엔진 모두에서 명령을 실행합니다.
기본 라우팅 엔진(server1에서 실행되는 GNF)에서 커밋 동기화를 수행합니다.
re0 JDM에서 구성한 set system commit synchronize 다음 적용합니다 commit .

이제 JDM은 Junos OS 버전 18.3R1과 함께 제공됩니다.

통합 ISSU 지원

Junos Node Slicing은 또한 통합된 ISSU(In-Service Software Upgrade)를 지원하므로 컨트롤 플레인에서 중단 없이 트래픽 중단을 최소화하면서 두 개의 서로 다른 Junos OS 버전 간에 업그레이드할 수 있습니다. BSYS와 GNF에서 별도로 통합 ISSU를 수행할 수 있습니다. 또한 다른 GNF에 영향을 주지 않고 각 GNF에서 독립적으로 통합 ISSU를 실행할 수 있습니다. 통합 ISSU 프로세스 이해도 참조하십시오.

참고:

멀티버전 소프트웨어 지원 제한(예: 버전 편차 제한)은 통합 ISSU 업그레이드에도 적용됩니다.
Junos OS 릴리스 21.4R1부터 SLC(서브 라인 카드)를 갖춘 MPC11E는 제로 패킷 손실 모드에서 ISSU를 지원합니다. 이전 버전의 Junos OS를 실행 중인 경우, SLC가 있는 Junos 노드 슬라이싱 설정에서 ISSU를 수행하려고 시도하지 마십시오.

멀티버전 소프트웨어 상호 운용성 관리

Junos Node Slicing은 멀티버전 소프트웨어 상호 운용성을 지원합니다. 그러나 소프트웨어 버전 간에 비호환성이 있는 경우 소프트웨어 업그레이드 프로세스 중 또는 GNF 또는 FRU가 온라인 상태가 될 때 경고 메시지가 나타납니다. 사소한 비호환성이 발생하면 이를 수락하고 계속 진행할 수 있습니다. 중대한 비호환성이 있는 경우 프로세스를 종료하거나 옵션을 사용하여 force 비호환성을 수락하고 계속 진행해야 합니다.

참고:

vmhost 소프트웨어 업그레이드 force 의 경우 옵션을 사용할 수 없습니다. 따라서 GNF가 오프라인 상태이거나 설치 중인 소프트웨어와 호환되지 않아 멀티버전 검사가 종료되는 경우 소프트웨어 업그레이드 중에 해당 GNF를 비활성화한 다음 업그레이드가 끝나면 다시 활성화해야 합니다.

다음은 소프트웨어 업그레이드 중에 비호환성이 감지될 경우 나타나는 샘플 메시지입니다.

Sample alert message indicating a minor incompatibility:

Sample alert message indicating a major incompatibility:

Sample output showing how to use the 'force' option to proceed with an upgrade:

소프트웨어 비호환성 경보 보기
소프트웨어 버전 간 비호환성 보기

소프트웨어 비호환성 경보 보기

GNF 또는 BSYS의 소프트웨어 업데이트 후 GNF와 BSYS 간에 소프트웨어 비호환성이 존재하는 경우 섀시 알람으로 발생합니다. 명령을 사용하여 비호환성 알람 정보를 볼 수 있습니다 show chassis alarms . 명령을 사용하여 비호환성에 대한 세부 정보를 추가로 볼 수 있습니다 show system anomalies . 자세한 내용은 소프트웨어 버전 간 비호환성 보기를 참조하십시오.

BSYS에서 업그레이드가 수행되더라도 경보는 GNF에만 나타납니다. 다음과 같은 유형의 알람이 발생할 수 있습니다.

System Noncompatibility with BSYS(BSYS와의 시스템 비호환성) - 이것은 주요 경보입니다. BSYS와 GNF 소프트웨어 버전 간의 비호환성으로 인해 GNF가 오프라인 상태가 될 때 나타납니다.
BSYS와의 기능 비호환성 - 이것은 사소한 경보입니다. 이는 BSYS와 GNF 소프트웨어 버전 간에 약간의 비호환성이 있음을 나타냅니다. 이로 인해 GNF가 오프라인으로 전환되지는 않습니다.

소프트웨어 버전 간 비호환성 보기

BSYS에서 소프트웨어 비호환성을 보려면 다음 예와 같이 CLI를 사용합니다.

GNF에서 소프트웨어 비호환성을 보려면 다음 예와 같이 CLI를 사용합니다.

참고:

CLI에 표시된 대로 BSYS의 비호환성을 보는 동안 GNF ID를 지정해야 합니다.
앞의 예제에서는 시스템 수준의 비호환성을 보여 줍니다. fru 또는 옵션을 사용하여 FRU 또는 config 기능 수준 비호환성을 볼 수 있습니다.

외부 서버 다시 시작

하드웨어 또는 호스트 OS 업그레이드 및 장애 격리와 같은 서버 유지 보수 활동을 하려면 Junos 노드 슬라이싱에 사용되는 외부 서버를 다시 시작해야 할 수 있습니다. 다음 절차에 따라 서버를 다시 시작합니다.

모든 GNF를 중지합니다.
두 서버를 모두 다시 시작하는 경우 다음 예와 같이 각 GNF를 all-servers 중지하는 동안 옵션을 선택합니다.
특정 서버를 다시 시작하는 경우 다음 예와 같이 server-id를 지정하여 해당 서버에서 GNF를 중지합니다.

GNF가 중지되었는지 확인합니다.

참고:

두 서버 모두에서 GNF의 상태를 보려면 옵션을 선택합니다 all-servers . 예: show virtual-network-functions all-servers).

Linux 호스트 셸에서 다음 명령을 사용하여 JDM을 중지합니다.
Linux 호스트 셸에서 JDM 상태가 중지됨으로 표시되는지 확인합니다.
재부팅 후 JDM 상태가 실행 중으로 표시되는지 확인합니다.

서버 재부팅 후 JDM 및 구성된 GNF가 자동으로 실행되기 시작합니다.

서버를 교체하는 경우 운영 서버 쌍의 하드웨어 구성이 계속 유사하거나 동일한지 확인하십시오. 교체 중에 서버 쌍이 일시적으로 유사하지 않게 되는 경우(서버를 순차적으로 교체하는 경우일 수 있음) 이 기간 동안 GRES 및 NSR을 비활성화하고 두 서버가 다시 한 번 유사한 경우에만 다시 활성화하는 것이 좋습니다.

외부 서버에서 호스트 OS 업데이트

외부 서버에서 호스트 OS를 업데이트하기 전에 먼저 외부 서버 다시 시작에 설명된 대로 해당 서버에서 GNF 및 JDM을 중지해야 합니다.

호스트 OS 업데이트 후 Intel X710 NIC를 사용하는 경우 사용 중인 X710 NIC 드라이버의 버전이 x86 서버용 Intel X710 NIC 드라이버 업데이트에 설명된 대로 계속 최신 버전인지 확인합니다.

호스트 OS에 보안 업데이트 적용

호스트 OS에는 때때로 보안 업데이트가 필요합니다. 이 섹션에서는 Red Hat(RHEL) OS를 사용하여 호스트 OS에 보안 업데이트를 적용하는 단계를 중점적으로 설명합니다.

Junos Node Slicing은 RHEL 9를 지원합니다.

호스트 OS를 업데이트하기 전에 Red Hat 서브스크립션 관리자가 버전 9로 설정되어 있고 Red Hat 서브스크립션 서비스에 EUS(Extended Update Support)가 포함되어 있는지 확인합니다.

명령을 subscription-manager release --show 사용하여 릴리스가 9로 설정되었는지 확인할 수 있습니다. 그렇지 않은 경우 명령을 subscription-manager release --set=9 사용하여 릴리스를 9로 설정할 수 있습니다.

참고:

Red Hat 서브스크립션 관리자가 버전 9로 설정되어 있는지 확인해야 합니다.

Red Hat의 확장 업데이트 지원을 통해 지정된 릴리스 내에서 패치 및 보안 업데이트를 적용할 수 있습니다. RHEL의 확장 업데이트 지원의 허용된 사용은 RHEL 지원 계약의 기능이며 이 섹션의 범위를 벗어납니다. 명령을 subscription-manager repos --list | grep rhel-7-server-eus-rpms사용하여 RHEL 구독에 EUS(Extended Update Support)가 포함되어 있는지 확인할 수 있습니다 . EUS 지원은 기본적으로 사용하도록 설정되지 않습니다. 명령을 사용하여 EUS를 subscription-manager repos --enable rhel-7-server-eus-rpms활성화할 수 있습니다.

호스트 OS 보안 업데이트를 적용하는 단계

호스트 OS에 보안 업데이트를 적용하려면 외부 x86 서버를 다시 부팅해야 할 수 있습니다. 외부 서버에서 호스트 OS 업데이트 주제를 참조하십시오.

호스트 OS 보안 업데이트가 새 커널 버전을 가져올 수도 있습니다. 호스트 OS 커널을 업데이트하면 Intel i40e 드라이버를 덮어써서 i40e 드라이버 최소 버전 요구 사항을 충족하지 않는 버전을 가져올 수도 있습니다. 그렇다면 최소 요구 사항을 충족하도록 i40e 드라이버를 업데이트해야 합니다. 자세한 내용은 x86 서버용 Intel X710 NIC 드라이버 업데이트를 참조하세요.

외부 x86 서버를 재부팅하기 전에 해당 서버에서 모든 GNF VM 및 JDM을 중지해야 합니다. 두 개의 외부 x86 서버가 있으므로 한 번에 하나의 서버를 업데이트하여 GNF 전달을 방해하지 않고 호스트 OS 보안 업데이트를 수행할 수 있습니다. 영향을 받는 서버에서 기본 라우팅 엔진을 이동하려면 GRES/NSR 기본 라우팅 엔진 전환이 필요합니다.

여기서는 각 GNF가 외부 x86 server1에서 실행되는 각 GNF re1 에 대한 백업 라우팅 엔진으로 라우팅 엔진 1(re1)의 기본 동작으로 시작합니다.

모든 구성을 백업합니다.
호스트 OS 보안 업데이트 전에 외부 x86 서버에서 호스트 OS 커널 및 패키지 버전 보기를 수집합니다. 또한 i40e 드라이버와 Intel X710 펌웨어가 최소 요구 사항(버전: 2.4.10 및 버전: 18.5.17)을 충족하는지 확인합니다.

RedHat Subscription Manager가 RHEL 9로 설정되어 있고 EUS 리포지토리가 활성화되어 있는지 확인합니다.

모든 GNF가 에서 server0기본 RE를 사용하고 있는지 확인합니다. 백업 라우팅 엔진이 켜져 있습니다 re1 server1. 먼저 백업 라우팅 엔진이 포함된 서버에서 호스트 OS 보안 업데이트를 수행합니다.
모든 GNF에서 이 명령을 실행하여 모든 GNF가 server0에 기본 라우팅 엔진을 가지고 있는지 확인합니다.
에 대한 요청을 통해서만 JDM CLI에서 모든 GNF VM을 중지합니다. 에는 모든 GNF에 stop server1 대한 백업 라우팅 엔진이 포함되어 있습니다. server1 옵션을 all-servers 사용하지 마십시오. 예제:
호스트 OS의 영향을 받는 서버에서 JDM을 중지합니다.
yum 보안 업데이트를 수행하고 서버를 다시 부팅합니다.
i40e 드라이버를 다시 로드하거나 컴파일합니다. 드라이버 업데이트에 대한 지침은 인텔 지원 페이지를 참조하십시오.

이제 에 대한 server1 호스트 OS 보안 업데이트가 완료되었습니다. GNF VM은 서버 재부팅 시 시작됩니다.
보안 업데이트가 완료되면 서버가 재부팅되고 GNF가 백업된 후 다른 서버에서 이 작업을 반복합니다.

Ubuntu 컨테이너에 보안 패치 적용

JDM(Juniper Device Manager)의 기반이 되는 Ubuntu 컨테이너는 보안 패치를 수시로 적용해야 합니다.

참고:

JDM은 인터넷에 연결할 수 있어야 하며 JDM이 구성되어 있어야 name-server 합니다. 다음 JDM CLI 구성 명령문을 적용하여 다음을 지정합니다.name-server

root@jdm# set system name-server address

JDM의 Ubuntu 컨테이너 구성 요소에 보안 업데이트를 적용하려면 다음 단계를 사용합니다.

외부 서버 모델을 사용하는 경우 호스트 OS에서 JDM 콘솔을 사용하여 JDM을 루트로 입력합니다.

root@server# jdm console

또는 JDM CLI에서 다음 명령을 사용하여 JDM 셸을 입력합니다.

root@jdm> start shell user root

섀시 내 Junos 노드 슬라이싱을 사용하는 경우 BSYS VM에서 다음 명령을 사용하여 JDM을 입력합니다.

root@router> request vmhost jdm login
JDM 셸에서 명령을 apt-get update 사용하여 새 패키지 또는 현재 설치된 패키지의 최신 버전에 대한 정보를 다운로드합니다.

jdm-srv1:~# sudo apt-get update
JDM 셸에서 명령을 apt-get upgrade사용합니다.

jdm-srv1:~# sudo apt-get upgrade

업그레이드 목록이 표시되고 계속하라는 메시지가 표시됩니다. '예'로 대답 Y 하고 Enter 키를 누릅니다.
JDM 셸에서 명령을 apt-get dist-upgrade 사용하여 업그레이드를 수행합니다.

jdm-srv1:~# sudo apt-get dist-upgrade

계속하라는 메시지가 표시되면 응답 Y 하고 업그레이드가 완료될 때까지 기다립니다.
외부 서버 모델을 사용하는 경우 호스트 OS에서 JDM을 다시 시작합니다.

user@server# sudo jdm restart

섀시 내 Junos 노드 슬라이싱을 사용하는 경우 BSYS VM에서 다음 명령을 사용하여 JDM을 다시 시작합니다.

root@router> request vmhost jdm stop

root@router> request vmhost jdm start

이 페이지의 내용

Junos Node Slicing 업그레이드