Routing database module type declarations
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.
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.
The head of a list of rt_aggr_entry
s. This also contains
the AS paths of the contributing routes.
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_entry
s for routes to this destination. This structure
also contains a back pointer to the internal node in the radix tree.
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.
A temporary structure used to hold route parameters until all
sanity checks have been done and the route has been added to the
database.
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.
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
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 to sequentially traverse, from the beginning (resp. end), a linked
list of rt_entry
s.
The corresponding macros for ending the loop traversal.
These macros manipulate the rt_list
s 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
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.
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.
Traverse a tsi list in a given rt_head
structure and
write the specified data to the tsi location specified by the
rtbit
.
Traverse a tsi list in a given rt_head
structure and
reset the data bytes at the tsi location specified by the
rtbit
.
Walk through a tsi list in the specified rt_head
structure
and release each block of tsi data.
This changes the bitmap of tsi allocations to reflect the fact that
the specified rtbit_map entry is no longer represented in the bitmap.
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.
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.
Free the resources associated with an rt_changes
structure.
These include any AS paths and address information.
Free the resources (AS path, rt_head
if necessary) for
the given rt_entry
structure.
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.
Remove a route entry from the list to which it belongs. Be sure
to decrement the count of routes in the queue head.
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.
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.
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.
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.
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.
Free the specified rtbit_map
entry.
Given a rt_entry
, set the specified protocol bit to
indicate that this protocol or protocol instance is announcing this
route.
Reset the specified protocol bit in the specified route entry.
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.
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.
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.
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.
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.
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).
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.