Local routes for interfaces should not be sent from FRR (version 10.0.1) to orchagent because IP2ME routes are already created by orchagent for these routes.

[sudhanshukumar22]

Hi all,
FRR 10.0.1 has introduced a new feature for supporting local routes. (FRRouting/frr#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

We already raised a PR in FRR(FRRouting/frr#17462), but they suggest that since this feature is needed on other dataplanes, they can't block this in FRR . SONIC should handle it gracefully(by blocking this using a patch in their dataplane).
Note that this is a new feature in FRR 10.0.1 and the issue is not seen in FRR 8.5.4.

Steps to reproduce the issue:

1. Configure an ip address on an interface
2. bring up the interface

Describe the results you received:

We see that FRR creates 2 routes (connected and local) for this address configuration on the interface.

Describe the results you expected:

Only connected route should be present.

Output of show version:

FRR version 10.0.1

(paste your output here)

Output of show techsupport:

(paste your output here or download and attach the file here )

Additional information you deem important (e.g. issue happens only occasionally):

[prabhataravind]

@adyeung to work on addressing this.