이 페이지의 내용

지원되는 RPC
네트워크 디바이스 구성
경로 수정
경로 가져오기
플러시 경로

gRIBI

gRPC 라우팅 정보 베이스 인터페이스(gRIBI)는 외부 애플리케이션이 네트워크 디바이스에서 경로를 프로그래밍 방식으로 추가, 수정 및 제거할 수 있도록 하는 gRPC 서비스입니다.

gRIBI 서비스는 디바이스의 라우팅 정보 베이스(RIB, 라우팅 테이블이라고도 함)에서 라우팅 항목을 추가, 수정 및 제거하기 위한 라우팅 테이블입니다. 항목이 포워딩 자격이 있는 경우 운영 체제는 디바이스의 포워딩 정보 베이스(FIB, 포워딩 테이블라고도 함)에 항목을 자동으로 추가합니다. gRIBI 클라이언트 애플리케이션은 주니퍼 Extension Toolkit(JET)에서 지원하는 모든 언어를 사용할 수 있습니다. 클라이언트 응용 프로그램은 외부 네트워크 관리 시스템에서 실행되거나 네트워크 디바이스에서 로컬 응용 프로그램으로 실행할 수 있습니다.

gRIBI 서비스 프로토 정의 파일은 https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto 에 있습니다. Junos 디바이스에서 지원하는 gRIBI 메시지는 JET IDL 패키지에 있습니다.

OpenConfig AFT(Abstract Forwarding Table) 모델은 네트워크 디바이스에 설치된 포워딩 항목을 설명하는 YANG 데이터 모델입니다. gRIBI는 OpenConfig AFT 모델의 프로토콜 버퍼 변환 버전을 사용하여 수정할 수 있는 RIB 항목을 설명합니다. OpenConfig AFT 스키마의 protobuf 표현은 https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto 에 있는 proto 정의 파일에 있습니다.

gRIBI의 이점:

경로를 프로그래밍할 때 확인을 보냅니다.
계층 조회를 지원합니다.
여러 클라이언트가 gRIBI 세션에 연결된 경우 중재를 지원합니다.

이 명령을 사용하여 show route extensive 경로에서 사용하는 클라이언트 ID 및 다음 홉 그룹 ID를 포함한 gRIBI에 대한 경로 데이터를 표시합니다.

참고:

특히 동일한 경로 집합의 경우 gRIBI 또는 JET RIB 서비스 API를 동시에 사용하지 않는 것이 좋습니다.

지원되는 RPC

Junos 디바이스는 gRIBI 서비스 RPC를 지원하여 디바이스의 RIB에서 경로를 원격으로 검색, 추가, 수정 또는 삭제할 수 있습니다. RPC는 디바이스에서 추상 포워딩 테이블(AFT)을 수정하거나 읽는 방식으로 작동합니다.

표 1: 지원되는 gribi.proto RPC
RPC	정의	릴리스에 도입된 내용
`Modify()`	AFT에서 항목을 추가, 수정 또는 삭제합니다.	Junos OS 릴리스 19.4R1 Junos OS Evolved 릴리스 20.3R1
`Get()`	AFT에서 설치된 항목을 검색합니다.	Junos OS Evolved 22.2R1
`Flush()`	메시지에 `FlushRequest` 설명된 내용과 일치하는 디바이스의 모든 AFT 항목을 제거합니다.	Junos OS Evolved 22.2R1

Junos OS Evolved 릴리스 23.4R1 이상

시작하기 전에:

gRPC 서비스 구성에 설명된 대로 네트워크 디바이스에서 gRPC 서비스를 구성합니다.

gRIBI를 위한 네트워크 디바이스 구성:

필터 기반 포워딩으로 라우팅 인스턴스를 생성합니다.

두 개의 정책을 구성합니다. 하나는 다중 경로 해결을 처리하고 다른 하나는 로드 밸런싱을 처리합니다.

