Introduction of host local routes has changed the behavior in between FRR8.5.4 and FRR10.0.1

[sudhanshukumar22]

Description

Hi all,
FRR 10.0.1 has introduced a new feature for supporting local routes. (#12600) This has created a difference in behavior between FRR 8.5.4 and FRR10.0.1. In SONIC, IP2ME routes are automatically created by orchagent and installed in hardware. Whereas now these local routes also get installed and conflict with the IP2ME routes, resulting in orchagent crash.

sonic# show ip route
Codes: K - kernel route, C - connected, L - local, S - static,
R - RIP, O - OSPF, I - IS-IS, B - BGP, E - EIGRP, N - NHRP,
T - Table, v - VNC, V - VNC-Direct, A - Babel, F - PBR,
f - OpenFabric, t - Table-Direct,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure

K>* 0.0.0.0/0 [0/202] via 10.59.128.1, eth0, 1d09h33m
C>* 10.0.0.0/31 is directly connected, Ethernet0, 1d09h33m
L> 10.0.0.0/32 is directly connected, Ethernet0, 1d09h33m
C>* 10.0.0.2/31 is directly connected, Ethernet4, 1d09h33m
L> 10.0.0.2/32 is directly connected, Ethernet4, 1d09h33m
C>* 10.0.0.4/31 is directly connected, Ethernet8, 1d09h33m
L> 10.0.0.4/32 is directly connected, Ethernet8, 1d09h33m
C>* 10.0.0.6/31 is directly connected, Ethernet12, 1d09h33m
L> 10.0.0.6/32 is directly connected, Ethernet12, 1d09h33m
C>* 10.0.0.8/31 is directly connected, Ethernet16, 1d09h33m
L> 10.0.0.8/32 is directly connected, Ethernet16, 1d09h33m
C>* 10.0.0.10/31 is directly connected, Ethernet20, 1d09h33m
L> 10.0.0.10/32 is directly connected, Ethernet20, 1d09h33m
C>* 10.0.0.12/31 is directly connected, Ethernet24, 1d09h33m
L> 10.0.0.12/32 is directly connected, Ethernet24, 1d09h33m
C>* 10.0.0.14/31 is directly connected, Ethernet28, 1d09h33m
L> 10.0.0.14/32 is directly connected, Ethernet28, 1d09h33m
C>* 10.0.0.16/31 is directly connected, Ethernet32, 1d09h33m
L> 10.0.0.16/32 is directly connected, Ethernet32, 1d09h33m
C>* 10.0.0.18/31 is directly connected, Ethernet36, 1d09h33m
L> 10.0.0.18/32 is directly connected, Ethernet36, 1d09h33m
C>* 10.0.0.20/31 is directly connected, Ethernet40, 1d09h33m
L> 10.0.0.20/32 is directly connected, Ethernet40, 1d09h33m
C>* 10.0.0.22/31 is directly connected, Ethernet44, 1d09h33m
L> 10.0.0.22/32 is directly connected, Ethernet44, 1d09h33m
C>* 10.0.0.24/31 is directly connected, Ethernet48, 1d09h33m

Version

FRR 10.0.1

How to reproduce

Configure ip addresses on a few interfaces and we will see connected subnet route and /32 local route. The /32 local route was not present in FRR8..5.4.

Expected behavior

The /32 local routes should not be created by default. If it is due to a new feature, there should have been a config knob to enable/disable this feature.

Actual behavior

New /32 local routes are created by default for every ip address configured.

Additional context

No response

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[ton31337]

@sudhanshukumar22 could you check if this would solve the issue? #14970

[donaldsharp]

We talked about this problem in the Sonic Routing working group last week. The problem is not properly identified. The dplane_fpm_nl file is sending down local routes which should just be not sent down the fpm.

In sonic, for whatever reason, the connected routes being sent down to the dplane via dplane_fpm_nl.c are being used to create the connected routes in the asic. The local routes are already created via a different mechanism and are causing a problem deep in the bowels of sonic code. Frankly sonic should take care of this. Sending a local or connected route down is needed as that not only sonic is using the dplane for reception of data.

[sudhanshukumar22]

Hi @ton31337
C>* 10.0.0.2/31 is directly connected, Ethernet4, 1d09h33m
L> 10.0.0.2/32 is directly connected, Ethernet4, 1d09h33m
These 2 routes have different prefix lengths. So they will not match.

[sudhanshukumar22]

@sudhanshukumar22 could you check if this would solve the issue? #14970

It will not work as told above.

[sudhanshukumar22]

We talked about this problem in the Sonic Routing working group last week. The problem is not properly identified. The dplane_fpm_nl file is sending down local routes which should just be not sent down the fpm.

In sonic, for whatever reason, the connected routes being sent down to the dplane via dplane_fpm_nl.c are being used to create the connected routes in the asic. The local routes are already created via a different mechanism and are causing a problem deep in the bowels of sonic code. Frankly sonic should take care of this. Sending a local or connected route down is needed as that not only sonic is using the dplane for reception of data.

Please note that sonic uses dplane_fpm_sonic now,

[sudhanshukumar22]

Raised PR(sonic-net/sonic-buildimage#20967) in SONIC.