RIB Service API
Route entry with route address, mask and attributes
|key||RouteMatchFields||optional||Route key attribute [REQUIRED]|
|nexthop||RouteNexthop||optional||Nexthop details of the route [REQUIRED]|
|protocol||RouteProtoType||optional||Protocol that added this route. Currently, this is only used in monitor reply. It cannot be used during RIB Add/modify/del calls as this should be set to the protocol adding the route and routes added via these APIs are always Static routes.|
Route gateway contains the parameters which are needed to forward traffic to next router/host. Consists of gateway address, local address and interface.
|gateway_address||NetworkAddress||optional||Address of the gateway or peer [REQUIRED]|
|interface_name||string||optional||Outgoing local interface name (IFL). If provided and router next-hop is built. If not provided, an indirect next-hop is built. [OPTIONAL]|
|local_address||NetworkAddress||optional||Local interface address to be used. This is useful when app is not aware of the outgoing interface, but knows the IP address of the interface. Local address is used to select a suitable interface. [OPTIONAL]|
|label_stack||LabelStack||optional||MPLS label stack. List of Stack Entries with each with an associated action Entries are ordered in the same order as actions to be performed. [OPTIONAL]
Note: The definition for a LabelStack can be found in the prpd_common API.
Route get reply containing the status of the operation and the full or partial set of matching routes, depending on how many reply RPCs the stream of routes is split among.
|status||RouteOperStatus||optional||The final return code for the request.|
|routes||RouteEntry||repeated||One or more matching routes.|
Route get operation request parameters.
|key||RouteMatchFields||optional||Route matching parameters [REQUIRED]|
|match_type||RouteMatchType||optional||If match_type is EXACT only routes for the exact destination prefix and prefix length will be matched.
If match_type is EXACT_OR_LONGER, routes for the given destination prefix or longer prefixes will be matched.
If match_type is BEST, longest prefix match is performed on the prefix.
[OPTIONAL], default is best
|active_only||bool||optional||If active_only is TRUE, inactive and hidden routes for a matching prefix will be omitted from the results. If FALSE, inactive and hidden routes are also returned. Optional (default is FALSE)|
|reply_address_format||AddressFormat||optional||The format for IP addresses in the replies to this request. Optional (default is string)|
|reply_table_format||RouteTableFormat||optional||The format to be used for route table in replies to this request Optional (default is string)|
|route_count||uint32||optional||The maximum number of routes requested in each reply. Replies will be streamed in multiple RPCs each having no more routes than given by this value. Counts from 1 through the maximum of 1000 may be specified. A value of zero or above 1000 indcates that the server will choose an appropriate. Optional (default 1)|
Route entry's unique fields typically used to match the route
|dest_prefix||NetworkAddress||optional||Address of the route [REQUIRED].|
|dest_prefix_len||uint32||optional||Route prefix length [REQUIRED].|
|table||RouteTable||optional||Routing table to which the route belongs [REQUIRED].|
|cookie||uint64||optional||Differentiate routes of same address set by application. [OPTIONAL]. Default value is 0. For non programmed routes cookie value returned in route get request will be 0.|
Route monitor entry which is sent to the client in the monitor reply message.
|monitor_rt_op||RouteMonitorRouteOp||optional||The monitor operation|
|route||RouteEntry||optional||route entries that are in the monitor reply|
Flags that can be used to change the behavior of routes recevied via the RouteMonitorReply. This can be like requesting End of Record. Matches RPD_MSG_FLASH_REGISTER_REQUEST*.
|request_eor||bool||optional||Register End of Record|
|no_eor_to_client||bool||optional||Requested by clients to NOT send them EOR , by default EOR will be sent to client.|
|request_no_withdrawal||bool||optional||clients can use this flag to inform server not send withdrawal messages when last filter is removed by this client for given table|
|request_from_eswd||bool||optional||To be set when register request is form Junos Process ESWD.|
|request_from_mcsnoopd||bool||optional||To be set when register request is form Junos Process MCSNOOPD.|
|request_from_vrrpd||bool||optional||To be set when register request is form Junos Process VRRPD.|
|request_force_re_notif||bool||optional||If this flag is set, client's re-registration triggers all routes to be notified once again.|
Request message to register for route monitoring. The registration denotes the routing table for which route monitoring is requested. Parameters in the registration request like monitor_policy can be set to influence which of the routes of the table are sent in the monitor reply message.
|rt_tbl_name||RouteTableName||optional||Name of the route table for which the route monitor is requested|
|monitor_op||RouteMonitorOp||optional||Monitor operation to be performed|
|monitor_flag||RouteMonitorRegFlags||optional||Route Monitor flags|
|monitor_policy||RouteMonitorPolicy||optional||By Default all routes of the table registered is sent in the reply message. Policy can be used for filtering which routes of the table are sent. For example, a policy can be defined using CLI to receive only static routes in the table.|
|monitor_ctx||uint32||optional||Context expected by clients to be sent back in reply message|
|monitor_reply_route_count||uint32||optional||Number of routes to be packed in Monitor reply message. This packing is done only when a new rib walk is started till the End of table is reached.|
Reply message which contains the routes of the table registered for monitoring.
|status||RouteOperStatus||optional||Return code to indicate operation status|
|monitor_ctx||uint32||optional||Context send by clients in the register request|
|rt_tbl_name||RouteTableName||optional||Route table to which the route entries of monitor_routes belong|
|monitor_routes||RouteMonitorEntry||repeated||One or more route entries to be sent to client|
When a data traffic arrives on a router, route nexthop indicates the next router(s) to which the traffic is to be forwarded. This consists of list of gateways.
|gateways||RouteGateway||repeated||List of nexthop gateways. JUNOS currently allows up to 64 gateways per next-hop [OPTIONAL]. defaults to a next-hop that blackholes the traffic|
Route operation reply containing the status of the operation. Replies always returns the final status (either success or the first error encountered) and the number of routes that were successfully processed prior to any error or full completion of the request.
|status||RouteOperStatus||optional||The final return code for the request.|
|operations_completed||uint32||optional||The number of requested operations for which the operation completed successfully. Note that in the case of remove operations with or_longer=TRUE or cookie=0, this is not the number of routes matched and removed.|
|keys||RouteMatchFields||repeated||Route mate parameters for one or more programmed routes to be deleted [REQUIRED]|
|routes||RouteEntry||repeated||One or more programmed routes to add, update, or modify. [REQUIRED]|
Various ways to match a route for get requests
Route Monitor operations; matches with RPD_MSG_FLASH_REGISTER_REQUEST
Operation type of routes replied in RouteMonitorReply; matches RPD_ROUTE_FLASH_OP*.
Possible return codes for route add/modify/update/remove operations.
|SUCCESS||0||Request successfully completed in full.|
|INTERNAL_ERROR||1||Request failed due to an internal server error.|
|NOT_INITIALIZED||2||The route service has not been initialized|
|NO_OP||3||Request did not result in any operations|
|TOO_MANY_OPS||4||Request contained too many operations|
|TABLE_INVALID||5||Request contained an invalid table.|
|TABLE_NOT_READY||6||Request contained a table that was not ready for operations.|
|PREFIX_INVALID||7||Request contained an invalid destination address prefix|
|PREFIX_LEN_TOO_SHORT||8||Request contained a destination prefix length too short for the supplied address/NLRI.|
|PREFIX_LEN_TOO_LONG||9||Request contained a destination prefix length too long for the supplied address/NLRI.|
|GATEWAY_INVALID||10||The server did not have a valid gateway associated with the client.|
|NEXTHOP_INVALID||11||Request contained an invalid nexthop.|
|NEXTHOP_ADDRESS_INVALID||12||Request contained a nexthop with an invallid address.|
|NEXTHOP_LIMIT_EXCEED||13||Request to add paths exceeding maximum ECMP paths for a destination.|
|ROUTE_EXISTS||14||Request contains a route that is already present in the table.|
|ROUTE_NOT_FOUND||15||Request contains a route that is NOT present in the table.|
|PROTOCOL_INVALID||16||Request contains an invalid protocol. Only PROTO_UNSPECIFID or PROTO_BGP_STATIC are allowed in route change operations.|
|ROUTE_ADD_FAILED||17||Request contains a route that is NOT present in the table.|
|NOT_READY||18||The protocol daemon is not initialized and ready to accept route change operations.|
|TRY_AGAIN||19||Request cannot be serviced until current requests are processed.|
|ROUTE_COUNT_INVALID||20||Request contains a route_count that exceeds the max of 1000|
|REQUEST_UNSUPPORTED||21||Request contains a parameter that is not currently supported.|
|REQUEST_INVALID||22||Request contains a parameter that is not valid.|
|INTERFACE_INVALID||23||Interface name is not valid.|
|ROUTE_MONITOR_REGISTER_OPERATION_INVALID||24||Invalid parameters for Route Monitor registration. This can be returned if a wrong value is set in the registration or requested operation is invalid. For example, this error is returned when Route Monitor registration API is called with operation > REGISTER_DEL. This error will also be returned if a registration API is called for an existing registration with a modified value of monitor_reply_route_count.|
|ROUTE_MONITOR_REGISTER_ENOENT||25||This error is returned when Route Monitor register API with delete operation is called for a table which was not registered for monitor using a add operation.|
|ROUTE_MONITOR_REGISTER_POLICY_INVALID||26||Route Monitor Policy invalid|
|ROUTE_MONITOR_REGISTER_REPLY_ROUTE_COUNT_INVALID||27||Route Monitor registration request has invalid monitor_reply_route_count. This error is also returned if monitor_reply_route_count is changed for an existing registration.|
|ROUTE_MONITOR_REGISTER_EXISTS||28||Route monitor registration for same table with same params exists|
|MPLS_LABEL_INVALID||29||MPLS Label value is invalid|
|MPLS_ACTION_INVALID||30||MPLS Label stack operation(s) is invalid|
|Method Name||Request Type||Response Type||Description|
|RouteAdd||RouteUpdateRequest||RouteOperReply||Route Add operation
Add a static route to the routing table.
RouteAdd may be called multiple times for the same prefix to add multiple paths with distinct cookie for the same destination. If a matching route already exists in the given table, then an error will be returned.
RoutingRouteOperRequest may contain from one to 1000 routes to be added.
If the request contains multiple routes, the routes will be processed in the order given and the first error encountered will cause the request to abort. The API always returns the final status (success or first error encountered) and the number of routes that were successfully created prior to any error or full completion of the request.
|RouteModify||RouteUpdateRequest||RouteOperReply||Route Modify operation Modify an existing programmed static route in the routing table. For each route in the request, if the key is matched, the matched route will be updated with the supplied route attributes.
If a matching route does not exist in the given table, then an error will be returned.
RouteUpdateRequest may contain from one to 1000 routes to be added. If the request contains multiple routes, the routes will be processed in the order given and the first error encountered will cause the request to abort. The API always returns the final status (success or first error encountered) and the number of routes that were successfully modified prior to any error or full completion of the request.
|RouteUpdate||RouteUpdateRequest||RouteOperReply||Route Update operation Create a new static route if a matching route does not exist, OR modify an existing static route if it is already present in the routing table. RouteUpdateRequest may contain from one to 1000 routes to be added. If the request contains multiple routes, the routes will be processed in the order given and the first error encountered will cause the request to abort. The API always returns the final status (success or first error encountered) and the number of routes that were successfully modified prior to any error or full completion of the request.|
|RouteRemove||RouteRemoveRequest||RouteOperReply||Route Remove operation
Remove a static route from the routing table. RouteRemove may be called multiple times for the same prefix to remove multiple paths with distinct path_cookie for the same destination. (NOTE: cookie support not yet implemented)
The request may contain from one to 1000 routes to be removed.
If the request contains multiple routes, the routes will be processed in the order given and the first error encountered will cause the request to abort. The API always returns the final status (success or first error encountered) and the number of routes that were successfully modified prior to any error or full completion of the request.
|RouteMonitorRegister||RouteMonitorRegRequest||RouteMonitorReply||Register for route monitoring to monitor the route entries of a table. When clients register for a table all routes that passes policy are streamed to the client. After this the routes that get added or changed or deleted are streamed.
Clients can register to more than one table for route monitoring. Each of these registrations will have a different stream on which the routes will be streamed.
Clients can also change registration parameters for the table. In this case the parameter will be re-applied for the table and the resulting routes of the table are streamed. For e.g if policy is added to the registration to notify only static routes, then all non static routes that were sent before are re-sent with a delete monitor operation. Subsequent monitor messages for the table will contain only static routes. For the above case, streaming will happen on the new stream created for the fresh Register request sent. Streaming of routes on the old stream will stop.
The reply is sent as stream and will be sent as long as monitor registration is valid. Once the monitor registration is deleted, then this streaming will be stopped.