Hướng dẫn cấu hình gRIBI trên thiết bị Juniper JunOS

Hướng dẫn cấu hình gRIBI trên thiết bị Juniper JunOS

Tổng quan: Giao diện bảng thông tin định tuyến dựa trên gRPC (gRPC Routing Information Base Interface - gRIBI) là một dịch vụ gRPC cho phép các ứng dụng bên ngoài lập trình để thêm, sửa đổi và xóa các tuyến đường trên thiết bị mạng.

Dịch vụ gRIBI là một API để thêm, sửa đổi và xóa các mục nhập định tuyến trong bảng thông tin định tuyến của thiết bị (RIB - Routing Information Base, còn được gọi là bảng định tuyến). Nếu mục nhập đủ điều kiện để chuyển tiếp, hệ điều hành sẽ tự động thêm mục nhập đó vào bảng thông tin chuyển tiếp (FIB - Forwarding Information Base), còn được gọi là bảng chuyển tiếp.

Các ứng dụng khách gRIBI có thể sử dụng bất kỳ ngôn ngữ nào được hỗ trợ bởi Juniper Extension Toolkit (JET). Ứng dụng khách có thể chạy trên một hệ thống quản lý mạng bên ngoài hoặc như một ứng dụng cục bộ trên thiết bị mạng.

Tệp định nghĩa giao thức của dịch vụ gRIBI nằm tại: https://github.com/openconfig/gribi/blob/master/v1/proto/service/gribi.proto

Các thông điệp gRIBI được hỗ trợ bởi thiết bị Junos nằm trong gói JET IDL.

Mô hình OpenConfig Abstract Forwarding Table (AFT) là một mô hình dữ liệu YANG mô tả các mục nhập chuyển tiếp được cài đặt trên thiết bị mạng. gRIBI sử dụng một phiên bản Protocol Buffer của mô hình OpenConfig AFT để mô tả các mục nhập RIB mà nó có thể sửa đổi. Định dạng protobuf của lược đồ OpenConfig AFT nằm trong tệp định nghĩa giao thức tại: https://github.com/openconfig/gribi/blob/master/v1/proto/gribi_aft/gribi_aft.proto

Lợi ích của gRIBI

• Gửi xác nhận khi bạn lập trình một tuyến đường.
• Hỗ trợ tra cứu phân cấp.
• Hỗ trợ tranh chấp khi nhiều ứng dụng khách kết nối vào phiên gRIBI.

Sử dụng lệnh sau để hiển thị dữ liệu tuyến đường của gRIBI, bao gồm client ID và next-hop group ID được sử dụng bởi tuyến đường: show route extensive

**Lưu ý: Chúng tôi khuyến nghị chỉ sử dụng một trong hai: gRIBI hoặc JET RIB Service API, không sử dụng cả hai đồng thời, đặc biệt là khi quản lý cùng một tập hợp tuyến đường.

Hỗ trợ RPCs

Các thiết bị Junos hỗ trợ các RPC (Remote Procedure Calls) của dịch vụ gRIBI, cho phép truy xuất, thêm, sửa đổi hoặc xóa các tuyến đường từ bảng thông tin định tuyến (RIB - Routing Information Base) của thiết bị từ xa.

Các RPC này hoạt động bằng cách sửa đổi hoặc đọc các bảng chuyển tiếp trừu tượng (AFT - Abstract Forwarding Tables) trên thiết bị.

Bảng 1: Các RPC được hỗ trợ trong gribi.proto

Cấu hình thiết bị mạng

Junos OS Evolved phiên bản 23.4R1 trở lên

Trước khi bắt đầu:

• Cấu hình dịch vụ gRPC trên thiết bị mạng theo hướng dẫn trong phần Configure gRPC Services.

Để cấu hình thiết bị mạng cho gRIBI:

- Tạo một routing instance với lọc chuyển tiếp dựa trên bộ lọc (filter-based forwarding).

- Cấu hình hai chính sách: Một chính sách để xử lý giải quyết đa đường (multipath resolve)và một chính sách để xử lý cân bằng tải (load balancing).

