Commit Graph

1144 Commits

Author SHA1 Message Date
Louis Scalbert
70e07678bf bgpd: fix leaving hidden state
Upon configuration of a VRF instance that references an absent default
VRF with "import vrf default", the default instance is created in hidden
state. However, the default instance is not properly un-hidden when
configured.

Restore the behavior prior to commit below.

Fixes: 9f7177af13 ("bgpd: fix duplicate BGP instance created with unified config")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-24 17:52:43 +01:00
Alexander Skorichenko
1515a59202 bgpd: update AS value of a hidden bgp instance
'import vrf VRF' could define a hidden bgp instance with
the default AS_UNSPECIFIED (i.e. = 1) value.
When a
	router bgp AS vrf VRF
gets configured later on, replace this AS_UNSPECIFIED setting
with a requested value.

Fixes: 9680831518 ("bgpd: fix as_pretty mem leaks when un-hiding")
Signed-off-by: Alexander Skorichenko <askorichenko@netgate.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-24 15:17:05 +01:00
Louis Scalbert
339206341f Revert "bgpd: fix bgp vrf instance creation from implicit"
This reverts commit 2ff08af78e.

The fix is obviously wrong.

Link: 2ff08af78e
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-24 15:17:05 +01:00
Louis Scalbert
71a3756f2d bgpd: fix process_queue when un-hiding
bgp_process_queue_init() is not called in bgp_create() when leaving the
BGP instance hidden state because of the following goto:

>	if (hidden) {
>		bgp = bgp_old;
>		goto peer_init;
>	}

Upon reconfiguration of the default instance, the prefixes are never set
into a meta queue by mq_add_handler(). They are never processed for
zebra RIB installation and announcements of update/withdraw.

Do not delete the BGP process_queue when hiding.

Fixes: 4d0e7a49cf ("bgpd: VRF-Lite fix default bgp delete")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-24 15:17:05 +01:00
Louis Scalbert
d2ff7e8a21 bgpd: fix default instance name when un-hiding
When unconfiguring a default BGP instance with VPN SAFI configurations,
the default BGP structure remains but enters a hidden state. Upon
reconfiguration, the instance name incorrectly appears as "VIEW ?"
instead of "VRF default". And the name_pretty pointer

The name_pretty pointer is replaced by another one with the incorrect
name. This also leads to a memory leak as the previous pointer is not
properly freed.

Do not rewrite the instance name.

Fixes: 4d0e7a49cf ("bgpd: VRF-Lite fix default bgp delete")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-24 15:17:05 +01:00
Louis Scalbert
d6363625c3 bgpd: release manual vpn label on instance deletion
When a BGP instance with a manually assigned VPN label is deleted, the
label is not released from the Zebra label registry. As a result,
reapplying a configuration with the same manual label leads to VPN
prefix export failures.

For example, with the following configuration:

> router bgp 65000 vrf BLUE
>  address-family ipv4 unicast
>   label vpn export <int>

Release zebra label registry on unconfiguration.

Fixes: d162d5f6f5 ("bgpd: fix hardset l3vpn label available in mpls pool")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
2025-02-12 14:03:02 +01:00
Chirag Shah
2ff08af78e bgpd: fix bgp vrf instance creation from implicit
In bgp route leak, when import vrf x is executed,
it creates bgp instance as hidden with asn value as unspecified.

When router bgp x is configured ensure the correct as,
asnotation is applied otherwise running config shows asn value as 0.

This can lead to frr-reload failure when any FRR config change.

Fix:
Move asn and asnotiation, as_pretty value in common done section,
so when bgp_create gets existing instance but before returning
update asn and required fields in common section.

In bgp_create(): when returning for hidden at least update asn
and required when bgp instance created implicitly due to vrf leak.

if (hidden) {
    bgp = bgp_old;
    goto peer_init; <<<
}

Before fix:
show running:

router bgp 0 vrf purple
 bgp router-id 10.10.3.11
 !
 address-family ipv4 unicast
  redistribute static
  import vrf blue
 exit-address-family
 !
 address-family ipv6 unicast
  import vrf blue
 exit-address-family
 !
 address-family l2vpn evpn
  advertise ipv4 unicast
  advertise ipv6 unicast
 exit-address-family
exit

Testing:

