Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

구성 커밋

commit 구성 모드 명령을 사용하면 장비 구성 변경 사항을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화할 수 있습니다.

구성을 위한 커밋 모델

디바이스 구성은 커밋 모델을 사용하여 저장됩니다. 후보 구성은 필요에 따라 수정된 다음 시스템에 투입됩니다. 구성이 커밋되면 디바이스가 구문 오류에 대한 구성을 검사하고 오류가 발견되지 않으면 구성이 저장되고 juniper.conf.gz 활성화됩니다. 이전 활성 구성 파일은 첫 번째 롤백 구성 파일(juniper.conf.1.gz)으로 저장되고 다른 롤백 구성 파일은 1로 증분됩니다. 예를 들어, juniper.conf.1.gz 증분되어 juniper.conf.2.gz두 번째 롤백 구성 파일로 만듭니다. 이 장치는 시스템에 최대 49개의 롤백 구성(번호 1 ~49)을 저장할 수 있습니다.

디바이스에서 현재 구성 파일과 처음 3개의 롤백 파일(juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3)이 디렉토리에 /config 있습니다. (나머지 4~49개 롤백 파일은 에 있습니다 /var/db/config.)

복구 구성 파일이 rescue.conf.gz 있는 경우 이 파일도 디렉토리에 /config 있습니다. 공장 기본 파일은 디렉토리에 /etc/config 있습니다.

장비 내에서 Routing Engines 간에 구성을 전파하는 데 사용되는 메커니즘은 다음과 같습니다.

  • 동기화: 동일한 장비 섀시 내에서 하나의 라우팅 엔진에서 두 번째 라우팅 엔진으로 구성을 전파합니다.

    구성을 동기화하려면 CLI 명령을 사용합니다 commit synchronize . ReS(Routing Engines) 중 하나가 잠겨 있으면 동기화에 장애가 발생합니다. 잠긴 구성 파일로 인해 동기화에 실패하면 이 명령을 사용할 commit synchronize force 수 있습니다. 이 명령은 잠금을 무효화하고 구성 파일을 동기화합니다.

  • 배포: 멀티섀시 디바이스의 라우팅 플레인 전반에서 구성을 전파합니다. 배포가 자동으로 이루어집니다. 배포 프로세스를 제어할 수 있는 사용자 명령이 없습니다. 구성 배포 중에 구성이 잠기면 잠금 구성이 분산된 구성 파일을 받지 못하므로 동기화에 실패합니다. 구성 전에 잠금을 지우고 라우팅 플레인을 재동기화해야 합니다.

    주:

    멀티섀시 플랫폼에서 CLI 명령을 사용하면 commit synchronize force 구성 파일의 강제 동기화가 라우팅 플레인에서 구성 파일의 배포에 영향을 미치지 않습니다. 명령이 발행된 장비에서 원격 디바이스에 컨퍼규레이션 파일이 잠겨 있으면 원격 디바이스에서 동기화에 실패합니다. 잠금을 취소하고 명령을 재발행 synchronization 해야 합니다.

디바이스 구성 커밋

장비 구성 변경 사항을 구성 데이터베이스에 저장하고 디바이스에서 구성을 활성화하려면 구성 모드 명령을 사용합니다 commit . 다음 계층 수준에서 명령을 실행할 commit 수 있습니다.

명령을 입력 commit 하면 구문 오류(commit check)에 대한 구성이 먼저 검사됩니다. 구문이 올바르면 구성이 활성화되고 현재 운영 디바이스 구성이 됩니다.

주:

주니퍼는 라우터에서 graceful Routing Engine 스위치오버가 실행될 때 백업 라우팅 엔진에서 커밋 작업을 수행할 것을 권장하지 않습니다.

다음과 같은 이유로 구성 커밋이 실패할 수 있습니다.

  • 컨피규레이션에는 잘못된 구문을 포함하고 있어 커밋 검사가 실패하게 됩니다.

  • 커밋하려는 후보 구성은 700MB보다 큽습니다.

  • 명령을 입력한 사용자가 구성을 잠근다 configure exclusive .

구성에 구문 오류가 포함되어 있으면 메시지가 오류 위치를 표시하며 구성이 활성화되지 않습니다. 오류 메시지에는 다음과 같은 형식이 있습니다.

예를 들어,

