Hello Quagga developers
We are running quagga with about 60 sessions. We dump bgp tables once a
day. Recently, we have noticed that bgpd drops its sessions while it's
writing bgp tables to the disk. The reason is that table dump takes
close to 2 minutes in our case....
To solve the problem of table dumps locking the bgpd process, I propose
to divide the table dump procedure into two parts:
(1) Make an in-memory copy of the current routing table (RIB). Store the
time-stamp of the copy operation for later use.
(2) Dump the in-memory copy in small chunks to the file. So, the process
will dump a few entries in one go, then come up for air and do other
higher priority stuff like keepalive and update processing, and then
again dive back into table dumping.
The time-stamps dumped along with the table entries is the one stored in
step (1).
The advantage: it's simple enough to implement, and should solve our
problem. Step (1) should not lock bgpd long enough for it to miss the
keepalives. All the routing table entries will have a single time-stamp
which will make it easier to re-construct RIB at any instance by
applying updates to the dumped routing table entries...
The disadvantage: the extra memory and a bit of extra processing....
I am sending this e-mail to u for the following reasons:
(1) Are there any other problems/pitfalls that u guys can think of?
(2) If I make the extensions, would there be any interest in making this
a part of the quagga distribution? If so, how do u want me to proceed?
Alternatively, if u guys want to do it, what time frame would it take u
do it?
thx,
aman
We are running quagga with about 60 sessions. We dump bgp tables once a
day. Recently, we have noticed that bgpd drops its sessions while it's
writing bgp tables to the disk. The reason is that table dump takes
close to 2 minutes in our case....
To solve the problem of table dumps locking the bgpd process, I propose
to divide the table dump procedure into two parts:
(1) Make an in-memory copy of the current routing table (RIB). Store the
time-stamp of the copy operation for later use.
(2) Dump the in-memory copy in small chunks to the file. So, the process
will dump a few entries in one go, then come up for air and do other
higher priority stuff like keepalive and update processing, and then
again dive back into table dumping.
The time-stamps dumped along with the table entries is the one stored in
step (1).
The advantage: it's simple enough to implement, and should solve our
problem. Step (1) should not lock bgpd long enough for it to miss the
keepalives. All the routing table entries will have a single time-stamp
which will make it easier to re-construct RIB at any instance by
applying updates to the dumped routing table entries...
The disadvantage: the extra memory and a bit of extra processing....
I am sending this e-mail to u for the following reasons:
(1) Are there any other problems/pitfalls that u guys can think of?
(2) If I make the extensions, would there be any interest in making this
a part of the quagga distribution? If so, how do u want me to proceed?
Alternatively, if u guys want to do it, what time frame would it take u
do it?
thx,
aman