Basic FIB operations are performed by functions defined by this module, enumerating of FIB contents is accomplished by using the FIB_WALK() macro or FIB_ITERATE_START() if you want to do it asynchronously. +
For simple iteration just place the body of the loop between FIB_WALK() and +FIB_WALK_END(). You can't modify the FIB during the iteration (you can modify +data in the node, but not add or remove nodes). +
If you need more freedom, you can use the FIB_ITERATE_*() group of macros. +First, you initialize an iterator with FIB_ITERATE_INIT(). Then you can put +the loop body in between FIB_ITERATE_START() and FIB_ITERATE_END(). In +addition, the iteration can be suspended by calling FIB_ITERATE_PUT(). +This'll link the iterator inside the FIB. While suspended, you may modify the +FIB, exit the current function, etc. To resume the iteration, enter the loop +again. You can use FIB_ITERATE_UNLINK() to unlink the iterator (while +iteration is suspended) in cases like premature end of FIB iteration. +
Note that the iterator must not be destroyed when the iteration is suspended, +the FIB would then contain a pointer to invalid memory. Therefore, after each +FIB_ITERATE_INIT() or FIB_ITERATE_PUT() there must be either +FIB_ITERATE_START() or FIB_ITERATE_UNLINK() before the iterator is destroyed.
void @@ -1346,6 +1361,27 @@ startup code.
void +proto_set_message +(struct proto * p, char * msg, int len) -- set administrative message to protocol +
+
+
protocol +
message +
message length (-1 for NULL-terminated string) +
The function sets administrative message (string) related to protocol state +change. It is called by the nest code for manual enable/disable/restart +commands all routes to the protocol, and by protocol-specific code when the +protocol state change is initiated by the protocol. Using NULL message clears +the last message. The message string may be either NULL-terminated or with an +explicit length. + + +
void proto_request_feeding (struct proto * p) -- request feeding routes to the protocol
@@ -2066,7 +2102,8 @@ processing of interface change events). Inactive entri when the protocol has explicitly requested it via the NEF_STICKY flag because it wishes to be notified when the node will again become a neighbor. Such entries are enqueued in a special list which is walked -whenever an interface changes its state to up. +whenever an interface changes its state to up. Neighbor entry VRF +association is implied by respective protocol.
When a neighbor event occurs (a neighbor gets disconnected or a sticky inactive neighbor becomes connected), the protocol hook neigh_notify() is called to advertise the change.