구성을 다시 시작하기 전에 오류를 수정해야 합니다. 오류가 있는 계층 수준으로 빠르게 돌아오려면 오류 첫 줄에서 경로를 복사하여 계층 수준에서 configuration 모드 프롬프트에 [edit] 붙여넣습니다.

커밋되지 않은 후보 구성 파일은 입니다 /var/rundb/juniper.db. 700MB로 제한됩니다. 메시지 configuration database size limit exceeded와 함께 커밋에 실패하면 명령 run file list /var/rundb detail을 입력하여 구성 모드에서 파일 크기를 확인합니다. 와일드카드로 구성 그룹을 만들거나 방화벽 필터에서 덜 구체적인 일치 정책을 정의하여 구성을 단순화하고 파일 크기를 줄일 수 있습니다.

주:

계층 수준의 구성 변경 [edit interfaces] 에 대해 표시되는 CLI 커밋 시간 경고가 제거되고 시스템 로그 메시지로 로깅됩니다.

이는 다음과 같은 계층 수준에서 VRRP 구성에도 적용됩니다.

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

구성을 커밋할 때는 현재 형식으로 전체 구성을 커밋합니다.

주:
  • 디바이스에서 graceful Routing Engine 스위치오버 가 실행될 때 백업 라우팅 엔진에서 커밋 작업을 수행할 것을 권장하지 않습니다.

  • GRES(Graceful Routing Engine Switchover)가 활성화될 때와 같은 fxp0 관리 인터페이스 또는 내부 인터페이스와 같은 ge-0/0/1외부 물리적 인터페이스를 위해 동일한 IP 주소를 구성하면, CLI는 전용 및 공용 인터페이스에서 동일한 주소가 발견된 적절한 커밋 오류 메시지를 표시합니다. 이 경우 중복 주소가 있는 두 인터페이스에 고유 IP 주소를 할당해야 합니다.

여러 사용자가 소프트웨어를 구성할 때 커밋 작업

최대 32명까지 구성 모드에서 동시에 구성을 변경할 수 있습니다. 모든 사용자가 변경한 내용은 구성을 편집하는 모든 사용자가 볼 수 있습니다. 사용자가 명령 setedit끝에 Enter 키를 누른 후 , 또는 delete.

구성을 편집하는 사용자가 명령을 실행 commit 하면 CLI는 모든 사용자의 모든 변경 사항을 검사하고 활성화합니다.

명령으로 구성 모드를 configure private 입력하면 각 사용자는 다른 사용자와 독립적으로 편집할 수 있는 전용 후보 구성을 가지고 있습니다. 구성을 커밋할 때 CLI는 사용자 고유의 변경 사항만 커밋합니다. 다른 사용자가 변경을 커밋한 후 구성 복사본을 동기화하려면 구성 모드에서 명령을 실행할 update 수 있습니다. 커밋 작업은 또한 모든 개인 지원자 구성을 업데이트합니다. 예를 들어 사용자 X와 사용자 Y가 모두 모드이고 configure private 사용자 X가 구성 변경을 커밋한다고 가정해 보겠습니다. 사용자 Y가 후속 커밋 작업을 수행한 다음 새 구성을 볼 때 사용자 Y가 볼 수 있는 새로운 구성에는 사용자 X에 의해 변경된 내용이 포함됩니다.

명령으로 구성 모드를 configure exclusive 입력하면 구성 모드로 유지된 기간 동안 후보 구성을 잠글 수 있습니다. 이를 통해 다른 사용자의 간섭 없이 변경할 수 있습니다. 다른 사용자는 구성 모드를 입력 및 종료할 수 있지만 구성을 커밋할 수는 없습니다. 명령어로 입력하기 전에 다른 사용자가 구성 모드로 입력한 경우에도 마찬가지입니다 configure exclusive . 예를 들어 사용자 X가 이미 또는 configure 모드에 있다고 configure private 가정해 보겠습니다. 사용자 Y가 모드에 들어간다고 가정해 보겠습니다 configure exclusive . 사용자 X는 사용자 Y가 로그인하기 전에 사용자 X가 해당 변경 사항을 입력한 경우에도 구성에 대한 변경을 커밋할 수 없습니다. 사용자 Y가 모드를 configure exclusive 벗어나면 사용자 X는 변경 사항을 커밋하거나 configure 모드에서 configure private 커밋할 수 있습니다.

