The RIB API service proto definition requires the client to provide values for all of the parameters listed in Table: IPv6 route table programming when performing an add or replace of an IPv6 route. When performing a delete operation, only the bolded parameters (the lookup keys) are required. Table: IPv6 route table programming describes the meaning of each parameter and its valid range.
Parameter | Type | Description |
---|---|---|
prefix |
string |
IPv6 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 IPv6 address that must correspond to an API-programmed IPv6 tunnel |
The router's RIB API database can hold up to eight different gPRC-programmed entries per IPv6 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 IPv6 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 IPv6 tunnel that is up.
If the entry is valid, the router compares it to all other valid API-programmed entries for the same IPv6 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 IPv6 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.