mirror of
https://git.proxmox.com/git/mirror_frr
synced 2025-07-15 05:08:02 +00:00
62196fbd19
Lots of questions raising regarding unresolved nht, I think it's time to relax this and make it a default ON. Here is an example list of issues when `nht resolvia-via-default` solved the problem: https://github.com/FRRouting/frr/issues/3241 https://github.com/FRRouting/frr/issues/7420 https://github.com/FRRouting/frr/issues/3474 https://github.com/FRRouting/frr/issues/5023 https://github.com/FRRouting/frr/issues/6504 https://github.com/FRRouting/frr/issues/6680 https://github.com/FRRouting/frr/issues/7049 https://github.com/FRRouting/frr/issues/7862 https://github.com/FRRouting/frr/issues/7999 https://github.com/FRRouting/frr/issues/13215 https://github.com/FRRouting/frr/issues/14098 TL;DR; The BGP session does not come up if using multihop sessions and/or the peer(nexthop) is not accessible from the RIB, but only via default route. This is even valid for iBGP, and not only for eBGP peering. Adding a static /32, /128 route for the peer would do the trick, but it's a workaround. If the route has a nexthop marked as invalid, most likely this is due to it can't be resolved from the current RIB, but only via default route. For instance, Cisco allows this by default (can't find even a knob to turn it off or I'm blind). For eBGP sessions it might be also combined with `disable-ebgp-connected-route-check`. Some people asked if this could be a default, also for instance MetalLB is adding this by default for all the configs it generates. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org> |
||
|---|---|---|
| .. | ||
| accords | ||
| developer | ||
| extra | ||
| figures | ||
| licenses | ||
| manpages | ||
| mpls | ||
| user | ||
| .gitignore | ||
| Makefile | ||
| requirements.txt | ||
| subdir.am | ||