[fpmsyncd] Skip routes to eth0 or docker0

[shi-su]

What I did
Skip routes to eth0 or docker0 in fpmsyncd.

Fix sonic-net/sonic-buildimage#6483

Why I did it
An FRR behavior change from 7.2 to 7.5 makes FRR update the default route to eth0 in interface up/down events. Skipping routes to eth0 or docker0 to avoid such behavior.

How I verified it
Tested locally that the default route does not change in interface up/down events.

Details if related

[imzyxwvu]

Which FRR behaviour change is it that causes fpmsyncd to update default route? What did this behaviour break?

[imzyxwvu]

Take this as a example: At first route 0.0.0.0/0 had a multipath nexthop "Ethernet0,Ethernet1", and some minutes later it became "Ethernet0,Ethernet1,eth0". Last it becomes "eth0". Since the change filters all routes including the eth0 nexthop, in the example this changes prevent "Ethernet0,Ethernet1" from exiting the next-hop list in ASIC. This is a rare situation but I suggest to take this into consideration.

[lguohan]

in our design, we would not have such mixed scenario.

[prsunny]

Minor comment, route updates can be in INFO level log.

[imzyxwvu]

After some investigation, I figured that the problem is actually introduced by this change. SONiC uses rtm_table field (which is designed to pass table ID) of netlink_route protocol to pass VRF ID to FPM, and table ID info is lost. Generally there should be only table main in the default VRF, so this is harmless. But in fact zebra allows multiple route tables per VRF (or at least the main VRF). This leads to a mix of default VRF route updates across all tables and leaves a broken APPL_DB ROUTE_TABLE.

See other_tables field in struct zebra_vrf: https://github.com/Azure/sonic-frr/blob/frr/7.5/zebra/zebra_vrf.h#L85

[shi-su]

After some investigation, I figured that the problem is actually introduced by this change. SONiC uses rtm_table field (which is designed to pass table ID) of netlink_route protocol to pass VRF ID to FPM, and table ID info is lost. Generally there should be only table main in the default VRF, so this is harmless. But in fact zebra allows multiple route tables per VRF (or at least the main VRF). This leads to a mix of default VRF route updates across all tables and leaves a broken APPL_DB ROUTE_TABLE.

See other_tables field in struct zebra_vrf: https://github.com/Azure/sonic-frr/blob/frr/7.5/zebra/zebra_vrf.h#L85

@imzyxwvu Thanks for your investigation. I still have some trouble understanding how other_tables leads to this behavior. And it seems that this patch is basically reverting the changes in FRRouting/frr@6dfcd75

[imzyxwvu]

@imzyxwvu Thanks for your investigation. I still have some trouble understanding how other_tables leads to this behavior. And it seems that this patch is basically reverting the changes in FRRouting/frr@6dfcd75

I'd suggest you to have a look at zebra_vrf_lookup_table_with_table_id.

https://github.com/Azure/sonic-frr/blob/frr/7.5/zebra/zebra_vrf.c#L361

This function includes a lookup on other_tables. The comment also contains some information on table_id.