커밋 준비 및 활성화 개요

커밋 프로세스를 두 단계로 완료할 수 있습니다. 2단계 커밋 기능을 사용하면 여러 디바이스를 구성하고 동시에 구성을 활성화할 수 있습니다. 2단계 커밋은 커밋이 시스템에서 효과를 발휘할 수 있는 확실한 시간을 제공합니다. 커밋을 준비한 후에는 커밋 모드를 입력할 수 있지만, 커밋이 활성화 대기 중이라는 메시지가 나타납니다.

첫 번째 단계에서는 준비 단계에서 커밋이 검증되고 필요한 파일이 있는 새 데이터베이스가 생성됩니다. 컨피규레이션에 구문 오류가 포함되어 있으면 적절한 오류 메시지가 표시되며 구성이 준비되지 않습니다. 준비 단계 중 장애가 발생하면 오류 메시지가 commit check-out failed표시됩니다.

두 번째 단계에서는 활성화 단계에서 이전에 준비한 구성이 활성화됩니다. 다음으로 준비된 구성을 지워야 하는 경우 명령을 사용하여 clear system commit prepared 이를 수행할 수 있습니다. 보류 중인 커밋을 성공적으로 지우면 로그 메시지가 생성됩니다.

주:

준비 및 활성화 단계 사이에 커밋 작업을 수행할 수 없습니다.

2단계 커밋 프로세스는 시간에 중요한 커밋을 위한 단일 단계 프로세스보다 우수합니다. 단일 단계 프로세스에서 준비 시간은 장비의 기존 구성에 따라 다를 수 있습니다. 2단계 프로세스에서는 복잡한 준비 작업을 보다 효율적으로 처리합니다.

구성 캐시를 준비하고 구성을 활성화할 수 있는 구성 명령이 제공됩니다. 새 구성으로 디바이스를 준비하고 원하는 정확한 시간에 디바이스를 활성화할 수 있습니다.

commit prepare 명령은 구성을 검증하고 commit activate 명령은 구성을 활성화합니다. 명령에는 다음과 같은 구성 옵션이 있습니다.

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

commit preparecommit activate 명령은 프라이빗, 독점 및 공유 커밋에서만 사용할 수 있습니다. 명령은 동적 및 임시 모드에는 적용되지 않습니다. 이 기능은 멀티섀시 디바이스에 적용할 수 있지만 일괄 커밋에는 해당되지 않습니다.

NETCONF(Network Configuration Protocol)를 사용하여 이러한 기능을 지원하려면 다음과 같은 새로운 RPC(Remote Procedure Call)가 제공됩니다.

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

주:
  • MX 시리즈 버추얼 섀시 설정에서는 다음을 적용합니다. commit prepare 스위치오버가 이어지는 라우팅 엔진 하나에 발행되면, 스위치오버 명령이 실행되는 Routing Engine은 재부팅됩니다. 따라서 준비된 캐시는 해당 Routing Engine에서 지워지게 되며,

  • MX 시리즈 Virtual Chassis 설정에서는 VC 기본에서만 명령을 실행하는 clear system commit prepared 것이 좋습니다.

커밋 디바이스 구성의 두 가지 단계: 준비 및 활성화

커밋 프로세스를 두 단계로 완료할 수 있습니다. 이를 통해 여러 디바이스를 구성할 수 있으며 구성을 동시에 활성화할 수 있습니다. 준비 단계로 알려진 첫 번째 단계에서는 커밋이 검증되고 필요한 파일과 함께 새로운 데이터베이스가 생성됩니다. 컨피규레이션에 구문 오류가 포함되어 있으면 적절한 오류 메시지가 표시되며 구성이 준비되지 않습니다. 활성화 단계라고 하는 두 번째 단계에서는 이전에 준비되었던 구성이 활성화되고 현재 운영 장비 구성이 됩니다.

구성을 준비하려면 다음을 수행합니다.

  1. 구성 모드의 [edit] 계층 수준에서 구성에 필요한 변경을 합니다.

    예를 들어 시스템의 스크립트를 구성하려면 다음 명령을 실행합니다.

    예를 들어,

  2. 명령을 실행합니다 commit prepare .

    메시지가 commit prepare successful 표시됩니다.

    준비 단계에 실패하면 오류 메시지가 commit check-out failed 표시됩니다.

  3. 발행 이후 commit prepare 명령의 출력을 show system commit 확인하려면 다음 명령을 사용합니다.