이 예에서는 라는 mp-resolve 정책이 다중 경로 확인을 처리합니다. 확인 경로에 여러 경로가 있는 경우 확인된 경로는 모든 경로에 대해 해결됩니다. 이 정책 pplb 은 패킷 포워딩 엔진에 각 패킷에 대한 트래픽을 로드 밸런싱하도록 지시합니다.

시스템이 경로를 업데이트할 수 있는 충분한 시간을 주기 위해 잔여 보류 시간을 설정합니다. 시스템이 재동된 후, rpd 프로세스는 경로를 정리하기 전에 잔여 보류 시간이 만료될 때까지 기다립니다. rpd 프로세스는 대기 시간이 만료되기 전에 업데이트된 경로를 삭제하지 않습니다.
이제 gRIBI 서비스 RPC를 사용할 준비가 되었습니다.

Junos OS Evolved 릴리스 23.4R1 이전

시작하기 전에:

gRPC 서비스 구성에 설명된 대로 네트워크 디바이스에서 gRPC 서비스를 구성합니다.

gRIBI를 위한 네트워크 디바이스 구성:

필터 기반 포워딩으로 라우팅 인스턴스를 생성합니다.

라우팅 인스턴스에서 기본, IPv4 제품군 프로토콜 및 IPv6 제품군 프로토콜 경로 확인에 사용할 라우팅 라우팅 테이블을 구성합니다.
각 프로토콜 제품군에 대해 최대 2개의 라우팅 테이블을 지정할 수 있습니다. 경로 확인 체계는 첫 번째 라우팅 테이블에서 프로토콜 다음 홉 주소에 대한 항목을 찾을 수 없는 경우에만 두 번째 라우팅 테이블을 확인합니다.

이 예에서 은(는teVRF.inet.0) 기본 라우팅 테이블입니다. 해당 라우팅 테이블에 다음 홉 주소에 대한 경로가 없는 경우, 경로 솔루션 체계는 테이블을 확인합니다.inet.3

IPv4 및 IPv6 패밀리 확인 트리에 대한 가져오기 정책을 지정합니다.

예를 들면 다음과 같습니다.

두 개의 정책을 구성합니다. 하나는 다중 경로 해결을 처리하고 다른 하나는 로드 밸런싱을 처리합니다.

포워딩 플레인에 다음 홉을 설치할 때 다음 홉 계층을 보존하도록 라우팅 옵션을 구성합니다.

IPv4 및 IPv6 제품군 프로토콜 경로 해결에 사용할 라우팅 테이블과 라우팅 옵션 수준에서 경로 해결을 위한 정책을 구성합니다. 라우팅 인스턴스 수준에서 구성한 각 라우팅 테이블에 대해 이 구성을 반복합니다.

예를 들면 다음과 같습니다.

시스템이 경로를 업데이트할 수 있는 충분한 시간을 주기 위해 잔여 보류 시간을 설정합니다. 시스템이 재동된 후, rpd 프로세스는 경로를 정리하기 전에 잔여 보류 시간이 만료될 때까지 기다립니다. rpd 프로세스는 대기 시간이 만료되기 전에 업데이트된 경로를 삭제하지 않습니다.
이제 gRIBI 서비스 RPC를 사용할 준비가 되었습니다.

경로 수정

RPC를 Modify() 사용하여 gRIBI 서버의 RIB에서 새 경로를 설치하고 기존 경로를 편집합니다. 경로가 정적 경로로 추가됩니다.

Modify()양방향 스트리밍 RPC입니다. 클라이언트는 서버의 AFT 항목을 수정하기 위한 메시지가 포함된 ModifyRequest RPC를 보냅니다Modify(). 각 ModifyRequest에 대해 gRIBI 서버는 메시지로 ModifyResponse 클라이언트에 응답합니다.

메시지는 ModifyRequest 하나 이상의 AFTOperation 메시지로 구성됩니다. 각 AFTOperation 메시지는 단일 AFT 항목을 추가, 수정 또는 제거하라는 요청을 정의합니다. gRIBI 서버는 RPC가 스트리밍하는 순서 Modify() 대로 AFT 작업을 처리합니다.