Trong ví dụ này, chính sách có tên mp-resolve xử lý giải quyết đa đường (multipath resolve). Nếu tuyến đường được giải quyết có nhiều đường đi, tuyến đường cuối cùng sẽ được giải quyết trên tất cả các đường đó. Chính sách pplb hướng dẫn Packet Forwarding Engine thực hiện cân bằng tải lưu lượng cho từng gói tin.

- Thiết lập remnant holdtime để hệ thống có đủ thời gian cập nhật các tuyến đường. Sau khi hệ thống khởi động lại, tiến trình rpd sẽ chờ cho đến khi remnant holdtime hết hạn trước khi dọn dẹp các tuyến đường. Tiến trình rpd sẽ không xóa bất kỳ tuyến đường nào nếu chúng được cập nhật trước khi thời gian chờ kết thúc.

Bây giờ bạn đã sẵn sàng để sử dụng các RPC của dịch vụ gRIBI.

Trước phiên bản Junos OS Evolved 23.4R1

Trước khi bắt đầu:

• Cấu hình dịch vụ gRPC trên thiết bị mạng theo hướng dẫn trong phần Configure gRPC Services.

Để cấu hình thiết bị mạng cho gRIBI:

- Tạo một routing instance với lọc chuyển tiếp dựa trên bộ lọc (filter-based forwarding).

- Cấu hình bảng định tuyến (routing table) mà bạn muốn sử dụng để giải quyết tuyến đường (route resolution) cho: mặc định (default), giao thức họ IPv4 (IPv4 family protocol), giao thức họ IPv6 (IPv6 family protocol) trong routing instance của bạn.

Bạn có thể chỉ định tối đa hai bảng định tuyến cho mỗi họ giao thức (protocol family). Cơ chế giải quyết tuyến đường (route resolution scheme) chỉ kiểm tra bảng định tuyến thứ hai nếu không tìm thấy mục nhập cho địa chỉ next-hop của giao thức trong bảng định tuyến thứ nhất.

Trong ví dụ này: teVRF.inet.0 là bảng định tuyến mặc định. Nếu không có tuyến đường cho địa chỉ next-hop trong bảng định tuyến này, cơ chế giải quyết tuyến đường sẽ kiểm tra bảng inet.3.

- Chỉ định chính sách nhập (import policies) cho các cây giải quyết tuyến đường (resolution trees) của họ giao thức IPv4 và IPv6.

Ví dụ:

Cấu hình hai chính sách: Một chính sách để xử lý giải quyết đa đường (multipath resolve) và một chính sách để xử lý cân bằng tải (load balancing).

Trong ví dụ này, chính sách có tên mp-resolve xử lý giải quyết đa đường (multipath resolve). Nếu tuyến đường được giải quyết có nhiều đường đi, tuyến đường cuối cùng sẽ được giải quyết trên tất cả các đường đó. Chính sách pplb hướng dẫn Packet Forwarding Engine thực hiện cân bằng tải lưu lượng cho từng gói tin.

- Cấu hình tùy chọn định tuyến (routing options) để bảo toàn thứ bậc next-hop khi cài đặt next-hop vào mặt phẳng chuyển tiếp (forwarding plane).

- Cấu hình bảng định tuyến (routing table) mà bạn muốn sử dụng để giải quyết tuyến đường (route resolution) cho họ giao thức IPv4 và IPv6, cũng như chính sách giải quyết tuyến đường ở cấp độ tùy chọn định tuyến (routing options level). Lặp lại cấu hình này cho từng bảng định tuyến mà bạn đã thiết lập ở cấp độ routing instance.

Ví dụ:

- Thiết lập remnant holdtime để hệ thống có đủ thời gian cập nhật các tuyến đường. Sau khi hệ thống khởi động lại, tiến trình rpd sẽ chờ cho đến khi remnant holdtime hết hạn trước khi dọn dẹp các tuyến đường. Tiến trình rpd sẽ không xóa bất kỳ tuyến đường nào nếu chúng được cập nhật trước khi thời gian chờ kết thúc.

Bây giờ bạn đã sẵn sàng để sử dụng các RPC của dịch vụ gRIBI.

Chỉnh sửa tuyến đường (Modify Routes)

