К чему может привести дублирование локальных маршрутов в FRR?

Question

[ne-vlezay80]

Вот примерно вывод:

localhost# sh ip ro
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

IPv4 unicast VRF default:
S>* 172.30.240.0/24 [1/0] unreachable (blackhole), weight 1, 05:48:42
O   172.30.240.1/32 [110/10] via 0.0.0.0, null0 onlink, rmapsrc 172.30.240.1, weight 1, 05:48:42
L * 172.30.240.1/32 is directly connected, null0, weight 1, 05:48:43
C>* 172.30.240.1/32 is directly connected, null0, weight 1, 05:48:43
O>* 172.30.240.2/32 [110/10] via 192.168.100.2, rtr-br0, rmapsrc 172.30.240.1, weight 1, 05:39:27
O>* 172.30.240.3/32 [110/10] via 192.168.100.5, rtr-br0, rmapsrc 172.30.240.1, weight 1, 05:43:20
O>* 172.30.240.4/32 [110/10] via 192.168.100.3, rtr-br0, rmapsrc 172.30.240.1, weight 1, 00:12:31
O>* 172.30.240.5/32 [110/10] via 192.168.100.6, rtr-br0, rmapsrc 172.30.240.1, weight 1, 05:43:11
L * 192.168.5.1/32 is directly connected, test0, weight 1, 00:00:25
C * 192.168.5.1/32 is directly connected, test0, weight 1, 00:00:25
L * 192.168.5.1/32 is directly connected, test0, weight 1, 00:07:13
L * 192.168.5.1/32 is directly connected, test0, weight 1, 00:07:27
L>* 192.168.5.1/32 is directly connected, test0, weight 1, 00:07:53
C>* 192.168.100.0/24 is directly connected, rtr-br0, weight 1, 05:44:02
O   192.168.100.0/24 [110/10] is directly connected, rtr-br0, weight 1, 05:48:42
L * 192.168.100.1/32 is directly connected, rtr-br0, weight 1, 05:44:02
L>* 192.168.100.1/32 is directly connected, rtr-br0, weight 1, 05:48:43

Версия: 10.5
Ссылка на баг репорт: https://github.com/FRRouting/frr/issues/20337

К чему может привести данный баг, если frr будет в таком режиме работать круглый год?

Answer 1

[Strabbo]

Это просто таблица маршрутизации. на сетевом слэнге это control plane. В зависимости от софта, в ней могут быть показаны только актуальные маршруты или же все известные. В вашем случае показывает все известные, дальше выигрывает тот маршрут у кого маска меньше, /32 всех побеждает. Если у одного маршрута и префикс и маска одинакова то решает локальный параметр, который в разных софтах может иметь разное название( Administrative Distance, Preference). Чем он ниже, тем круче. У OSPF он 110, а у локальных он скорее всего 0 или 1. Надо уже смотреть доки FRR. Вот это всё, что я написал это Control Plane, он собирает всю инфу по маршрутизации и передает его операционной системе, которая уже формирует Forwarding plane и вот там уже не будет дублированных записей от разных протоколов, будет только одна.

К чему может привести данный баг, если frr будет в таком режиме работать круглый год?

Всё будет работать без проблем.