Junos 노드 슬라이싱 업그레이드

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

주니퍼 장치 관리자(JDM) 패키지
게스트 네트워크 기능(GNF)을 위한 Junos OS 이미지
기본 시스템(BSYS)용 Junos OS 패키지

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

참고:

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

외부 서버 모델에 대한 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 24.04(외부 서버 모델)를 실행하는 x86 서버에 JDM Ubuntu 패키지 설치

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

Junos OS 릴리스 23.2R1부터 외부 서버 기반 Junos Node Slicing은 포드 관리자 도구(podman)를 사용한 주니퍼 디바이스 관리자(JDM) 구축을 지원합니다. RHEL(Red Hat® Enterprise Linux®) 9 이상 버전을 실행하는 서버만 podman을 지원합니다.

23.2R1 이전의 Junos 릴리스에서는 외부 서버 기반 Junos Node Slicing이 JDM을 배포하기 위해 libvirt의 lxc 드라이버(libvirt-lxc)를 제공하는 RHEL 7.3을 지원했습니다.

참고:

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 Node Slicing을 위한 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은 VM 호스트 소프트웨어의 WRL9 버전을 제공합니다. 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단계까지 반복합니다.
두 라우팅 엔진의 JDM에서 명령을 실행 request server authenticate-peer-server 합니다.
re0 JDM에 구성 set system commit synchronize 한 다음 적용 commit 합니다.

참고:

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

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

참고:

단일 서버 기반 Junos Node Slicing 설정에 설치된 주니퍼 디바이스 관리자(JDM)는 다운그레이드할 수 없습니다.

다음 단계를 사용하여 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 Node Slicing 설정에 설치된 주니퍼 디바이스 관리자(JDM)는 다운그레이드할 수 없습니다.

다음 단계를 사용하여 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 Node Slicing 설정에서 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에만 나타납니다. 다음과 같은 유형의 알람이 발생할 수 있습니다.

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

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

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

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

참고:

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

외부 서버 다시 시작

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

모든 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 업데이트 후 인텔 X710 NIC를 사용하는 경우 사용 중인 X710 NIC 드라이버 버전이 x86 서버용 인텔 X710 NIC 드라이버 업데이트 에 설명된 대로 최신 버전인지 확인합니다.

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

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

Junos Node Slicing은 RHEL 7.3을 지원합니다.

호스트 OS를 업데이트하기 전에 Red Hat Subscription Manager가 버전 7.3으로 설정되어 있고 Red Hat Subscription Service에 EUS(Extended Update Support)가 포함되어 있는지 확인합니다.

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

참고:

Red Hat 서브스크립션 관리자가 버전 7.3으로 설정되어 있는지 확인해야 합니다. 그렇지 않으면 RHEL에 대한 업데이트가 최신 마이너 릴리스로 업그레이드를 시도합니다. 예를 들어 RHEL 7.3은 일반 yum 업데이트를 통해 RHEL 7.4(또는 이후 버전)가 되거나 보안 업데이트가 yum RHEL 7.3 이상의 새 커널을 가져올 수 있습니다.

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

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

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

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

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

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

모든 구성을 백업합니다.
호스트 OS 보안 업데이트 전에 외부 x86 서버의 호스트 OS 커널 및 패키지 버전에 대한 보기를 수집합니다. 또한 i40e 드라이버 및 Intel X710 펌웨어가 최소 요구 사항(버전: 2.4.10 및 버전: 18.5.17)을 충족하는지 확인합니다.
RedHat 서브스크립션 관리자가 RHEL 7.3으로 설정되어 있고 EUS 리포지토리가 활성화되어 있는지 확인합니다.
모든 GNF가 에서 기본 REserver0를 사용하고 있는지 확인합니다. 백업 라우팅 엔진이 켜져 server1있습니다re1. 먼저 백업 라우팅 엔진이 포함된 서버에서 호스트 OS 보안 업데이트를 수행합니다.
모든 GNF에서 이 명령을 실행하여 모든 GNF가 server0에 기본 라우팅 엔진을 가지고 있는지 확인합니다.
요청만 통해 stop JDM cli의 모든 GNF VM을 중지합니다. server1 server1 모든 GNF에 대한 백업 라우팅 엔진을 포함합니다. 이 옵션은 사용하지 all-servers 마십시오. 예:
호스트 OS에서 영향을 받는 서버에서 JDM을 중지합니다.

보안 업데이트를 수행 yum 하고 서버를 재부팅합니다.

i40e 드라이버를 다시 로드하거나 컴파일합니다. 드라이버 업데이트에 대한 지침은 인텔 지원 페이지를 참조하십시오.

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

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

주니퍼 장치 관리자(JDM)의 기반이 되는 Ubuntu 컨테이너에는 보안 패치를 수시로 적용해야 합니다.

참고:

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 Node Slicing을 사용하는 경우 BSYS VM에서 다음 명령을 사용하여 JDM을 입력합니다.

루트@라우터> 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 Node Slicing을 사용하는 경우 BSYS VM에서 다음 명령을 사용하여 JDM을 다시 시작합니다.

루트@라우터> request vmhost jdm stop

루트@라우터> request vmhost jdm start

이 페이지의 내용

Junos 노드 슬라이싱 업그레이드