Sử dụng RPC Modify() để cài đặt tuyến đường mới và chỉnh sửa tuyến đường hiện có trong RIB của máy chủ gRIBI. Các tuyến đường được thêm vào dưới dạng static route (tuyến tĩnh).

Modify() là một RPC truyền dữ liệu hai chiều (bidirectional streaming RPC). Client gửi một Modify() RPC chứa các ModifyRequest để chỉnh sửa một mục AFT trên máy chủ. Với mỗi ModifyRequest, máy chủ gRIBI phản hồi lại client bằng một ModifyResponse.

Cấu trúc ModifyRequest: ModifyRequest bao gồm một hoặc nhiều tin nhắn AFTOperation. Mỗi AFTOperation xác định một yêu cầu thêm (add), sửa đổi (modify), hoặc xóa (remove) một mục AFT. Máy chủ gRIBI xử lý các thao tác AFT theo thứ tự luồng của Modify() RPC.

Các loại mục AFT được Junos hỗ trợ:

• IPv4Entry – Cấu hình một tuyến đường IPv4.
• NextHopEntry – Cấu hình một next-hop.
• NextHopGroup – Cấu hình một nhóm next-hop.

Sử dụng Modify() RPC để thực hiện các chức năng sau:

Xác nhận tuyến đường (Route Acknowledgments)

Máy chủ sẽ gửi một xác nhận (acknowledgment) khi bạn lập trình tuyến đường thành công trong Packet Forwarding Engine bằng Modify() RPC. Nếu API gRIBI không thể lập trình tuyến đường trong Packet Forwarding Engine trong khoảng thời gian chờ (timeout period) được chỉ định, máy chủ sẽ gửi thông báo lỗi (error message). Bạn có thể cấu hình độ dài thời gian chờ này. Xác nhận chỉ hợp lệ đối với tuyến đường mới nhất. Nếu một tuyến đường cũ hơn nhận được xác nhận, nhưng tuyến đường mới không nhận được, Packet Forwarding Engine sẽ ghi nhận lỗi.

Các giá trị được thiết bị Junos hỗ trợ trong trường entry của tin nhắn AFTOperation:

**Lưu ý: Thiết bị Junos không hỗ trợ tùy chọn MAC_ENTRY.

Sử dụng lệnh show route extensive để hiển thị trạng thái xác nhận. Trạng thái xác nhận sẽ được giữ nguyên ngay cả khi tiến trình rpd khởi động lại.

Lập trình tuyến đường IPv4 (Program an IPv4 Route)

Để lập trình một tuyến đường IPv4, sử dụng mục AFT IPv4Entry. AFT sẽ khớp các gói tin đầu vào dựa trên địa chỉ đích (destination address) và ánh xạ chúng đến các next-hop tương ứng. Cài đặt mục AFT trên VRF mặc định cũng như trên các VRF traffic engineering trong mạng. Nếu muốn cài đặt AFT vào một VRF không phải mặc định, hãy chỉ định tên VRF trong trường network_instance của thông điệp AFTOperation.

Ví dụ:

• Traffic engineering VRF instance: g_b4_cos1
• Giá trị của trường network_instance: g_b4_cos1

gRIBI client chỉ lập trình mục IPv4Entry trên máy chủ sau khi nhận được xác nhận từ máy chủ rằng NextHopGroup và NextHop liên quan đã được cài đặt thành công. Nếu client lập trình mục IPv4Entry mà chưa nhận được xác nhận của NextHopGroup, tuyến đường sẽ được thêm vào dưới dạng tuyến ẩn (hidden route).

Lập trình Next-Hop và Next-Hop Group

Sử dụng gRIBI Modify() RPC để lập trình next-hop hoặc next-hop group trên máy chủ gRIBI. RPC chỉ tạo next-hop và next-hop group trong VRF mặc định.

Xử lý NextHop và NextHopGroup trong ModifyRequest: Nếu yêu cầu thêm (add) NextHop và NextHopGroup, client thêm tất cả NextHop trước, sau đó mới thêm NextHopGroup. Nếu yêu cầu xóa (delete) NextHop và NextHopGroup, client xóa NextHopGroup trước, sau đó mới xóa NextHop.

