Routing database module type declarations

type rt_changes

This structure is part of the rt_head structure. The latter heads a list of routes and contains a pointer to the active route being advertised to this destination. This structure contains changes (in metric, preference, AS path etc) if any, that have occurred in the active route.

type rt_aggr_entry

When a protocol aggregates a number of different destinations, the routes to be aggregated are stored in a doubly-linked list. This element forms the head of this doubly-linked list. It contains a back-pointer to the rt_entry for this route.

type rt_aggr_head

The head of a list of rt_aggr_entrys. This also contains the AS paths of the contributing routes.

type rt_head

The routing database in gated is a radix tree, each internal node of which contains a pointer to an rt_head structure. This structure contains a destination address and a doubly linked list of rt_entrys for routes to this destination. This structure also contains a back pointer to the internal node in the radix tree.

type rt_entry

This structure contains one of the routes known to the GateD routing database to a given destination. The information contained in this descriptor includes how the route was learned (IGP/EGP etc.), the next hop to the destination, the metric/preference value, the AS paths and so on.

type rt_parms

A temporary structure used to hold route parameters until all sanity checks have been done and the route has been added to the database.

type rt_parms

Each rt_head entry has a linked list of target specific information (tsi). This is a linked list of 16byte chunks of data which is route and protocol specific (for instance, the tsi data for a BGP route points to the corresponding bgp_rto_entry that contains this route). The tsi's for each protocol are stored sequentially; the rttsi*() set of routines is used to access this data.

type rt_list

Route flash updates to be processed are stored in this structure. An rt_list structure is a descriptor block at the head of a page. Descriptor blocks to routes to be processed are store in the page after this descriptor block. Subsequent pages are chained in a list through the rtl_next field in the descriptor.

Routing database module macros

macro RTBIT_*

Each protocol or protocol peer (in peer-based protocols) is assigned a bit. The rtbit_map array contains a pointer to protocol specific state for each protocol. Each rt_entry contains a bit mask which specifies which protocol(s) this route was learned from. These macros manipulate this bitmask. The GateD routing database module maintains a mapping from bit number to the task that has the bit registered with the module.

macro RT_ALLRT(_REV)

Macro to sequentially traverse, from the beginning (resp. end), a linked list of rt_entrys.

macro RT_ALLRT(_REV)_END

The corresponding macros for ending the loop traversal.

macro RT_LIST_*

These macros manipulate the rt_lists containing flash updates. These include macros to traverse the list one element at a time as well as macros to allocate the list.

Routing database module function definitions

function rttsi_alloc()

The rttsi_map array is a bitmask of all the tsi positions currently allocated. We simply find the first block of unallocated data bytes and proceed to allocate from there. This ensures that, for each protocol, we allocate tsi's contiguously. This function sets the index field in the rtbit_map array entry accordingly.

function rttsi_get()

Traverse a tsi list in a given rt_head structure and find out the data corresponding to the specified rtbit. Copy the data out onto the specified buffer.

function rttsi_set()

Traverse a tsi list in a given rt_head structure and write the specified data to the tsi location specified by the rtbit.

function rttsi_reset()

Traverse a tsi list in a given rt_head structure and reset the data bytes at the tsi location specified by the rtbit.

function rttsi_release()

Walk through a tsi list in the specified rt_head structure and release each block of tsi data.

function rttsi_free()

This changes the bitmap of tsi allocations to reflect the fact that the specified rtbit_map entry is no longer represented in the bitmap.

function rth_remove()

This removes all the resources associated with the specified rt_head including the tsi list and the radix tree node to which the rt_head belongs. The list of routes themselves are taken care of elsewhere.

function rth_locate()

For a given destination/mask pair, call the tree search routine to find a matching internal node with a non-null external data. If one exists, return the external data. Otherwise, allocate an rt_head entry, initialize it and insert it into the radix tree.

function rtchanges_free()

Free the resources associated with an rt_changes structure. These include any AS paths and address information.

function rt_free()

Free the resources (AS path, rt_head if necessary) for the given rt_entry structure.

function select_active()

Called whenever a list of routes to a destination changes (i.e. either a route is added or one is removed or both). This function selects the first route in the list of routes pointed to by the specified rt_head. This is used as the active route unless a holddown protocol is advertizing the currently active route.

function rt_remove()

Remove a route entry from the list to which it belongs. Be sure to decrement the count of routes in the queue head.

function rt_remove()

In a list of routes, the routes are ordered active first, followed by hidden and "deleted" routes. To insert a "deleted" route, add to end of list. To insert a hidden route, search list from the back until you find an appropriate location to insert. Finally, to insert an active route, insert in order of preference. For routes of the same preference, aspath lengths and numerical origin IDs are used to break ties.

function rt_event_*()

This set of functions is called when a route state transition happens. Examples of such transitions include a route becoming active/inactive, routes changing preferences or next-hops etc. The action taken depends on the state (or combination of states) the route is currently in, and usually involves setting the state flag appropriately and (in some cases) could also involve re-queueing the route and recomputing the new active route.

function rt_new_policy()

Called when gated is initialized or after a reconfiguration. Remove any existing flash list and build a complete flash list from the entire routing database. Update the kernel routing table.

function rt_flash_update()

Called when gated is shutting down. Simply process the existing flash list by recomputing the aggregate list and flashing the kernel routing table with the given list.

function rtbit_alloc()

The rtbit_map array contains a map of bits allocated to a protocol or protocol peer. Traverse through this array to find the first unallocated bit and allocate it to this protocol. Also allocate a tsi block from the rttsi_map for this bit number and for the specified data size.

function rtbit_free()

Free the specified rtbit_map entry.

function rtbit_set()

Given a rt_entry, set the specified protocol bit to indicate that this protocol or protocol instance is announcing this route.

function rtbit_reset()

Reset the specified protocol bit in the specified route entry.

function rtbit_reset_all()

Reset the specified protocol bit in all existing routes. Make sure to clear out the tsi fields in each route header to which such route entries may belong.

function rt_locate*()

Given a destination address and mask, locate the rt_entry corresponding to this destination and additionally matching certain criteria (e.g. matching state and protocol, gateway entry etc.). Traverse the radix tree, find the matching rt_head, and traverse the rt_list until you find the corresponding rt_entry. Appears to be used in RIP and OSPF, not in BGP.

function rt_lookup()

Similar to rt_lookup*(), this function finds route to a destination/mask matching a set of criteria. However, it scans the entire routing table for aggregates to this destination and finds the most specific aggregate matching this criteria. Seems to be used mostly in the SNMP code.

function rt_add()

Add a route to the GateD routing database, given the various parameters to the route in a rt_parms struct. This function is called when updates are received in BGP, for instance. Simply locate the head of the queue into which this rt_entry should go into. Allocate a rt_entry copy the parameters (preference, metrics etc) into it. Add the rt_entry to the list of routes advertised by the specified router. Allocate an AS path to the route if necessary. Finally, call rt_insert() to insert the route into the list in preference order.

function rt_change_aspath()

Inaptly named, called when an update is received for any existing route and one or more of the route's attributes (metric, AS path, preference) might have changed. Most complicated processing in this case: is when a next-hop (or set of next-hops for a multi-path) has changed.

function rt_delete()

Called when an unreachable has been received. This simply removes the route from its gateway list, and marks it for deletion (which has to be done carefully if it is on a flash list, for example).

function rt_default*()

A configuration may specify a default route with a specified nexthop and preference. These set of routines are used to add/delete or reinitialize the default route after a re-configuration.