Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의
 

Junos XML 프로토콜을 사용하여 중복 컨트롤 플레인에서 구성 커밋 및 동기화

라우팅 엔진은 컨트롤 플레인 내에 위치합니다. 단일 섀시 구성의 경우 하나의 컨트롤 플레인이 있습니다. 이중화된 시스템에는 2개의 컨트롤 플레인, 기본 플레인 및 백업 플레인이 있습니다. 멀티섀시 구성에서 컨트롤 플레인에는 동일한 라우팅 엔진이 지정된 모든 라우팅 엔진이 포함됩니다. 예를 들어, 모든 기본 라우팅 엔진은 기본 컨트롤 플레인 내에 상주하며 모든 백업 라우팅 엔진은 백업 컨트롤 플레인 내에 상주합니다.

구성을 커밋하는 것은 장비 엔진에 새로운 구성을 적용합니다. 멀티섀시 구성에서 구성 변경이 시스템에 커밋되면 이 변경은 디스트리포션 기능을 사용하여 컨트롤 플레인 전체로 전파됩니다.

이중 아키텍처에서 기본 및 백업 컨트롤 플레인 모두에 새 구성을 커밋하는 명령을 실행할 synchronize 수 있습니다. 이 명령이 실행되면 디바이스 라우팅 엔진에 대한 현재 구성을 저장하고 두 컨트롤 플레인 모두에 새로운 구성을 커밋합니다. 멀티섀시 시스템에서 구성이 두 플레인에서 모두 커밋되면 디스트리포션 기능은 두 플레인에 걸쳐 새로운 구성을 배포합니다. Routing Engine 이중화에 대한 자세한 내용은 Junos OS 고가용성 사용자 가이드를 참조하십시오.

참고:

이중 컨트롤 플레인을 갖춘 멀티섀시 아키텍처에서는 두 플레인을 동기화하는 것과 각 플레인 전반에 걸쳐 구성을 분산시키는 것 사이에 차이가 있습니다. 동기화는 동일한 섀시 내의 라우팅 엔진 간에만 발생합니다. 동기화가 완료되면, 새로운 구성은 별도의 분산 기능으로 다른 섀시의 컨트롤 플레인 내의 다른 모든 라우팅 엔진에 배포됩니다.

동기화는 2개의 개별 컨트롤 플레인에서 이루어지기 때문에 구성 동기화는 이중화된 Routing Engine 아키텍처에서만 유효합니다. 또한 re0 및 re1 구성 그룹은 각 라우팅, 스위칭 또는 보안 플랫폼에 정의되어야 합니다. 구성 그룹에 대한 자세한 내용은 CLI 사용자 가이드를 참조하십시오.

참고:

무중단 라우팅 엔진 시스템에서 명령을 실행 synchronize 하면 Junos XML 프로토콜 서버가 하나의 컨트롤 플레인에서 구성을 커밋합니다.

임시 구성 데이터베이스 동기화에 대한 자세한 내용은 NETCONF 또는 Junos XML 프로토콜을 사용하여 Ephemeral Configuration Data의 커밋 및 동기화를 참조하십시오. 지원자 구성 동기화에 대한 자세한 내용은 다음 섹션을 참조하십시오.

두 라우팅 엔진에서 후보 구성 동기화

이중화된 Routing Engine 시스템에서 후보 컨피규레이션 또는 프라이빗 카피를 동기화하기 위해 클라이언트 애플리케이션은 빈 <synchronize/> 태그 <commit-configuration> 와 <rpc> 태그 요소를 동봉합니다.

Junos XML 프로토콜 서버는 태그가 방출되는 라우팅 엔진(로컬 라우팅 엔진 <synchronize/> 이라고 함)에서 구성의 구문 정확성을 확인하고, 컨피규레이션을 원격 라우팅 엔진으로 복사한 후, 그곳에서 구문 정확성을 확인한 다음, 두 라우팅 엔진 모두에서 구성을 커밋합니다.

Junos XML 프로토콜 서버는 응답 <rpc-reply> <commit-results> 과 태그 요소를 동봉합니다. 각 라우팅 엔진의 각 작동에 대해 별도의 <routing-engine> 태그 요소를 내 방출합니다.

  • 구문 검사가 Routing Engine에서 성공하면 태그 <routing-engine> 요소가 태그와 <name> 태그 요소를 포함 <commit-check-success/> 하며, 이 태그 요소는 검사가 성공한 Routing Engine의 이름(re0 또는 re1)을 보고합니다.

    구성이 올바르지 <xnm:error> 않으면 태그 요소가 오류에 대한 설명을 동봉합니다.

  • 커밋 작업이 Routing Engine에서 성공하면 태그 <routing-engine> 요소는 커밋 작업이 성공한 Routing Engine의 이름을 보고하는 태그 요소와 <name> 태그 요소를 동봉 <commit-success/> 합니다.

    커밋 작업에 실패 <xnm:error> 하면 태그 요소가 오류에 대한 설명을 동봉합니다. 장애의 가장 일반적인 원인은 구성에서 의미론적 또는 구문 오류입니다.

다음 예제에서는 두 라우팅 엔진에서 후보 구성을 커밋하고 동기화하는 방법을 보여 줍니다.

동기화된 커밋 작업 강제