Cách xử lý NextHop trên thiết bị Junos: NextHop trong bảng inet6.3 có dạng FC01::next_hop_id. Ví dụ: Nếu NextHop ID = 10, máy chủ sẽ cài đặt tuyến đường FC01::A trong bảng inet6.3.

NextHopGroup trong bảng inet6.3 có dạng FC02::next_hop_id. Ví dụ: Nếu NextHopGroup ID = 100, máy chủ sẽ cài đặt tuyến đường FC02::64 trong bảng inet6.3.

Ví dụ lập trình NextHop thông qua giao diện trực tiếp:

- Giả sử địa chỉ 10.0.1.2 có thể truy cập thông qua giao diện et-0/0/7.0, hãy thiết lập các trường trong thông điệp Afts như sau = nghĩa là gán giá trị đó cho trường tương ứng.

- Thiết lập các trường trong thông điệp AFTOperation như sau:

- Đặt thông điệp ModifyRequest để sử dụng AFTOperation đã được xác định ở trên.

- Gọi RPC Modify() với thông điệp ModifyRequest ở trên.

- Để xác nhận tuyến đường đã được lập trình thành công, sử dụng lệnh show route programmed trong CLI.

Lập trình Next Hop với Địa chỉ MAC

Bạn có thể xác định một next hop bằng địa chỉ MAC thay vì địa chỉ IP. Tính năng này hữu ích trong các mạng mà thiết bị không thể sử dụng giao thức phân giải địa chỉ động như ARP (Address Resolution Protocol) hoặc NDP (Neighbor Discovery Protocol) để tra cứu địa chỉ MAC của next hop. Để sử dụng địa chỉ MAC, sử dụng trường mac_address thay vì trường ip_address trong thông điệp AFT.

**Lưu ý: Tất cả lưu lượng sử dụng giao diện này sẽ sử dụng địa chỉ MAC tĩnh được lập trình bởi dịch vụ gRIBI, ngay cả đối với lưu lượng trên các tuyến đường không được lập trình bởi gRIBI.

Sau khi bạn sử dụng dịch vụ gRIBI để lập trình địa chỉ MAC làm next hop trên giao diện, thiết bị sẽ không sử dụng ARP động hoặc NDP cho bất kỳ lưu lượng nào trên giao diện này. Nếu next hop được lập trình bằng gRIBI bị xóa hoặc bị loại bỏ khi client ngắt kết nối, thiết bị sẽ tự động kích hoạt lại ARP trên giao diện và tuyến đường vẫn tiếp tục hoạt động bằng ARP động.

Ví dụ: Lập trình Next Hop với Địa chỉ MAC qua Giao diện Trực Tiếp

- Đảm bảo rằng giao diện bạn muốn lập trình với một next hop là giao diện có số (numbered interface).

- Đảm bảo rằng giao thức IPv6 đã được kích hoạt trên giao diện.

- Giả sử địa chỉ MAC 00:00:5E:00:53:00 có thể truy cập qua giao diện et-0/0/7.0, hãy đặt các trường sau trong thông điệp Afts, trong đó = có nghĩa là đặt trường thành giá trị đó.

- Đặt các trường của thông điệp AFTOperation như sau:

- Đặt thông điệp ModifyRequest để sử dụng AFTOperation đã được định nghĩa ở trên.

- Gọi RPC Modify() với thông điệp ModifyRequest đã thiết lập.

- Để xác nhận rằng tuyến đường đã được lập trình thành công, sử dụng lệnh show route programmed trong CLI.

Tra cứu phân cấp và đường hầm IP-in-IP

Triển khai gRIBI trên Junos hỗ trợ tra cứu phân cấp. Để cấu hình tra cứu phân cấp, sử dụng IPv4 AFT để lập trình các điểm cuối của đường hầm IP-in-IP và các tuyến địa chỉ IP ảo của nhóm site. Để đóng gói lưu lượng tại nút đầu vào trong một đường hầm IP-in-IP, đặt các trường sau trong thông điệp NextHop:

Tranh chấp giữa nhiều client

