zebra: Add kernel level graceful restart

[praveen-li]

Add the a --graceful_restart X flag to zebra start that
now creates a timer that pops in X seconds and will go
through and remove all routes that are older than startup.

If graceful_restart is not specified then we will just pop
a timer that cleans everything up immediately.

Signed-off-by: Praveen Chaudhary pchaudhary@linkedin.com
Signed-off-by: Donald Sharp sharpd@cumulusnetworks.com

[praveen-li]

@lguohan @zhenggen-xu @jipanyang for review.

[lguohan]

if you want to get into sonic image, it should be frr/7.0 branch.

[pavel-shirshov]

We can add patches to sonic-frr in two ways:
Either make a PR for https://github.com/FRRouting/frr/tree/stable/7.0
Or add a patch as a .patch file into https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-frr/patch

[jipanyang]

Just to confirm my understanding the -K route processing behavior.

<1> Suppose some route entries exist in both kernel and appDB

 Kernel:  route_A, route_B, route_C,
appDB:  route_A, route_B, route_C

<2> warm restart FRR docker, route_A became stale and new route_D generated.
With the change:

   kernel is ok:  route_B, route_C, route_D

What will be the routes sent to fpmsyncd? Any change needed with current fpmsyncd warm restart logic?

Before the change, fpmsyncd expects route_B, route_C and route_D from zebra. It figures out route_A has become stale, will delete it through appDB, and push down the new route_D as well.

[praveen-li]

Just to confirm my understanding the -K route processing behavior.

<1> Suppose some route entries exist in both kernel and appDB

 Kernel:  route_A, route_B, route_C,
appDB:  route_A, route_B, route_C

<2> warm restart FRR docker, route_A became stale and new route_D generated.
With the change:

   kernel is ok:  route_B, route_C, route_D

What will be the routes sent to fpmsyncd? Any change needed with current fpmsyncd warm restart logic?

Before the change, fpmsyncd expects route_B, route_C and route_D from zebra. It figures out route_A has become stale, will delete it through appDB, and push down the new route_D as well.

@jipanyang : -K option does not change the logic for FRR in terms of route sent to kernel or FPM, it changes RIB calculation. Which means, ideally FRR should send same update to kernel and FPM.

In the example, you mentioned. Updates to kernel will be :
ADD for route B, C ,D
DEL for route A (delayed by a fixed time)

So same update must go to FPM, if not we may have some FRR bug to address.

[praveen-li]

We can add patches to sonic-frr in two ways:
Either make a PR for https://github.com/FRRouting/frr/tree/stable/7.0
Or add a patch as a .patch file into https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-frr/patch

@pavel-shirshov : This PR is already merged in FRR master, but FRR community is reluctant to backport it to FRR7.0. That`s why we need to merge it explicitly in SONIC-FRR.
I was thinking we can merge it in sonic-frr master or sync sonic-frr master with FRR Master.
Then back port the fix in Sonic-FRR 7.0.

[praveen-li]

if you want to get into sonic image, it should be frr/7.0 branch.

@lguohan : I want to merge this fix in sonic-FRR 4.0 to 7.0 . What is the process, do we need 4 separate PRs or one PR and then chery-pick.
I thought I can merge it in master and then cherry-pick same for other branches.

[pavel-shirshov]

@praveen-li I understand that. Can you please make it your change in sonic-buildimage repo as patch?
https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-frr/patch

[praveen-li]

@praveen-li I understand that. Can you please make it your change in sonic-buildimage repo as patch?
https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-frr/patch

@pavel-shirshov Sure, If that is the way to go. I will make it a patch. Thx.

[praveen-li]

@praveen-li I understand that. Can you please make it your change in sonic-buildimage repo as patch?
https://github.com/Azure/sonic-buildimage/tree/master/src/sonic-frr/patch

@pavel-shirshov Sure, If that is the way to go. I will make it a patch. Thx.
@pavel-shirshov : I was planning to raise PR for this code to merge in FRR-4.0 to FRR 7.0.
I noticed that, In sonic we do not use patch for submodules. We use patch only when Makefile uses "git clone" or dsc file to fetch fresh code with each build, i.e. we do not maintain the code. With Submodule, we are maintaining the code already, so we should directly commit the code.
If I use patch for submodules, each subsequence build needs to remove the patches done by stg first and then reapply. Kindly let know your views, thanks a lot.

[praveen-li]

Closing, I will raise as patch.