Junos 디바이스는 다음과 같은 AFT 항목 유형을 지원합니다.

IPv4Entry- IPv4 경로를 프로그래밍합니다.
NextHopEntry- 다음 홉을 프로그래밍합니다.
NextHopGroup- 다음 홉 그룹을 프로그래밍합니다.

RPC를 Modify() 사용하여 다음 기능을 수행합니다.

경로 승인
IPv4 경로 프로그래밍
다음 홉 및 다음 홉 그룹 프로그래밍
MAC 주소를 사용하여 다음 홉 프로그래밍
계층 조회 및 IP-in-IP 터널링
다중 클라이언트에 대한 중재
VRF 인스턴스에서 폴백 경로 프로그래밍
VRF 인스턴스 선택
정책 기반 포워딩

경로 승인

RPC를 사용하여 Modify() 패킷 포워딩 엔진에서 경로를 성공적으로 프로그래밍하면 서버는 확인을 보냅니다. gRIBI API가 주어진 시간 제한 기간 내에 패킷 포워딩 엔진의 경로를 프로그래밍하지 못하면 서버는 오류 메시지를 보냅니다. 이 시간 초과의 길이를 구성할 수 있습니다. 승인은 가장 최근의 경로에만 유효합니다. 이전 경로는 승인을 보지만 새 경로는 수신 확인을 보내지 않는 경우, 패킷 포워딩 엔진은 이를 오류로 기록합니다.

Junos 디바이스는 메시지 AFTOperation필드에서 entry 다음 값을 지원합니다.

참고:

Junos 디바이스는 이 MAC_ENTRY 옵션을 지원하지 않습니다.

명령을 사용하여 show route extensive 승인 상태를 표시합니다. 승인 상태는 rpd 프로세스가 다시 시작되어도 지속됩니다.

IPv4 경로 프로그래밍

IPv4 경로를 프로그래밍하려면 AFT 항목을 사용합니다 IPv4Entry . AFT는 대상 주소를 기반으로 입력 패킷을 일치시키고 해당 다음 홉에 매핑합니다. 네트워크의 기본 VRF 인스턴스와 트래픽 엔지니어링 VRF 인스턴스에 AFT 항목을 설치합니다. 기본이 아닌 인스턴스에 AFT 항목을 설치하려면 메시지 필드에서 network_instance VRF 인스턴스를 지정합니다. AFTOperation 예를 들면 다음과 같습니다.

트래픽 엔지니어링 VRF 인스턴스: g_b4_cos1
필드를 network_instance 다음으로 설정합니다. g_b4_cos1

gRIBI 클라이언트는 서버가 관련 NextHopGroup AND NextHop 메시지를 수신했다는 확인을 서버로부터 받은 후에만 서버에서 AFT 항목을 프로그래밍 IPv4Entry 합니다. 클라이언트가 메시지에 대한 NextHopGroup 승인 없이 서버에서 AFT 항목을 프로그래밍 IPv4Entry 하는 경우 숨겨진 경로로 서버에 경로를 추가합니다.

다음 홉 및 다음 홉 그룹 프로그래밍

gRIBI Modify() RPC를 사용하여 gRIBI 서버에서 다음 홉 또는 다음 홉 그룹을 프로그래밍합니다. RPC는 기본 VRF 인스턴스 내에 다음 홉과 다음 홉 그룹만 생성합니다.

동일한 ModifyRequest 메시지에 다음 홉과 다음 홉 그룹이 있는 경우, gRIBI 클라이언트는 AFT 작업에 따라 이를 처리합니다. AFT 작업이 추가 NextHop 및 NextHopGroup 입력되면 클라이언트는 다음 홉 그룹을 추가하기 전에 모든 다음 홉을 서버에 추가합니다. AFT 작업이 삭제하고 NextHopGroup 입력하는 NextHop 경우 클라이언트는 반대 순서로 처리합니다. 다음 홉을 삭제하기 전에 모든 다음 홉 그룹을 삭제합니다.