1) following snippet config:
router bgp 63420 vrf blue
 import vrf purple
router bgp 63420 vrf purple
 import vrf blue
2) restart frr leads to the running config with 0 asn value.

Signed-off-by: Chirag Shah <chirag@nvidia.com>
2025-02-10 19:08:00 -08:00
Russ White
2ef76a3350
Merge pull request #17871 from opensourcerouting/feature/bgp_link_local_capability
bgpd: Implement Link-Local Next Hop capability
2025-02-07 14:00:59 -05:00
Carmine Scarpitta
0768c620e0
Merge pull request #17913 from Sokolmish/bgp-sid-release
bgpd: Release SID on router deletion
2025-02-03 14:52:00 +01:00
Mikhail Sokolovskiy
f3680ab410 bgpd: Release SID on router deletion
Signed-off-by: Mikhail Sokolovskiy <sokolmish@gmail.com>
2025-01-30 01:54:31 +03:00
Russ White
cec2e9b159
Merge pull request #17881 from opensourcerouting/fix/last_reset_reason
bgpd: last reset SNAFU
2025-01-28 10:40:50 -05:00
Donatas Abraitis
4338e21aa2 Revert "bgpd: Handle Addpath capability using dynamic capabilities"
This reverts commit 05cf9d03b3.

TL;DR; Handling BGP AddPath capability is not trivial (possible) dynamically.

When the sender is AddPath-capable and sends NLRIs encoded with AddPath ID,
and at the same time the receiver sends AddPath capability "disable-addpath-rx"
(flag update) via dynamic capabilities, both peers are out of sync about the
AddPath state. The receiver thinks already he's not AddPath-capable anymore,
hence it tries to parse NLRIs as non-AddPath, while they are actually encoded
as AddPath.

AddPath capability itself does not provide (in RFC) any mechanism on backward
compatible way to handle NLRIs if they come mixed (AddPath + non-AddPath).

This explains why we have failures in our CI periodically.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-25 20:51:16 +02:00
Philippe Guibert
3a921c6a1d bgpd: fix import vrf creates multiple bgp instances
The more the vrf green is referenced in the import bgp command, the more
there are instances created. The below configuration shows that the vrf
green is referenced twice, and two BGP instances of vrf green are
created.

The below configuration:
> router bgp 99
> [..]
>  import vrf green
> exit
> router bgp 99 vrf blue
> [..]
>  import vrf green
> exit
> router bgp 99 vrf green
> [..]
> exit
>
> r4# show bgp vrfs
> Type  Id     routerId          #PeersCfg  #PeersEstb  Name
>              L3-VNI            RouterMAC              Interface
> DFLT  0      10.0.3.4          0          0           default
>              0                 00:00:00:00:00:00      unknown
>  VRF  5      10.0.40.4         0          0           blue
>              0                 00:00:00:00:00:00      unknown
>  VRF  6      0.0.0.0           0          0           green
>              0                 00:00:00:00:00:00      unknown
>  VRF  6      10.0.94.4         0          0           green
>              0                 00:00:00:00:00:00      unknown

Fix this at import command, by looking at an already present bgp
instance.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2025-01-21 13:48:36 +01:00
Philippe Guibert
9f7177af13 bgpd: fix duplicate BGP instance created with unified config
When running the bgp_evpn_rt5 setup with unified config, memory leak
about a non deleted BGP instance happens.

> root@ubuntu2204hwe:~/frr/tests/topotests/bgp_evpn_rt5# cat /tmp/topotests/bgp_evpn_rt5.test_bgp_evpn/r1.asan.bgpd.1164105
>
> =================================================================
> ==1164105==ERROR: LeakSanitizer: detected memory leaks
>
> Indirect leak of 12496 byte(s) in 1 object(s) allocated from:
>     #0 0x7f358eeb4a57 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:154
>     #1 0x7f358e877233 in qcalloc lib/memory.c:106
>     #2 0x55d06c95680a in bgp_create bgpd/bgpd.c:3405
>     #3 0x55d06c95a7b3 in bgp_get bgpd/bgpd.c:3805
>     #4 0x55d06c87a9b5 in bgp_get_vty bgpd/bgp_vty.c:603
>     #5 0x55d06c68dc71 in bgp_evpn_local_l3vni_add bgpd/bgp_evpn.c:7032
>     #6 0x55d06c92989b in bgp_zebra_process_local_l3vni bgpd/bgp_zebra.c:3204
>     #7 0x7f358e9e3feb in zclient_read lib/zclient.c:4626
>     #8 0x7f358e98082d in event_call lib/event.c:1996
>     #9 0x7f358e848931 in frr_run lib/libfrr.c:1232
>     #10 0x55d06c60eae1 in main bgpd/bgp_main.c:557
>     #11 0x7f358e229d8f in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58