RPC Modify() hỗ trợ cơ chế tranh chấp khi nhiều client kết nối đến máy chủ gRIBI. Cơ chế tranh chấp xác định client nào có quyền thực hiện các thao tác nào.

Sử dụng thông điệp SessionParameters để thiết lập chế độ duy trì (persistence mode) và chế độ dự phòng (redundancy mode) cho các client gRIBI. Tất cả các client phải gửi cùng một giá trị cho tất cả các thuộc tính trong thông điệp SessionParameters.

SessionParameters chỉ nên được gửi một lần trong suốt vòng đời của phiên làm việc. SessionParameters phải là thông điệp đầu tiên được gửi sau khi kết nối lại. Khi một client kết nối lại, một phiên mới bắt đầu. Nếu có các client khác đã kết nối, giá trị của SessionParameters phải khớp với các giá trị đã được thiết lập bởi các client trước đó. Nếu tất cả các client kết nối lại, bạn có thể đặt các giá trị SessionParameters khác với phiên trước.

Thiết bị Junos hỗ trợ cả hai chế độ duy trì PRESERVE và DELETE. Nếu chế độ duy trì được đặt thành PRESERVE, máy chủ sẽ giữ lại các mục AFT mà client đã thêm ngay cả sau khi client ngắt kết nối. Nếu chế độ duy trì được đặt thành DELETE, máy chủ sẽ xóa các mục AFT khi client ngắt kết nối.

Chúng tôi khuyến nghị xóa tất cả các tuyến trước khi thay đổi tham số phiên. Bạn có thể gặp hành vi không mong muốn nếu thay đổi tham số phiên và chuyển chế độ dự phòng giữa ALL_PRIMARY và SINGLE_PRIMARY sau khi đã thêm các tuyến ở chế độ khác.

Khi có nhiều client, bạn phải chọn giữa hai chế độ dự phòng:

Chế độ tất cả là chính (ALL_PRIMARY)

Trong chế độ ALL_PRIMARY:

• Bất kỳ client nào cũng có thể sửa đổi tuyến.
• Nhiều client có thể thêm cùng một mục AFT.
• API gRIBI duy trì ánh xạ giữa client và các tuyến mà client đã thêm.
• Lệnh add đầu tiên sẽ thêm mục vào RIB. Các lệnh add tiếp theo từ client khác sẽ thêm client đó vào danh sách tham chiếu của mục đó.
• Lệnh delete sẽ xóa client khỏi danh sách tham chiếu của mục. Mục đó chỉ bị xóa khi không còn client nào tham chiếu đến nó.

**Lưu ý: Khi FlushRequest được xử lý, các mục sẽ bị xóa mà không kiểm tra số lượng tham chiếu.

Sử dụng lệnh show route extensive để xem chi tiết tuyến. Dưới đây là ví dụ về đầu ra của lệnh show route extensive trong chế độ ALL_PRIMARY. Nội dung đầu ra đã được rút gọn để dễ đọc.

Chế độ một chính duy nhất (SINGLE_PRIMARY)

Trong chế độ SINGLE_PRIMARY:

• Các client gRIBI có thể đóng vai trò chính (primary) hoặc dự phòng (backup).
• Chỉ client chính (primary client) mới có thể thực hiện các thao tác trên AFT.
• Client có election ID cao nhất sẽ trở thành client chính (primary). Tất cả các client còn lại là client dự phòng (backup).
• Khi một client dự phòng trở thành client chính, nó có thể sửa đổi các tuyến do client chính trước đó đã thêm.

Đặt election ID cho từng thiết bị để xác định client nào là client chính. Bạn chỉ có thể đặt election ID trong chế độ dự phòng SINGLE_PRIMARY. Election ID vẫn được giữ nguyên ngay cả khi một client bị mất kết nối (down state). Nếu client chính bị ngắt kết nối, nó vẫn giữ vai trò chính cho đến khi bạn đặt election ID của một client khác cao hơn. Sau khi thiết lập election ID, client chính mới sẽ tiếp tục lập trình các mục gRIBI.

Để cập nhật election ID, gửi thông điệp ModifyRequest với election ID được đặt thành giá trị mới. Mỗi client phải có một election ID duy nhất. Không đặt bất kỳ trường nào khác trong thông điệp ModifyRequest khi cập nhật election ID.

