The RIB API service proto definition requires the client to provide values for all of the parameters listed in Table: IPv4 route table programming when performing an add or replace of an IPv4 route. When performing a delete operation, only the bolded parameters (the lookup keys) are required. Table: IPv4 route table programming describes the meaning of each parameter and its valid range.
| Parameter | Type | Description |
|---|---|---|
prefix |
string |
IPv4 prefix and prefix-length in CIDR format |
preferences |
uint32 (0-65535) |
RIB API preference, used to compare one RIB API entry to another one; the lowest preference wins |
rtm_preference |
uint32 (0-255) |
RTM preference, used to compare RIB API entry to other routes in RTM; the lowest preference wins |
metric |
uint32 (0-16777215) |
Route cost/metric |
tunnel_next_hop |
string |
A remote IPv4 address that must correspond to an API-programmed IPv4 tunnel |
The router's RIB API database can hold up to eight different gPRC-programmed entries per IPv4 prefix. Typically N entries would be associated with N different gRPC clients although the same client can program multiple entries for the same prefix as long as the preference values are unique.
When an IPv4 route entry is successfully added or modified in the RIB API database, the router assesses whether the entry is valid or invalid and constantly re-evaluates this status. The entry is invalid if its next hop cannot be resolved to a gRPC-programmed IPv4 tunnel that is up.
If the entry is valid, the router compares it to all other valid API-programmed entries for the same IPv4 prefix. The router chooses any non-stale entry over a stale entry, then the entry with the lowest preference value, and then if there is a tie, the lowest metric, and then if there is a still a tie, the entry from the client with the lowest 128-bit IP address (an IPv4 address is encoded in the lower 32 bits).
If the entry is valid and the best relative to other RIB API entries then it is submitted to the route table manager. This software task compares the API route to all other non-API routes it has for the same IPv4 prefix. The router chooses the entry with the lowest RTM preference value, and then if there is a tie, the lowest metric, and then if there is still a tie, the entry submitted by the protocol with the lowest default preference.
If the route table manager selects the API route as the best route it is sent to the FIB manager for programming into the data path.