Junos 디바이스에서 RPC는 테이블의 inet6.3 다음 홉을 로 인스턴스화합니다. FC01::next_hop_id여기서 다음 홉 ID는 16진수 입니다. 예를 들어, 다음 홉 ID가 10이면 서버는 테이블에 호출된 FC01::A 경로를 설치합니다.inet6.3

다음 홉 그룹은 테이블에 inet6.3 로 나타납니다.FC02::next_hop_id 예를 들어, 다음 홉 그룹 ID가 100이면 서버는 테이블에서 호출된 FC02::64 경로를 설치합니다.inet6.3

예를 들어, 직접 도달 가능한 인터페이스를 통해 다음 홉 개체를 프로그래밍하려면 다음을 수행합니다.

주소 10.0.1.2가 인터페이스 et-0/0/7.0을 통해 도달할 수 있다고 가정하고 메시지에 Afts 다음 필드를 설정합니다. 여기서 =는 필드를 해당 값으로 설정합니다.

다음과 같이 메시지 필드를 AFTOperation 설정합니다.

위에서 ModifyRequest 정의한 것을 AFTOperation 사용하도록 메시지를 설정합니다.
위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.
경로가 성공적으로 프로그래밍되었는지 확인하려면 CLI에서 명령을 사용합니다 show route programmed .

MAC 주소를 사용하여 다음 홉 프로그래밍

선택적으로 IP 주소 대신 MAC 주소로 다음 홉을 식별할 수 있습니다. 이 기능은 디바이스가 동적 ARP(Address Resolution Protocol) 또는 NDP(Neighbor Discovery Protocol)를 사용하여 다음 홉의 MAC 주소를 조회할 수 없는 네트워크에서 유용합니다. MAC 주소를 사용하려면 AFT 메시지에서 필드 대신 ip_address 필드를 사용합니다mac_address.

참고: 이 인터페이스를 사용하는 모든 트래픽은 gRIBI 서비스에 의해 프로그래밍된 정적 MAC 주소를 사용하며, gRIBI 서비스로 프로그래밍되지 않은 경로의 트래픽도 마찬가지입니다.

gRIBI 서비스를 사용하여 인터페이스의 다음 홉으로 MAC 주소를 프로그래밍한 후에는 디바이스는 이 인터페이스를 사용하는 모든 트래픽에 대해 동적 ARP 또는 NDP를 사용하지 않습니다. 클라이언트의 연결이 끊어질 때 프로그래밍된 gRIBI 다음 홉이 삭제되거나 제거되면, 디바이스는 인터페이스에서 ARP를 자동으로 다시 활성화하고 경로는 동적 ARP를 사용하여 계속 작동합니다.

예를 들어, 직접 도달 가능한 인터페이스를 통해 MAC 주소로 다음 홉 개체를 프로그래밍하려면 다음을 수행합니다.

다음 홉으로 프로그래밍하려는 인터페이스가 번호가 매겨진 인터페이스인지 확인합니다.
인터페이스에서 IPv6 family가 활성화되어 있는지 확인합니다.
MAC 주소 00:00:5E:00:53:00이 인터페이스 et-0/0/7.0을 통해 도달할 수 있다고 가정하고 메시지에서 Afts 다음 필드를 설정합니다. 여기서 =는 필드를 해당 값으로 설정합니다.

다음과 같이 메시지 필드를 AFTOperation 설정합니다.

위에서 ModifyRequest 정의한 것을 AFTOperation 사용하도록 메시지를 설정합니다.
위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.
경로가 성공적으로 프로그래밍되었는지 확인하려면 CLI에서 명령을 사용합니다 show route programmed .

계층 조회 및 IP-in-IP 터널링

gRIBI의 Junos 구현은 계층적 조회를 지원합니다. 계층 조회를 구성하려면 IPv4 AFT를 사용하여 IP-IP 터널 엔드포인트 및 사이트 그룹 가상 IP 주소 경로를 프로그래밍합니다.