준비된 구성을 활성화하려면 다음을 수행합니다.

  1. 명령어 commit activate 사용

    메시지가 commit complete 표시됩니다.

  2. 활성화된 시스템 구성을 확인하려면 다음 명령을 사용합니다.

발행된 이후 commit activateshow system commit 명령어 출력 show system commit revision detail 을 확인하려면 다음 명령을 실행합니다.

확인을 통한 장비 구성 활성화

현재 후보 구성을 커밋할 때 커밋이 영구적으로 되도록 명시적으로 확인해야 할 수 있습니다. 이는 구성 변경이 올바르게 작동하고 장치에 대한 액세스를 차단하지 않는지 확인하려는 경우에 유용합니다. 변경으로 인해 액세스가 차단되거나 다른 오류가 발생하는 경우 장비는 롤백 확인 타임아웃이 통과한 후 자동으로 이전 구성으로 돌아와 액세스를 복원합니다. 이 기능을 자동 롤백이라고 합니다.

현재 후보 구성을 커밋하지만 커밋이 영구적으로 되도록 명시적으로 확인해야 하려면 구성 모드 명령을 사용합니다 commit confirmed .

변경이 올바르게 작동하는지 확인하면 명령의 10분 이내에 또는 commit check 명령을 입력 commit 하여 새 구성을 commit confirmed 활성 상태로 유지할 수 있습니다. 예를 들어,

특정 시간(기본적으로 10분) 내에 커밋이 확인되지 않으면 운영 체제가 자동으로 이전 구성으로 롤백되고 브로드캐스트 메시지가 로그인된 모든 사용자에게 전송됩니다.

명령 이후에 롤백이 스케줄링되는 commit confirmed 시기를 표시하려면 명령을 입력합니다 show system commit . 예를 들어,

명령어와 commit 마찬가지로 명령어도 commit confirmed 구성 구문을 확인하고 오류를 보고합니다. 오류가 없는 경우 구성이 일시적으로 활성화되고 (기본적으로 10분) 디바이스에서 실행되기 시작합니다.

그림 1: 구성 확인 구성 확인

새 구성을 확인해야 하기 전에 시간을 변경하려면 다음 명령을 실행할 때 분 수를 지정합니다.

또한 구성 모드에서 [edit private] 명령을 사용할 commit confirmed 수도 있습니다.

커밋 작업 예약

지원자 구성이 활성화될 일정을 수립할 수 있습니다. 디바이스 구성 변경을 저장하고 재부팅 시 디바이스에서 구성을 활성화하려면 [edit] 계층 수준에서 구성 모드 명령, 지정 reboot 또는 향후 시간을 사용 commit at 하십시오.

stringreboot 구성 변경을 활성화할 때입니다. 시간을 두 가지 형식으로 지정할 수 있습니다.

  • 양식 hh:mm[시간] (:ss시간, 분, 선택적으로 초)—지정된 시간에 구성을 커밋합니다. 해당 시간에는 향후 구성 모드 명령이 발행되는 날 commit at 오후 11시 59분 이전에 커밋합니다. 값은 hh 24시간을 사용합니다. 예를 들어 오전 04:30:00 4시 30분, 20:00 오후 8시입니다. 시간은 라우터의 클럭 및 시간대 설정에 따라 해석됩니다.

  • 양식 yyyy-mm-dd hh:mm의 날짜 및 시간 값[:ss] (연도, 월, 날짜, 시간, 분, 선택적으로 초)—명령이 발행된 이후 commit at 여야 하는 지정된 날짜 및 시간에 구성을 커밋합니다. 가치에는 24시간이 소요됩니다 hh . 예를 들어, 2018-08-21 12:30:00 2018년 8월 21일 오후 12시 30분입니다. 시간은 라우터의 클럭 및 시간대 설정에 따라 해석됩니다.

견적표(" ")에 값을 동봉 string 합니다. 예를 들어, commit at "18:00:00". 날짜와 시간에 대해 동일한 견적표 세트에 두 값을 모두 포함하십시오. 예를 들어 commit at "2018-03-10 14:00:00".