두 번째 Routing Engine의 후보 컨피규레이션이 잠기면 동기화 작업이 실패합니다. 동기화 장애가 발생하면 장애의 원인을 파악하고 교정 조치를 취한 다음 두 라우팅 엔진을 다시 동기화하는 것이 가장 좋습니다. 그러나 필요할 경우 이 명령을 사용하여 <force-synchronize/> 잠긴 구성을 무효화하고 동기화를 강제할 수 있습니다.

참고:

명령을 사용하면 force-synchronize 구성에 대한 커밋되지 않은 변경이 손실됩니다.

동기화를 강제로 실행하려면 빈 <synchronize/> 요소와 <force-synchronize/> 태그를 다음 요소에 <rpc> <commit-configuration> 동봉합니다.

참고:

멀티섀시 환경에서는 동일한 섀시의 라우팅 엔진 간에 동기화가 이루어집니다. 동기화가 발생하면 구성 변경이 배포 기능을 사용하여 각 컨트롤 플레인에 전파됩니다. 구성 배포 중에 하나 이상의 라우팅 엔진이 잠겨 있으면 배포가 실패합니다. 원격 섀시의 오류를 지우고 명령을 다시 실행 synchronize 해야 합니다.

다음 예에서는 라우팅 엔진 플레인 모두에서 동기화를 강제하는 방법을 보여줍니다.

클라이언트 애플리케이션

Junos XML 프로토콜 서버

 
<rpc>
    <commit-configuration>
        <synchronize/>
        <force-synchronize/>
    </commit-configuration>
</rpc>
  
<rpc-reply xmlns:junos=
             "http://xml.juniper.net/junos/9.010/junos">
    <commit-results>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-check-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re1</name>
            <commit-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-success/>
        </routing-engine>
    </commit-resuls>
</rpc-reply>

후보 구성을 다른 작업과 동시에 동기화

태그는 <synchronize/> 태그 요소 내에서 발생할 수 있는 다른 태그 요소와 <commit-configuration> 결합할 수 있습니다. Junos XML 프로토콜 서버는 태그 자체에서 사용될 때 <synchronize/> 와 동일한 응답 태그 요소를 검사, 복사 및 커밋합니다. 가능한 조합은 다음 섹션에서 설명합니다.

두 라우팅 엔진 모두에서 구성 확인

커밋하지 않고 두 Routing Engine에서 로컬 컨피규레이션의 구문적 정확성을 검사하기 위해 애플리케이션은 요소 및 태그 요소에 <synchronize/> <commit-configuration> 해당 요소 및 <check/> <rpc> 태그 요소를 동봉합니다.

태그는 <force-synchronize/> 태그 요소와 <check/> 결합할 수 없습니다.

구성 확인에 대한 자세한 내용은 Junos XML 프로토콜을 사용하여 구성 구문 검증을 참조하십시오.

지정된 시간에 대한 동기화 스케줄링

향후 지정된 시간에 두 라우팅 엔진에 대한 구성을 커밋하기 위해 애플리케이션은 다음 요소와 태그 요소에 <commit-configuration> 해당 요소와 <rpc> <at-time> 태그 요소를 동봉합니다<synchronize/>.

태그 요소가 스스로 방출될 때 <at-time> 와 마찬가지로, Junos XML 프로토콜 서버는 구문의 정확성을 즉시 검증하며, 실제로 각 라우팅 엔진에서 커밋 작업을 수행할 때 추가 태그 요소를 내보내지 않습니다.

구성 동기화하지만 확인 필요

RE(Routing Engines)에서 후보 구성을 커밋하지만 커밋이 영구적으로 실행되도록 확인해야 하려면, 애플리케이션은 에 , <confirmed/>(선택적으로) <confirm-timeout> 태그 요소 및 <rpc> 태그 요소를 <commit-configuration> 동봉<synchronize/>합니다.

동일한 롤백 기한은 RE(Routing Engines)에 적용되며, 태그 요소가 처음 방출된 Routing Engine에서 (<confirmed/>선택적으로) <confirm-timeout> 태그 요소를 다시 방출함으로써 <synchronize/>한꺼번에 연장될 수 있습니다.

태그는 <force-synchronize/> 및 태그 요소와 <confirmed/> <confirm-timeout> 결합할 수 없습니다.

확인된 커밋 작업에 대한 자세한 내용은 Junos XML 프로토콜을 사용하여 확인 후에만 후보 구성 커밋을 참조하십시오.

동기화된 구성에 대한 메시지 로깅

각 Routing Engine에서 커밋이 성공할 때 구성을 동기화하고 로그 메시지를 기록하기 위해 애플리케이션은 요소 및 태그 요소에 <commit-configuration> 해당 요소와 <log/> <rpc> 태그 요소를 동봉합니다<synchronize/>.

커밋 작업은 또는 <force-synchronize/> 태그 설명에 앞서 설명한 <synchronize/> 대로 진행됩니다. 각 라우팅 엔진에 대한 메시지는 해당 라우팅 엔진이 유지 관리하는 커밋 히스토리 로그에 기록됩니다. 로깅에 대한 자세한 내용은 Junos XML 프로토콜을 사용하여 커밋 작업에 대한 메시지 로깅을 참조하십시오.

관련 설명서