IP-in-IP 터널의 수신 노드에서 트래픽을 캡슐화하려면 메시지에서 다음 필드를 설정합니다.NextHop

다중 클라이언트에 대한 중재

RPC는 Modify() 여러 클라이언트가 gRIBI 서버에 연결되어 있을 때 중재를 지원합니다. 중재는 어떤 클라이언트가 어떤 작업을 수행할 수 있는지를 결정합니다.

메시지를 사용하여 SessionParameters gRIBI 클라이언트에 대한 지속 모드 및 클라이언트 중복 모드를 설정합니다. 모든 클라이언트는 메시지의 모든 속성에 대해 동일한 값을 보내야 합니다. SessionParameters SessionParameters 세션 수명 동안 한 번만 전송해야 합니다.

SessionParameters 재연결 후 전송된 첫 번째 메시지여야 합니다. 클라이언트가 다시 연결되면 새 세션이 시작됩니다. 다른 클라이언트가 이미 연결되어 있는 경우 메시지 값을 기존 클라이언트가 설정한 값과 일치 SessionParameters 시킵니다. 모든 클라이언트가 다시 연결되면 메시지 값을 이전 세션에서 사용된 값과 다른 값으로 설정할 SessionParameters 수 있습니다.

Junos 디바이스는 및 DELETE 지속성 모드를 모두 PRESERVE 지원합니다. 지속성 모드가 로 PRESERVE설정된 경우, 서버는 클라이언트 연결이 끊어진 후에도 클라이언트가 추가한 AFT 항목을 보존합니다. 지속 모드가 로 DELETE설정된 경우, 클라이언트의 연결이 끊어질 때 서버는 AFT 항목을 삭제합니다.

세션 매개 변수를 변경하기 전에 모든 경로를 삭제하는 것이 좋습니다. 세션 매개 변수를 변경하고 다른 모드에서 경로를 추가한 후 중복 모드를 ALL_PRIMARY SINGLE_PRIMARY 전환하면 예기치 않은 동작이 발생할 수 있습니다.

클라이언트가 여러 개 있는 경우 다음 두 가지 클라이언트 중복 모드 중 하나를 선택해야 합니다.

모든 기본 모드
단일 기본 모드

모든 기본 모드

중복 모드에서 ALL_PRIMARY :

모든 클라이언트는 경로를 수정할 수 있습니다.
여러 클라이언트가 동일한 AFT 항목을 추가할 수 있습니다.
gRIBI API는 어떤 클라이언트가 경로를 추가했는지에 대한 매핑을 유지합니다.
첫 번째 추가 작업은 RIB에 항목을 추가합니다. 다른 클라이언트의 동일한 항목에 대한 후속 추가 작업은 해당 항목을 참조하는 클라이언트 목록에 클라이언트를 추가합니다.
삭제 작업은 항목을 참조하는 클라이언트 목록에서 클라이언트를 제거합니다. 항목을 참조하는 클라이언트가 없는 경우에만 항목이 삭제됩니다.

참고:

처리되면 FlushRequest 참조 카운트 검사 없이 항목이 삭제됩니다.

명령을 사용하여 show route extensive 경로의 세부 정보를 봅니다. 다음은 명령이 show route extensive 모드에서 표시되는 ALL_PRIMARY 내용의 예입니다. 명확성을 위해 출력이 단축되었습니다.

단일 기본 모드

중복 모드에서 SINGLE_PRIMARY :

gRIBI 클라이언트는 기본(활성) 또는 백업 역할을 가질 수 있습니다.
기본 클라이언트만 AFT 작업을 수행할 수 있습니다.
가장 높은 선택 ID를 가진 클라이언트가 기본 클라이언트입니다. 다른 모든 클라이언트는 백업 클라이언트입니다.
백업 클라이언트가 기본 클라이언트가 되면 이전 기본 클라이언트가 추가한 경로를 새 기본 클라이언트가 수정할 수 있습니다.