구성 모드 명령을 실행할 commit at 때 커밋 검사가 즉시 수행됩니다. 검사 결과가 성공하면 현재 사용자가 구성 모드에서 로그아웃되고 구성 데이터가 읽기 전용 상태로 남게 됩니다. 예약된 커밋이 완료될 때까지 다른 커밋을 수행할 수 없습니다.

주:

구성 변경이 활성화되기 전에 장비 소프트웨어에 장애가 발생하면 모든 구성 변경이 손실됩니다.

명령을 실행한 후에는 commit at 구성 명령을 입력할 request system reboot 수 없습니다.

향후 특정 시간 동안 커밋 작업을 예약하면 명령을 입력 request system reboot 할 수 없습니다.

예약된 커밋이 보류 중인 경우 구성을 커밋할 수 없습니다. 명령어로 clear 예약된 구성을 취소하는 방법에 대한 자세한 내용은 CLI Explorer를 참조하십시오.

주:

디바이스에서 graceful Routing Engine 스위치오버가 실행될 때 백업 라우팅 엔진에서 커밋 작업을 수행할 것을 권장하지 않습니다.

커밋 프로세스 모니터링

디바이스 구성 커밋 프로세스를 모니터링하려면 다음 명령어와 함께 commit 파이프 다음 명령을 사용합니다display detail.

예를 들어,

커밋된 구성을 설명하는 주석 추가

커밋된 구성의 변경 사항을 설명하는 설명을 포함할 수 있습니다. 이를 위해 성명서를 포함하십시오 commit comment . 주석은 512 바이트의 길이가 될 수 있으며 한 줄에 입력해야합니다.

comment-string 는 의견의 텍스트입니다.

주:

명령에 주석 commit check 을 포함할 수 없습니다.

명령어에 주석 commit 을 추가하려면 다음 명령어 다음을 commentcommit 포함한 명령문을 포함합니다.

명령어에 주석 commit confirmed 을 추가하려면 다음 명령어 다음을 commentcommit confirmed 포함한 명령문을 포함합니다.

이러한 커밋 설명을 보려면 운영 모드 명령을 실행 show system commit 하십시오.

주:

또한 구성 모드에서 [edit private] 명령을 사용할 commit confirmed 수도 있습니다.

일괄 커밋 개요

배치 커밋은 서로 다른 CLI 세션 또는 사용자의 여러 구성 편집을 집계하거나 병합하여 일괄 커밋 큐에 추가합니다. 장비에서 실행되는 일괄 커밋 서버는 일괄 커밋 큐에서 하나 이상의 작업을 수행하며 구성 변경 사항을 공유 구성 데이터베이스에 적용한 다음 단일 커밋 작업에서 구성 변경을 커밋합니다.

배치는 사용자가 지정한 일괄 처리의 우선 순위 또는 배치 작업이 추가되는 시간을 기준으로 커밋 서버에 의해 우선 순위가 지정됩니다. 단일 배치 커밋이 완료되면 다음 구성 변경 세트가 집계되어 배치 커밋 작업의 다음 세션을 위해 배치 큐에 로드됩니다. 큐 디렉토리에 커밋 엔트리가 남지 않을 때까지 배치가 생성됩니다.

모든 커밋이 독립적으로 순차적으로 커밋되는 일반 커밋 작업과 비교해 보면, 일괄 커밋은 단일 커밋 작업에서 여러 개의 작은 구성 편집을 커밋하여 시간과 시스템 리소스를 절약합니다.

일괄 처리 커밋은 구성 모드에서 [edit batch] 수행됩니다. 커밋 서버 속성은 계층 수준에서 구성할 [edit system commit server] 수 있습니다.

어그리게이션 및 오류 처리

집계된 작업 중 하나에 로드 시간 오류가 발생하면 오류가 발생하는 커밋 작업이 폐기되고 나머지 작업이 집계되고 커밋됩니다.

예를 들어, 5개의 커밋 작업(commit-1, , , commit-3commit-4commit-5)이 집계 commit-3 되고 로딩하는 commit-3 동안 오류가 발생하고 폐기되고 , , commit-4commit-2commit-5 통합 및 commit-1커밋됩니다. commit-2

2개 이상의 작업이 집계되고 커밋된 경우 커밋 작업 중에 오류가 발생하면 어그리게이션이 폐기되고 각 작업은 정기적인 커밋 작업처럼 개별적으로 커밋됩니다.

