Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
이 페이지의 내용
 

그리비

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

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

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 22.2R1
Flush()

메시지에 설명된 FlushRequest 것과 일치하는 모든 장치의 AFT 항목을 제거합니다.

진화한 Junos OS 22.2R1

네트워크 디바이스 구성

Junos OS Evolved 릴리스 23.4R1 이상

시작하기 전에:

gRIBI용 네트워크 디바이스를 구성하려면 다음을 수행합니다.

  1. 필터 기반 포워딩을 사용하여 라우팅 인스턴스를 생성합니다.
  2. 다중 경로 해결을 처리하는 정책과 로드 밸런싱을 처리하는 정책의 두 정책을 구성합니다.

    이 예에서 handles multipath resolve라는 mp-resolve 정책이 있습니다. 확인 경로에 여러 경로가 있는 경우 확인된 경로는 모든 경로에서 확인됩니다. 이 정책은 pplb 패킷 전달 엔진에 각 패킷에 대한 트래픽 부하를 분산하도록 지시합니다.

  3. 시스템이 경로를 업데이트할 수 있는 충분한 시간을 제공하도록 잔여 보류 시간을 설정합니다. 시스템이 다시 시작된 후 rpd 프로세스는 경로를 정리하기 전에 남은 보류 시간이 만료될 때까지 기다립니다. rpd 프로세스는 대기 시간이 만료되기 전에 업데이트된 경로를 삭제하지 않습니다.

    이제 gRIBI 서비스 RPC를 사용할 준비가 되었습니다.

Junos OS Evolved 릴리스 23.4R1 이전

시작하기 전에:

gRIBI용 네트워크 디바이스를 구성하려면 다음을 수행합니다.

  1. 필터 기반 포워딩을 사용하여 라우팅 인스턴스를 생성합니다.
  2. 라우팅 인스턴스에서 기본, IPv4 제품군 프로토콜 및 IPv6 제품군 프로토콜 경로 확인에 사용할 라우팅 테이블을 구성합니다.

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

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

  3. IPv4 및 IPv6 제품군 확인 트리에 대한 가져오기 정책을 지정합니다.

    예를 들어:

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

    이 예에서 handles multipath resolve라는 mp-resolve 정책이 있습니다. 확인 경로에 여러 경로가 있는 경우 확인된 경로는 모든 경로에서 확인됩니다. 이 정책은 pplb 패킷 전달 엔진에 각 패킷에 대한 트래픽 부하를 분산하도록 지시합니다.

  5. 포워딩 플레인에 다음 홉을 설치할 때 다음 홉 계층을 보존하도록 라우팅 옵션을 구성합니다.
  6. IPv4 및 IPv6 제품군 프로토콜 경로 확인에 사용할 라우팅 테이블과 라우팅 옵션 수준에서 경로 확인 정책을 구성합니다. 라우팅 인스턴스 수준에서 구성한 각 라우팅 테이블에 대해 이 구성을 반복합니다.

    예를 들어:

  7. 시스템이 경로를 업데이트할 수 있는 충분한 시간을 제공하도록 잔여 보류 시간을 설정합니다. 시스템이 다시 시작된 후 rpd 프로세스는 경로를 정리하기 전에 남은 보류 시간이 만료될 때까지 기다립니다. rpd 프로세스는 대기 시간이 만료되기 전에 업데이트된 경로를 삭제하지 않습니다.

    이제 gRIBI 서비스 RPC를 사용할 준비가 되었습니다.

경로 수정

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

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

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

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

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

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

경로 승인

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

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

메모:

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

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

IPv4 경로 프로그래밍

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

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

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

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

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

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

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

다음 홉 그룹은 테이블에 (으)로 FC02::next_hop_id나타납니다inet6.3. 예를 들어 다음 홉 그룹 ID가 100인 경우 서버는 테이블에 라는 FC02::64 inet6.3 경로를 설치합니다.