각 디바이스에 대한 선택 ID를 설정하여 어떤 클라이언트가 기본 클라이언트인지 결정합니다. 선거 ID는 중복 모드에서만 SINGLE_PRIMARY 설정할 수 있습니다. 선거 ID는 클라이언트가 다운 상태인 경우에도 유지됩니다. 기본 클라이언트의 연결이 끊어지면 다른 디바이스의 선택 ID를 더 높게 설정할 때까지 기본 클라이언트로 유지됩니다. 선거 ID가 설정된 후, 새로운 기본 클라이언트는 gRIBI 항목을 계속 프로그래밍합니다.

선거 ID를 업데이트하려면 선거 ID가 새 값으로 설정된 메시지를 보냅니다 ModifyRequest . 각 클라이언트는 고유한 선거 ID를 가져야 합니다. 선거 ID를 업데이트할 때 메시지의 다른 필드를 ModifyRequest 설정하지 마십시오.

선거 ID는 다음 메시지에 표시됩니다.

ModifyRequest- 클라이언트의 선택 ID를 설정합니다. 가장 높은 선택 ID를 가진 클라이언트가 기본 클라이언트가 됩니다.
AFTOperation- 서버가 AFT 작업을 처리해야 하는지 여부를 결정합니다.
ModifyResponse- 서버는 현재 가장 높은 선택 ID로 응답합니다.

명령을 사용하여 show programmable-rpd clients detail 그룹 ID와 클라이언트에 기본 또는 백업 역할이 있는지 여부를 확인합니다.

명령을 사용하여 show route extensive 경로의 세부 정보를 봅니다. 다음은 명령이 show route extensive 모드에서 표시되는 SINGLE_PRIMARY 내용의 예입니다. 명확성을 위해 출력이 단축되었습니다.

VRF 인스턴스에서 폴백 경로 프로그래밍

고정 경로를 통해 다음 홉에 도달할 수 없게 되면 네트워크는 트래픽 중단을 방지하기 위해 대체 경로를 통해 트래픽을 재라우팅할 수 있습니다. 이 대체 경로를 폴백 경로라고 합니다. 트래픽이 터널에 캡슐화되지 않은 경우 일반적으로 CLI를 사용하는 것처럼 폴백 정적 경로를 구성합니다. 그러나 트래픽이 터널에 캡슐화된 경우 gRIBI를 사용하여 캡슐화 해제 및 캡슐화를 포함하는 폴백 터널을 프로그래밍할 수 있습니다.

VRF에서 폴백 경로를 프로그래밍하여 시스템이 이전 터널의 트래픽을 디캡슐화하고 트래픽을 다음 홉으로 다시 라우팅하기 전에 새 터널에 다시 캡슐화하도록 할 수 있습니다. 이 기능은 IPv4 또는 IPv6 페이로드가 있는 동적 IP-IP 터널에 대한 IPv4 전송을 지원합니다.

캡슐화 해제 및 재캡슐화 기능으로 폴백 IP-in-IP 터널을 프로그래밍하려면 메시지에서 다음 필드를 설정합니다.NextHop

트래픽 엔지니어링 가상 라우팅 및 포워딩(VRF) 인스턴스의 기본 경로를 백업 경로로 사용할 수 있습니다. VRF에서 구성하는 향후 경로가 이를 폴백 경로로 사용할 수 있도록 먼저 VRF에 기본 경로를 추가합니다. 이 기본 경로를 사용하려면 필드를 decapsulate_header 로 OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4 설정하고 로 설정합니다 network_instance . DEFAULT 이 기본 경로에는 캡슐화 해제가 있는 다음 홉이 있으며 기본 VRF에서 경로를 조회합니다.

백업 다음 홉 그룹을 선택하여 폴백 경로를 더 쉽게 구성할 수도 있습니다. 이렇게 하려면 메시지의 필드를 설정합니다backup_next_hop_group.NextHopGroup