예를 들어 5개의 커밋 작업(commit-1, , , commit-3commit-4commit-5)이 집계되고 그로 commit-3인해 발생하는 커밋 오류가 있는 경우 어그리게이션은 폐기되고commit-1, commit-2commit-5commit-3commit-4개별적으로 커밋되며 CLI는 에 대한 commit-3커밋 오류를 보고합니다. commit-2

예를 들면 다음과 같습니다. 배치 커밋 서버 속성 구성

이 예에서는 일괄 커밋 서버 속성을 구성하여 일괄 커밋 작업을 관리하는 방법을 보여줍니다.

요구 사항

이 예에서는 다음과 같은 하드웨어 및 소프트웨어 구성 요소를 사용합니다.

  • MX 시리즈 5G 유니버설 라우팅 플랫폼

개요

계층 수준에서 서버 속성을 구성하여 일괄 커밋 큐가 커밋 서버에서 처리하는 방식을 제어할 [edit system commit server] 수 있습니다. 이를 통해 집계 또는 병합되는 커밋 작업 수, 대기열에 추가할 수 있는 최대 작업 수, 일괄 커밋 오류 로그를 유지하기 위한 일, 2개의 일괄 커밋 간 간격, 일괄 커밋 작업을 위한 추적 작업을 제어할 수 있습니다.

구성

CLI 빠른 구성

예제의 이 섹션을 신속하게 구성하려면 다음 명령을 복사하여 텍스트 파일에 붙여넣고, 줄 바꿈을 제거하고, 네트워크 구성에 필요한 세부 정보를 변경한 다음, 명령을 복사하여 계층 수준에서 CLI [edit] 에 붙여넣습니다. regular [edit] 모드 또는 [edit batch] 모드에서 커밋 서버 속성을 구성할 수 있습니다.

디바이스 R0

커밋 서버 속성 구성

단계별 절차
  1. (선택사항) 단일 커밋 작업에서 통합 또는 병합할 커밋 트랜잭션의 수를 구성합니다.

    기본값 maximum-aggregate-pool5.

    주:

    각 작업을 개별적으로 커밋하도록 1 설정 maximum-aggregate-pool

    이 예에서 커밋 트랜잭션의 수는 커밋 작업이 시작되기 전에 네 개의 서로 다른 커밋 작업이 단일 커밋으로 집계됨을 나타내는 것으로 설정 4 됩니다.

  2. (선택사항) 일괄 처리에 허용되는 최대 작업 수를 구성합니다.

    이는 큐에 추가되는 커밋 작업의 수를 제한합니다.

    주:

    설정 maximum-entries1하면 커밋 서버가 대기열에 두 개 이상의 작업을 추가할 수 없으며, 두 개 이상의 작업을 커밋하려고 할 때 CLI가 적절한 메시지를 표시합니다.

  3. (선택사항) 다음 일괄 커밋 작업을 시작하기 전에 기다릴 시간을 몇 초만에 구성합니다.

  4. (선택사항) 오류 로그를 유지하도록 일 수를 구성합니다.

    기본값은 며칠입니다 30 .

  5. (선택사항) 일괄 커밋 이벤트를 기록하도록 추적 작업을 구성합니다.

    이 예에서는 일괄 커밋 이벤트를 로깅하기 위한 파일 이름은 이며 commitd_nov모든 traceoption 플래그가 설정됩니다.

결과

구성 모드에서 명령을 입력하여 구성을 show system commit server 확인합니다. 출력이 의도한 구성을 표시하지 않는 경우 이 예제의 지침을 반복하여 구성을 수정합니다.

Batch Configuration 모드에서 구성 커밋

단계별 절차

모드에서 구성을 [edit batch] 커밋하려면 다음 중 하나를 수행합니다.

  • 디바이스에 로그인하고 를 입력합니다 commit.

  • 일괄 처리 커밋 작업에 더 높은 우선 순위를 할당하려면 해당 옵션을 명령어로 발행 commit 하십시오 priority .

  • 큐의 다른 커밋 작업과 함께 구성 변경 사항을 집계하지 않고 구성을 커밋하려면 해당 옵션을 명령어로 발행 commit 하십시오 atomic .

  • 큐의 다른 커밋 작업과 함께 구성 변경 사항을 어그리게이션하고 커밋 작업에 commit 더 높은 우선 순위를 발행하지 않고 구성을 커밋하려면 명령에서 atomic priority 옵션을 실행합니다.