Actually, a BGP VRF Instance is created in auto mode when creating the
global BGP instance for the L3 VNI. And again, an other BGP VRF instance
is created. Fix this by ensuring that a non existing BGP instance is not
present. If it is present, and with auto mode or in hidden mode, then
override the AS value.

Fixes: f153b9a9b6 ("bgpd: Ignore auto created VRF BGP instances")

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2025-01-21 13:48:36 +01:00
Donatas Abraitis
9a5be11191 bgpd: Set last reset No AFI/SAFI activated for peer after we do defaults
Move checking if the peer is active only after we apply defaults for address
families.

If the family got activated after applying the defaults we should reset last_reset
reason.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-19 11:08:00 +02:00
Donatas Abraitis
db853cc97e bgpd: Implement Link-Local Next Hop capability
Related: https://datatracker.ietf.org/doc/html/draft-white-linklocal-capability

TL;DR; use 16 bytes long next-hops for point-to-point (unnumbered) links instead
of sending 32 bytes (::/LL, GUA/LL, LL/LL combinations).

For backward compatiblity we should handle even 32 bytes existing next hops.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-17 16:48:32 +02:00
Donatas Abraitis
d3c46bce3b bgpd: Set the last reset reason correctly if we change capabilities per-peer
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-17 13:22:38 +02:00
Russ White
66a5d76920
Merge pull request #17810 from donaldsharp/bgp_connect_refactor
Bgp connect refactor
2025-01-15 11:11:41 -05:00
Donatas Abraitis
d60320c6d2 bgpd: Handle ENHE capability via dynamic capability
FRR supports dynamic capability which is useful to exchange the capabilities
without tearing down the session. ENHE capability was missed to be included
handling via dynamic capability. Let's add it too.

This was missed and asked in Slack that it would be useful.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-14 22:46:53 +02:00
Donald Sharp
78fa9b6feb bgpd: su_remote and su_local are properties of the connection
su_local and su_remote in the peer can change based upon
if we are initiating the remote connection or receiving it.
As such we need to treat it as a property of the connection.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2025-01-10 10:07:11 -05:00
Donatas Abraitis
76fc75de9e bgpd: Fix showing default timers bgp x y
Fixes: ef4a9215b9 ("bgpd: Reuse defined constants for BGP timers")
Fixes: ab3535fbcf ("bgpd: Implement connect retry backoff")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2025-01-09 23:56:31 +02:00
Russ White
2a90c80f49
Merge pull request #17733 from pguibert6WIND/bmp_event_changes
BMP handling of BGP configuration changes
2025-01-07 09:06:43 -05:00
Enke Chen
bcd1017794 bgpd: fix a bug in peer_allowas_in_set()
Fix a bug in peer_allowas_in_set() so that the config takes effect
for peer-group members.

Signed-off-by: Enke Chen <enchen@paloaltonetworks.com>
2025-01-06 21:01:14 -08:00
Donatas Abraitis
f3daeda935
Merge pull request #17716 from ykholod/master-17463
bgpd: Clean address-family config on daemon restart
2025-01-01 21:16:39 +02:00
Philippe Guibert
f3c17d94e0 bgpd: bmp, define hook for router-id updates
At startup, if bmp loc-rib is enabled, the peer_id of the
loc-rib per peer header message has the router-id set to 0.0.0.0.
Actually, the router-id has been updated after the peer up
message is sent, and the information is not refreshed.

Create a hook API to handle router id events: withdraw and
updates. Use that hook in BMP module to send peer down, and
peer up events when necessary.

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-12-30 15:13:38 +01:00
Yaroslav Kholod
663281ca6a BGP: Clean address-family config on daemon restart
When stopping and restarting BGP daemon part of the configuration
remains. It should be cleared.
Particulary those are address-family parametes, like: distance,
ead-es-frag, disable-ead-evi-rx, disable-ead-evi-tx.