VRF 인스턴스 선택

gRIBI는 기본이 아닌 VRF 인스턴스에서 경로 프로그래밍을 지원하지 않습니다. 기본이 아닌 VRF 인스턴스를 사용하려면 먼저 CLI를 사용하여 방화벽 필터를 구성합니다. 방화벽 필터는 필요한 DSCP 및 IP 프로토콜과 일치해야 합니다. 트래픽이 예상되는 인터페이스에 필터를 적용합니다.

예를 들어, 트래픽이 인터페이스 et-0/0/0에 있는 경우:

정책 기반 포워딩

메시지를 사용하여 PolicyForwardingEntry gRIBI 서버에서 정책 기반 전달을 프로그래밍합니다. 정책 기반 포워딩은 백업 터널로 이동된 트래픽이 라우팅 테이블의 내용에 관계없이 터널에 남아 있는지 보장합니다.

일치 조건을 설정하고 트래픽 포워딩 정책을 프로그래밍하려면

메시지에서 다음 필드를 설정합니다.Afts

메시지에서 다음 필드를 설정합니다.AFTOperation

위에서 ModifyRequest 정의한 것을 AFTOperation 사용하도록 메시지를 설정합니다.
위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.

경로 가져오기

클라이언트가 gRIBI 서버에 대한 연결이 끊어지면 다운타임 동안 프로그래밍된 모든 경로가 서버에 추가되지 않을 수 있습니다. 서버에 대한 연결이 다시 연결되면 RPC를 사용하여 Get() 모든 경로가 서버의 라우팅 테이블에 올바르게 추가되었는지 확인합니다. RPC는 Get() 서버에 설치된 경로가 올바른지 주기적으로 확인하고 차이점을 조정하는 데에도 유용합니다.

RPC는 Get() 서버에 설치된 AFT의 콘텐츠를 검색합니다. 클라이언트가 Get() RPC 요청을 보내면 서버는 스트림을 사용하여 현재 설치된 항목 집합으로 응답합니다. GetResponse 서버는 승인된 항목으로만 응답합니다. 서버가 모든 항목을 클라이언트에 보낸 후 서버는 RPC를 닫습니다.

GRES(Graceful 라우팅 엔진 스위치오버)가 구성된 경우 gRIBI 서버 및 rpd 프로세스는 gRIBI 서버가 재시작된 후 경로도 복구합니다. 클라이언트가 서버에 다시 연결한 후 클라이언트는 자동으로 서버에 gRIBI Get() RPC 요청을 보냅니다. GRES가 구성된 경우, 클라이언트는 서버의 경로를 조정합니다. 클라이언트가 다른 Get() RPC 요청을 보내는 경우 스트림에는 GetResponse 서버의 활성 조정된 경로가 포함됩니다. GRES가 구성되고 논스톱 라우팅이 구성되지 않은 경우, gRIBI API는 라우팅 엔진 전환 후 경로도 복구합니다.

참고:

rpd 프로세스가 다시 시작되면 활성 경로만 복구됩니다.

플러시 경로

RPC는 Flush() 메시지에 FlushRequest 설명된 것과 일치하는 서버의 모든 gRIBI 프로그래밍 경로를 제거합니다. 메시지를 보내는 FlushRequest 것은 서버에서 gRIBI 프로그래밍된 경로를 빠르고 쉽게 삭제할 수 있는 방법입니다.

트래픽 엔지니어링 VRF 인스턴스에 경로가 있는 경우 VRF 인스턴스를 삭제하기 전에 RPC를 Flush() 사용하여 VRF 인스턴스에서 경로를 플러시합니다.

변경 내역 표

기능 지원은 사용 중인 플랫폼과 릴리스에 따라 결정됩니다. 기능 탐색기를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.

출시

설명

23.4R1-EVO

gRIBI 서비스 RPC를 실행하기 위해 더 이상 [edit routing-options resolution] 계층 수준에서 문을 구성할 필요가 없습니다.