Election ID có mặt trong các thông điệp sau:

• ModifyRequest – Đặt election ID cho client. Client có election ID cao nhất sẽ trở thành client chính.
• AFTOperation – Xác định xem máy chủ có nên xử lý thao tác AFT hay không.
• ModifyResponse – Máy chủ phản hồi với election ID cao nhất hiện tại.

Sử dụng lệnh show programmable-rpd clients detail để xem group ID và xác định xem client đang đóng vai trò chính (primary) hay dự phòng (backup).

Sử dụng lệnh show route extensive để xem chi tiết tuyến đường. Dưới đây là ví dụ về đầu ra của lệnh show route extensive trong chế độ SINGLE_PRIMARY. Nội dung đầu ra đã được rút gọn để dễ đọc.

Lập trình tuyến dự phòng trong một VRF Instance

Khi một next hop không còn khả dụng thông qua một tuyến tĩnh (static route), mạng có thể định tuyến lại lưu lượng qua một tuyến thay thế để tránh gián đoạn. Tuyến thay thế này được gọi là tuyến dự phòng (fallback route). Nếu lưu lượng không được đóng gói trong một đường hầm (tunnel), bạn có thể cấu hình tuyến tĩnh dự phòng như bình thường bằng CLI. Tuy nhiên, nếu lưu lượng được đóng gói trong một đường hầm, bạn có thể sử dụng gRIBI để lập trình một đường hầm dự phòng (fallback tunnel) có khả năng giải đóng gói (decapsulation) và tái đóng gói (re-encapsulation).

Bạn có thể lập trình tuyến dự phòng trong VRF, giúp hệ thống: Giải đóng gói (decapsulate) lưu lượng từ đường hầm cũ. Tái đóng gói (re-encapsulate) lưu lượng trong một đường hầm mới. Định tuyến lại (re-route) lưu lượng đến next hop mới. Tính năng này hỗ trợ IPv4 transport cho các đường hầm IP-IP động với tải IPv4 hoặc IPv6.

Để lập trình đường hầm dự phòng có khả năng giải đóng gói (decapsulation) và tái đóng gói (re-encapsulation), hãy thiết lập các trường sau trong thông điệp NextHop:

Bạn có thể sử dụng tuyến mặc định (default route) trong VRF kỹ thuật giao thông làm tuyến dự phòng (backup route). Hãy thêm tuyến mặc định (default route) vào VRF trước, để các tuyến tương lai bạn cấu hình trong VRF có thể sử dụng nó làm tuyến dự phòng (fallback route). Để sử dụng tuyến mặc định :thiết lập trường decapsulate_header thành OPENCONFIGAFTTYPESENCAPSULATION HEADERTYPE_IPV4, thiết lập network_instance thành DEFAULT. Tuyến mặc định này có next hop với chức năng decapsulation và thực hiện tra cứu tuyến (route lookup) trong VRF mặc định.

Bạn cũng có thể chọn một nhóm next hop dự phòng (backup next hop group), giúp cấu hình tuyến dự phòng dễ dàng hơn. Để làm điều này, hãy thiết lập trường backup_next_hop_group trong thông điệp NextHopGroup.

Lựa Chọn VRF Instance

gRIBI không hỗ trợ lập trình tuyến (programming routes) trong VRF không phải mặc định (non-default VRF). Để sử dụng một VRF không mặc định, trước tiên bạn phải cấu hình bộ lọc tường lửa (firewall filter) bằng CLI. Bộ lọc tường lửa phải khớp (match) với DSCP và giao thức IP cần thiết. Áp dụng bộ lọc (apply the filter) vào giao diện nơi lưu lượng dự kiến sẽ đi qua.

Ví dụ: Nếu lưu lượng đi qua giao diện et-0/0/0

Chuyển tiếp dựa trên chính sách (Policy-Based Forwarding)

Sử dụng thông điệp PolicyForwardingEntry để lập trình chuyển tiếp dựa trên chính sách (policy-based forwarding) trên máy chủ gRIBI. Chuyển tiếp dựa trên chính sách đảm bảo rằng lưu lượng được chuyển vào đường hầm dự phòng (backup tunnel) sẽ vẫn ở trong đường hầm, bất kể bảng định tuyến (routing table) hiển thị điều gì.