Signed-off-by: Yaroslav Kholod <y.kholod@vyos.io>
2024-12-30 14:37:54 +02:00
Donatas Abraitis
9ce3b144c9
Merge pull request #17580 from varuntumbe/dev/label_pool_release_fix
BGP Labelpool : Releasing the label in labelpool when VPN session gets removed
2024-12-23 14:48:21 +02:00
Donatas Abraitis
b6dcf61877 bgpd: Fix enforce-first-as per peer-group removal
If we do `no neighbor PG enforce-first-as`, it wasn't working because the flag
was inherited incorrectly for the members of the peer-group.

Fixes: 322462920e ("bgpd: Enable enforce-first-as by default")

Closes: https://github.com/FRRouting/frr/issues/17702

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-21 17:04:30 +02:00
Jafar Al-Gharaibeh
1b213448a9
Merge pull request #17619 from donaldsharp/bgp_metaq_upstream
bgpd: add meta queue in bgp
2024-12-20 13:59:15 -06:00
Jafar Al-Gharaibeh
956143a8fc
Merge pull request #17586 from opensourcerouting/fix/revalidate_only_affected_routes
bgpd: Validate only affected RPKI prefixes instead of a full RIB
2024-12-19 15:59:17 -06:00
Karthikeya Venkat Muppalla
16ca97d2d9 bgpd: add meta queue in bgp
This commit introduces meta queue to the BGP process_queue which is
helpful in having a priority of lists where some routes can be processed
earlier than 'other' routes. This is similar to how meta queue is
present in zebra.

After Fix:
---------

For testing, note that all 100.x routes are marked as Early routes which
got enqueued and dequeued first before Other routes in every batch of
updates. Also, the items are dequeued in FIFO order.

switch# cat /var/log/frr/bgpd.log | grep sub-queue
2024/12/06 19:19:42.788014 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:42.856127 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:42.856138 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:42.886715 BGP: [V64FH-G6883] 66.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.022835 BGP: [V64FH-G6883] 33.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.058842 BGP: [V64FH-G6883] 44.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.092365 BGP: [V64FH-G6883] 55.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.540770 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541233 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.541523 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:43.602094 BGP: [V64FH-G6883] 88.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.649083 BGP: [V64FH-G6883] 100.90.9.186/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649092 BGP: [V64FH-G6883] 100.90.9.187/32 queued into sub-queue Early Route
2024/12/06 19:19:43.649148 BGP: [V64FH-G6883] 77.0.0.9/32 queued into sub-queue Other Route
2024/12/06 19:19:43.712282 BGP: [V64FH-G6883] 100.90.9.138/32 queued into sub-queue Early Route
2024/12/06 19:19:43.712314 BGP: [V64FH-G6883] 100.90.9.139/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817194 BGP: [V64FH-G6883] 100.90.8.58/32 queued into sub-queue Early Route
2024/12/06 19:19:43.817205 BGP: [V64FH-G6883] 100.90.8.59/32 queued into sub-queue Early Route
2024/12/06 19:19:43.942464 BGP: [ZAPXS-9754G] 100.90.9.186/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942530 BGP: [ZAPXS-9754G] 100.90.9.187/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942550 BGP: [ZAPXS-9754G] 100.90.9.138/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942738 BGP: [ZAPXS-9754G] 100.90.9.139/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942763 BGP: [ZAPXS-9754G] 100.90.8.58/32 dequeued from sub-queue Early Route
2024/12/06 19:19:43.942788 BGP: [ZAPXS-9754G] 100.90.8.59/32 dequeued from sub-queue Early Route
2024/12/06 19:19:44.558611 BGP: [ZAPXS-9754G] 66.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:44.893541 BGP: [ZAPXS-9754G] 33.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.171794 BGP: [ZAPXS-9754G] 44.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.453137 BGP: [ZAPXS-9754G] 55.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.685269 BGP: [ZAPXS-9754G] 88.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 19:19:45.764752 BGP: [ZAPXS-9754G] 77.0.0.9/32 dequeued from sub-queue Other Route

With 'update-delay' feature (EOIU marker):
------------------------------------------

