bug-zebra
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

PATCH: remove routes from zebra upon protocol daemon crash (take #2)


From: Arnold, Gilad
Subject: PATCH: remove routes from zebra upon protocol daemon crash (take #2)
Date: Mon, 13 May 2002 12:43:04 +0300

Hi,

I already tried to post it once, with no success. Maybe this time it'll 
work... (plus, I've changed some constant name in the patch)

I'm suggesting my solution for the situation in which a protocol daemon
crashes unexpectedly, thus leaving all distributed routes within Zebra's
RIB. I've seen some different approaches through the list history, most
of them tend to use an outer script that kills the zebra daemon upon a
protocol daemon crash, which seems to me as an overkill (and not so
clean) solution in some cases.

My simple extensions in brief:

1. Extend the RIB element to include a unique "client association",
   which is in fact the client's socket descriptor. This way, each route
   from a protocol daemon is uniquely identified with that daemon's
   connection towards zebra.  When a connection to the daemon is broken,
   zebra will remove from the RIB all routes that were associated with
   that connection.

2. Note that the above extension modifies the traditional behavior of
   the zebra server regarding client routes -- this seemed to me as the
   expected behavior in most cases. However, if a daemon insists on
   having its routes retained within the RIB even after the connection
   is down, it may mark some route message(s) with a new flag:
   ZAPI_MESSAGE_RETAIN. This tells zebra to conform with its old
   behavior, that is not associate the route with the connection. This
   way the route is not removed upon connection breakdown.

3. The association of routes has nothing to do with protocol types an
   so; therefore, it is expected to work for more complicated cases,
   such as multiple protocol daemons (if they exist...), and so on.

4. My code has been compiled *without* IPv6, so I'll appreciate it if
   someone could check to see whether it works well under such
   environment. Also, the code was checked with ospfd as client only
   (although there shouldn't be any difference), so the same holds for
   that as well.

Patch is against CVS version from 2002-05-12.
Hope this is useful and that I'm not killing a dead issue here...

Regards, G.

Attachment: zebra.client_down.cvs_2002-05-12.diff
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]