Thiết Lập Điều Kiện Khớp (Match Conditions) Và Cấu Hình Chính Sách Chuyển Tiếp (Policy for Forwarding Traffic)

- Để cấu hình chính sách chuyển tiếp (policy-based forwarding policy), hãy thiết lập các trường sau trong thông điệp Afts:

- Thiết lập các trường sau trong thông điệp AFTOperation:

Thiết lập thông điệp ModifyRequest để sử dụng AFTOperation đã định nghĩa ở trên.

Gọi RPC Modify() với thông điệp ModifyRequest đã thiết lập ở trên.

Lấy các tuyến đường (Get Routes)

Khi máy khách bị mất kết nối với máy chủ gRIBI, bất kỳ tuyến đường nào đã được lập trình trong thời gian gián đoạn có thể sẽ không được thêm vào máy chủ. Sau khi kết nối với máy chủ được khôi phục, sử dụng RPC Get() để kiểm tra xem tất cả các tuyến đường có được thêm chính xác vào bảng định tuyến của máy chủ hay không. RPC Get() cũng hữu ích để kiểm tra định kỳ xem các tuyến đường đã được cài đặt trên máy chủ có chính xác không và để đối chiếu bất kỳ sự khác biệt nào.

RPC Get() truy xuất nội dung của các AFT đã được cài đặt trên máy chủ. Khi máy khách gửi yêu cầu RPC Get(), máy chủ sẽ phản hồi với tập hợp các mục hiện đang được cài đặt bằng luồng GetResponse. Máy chủ chỉ phản hồi với các mục đã được xác nhận. Sau khi máy chủ gửi tất cả các mục cho máy khách, máy chủ sẽ đóng phiên RPC.

Khôi phục tuyến đường khi xảy ra chuyển đổi động cơ định tuyến (Routing Engine Switchover). Nếu quá trình chuyển đổi động cơ định tuyến mượt mà (GRES) được cấu hình, máy chủ gRIBI và tiến trình rpd cũng sẽ khôi phục các tuyến đường sau khi máy chủ gRIBI khởi động lại. Sau khi máy khách kết nối lại với máy chủ, máy khách sẽ tự động gửi yêu cầu RPC Get() đến máy chủ gRIBI. Nếu GRES được cấu hình, máy khách sẽ đối chiếu các tuyến đường trên máy chủ. Nếu máy khách gửi một yêu cầu RPC Get() khác, luồng GetResponse sẽ bao gồm các tuyến đường đã được đối chiếu và đang hoạt động trên máy chủ. Nếu GRES được cấu hình nhưng không có định tuyến không gián đoạn (non-stop routing), API gRIBI cũng sẽ khôi phục các tuyến đường sau khi xảy ra chuyển đổi động cơ định tuyến (Routing Engine switchover).

**Lưu ý: Chỉ các tuyến đường đang hoạt động mới được khôi phục khi tiến trình rpd khởi động lại.

Xóa các tuyến đường (Flush Routes)

RPC Flush() xóa tất cả các tuyến đường được lập trình bằng gRIBI trên máy chủ mà phù hợp với mô tả trong thông điệp FlushRequest. Gửi một thông điệp FlushRequest là một cách nhanh chóng và dễ dàng để xóa các tuyến đường đã lập trình bằng gRIBI khỏi máy chủ.

Khi có các tuyến đường trong một phiên bản VRF định tuyến lưu lượng (traffic engineering VRF instance), hãy sử dụng RPC Flush() để xóa các tuyến đường khỏi phiên bản VRF trước khi xóa phiên bản VRF đó.

Chúc các bạn thực hiện thành công. Hi vọng bài viết này sẽ giúp ích cho các bạn trong công việc. Nếu bạn có vấn đề gì thắc mắc đừng ngần ngại liên hệ với chúng tôi theo thông tin dưới đây để được hỗ trợ thêm.

Hẹn gặp lại các bạn trong các bài viết tiếp theo !