switch# vtysh -c "show run bgp" | grep update-delay
 update-delay 40

switch# cat /var/log/frr/bgpd.log | grep sub-queue
2024/12/06 23:27:46.124461 BGP: [V64FH-G6883] 22.0.0.9/32 queued into sub-queue Other Route
2024/12/06 23:27:46.160224 BGP: [V64FH-G6883] 100.90.8.11/32 queued into sub-queue Early Route
2024/12/06 23:27:46.219663 BGP: [W9QTR-P4REP] EOIU Marker queued into sub-queue EOIU Marker
2024/12/06 23:27:46.269711 BGP: [ZAPXS-9754G] 100.90.8.11/32 dequeued from sub-queue Early Route
2024/12/06 23:27:46.270980 BGP: [ZAPXS-9754G] 22.0.0.9/32 dequeued from sub-queue Other Route
2024/12/06 23:27:46.404868 BGP: [RBX2V-K33CZ] EOIU Marker dequeued from sub-queue EOIU Markera

Ticket: #4200787
Signed-off-by: Karthikeya Venkat Muppalla <kmuppalla@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-12-17 12:41:29 -05:00
varuntumbe
d5c2f2df19 bgpd: Releasing the label in bgp_delete flow
Releasing the vpn label from label pool chunk using bgp_lp_release routine whenever vpn session is removed.
bgp_lp_release will clear corresponding bit in the allocated map of the label pool chunk and increases nfree by 1

Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
2024-12-16 21:27:46 +05:30
Rajasekar Raja
0f2cb27310 bgpd: backpressure - Optimize EVPN L3VNI remote routes processing
Anytime BGP gets a L3 VNI ADD/DEL from zebra,
 - Walking the entire global routing table per L3VNI is very expensive.
 - The next read (say of another VNI ADD/DEL) from the socket does
   not proceed unless this walk is complete.

So for triggers where a bulk of L3VNI's are flapped, this results in
huge output buffer FIFO growth spiking up the memory in zebra since bgp
is slow/busy processing the first message.

To avoid this, idea is to hookup the BGP-VRF off the struct bgp_master
and maintain a struct bgp FIFO list which is processed later on, where
we walk a chunk of BGP-VRFs and do the remote route install/uninstall.

Ticket :#3864372

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-12-09 08:46:16 -08:00
Rajasekar Raja
07a80709c7 bgpd: backpressure - Optimize EVPN L2VNI remote routes processing
Anytime BGP gets a L2 VNI ADD from zebra,
 - Walking the entire global routing table per L2VNI is very expensive.
 - The next read (say of another VNI ADD) from the socket does
   not proceed unless this walk is complete.

So for triggers where a bulk of L2VNI's are flapped, this results in
huge output buffer FIFO growth spiking up the memory in zebra since bgp
is slow/busy processing the first message.

To avoid this, idea is to hookup the VPN off the bgp_master struct and
maintain a VPN FIFO list which is processed later on, where we walk a
chunk of VPNs and do the remote route install.