확인

구성이 올바르게 작동하는지 확인합니다.

Batch Commit 서버 상태 확인

목적

일괄 커밋 서버의 상태를 확인합니다.

실행

기본적으로 커밋 서버 Not running의 상태는 . 일괄 커밋 작업이 큐에 추가된 경우에만 커밋 서버가 실행됩니다.

일괄 커밋 작업이 큐에 추가되면 커밋 서버의 상태가 으로 변경됩니다 Running.

의미

필드에는 Jobs in process 진행 중인 작업의 커밋 IP가 나열되어 있습니다.

배치 커밋 상태 확인

목적

일괄 커밋 상태를 확인하려면 커밋 서버 큐를 선택합니다.

실행
의미

Pending commits 커밋 큐에 추가되었지만 아직 커밋되지 않은 커밋 작업을 표시합니다. Completed commits 성공한 커밋 작업 목록을 표시합니다. Error commits 오류로 인해 실패한 커밋입니다.

일괄 커밋 작업에서 패치 파일 보기

목적

타임스탬프, 패치 파일 및 각 커밋 작업의 상태를 확인합니다. 패치 파일에는 일괄 커밋 큐에 추가되는 각 커밋 작업에서 발생하는 구성 변경이 표시됩니다.

실행
  1. show system commit server queue patch 명령을 사용하여 모든 커밋 작업에 대한 패치를 볼 수 있습니다.

    출력은 각 커밋 작업 ID에 대한 구성의 변경을 보여줍니다.

  2. 특정 커밋 작업 ID에 대한 패치를 보려면 명령을 실행하십시오 show system commit server queue patch id <id-number> .

의미

출력은 커밋 작업을 위해 생성된 패치를 보여줍니다. 또는 - 기호는 + 특정 커밋 작업에 대한 구성의 변경을 나타냅니다.

배치 커밋 작업을 위한 Trace 파일 보기

목적

일괄 커밋 작업을 위해 추적 파일을 봅니다. 문제 해결 목적으로 추적 파일을 사용할 수 있습니다.

실행
  • file show /var/log/<filename> 명령을 사용하여 로그 파일의 모든 항목을 볼 수 있습니다.

    결과물은 일괄 커밋을 위한 커밋 서버 이벤트 로그 및 기타 로그를 보여줍니다.

  • 성공적인 일괄 커밋 작업에 대해서만 로그 항목을 보려면 파이프 옵션을 명령어로 | match committed 발행 file show /var/log/<filename> 합니다.

    결과물은 성공적인 커밋 작업을 위한 일괄 커밋 작업 IP를 보여줍니다.

  • 실패한 일괄 커밋 작업에 대해서만 로그 항목을 보려면 파이프 옵션을 명령어로 | match “Error while” 발행 file show /var/log/<filename> 합니다.

    출력은 실패한 커밋 작업에 대한 커밋 작업 ID를 보여줍니다.

  • 커밋 서버 이벤트에 대한 로그 엔트리만 보려면 파이프 옵션을 명령어로 | match “commit server” 발행 file show /var/log/<filename> 하십시오.

    출력은 커밋 서버 이벤트 로그를 보여줍니다.

Alternate Boot Drive에서 커밋된 구성 백업

구성을 커밋하고 실행 중임을 충족한 후에는 파일 시스템에 새 소프트웨어를 /altconfig 백업하는 명령을 실행 request system snapshot 해야 합니다. 명령을 실행 request system snapshot 하지 않으면 대체 부트 드라이브의 구성이 기본 부트 드라이브의 구성과 동기화되지 않습니다.

명령어로 request system snapshot 루트 파일 시스템을 /altroot백업합니다 /config/altconfig. 루트 및 /config 파일 시스템은 라우터의 플래시 드라이브에 있고 /altroot/altconfig 파일 시스템은 라우터의 하드 디스크에 있습니다(가능한 경우).

명령문을 실행한 request system snapshot 후 소프트웨어의 실행 및 백업 복사본이 동일하기 때문에 이전 버전의 소프트웨어로 돌아갈 수 없습니다.