예를 들어, 직접 연결할 수 있는 인터페이스를 통해 다음 홉 개체를 프로그래밍하려면 다음을 수행합니다.

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

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

  3. 위에서 정의한 ModifyRequest 것을 AFTOperation 사용하도록 메시지를 설정합니다.

  4. 위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.

  5. 경로가 성공적으로 프로그래밍되었는지 확인하려면 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 주소로 다음 홉 개체를 프로그래밍하려면 다음을 수행합니다.

  1. 다음 홉으로 프로그래밍하려는 인터페이스가 번호가 매겨진 인터페이스인지 확인합니다.

  2. 인터페이스에서 IPv6 제품군이 활성화되어 있는지 확인합니다.

  3. 인터페이스 et-0/0/7.0을 통해 MAC 주소 00:00:5E:00:53:00에 연결할 수 있다고 가정하면 메시지에서 Afts 다음 필드를 설정합니다. 여기서 =는 필드를 해당 값으로 설정한다는 의미입니다.

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

  5. 위에서 정의한 ModifyRequest 것을 AFTOperation 사용하도록 메시지를 설정합니다.

  6. 위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.

  7. 경로가 성공적으로 프로그래밍되었는지 확인하려면 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 항목을 삭제합니다.

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

클라이언트가 여러 개인 경우 다음 두 가지 클라이언트 중복 모드 중에서 선택해야 합니다.

모든 기본 모드

이중화 모드에서 ALL_PRIMARY :

  • 모든 클라이언트가 경로를 수정할 수 있습니다.

  • 여러 클라이언트가 동일한 AFT 항목을 추가할 수 있습니다.

  • gRIBI API는 경로를 추가한 클라이언트에 대한 매핑을 유지 관리합니다.

  • 첫 번째 추가 작업은 RIB에 항목을 추가합니다. 다른 클라이언트에서 동일한 항목에 대한 후속 추가 작업은 항목을 참조하는 클라이언트 목록에 클라이언트를 추가합니다.

  • 삭제 작업은 항목을 참조하는 클라이언트 목록에서 클라이언트를 제거합니다. 항목을 참조하는 클라이언트가 없는 경우에만 항목이 삭제됩니다.

메모:

이 처리되면 FlushRequest 참조 횟수 검사 없이 항목이 삭제됩니다.

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

단일 기본 모드

이중화 모드에서 SINGLE_PRIMARY :

  • gRIBI 클라이언트는 기본(활성) 또는 백업 역할을 가질 수 있습니다.

  • 기본 클라이언트만 AFT 작업을 수행할 수 있습니다.

  • election ID가 가장 높은 클라이언트가 기본 클라이언트입니다. 다른 모든 클라이언트는 백업 클라이언트입니다.

  • 백업 클라이언트가 기본 클라이언트가 되면 이전 기본 클라이언트가 추가한 경로를 새 기본 클라이언트가 수정할 수 있습니다.

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

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

election ID는 다음 메시지에 있습니다.

  • ModifyRequest- 클라이언트의 선택 ID를 설정합니다. 선택 ID가 가장 높은 클라이언트가 기본 클라이언트가 됩니다.

  • AFTOperation- 서버가 AFT 작업을 처리해야 하는지 여부를 결정합니다.

  • ModifyResponse- 서버가 현재 가장 높은 election ID로 응답합니다.

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

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

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

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

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

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

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

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

VRF 인스턴스 선택

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

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

정책 기반 포워딩

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

일치 조건을 설정하고 트래픽 포워딩 정책을 프로그래밍하려면 다음을 수행합니다.

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

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

  3. 위에서 정의한 ModifyRequest 것을 AFTOperation 사용하도록 메시지를 설정합니다.

  4. 위의 ModifyRequest 메시지로 RPC를 Modify() 호출합니다.

경로 가져오기

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

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

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

메모:

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

플러시 경로

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

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

변경 내역 테이블

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

석방
묘사
변경 완료