Note: So far in the L3 backpressure cases(#15524), we have considered
the fact that zebra is slow, and the buffer grows in the BGP.

However this is the reverse i.e. BGP is very busy processing the first
ZAPI message from zebra due to which the buffer grows huge in zebra
and memory spikes up.

Ticket :#3864372

Signed-off-by: Rajasekar Raja <rajasekarr@nvidia.com>
2024-12-09 08:46:16 -08:00
Donatas Abraitis
b0800bfdf0 bgpd: Validate only affected RPKI prefixes instead of a full RIB
Before this fix, if rpki_sync_socket_rtr socket returns EAGAIN, then ALL routes
in the RIB are revalidated which takes lots of CPU and some unnecessary traffic,
e.g. if using BMP servers. With a full feed it would waste 50-80Mbps.

Instead we should try to drain an existing pipe (another end), and revalidate
only affected prefixes.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-06 23:31:33 +02:00
Donatas Abraitis
2797506a5e bgpd: Check if as_type is not specified when peer is a peer-group member
Fixes this sequences:

```
neighbor pg4 peer-group
neighbor 127.0.0.4 peer-group pg4
neighbor 127.0.0.4 remote-as 65004

neighbor pg5 peer-group
neighbor 127.0.0.5 peer-group pg5
neighbor 127.0.0.5 remote-as internal
```

Fixes: 0dfe256 ("bgpd: Implement neighbor X remote-as auto")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-06 08:25:09 +02:00
Russ White
e9c9db0122
Merge pull request #17542 from opensourcerouting/fix/peer-group_remote_as_regression
bgpd: Fix remote-as with peer-group
2024-12-03 10:05:44 -05:00
Donatas Abraitis
e57fb3282a bgpd: Initialize as_type for peer-group as AS_UNSPECIFIED
Previously AS_UNSPECIFIED was treated as 0, but with now it's 1 after renumbering
peer_asn_type enum.

Fixes: 0dfe25697f ("bgpd: Implement neighbor X remote-as auto")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-12-01 14:32:08 +02:00
Donatas Abraitis
3747e86149 bgpd: Use peer group's member for BGP notify instead of the peer-group
Fixes: eacf923b00 ("bgpd: Fix pattern of usage in bgp_notify_config_change")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-27 08:07:35 +02:00
Donald Sharp
7bf3f53e44 bgpd: peer_active is connection oriented, make it so
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-26 11:59:39 -05:00
Donald Sharp
eacf923b00 bgpd: Fix pattern of usage in bgp_notify_config_change
if (BGP_IS_VALID_STATE_FOR_NOTIF(peer->connection->status))
        peer_notify_config_change(peer->connection);
else
        bgp_session_reset_safe(peer, &nnode);

Let's add a bool return to peer_notify_config_change of whether or
not it should call the peer session reset.  This simplifies
the code a bunch.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-26 11:59:18 -05:00
Donald Sharp
ba0edb9545 bgpd: Add peer_notify_config_change() function
We have about a bajillion tests of if we can
notify the peer and then we send a config change
notification.  Let's just make a function that
does this.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-26 11:58:23 -05:00
Donald Sharp
2e5b4e32c4 bgpd: peer_notify_unconfig should be connection based
Convert this function to being connection based.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-11-26 11:49:34 -05:00
Donatas Abraitis
0a85b1ba04 bgpd: Fix graceful-restart for peer-groups
Slipped somehow that peer-groups with GR is just completely broken, but it was
working before.

Strikes again, that we MUST have more and more topotests.

Fixes: 15403f521a ("bgpd: Streamline GR config, act on change immediately")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-24 21:57:19 +02:00
Donald Sharp
d745f4eae5
Merge pull request #17459 from opensourcerouting/fix/disable_rpki_community_by_default
bgpd: Disable sending ROV extended community by default
2024-11-23 09:13:06 -05:00
Donatas Abraitis
7fb4c03f5b bgpd: Do not reset peers on suppress-fib toggling
If the desired state is the same - do nothing instead of resetting once again.

Fixes: bdb5ae8bce ("bgpd: Make suppress-fib-pending clear peering")

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-22 10:30:37 +02:00
Donatas Abraitis
8cc6359fdc bgpd: Disable sending ROV extended community by default
https://datatracker.ietf.org/doc/html/rfc8097 defines ROV extended community,
but https://datatracker.ietf.org/doc/draft-ietf-sidrops-avoid-rpki-state-in-bgp
is against sending it by default even for iBGP peers.

Let's do this practice and reverse it.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-19 16:25:12 +02:00
Donatas Abraitis
6e92e25518 bgpd: Do not use an existing peer pointer for ALL_LIST_ELEMENTS()
Use a separate `member` in this case.

Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
2024-11-11 16:49:08 +02:00
hanyu.zly
9fa56a03c7 bgpd:support tcp-mss for neighbor group
Signed-off-by: hanyu.zly <hanyu.zly@alibaba-inc.com>
2024-11-07 14:50:21 +08:00
Donald Sharp
2b1e5ced04 bgpd: Remove call into event_master_free_unused
This call was originally put into place to help reduce
memory problems associated with bgp having a bajillion
events under load and then we would have a bunch of events
ready to be used on the unused list.  In the meantime
code was put into place that limited the depth of the
unused list to 10 elements.  This call has now become
unnecessary.  Let's just remove it.

Signed-off-by: Donald Sharp <sharpd@nvidia.com>
2024-10-31 14:06:20 -04:00