| Age | Commit message (Collapse) | Author |
|---|
|
Changelog:
bgpd
Allow bfd to work if peer known but interface address not yet
Apply route-map for aggregate before attribute comparison
Do not start bgp session if bgp identifier is not set
Don't reuse nexthop variable in loop/switch
Fix a bug in peer_allowas_in_set()
Fix add label support to evpn ad routes
Fix bfd with update-source in peer-group
Fix bgp orf prefix-list json prefix
Fix crash in bgp_labelpool
Fix crash in displaying json orf prefix-list
Fix crash upon bgp network import-check command
Fix deadlock in bgp_keepalive and master pthreads
Fix for local interface mac cache issue in 'bgp mac hash' table
Fix incorrect json in bgp_show_table_rd
Fix memory leak in bgp_aggregate_install()
Fix route-distinguisher in vrf leak json cmd
Fix vty output of evpn route-target as4
Fix wrong pthread event cancelling
Remove dmed check not required in bestpath selection
Reset bgp session only if it was a real bfd down event
Update source address for bfd session
Use igpmetric in bgp_aigp_metric_total()
When bgp notices a change to shared_network inform bfd of it
When removing the prefix list drop the pointer
With suppress-fib-pending ensure withdrawal is sent
Revert: Handle addpath capability using dynamic capabilities
Revert: Reinstall aggregated routes if using route-maps and it was changed
fpm
Guard against garbage in unused address bytes
isisd
Allow full `no` form for `domain-password` and `area-password`
Correct edge insertion into ted
Show correct level information for `show isis interface detail json`
lib
Crash handlers must be allowed on threads
Fix false context information for srv6 route
Guard against padding garbage in zapi read
mgmtd
Prevent use after free
nhrpd
Fix do not consider incomplete l2 entry
pbrd
Initialize structs used in hash_lookup
pimd
During prefix-list update, behave as pim_upstream_notjoined state (conformance issue)
Fix dr election race on startup
Fix for data packet loss when fhr is lhr and rp
Fix for fhr mroute taking longer to age out
Fix pim vrf support (send register/register stop in vrf)
Fix pim6 mld vrf support (use recvmsg() pktinfo)
tools
Add missing rpki keyword to vrf in frr-reload
Fix frr-reload for ebgp-multihop ttl reconfiguration.
zebra
Evpn svd hash avoid double free
Fix resetting valid flags for nhg dependents
Guard against junk in nexthop->rmap_src
Include resolving nexthops in nhg hash
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
bgpd: Fixed crash upon bgp network import-check command (backport #18387)
|
|
BT:
```
3 <signal handler called>
4 0x00005616837546fc in bgp_static_update (bgp=bgp@entry=0x5616865eac50, p=0x561686639e40,
bgp_static=0x561686639f50, afi=afi@entry=AFI_IP6, safi=safi@entry=SAFI_UNICAST) at ../bgpd/bgp_route.c:7232
5 0x0000561683754ad0 in bgp_static_add (bgp=0x5616865eac50) at ../bgpd/bgp_table.h:413
6 0x0000561683785e2e in no_bgp_network_import_check (self=<optimized out>, vty=0x5616865e04c0,
argc=<optimized out>, argv=<optimized out>) at ../bgpd/bgp_vty.c:4609
7 0x00007fdbcc294820 in cmd_execute_command_real (vline=vline@entry=0x561686663000,
```
The program encountered a SEG FAULT when attempting to access pi->extra->vrfleak->bgp_orig because
pi->extra->vrfleak was NULL.
```
(gdb) p pi->extra->vrfleak
$1 = (struct bgp_path_info_extra_vrfleak *) 0x0
(gdb) p pi->extra->vrfleak->bgp_orig
Cannot access memory at address 0x8
```
Added NOT NULL check on pi->extra->vrfleak before accessing pi->extra->vrfleak->bgp_orig
to prevent the segmentation fault.
Signed-off-by: Manpreet Kaur <manpreetk@nvidia.com>
(cherry picked from commit bc1008b970541c090e36fc1d50c720df822fcb99)
|
|
Backport missing frr config to 10.1
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
|
|
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
pimd: Fix PIM6 MLD VRF support (use recvmsg() pktinfo) (backport #18315)
|
|
When receiving MLD messages, prefer pktinfo over msghdr.msg_name for
determining the source interface. The latter is just the VRF master
interface in case of VRF and we need the true interface the packet was
received on instead.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
(cherry picked from commit 374c8dc4dbc8a560036fecdfb3213f690099b869)
|
|
isisd: Correct edge insertion into TED (backport #18294)
|
|
mgmtd: Prevent use after free (backport #18264)
|
|
Edges are not correctly linked to Vertices during LSP processing. In function
lsp_to_edge_cb(), once edge created or updated from the LSP TLVs, the code try
to link the edge to destination vertices. In case the revert edge is not found,
the code try to found a destination vertex to link to. But, the sys_id used
for this operation corresponds to the source vertex. As a result, the edge is
attached as source and destination of the vertex. When Traffic Engineering is
stopped, TED is deleted which result into a double free of the edge attributes.
This cause a crash when attempt to free extended admin groupi the second time.
This patch removed wrong code which link twice the edge to the source vertex.
Signed-off-by: Olivier Dugeon <olivier.dugeon@orange.com>
(cherry picked from commit 605fc1dd6404b6ed51691c647568939adde4962a)
|
|
ci is picking up this use after free on occasion:
ERROR: AddressSanitizer: attempting to call malloc_usable_size() for pointer which is not owned: 0x6030001d94a0
0 0x7fab994b7f04 in __interceptor_malloc_usable_size ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:119
1 0x7fab994264f6 in __sanitizer::BufferedStackTrace::Unwind(unsigned long, unsigned long, void*, bool, unsigned int) ../../../../src/libsanitizer/sanitizer_common/sanitizer_stacktrace.h:131
2 0x7fab994264f6 in __asan::asan_malloc_usable_size(void const*, unsigned long, unsigned long) ../../../../src/libsanitizer/asan/asan_allocator.cpp:1058
3 0x7fab99039bcf in mt_count_free lib/memory.c:78
4 0x7fab99039bcf in qfree lib/memory.c:130
5 0x7fab98ff971a in hash_clean lib/hash.c:290
6 0x56110cdb0e7f in mgmt_txn_hash_destroy mgmtd/mgmt_txn.c:1881
7 0x56110cdb0e7f in mgmt_txn_destroy mgmtd/mgmt_txn.c:2013
8 0x56110cd8e5de in mgmt_terminate mgmtd/mgmt.c:91
9 0x56110cd8e003 in sigint mgmtd/mgmt_main.c:90
10 0x7fab990bf4b0 in frr_sigevent_process lib/sigevent.c:117
11 0x7fab990ea7a1 in event_fetch lib/event.c:1740
12 0x7fab9901a24e in frr_run lib/libfrr.c:1245
13 0x56110cd8e21f in main mgmtd/mgmt_main.c:290
14 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
15 0x7fab98af9304 in __libc_start_main_impl ../csu/libc-start.c:360
16 0x56110cd8dd30 in _start (/usr/lib/frr/mgmtd+0x3ad30)
0x6030001d94a0 is located 0 bytes inside of 24-byte region [0x6030001d94a0,0x6030001d94b8)
freed by thread T0 here:
0 0x7fab994b76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
1 0x7fab99039bf0 in qfree lib/memory.c:131
2 0x7fab98ff93e1 in hash_release lib/hash.c:227
3 0x56110cdaabdc in mgmt_txn_unlock mgmtd/mgmt_txn.c:1931
4 0x56110cdab049 in mgmt_txn_delete mgmtd/mgmt_txn.c:1841
5 0x56110cdab0ce in mgmt_txn_hash_free mgmtd/mgmt_txn.c:1864
6 0x7fab98ff970b in hash_clean lib/hash.c:288
7 0x56110cdb0e7f in mgmt_txn_hash_destroy mgmtd/mgmt_txn.c:1881
8 0x56110cdb0e7f in mgmt_txn_destroy mgmtd/mgmt_txn.c:2013
9 0x56110cd8e5de in mgmt_terminate mgmtd/mgmt.c:91
10 0x56110cd8e003 in sigint mgmtd/mgmt_main.c:90
11 0x7fab990bf4b0 in frr_sigevent_process lib/sigevent.c:117
12 0x7fab990ea7a1 in event_fetch lib/event.c:1740
13 0x7fab9901a24e in frr_run lib/libfrr.c:1245
14 0x56110cd8e21f in main mgmtd/mgmt_main.c:290
15 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
0 0x7fab994b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7fab990392fd in qcalloc lib/memory.c:106
2 0x7fab98ff8b4f in hash_get lib/hash.c:156
3 0x56110cdb13ae in mgmt_txn_create_new mgmtd/mgmt_txn.c:1825
4 0x56110cdb3b4d in mgmt_txn_notify_be_adapter_conn mgmtd/mgmt_txn.c:2212
5 0x56110cd91178 in mgmt_be_adapter_conn_init mgmtd/mgmt_be_adapter.c:842
6 0x7fab990ec6de in event_call lib/event.c:2019
7 0x7fab9901a243 in frr_run lib/libfrr.c:1246
8 0x56110cd8e21f in main mgmtd/mgmt_main.c:290
9 0x7fab98af9249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
The only time that mgmt_txn_hash_free is called is in hash_clean.
There are other places that mgmt_txn_unlock/delete are called and
hash_release should be called. Let's just notice when mgmtd is
being called from the hash_clean and not call hash_release (since
we know it is being released already)
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 62f35c7bdb2a6364dd03ab120e7bb685dd317c24)
|
|
pimd: Fix PIM VRF support (send register/register stop in VRF) (backport #18216)
|
|
In 946195391406269003275850e1a4d550ea8db38b and
8ebcc02328c6b63ecf85e44fdfbf3365be27c127, transmission of PIM register and
register stop messages was changed to use a separate socket. However, that
socket is not bound to a possible VRF, so the messages were sent in the
default VRF instead. Call vrf_bind() once after socket creation and when the
VRF is ready to ensure transmission in the correct VRF. vrf_bind() handles
the non-VRF case (i.e. VRF_DEFAULT) automatically, so it may be called
unconditionally.
Signed-off-by: Martin Buck <mb-tmp-tvguho.pbz@gromit.dyndns.org>
(cherry picked from commit 5a01011e0d2db538a8ba523904bd4f08b786edfb)
|
|
bgpd: remove dmed check not required in bestpath selection (backport #18210)
|
|
As part of the upstream master commit (f3575f61c7 bgpd: Sort the
bgp_path_inf) the snippet of the code for dmed check condition
left out, which leads to an issue of selecting incorrect bestpath.
As an example:
During the bestpath selection local route looses to another path due
to dmed condition being hit.
The snippet of the logs:
2025/02/20 03:06:20.131441 BGP: [JW7VP-K1YVV]
[2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path
27.0.0.7 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted
2025/02/20 03:06:20.131445 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.7 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local
2025/02/20 03:06:20.131452 BGP: [JW7VP-K1YVV] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): Comparing path 27.0.0.8 flags Valid with path Static announcement flags Selected Valid Attr Changed Unsorted
2025/02/20 03:06:20.131456 BGP: [SYTDR-QV6X9] [2]:[0]:[48]:[00:92:00:00:00:10]: path 27.0.0.8 loses to path Static announcement as ES 03:44:38:39:ff:ff:02:00:00:01 is same and local
2025/02/20 03:06:20.131458 BGP: [WEWEC-8SE72] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): path Static announcement is the bestpath from AS 0 <<<< static is best
2025/02/20 03:06:20.131463 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.7 dmed
2025/02/20 03:06:20.131467 BGP: [Z3A78-GM3G5] bgp_best_selection: [2]:[0]:[48]:[00:92:00:00:00:10](VRF default) pi 27.0.0.8 dmed
2025/02/20 03:06:20.131471 BGP: [N6CTF-2RSKS] [2]:[0]:[48]:[00:92:00:00:00:10](VRF default): After path selection, newbest is path 27.0.0.7 oldbest was Static announce
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 83ad94694bc061e1ff5f43db42cba46320e0df73)
|
|
pimd: During prefix-list update, behave as PIM_UPSTREAM_NOTJOINED sta… (backport #17666)
|
|
pimd: Fix for data packet loss when FHR is LHR and RP (backport #14227)
|
|
(conformance issue)
Issue:
If there are any changes to the prefix list, we perform a re-lookup to map the correct RP for the group.
Even if the S,G entry is PIM_UPSTREAM_NOTJOINED and in FHR, In the case of IGMPv3, an S,G entry can be
created with no joins. this is not necessary.
https://www.rfc-editor.org/rfc/rfc4601#section-4.5.7 says no op in case of NOTJOINED
Solution:
To solve this issue, Stop RP mapping when the state is NOTJOINED
Ticket: #3496931
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 51f26d17da288af44a8a0e536dbe317a7e678514)
|
|
Topology:
A single router is acting as the First Hop Router (FHR), Last Hop Router (LHR), and RP.
RC and Issue:
When an upstream S,G is in join state, it sends a register message to the RP.
If the RP has the receiver, it sends a register stop message and switches to the shortest path.
When the register stop message is processed, it removes pimreg, moves to prune,
and starts the reg stop timer.
When the reg stop timer expires, PIM changes S,G state to Join Pending and sends out a NULL
register message to RP. RP receives it and fails to send Reg stop because SPT is not set at that point.
The problem is when the register stop timer pops and state is in Join Pending.
According to https://www.rfc-editor.org/rfc/rfc4601#section-4.4.1,
we need to put back the pimreg reg tunnel into the S,G mroute.
This causes data to be sent to the control plane and subsequently interrupts the line rate.
Fix:
If the router is FHR and RP to the group,
ignore SPT status and send out a register stop message back to the DR (in this context, the same router).
Ticket: #3506780
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
(cherry picked from commit 8280257cc99e071c205e469399f2fb41671b30eb)
|
|
FRRouting/revert-18156-mergify/bp/stable/10.1/pr-18121
Revert "bgpd: release manual vpn label on instance deletion (backport #18121)"
|
|
|
|
bgpd: Fix crash in bgp_labelpool (backport #18079)
|
|
bgpd: release manual vpn label on instance deletion (backport #18121)
|
|
bgpd: fix vty output of evpn route-target AS4 (backport #18109)
|
|
evpn route-targets are decoded in ... multiple places; at least
two have a bug where the AS4 form doesn't have its AS decoded.
Signed-off-by: Mark Stapp <mjs@cisco.com>
(cherry picked from commit 9943a08720ccbed87cd6938791066a0de94a92c6)
|
|
lib: fix false context information for SRv6 route (backport #18023 for 10.1)
|
|
bgpd: When removing the prefix list drop the pointer (backport #18160)
|
|
The seg6local route dumped by 'show ipv6 route' makes think that the USP
flavor is supported, whereas it is not the case. This information is a
context information, and for End, the context information should be
empty.
> # show ipv6 route
> [..]
> I>* fc00:0:4::/128 [115/0] is directly connected, sr0, seg6local End USP, weight 1, 00:49:01
Fix this by suppressing the USP information from the output.
Fixes: e496b4203055 ("bgpd: prefix-sid srv6 l3vpn service tlv")
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
We are very very rarely seeing this crash:
0 0x7f36ba48e389 in prefix_list_apply_ext lib/plist.c:789
1 0x55eff3fa4126 in subgroup_announce_check bgpd/bgp_route.c:2334
2 0x55eff3fa858e in subgroup_process_announce_selected bgpd/bgp_route.c:3440
3 0x55eff4016488 in subgroup_announce_table bgpd/bgp_updgrp_adv.c:808
4 0x55eff401664e in subgroup_announce_route bgpd/bgp_updgrp_adv.c:861
5 0x55eff40111df in peer_af_announce_route bgpd/bgp_updgrp.c:2223
6 0x55eff3f884cb in bgp_announce_route_timer_expired bgpd/bgp_route.c:5892
7 0x7f36ba4ec239 in event_call lib/event.c:2019
8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
9 0x55eff3e668b7 in main bgpd/bgp_main.c:557
10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
11 0x7f36b9e2d304 in __libc_start_main_impl ../csu/libc-start.c:360
12 0x55eff3e64a30 in _start (/home/ci/cibuild.1407/frr-source/bgpd/.libs/bgpd+0x2fda30)
0x608000037038 is located 24 bytes inside of 88-byte region [0x608000037020,0x608000037078)
freed by thread T0 here:
0 0x7f36ba8b76a8 in __interceptor_free ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:52
1 0x7f36ba439bd7 in qfree lib/memory.c:131
2 0x7f36ba48d3a3 in prefix_list_free lib/plist.c:156
3 0x7f36ba48d3a3 in prefix_list_delete lib/plist.c:247
4 0x7f36ba48fbef in prefix_bgp_orf_remove_all lib/plist.c:1516
5 0x55eff3f679c4 in bgp_route_refresh_receive bgpd/bgp_packet.c:2841
6 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069
7 0x7f36ba4ec239 in event_call lib/event.c:2019
8 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
9 0x55eff3e668b7 in main bgpd/bgp_main.c:557
10 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
previously allocated by thread T0 here:
0 0x7f36ba8b83b7 in __interceptor_calloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:77
1 0x7f36ba4392e4 in qcalloc lib/memory.c:106
2 0x7f36ba48d0de in prefix_list_new lib/plist.c:150
3 0x7f36ba48d0de in prefix_list_insert lib/plist.c:186
4 0x7f36ba48d0de in prefix_list_get lib/plist.c:204
5 0x7f36ba48f9df in prefix_bgp_orf_set lib/plist.c:1479
6 0x55eff3f67ba6 in bgp_route_refresh_receive bgpd/bgp_packet.c:2920
7 0x55eff3f70bab in bgp_process_packet bgpd/bgp_packet.c:4069
8 0x7f36ba4ec239 in event_call lib/event.c:2019
9 0x7f36ba41a22a in frr_run lib/libfrr.c:1295
10 0x55eff3e668b7 in main bgpd/bgp_main.c:557
11 0x7f36b9e2d249 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58
Let's just stop trying to save the pointer around in the peer->orf_plist
data structure. There are other design problems but at least lets
stop the crash from possibly happening.
Fixes: #18138
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 3d43d7b78971520854903c11b6aec23754fdca34)
|
|
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>
(cherry picked from commit d6363625c35a99933bf60c9cf0b79627b468c9f7)
# Conflicts:
# bgpd/bgpd.c
|
|
The bgp labelpool code is grabbing the vpn policy data structure.
This vpn_policy has a pointer to the bgp data structure. If
a item placed on the bgp label pool workqueue happens to sit
there for the microsecond or so and the operator issues a
`no router bgp...` command that corresponds to the vpn_policy
bgp pointer, when the workqueue is run it will crash because
the bgp pointer is now freed and something else owns it.
Modify the labelpool code to store the vrf id associated
with the request on the workqueue. When you wake up
if the vrf id still has a bgp pointer allow the request
to continue, else drop it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 14eac319e8ae9314f5270f871106a70c4986c60c)
|
|
bgpd: fix incorrect JSON in bgp_show_table_rd (backport #18120)
|
|
bgp/bfd backports for stable/10.1
|
|
Fix BFD session not created when the peer is in update-group with the
update-source option.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
|
|
When bgp is started up and reads the config in *before* it has
received interface addresses from zebra, shared_network can
be set to false in this case. Later on once bgp attempts to
reconnect it will refigure out the shared_network again( because
it has received the data from zebra now ). In this case
tell bfd about it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
If bgp is coming up and bgp has not received the interface address yet
but bgp has knowledge about a bfd peering, allow it to set the peering
data appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
|
|
If BFD is down, we should try to detect the source automatically from the given
interface.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
Without this patch we always see a double-reset, e.g.:
```
2024/11/04 12:42:43.010 BGP: [VQY9X-CQZKG] bgp_peer_bfd_update_source: address [0.0.0.0->172.18.0.3] to [172.18.0.2->172.18.0.3]
2024/11/04 12:42:43.010 BGP: [X8BD9-8RKN4] bgp_peer_bfd_update_source: interface none to eth0
2024/11/04 12:42:43.010 BFD: [MSVDW-Y8Z5Q] ptm-del-dest: deregister peer [mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default cbit:0x00 minimum-ttl:255]
2024/11/04 12:42:43.010 BFD: [NYF5K-SE3NS] ptm-del-session: [mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default] refcount=0
2024/11/04 12:42:43.010 BFD: [NW21R-MRYNT] session-delete: mhop:no peer:172.18.0.3 local:0.0.0.0 vrf:default
2024/11/04 12:42:43.010 BGP: [P3D3N-3277A] 172.18.0.3 [FSM] Timer (routeadv timer expire)
2024/11/04 12:42:43.010 BFD: [YA0Q5-C0BPV] control-packet: no session found [mhop:no peer:172.18.0.3 local:172.18.0.2 port:11]
2024/11/04 12:42:43.010 BFD: [MSVDW-Y8Z5Q] ptm-add-dest: register peer [mhop:no peer:172.18.0.3 local:172.18.0.2 vrf:default cbit:0x00 minimum-ttl:255]
2024/11/04 12:42:43.011 BFD: [PSB4R-8T1TJ] session-new: mhop:no peer:172.18.0.3 local:172.18.0.2 vrf:default ifname:eth0
2024/11/04 12:42:43.011 BGP: [Q4BCV-6FHZ5] zclient_bfd_session_update: 172.18.0.2/32 -> 172.18.0.3/32 (interface eth0) VRF default(0) (CPI bit no): Down
2024/11/04 12:42:43.011 BGP: [MKVHZ-7MS3V] bfd_session_status_update: neighbor 172.18.0.3 vrf default(0) bfd state Up -> Down
2024/11/04 12:42:43.011 BGP: [HZN6M-XRM1G] %NOTIFICATION: sent to neighbor 172.18.0.3 6/10 (Cease/BFD Down) 0 bytes
2024/11/04 12:42:43.011 BGP: [QFMSE-NPSNN] zclient_bfd_session_update: sessions updated: 1
2024/11/04 12:42:43.011 BGP: [ZWCSR-M7FG9] 172.18.0.3 [FSM] BGP_Stop (Established->Clearing), fd 22
```
Reset is due to the source address change.
With this patch, we reset the session only if it's a _REAL_ BFD down event, which
means we trigger session reset if BFD session is established earlier than BGP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
|
|
In bgp_show_table_rd(), the is_last argument is determined using the
expression "next == NULL" to check if the RD table is the last one. This
helps ensure proper JSON formatting.
However, if next is not NULL but is no longer associated with a BGP
table, the JSON output becomes malformed.
Updates the condition to also verify the existence of the next bgp_dest
table.
Fixes: 1ae44dfcba ("bgpd: unify 'show bgp' with RD with normal unicast bgp show")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
(cherry picked from commit cf0269649cdd09b8d3f2dd8815caf6ecf9cdeef9)
|
|
pimd: Fix for FHR mroute taking longer to age out (backport #14105)
|
|
pimd: fix DR election race on startup (backport #18048)
|
|
zebra: include resolving nexthops in nhg hash (backport #17935)
|
|
nhrpd: fix dont consider incomplete L2 entry (backport #18078)
|
|
Sometimes, NHRP receives L2 information on a cache entry with the
0.0.0.0 IP address. NHRP considers it as valid and updates the binding
with the new IP address.
> Feb 09 20:09:54 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x2 cache used 0 type 4
> Feb 09 20:10:35 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:48 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: del-neigh 10.2.114.238 dev dmvpn1 lladdr 162.251.180.10 nud 0x4 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: who-has 10.2.114.238 dev dmvpn1 lladdr (unspec) nud 0x1 cache used 1 type 4
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QVXNM-NVHEQ] Netlink: update binding for 10.2.114.238 dev dmvpn1 from c 162.251.180.10 peer.vc.nbma 162.251.180.10 to lladdr (unspec)
> Feb 09 20:10:49 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x2 cache used 1 type 4
> Feb 09 20:11:30 aws-sin-vpn01 nhrpd[2695]: [QQ0NK-1H449] Netlink: new-neigh 10.2.114.238 dev dmvpn1 lladdr 0.0.0.0 nud 0x4 cache used 1 type 4
Actually, the 0.0.0.0 IP addressed mentiones in the 'who-has' message is
wrong because the nud state value means that value is incomplete and
should not be handled as a valid entry. Instead of considering it, fix
this by by invalidating the current binding. This step is necessary in
order to permit NHRP to trigger resolution requests again.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
(cherry picked from commit 3202323052485d8138a3440e9c9907594ad99c57)
|
|
lib: crash handlers must be allowed on threads (backport #18060)
|
|
lib: actually hash all 16 bytes of IPv6 addresses, not just 4 (backport #17901)
|
|
Blocking all signals on non-main threads is not the way to go, at least
the handlers for SIGSEGV, SIGBUS, SIGILL, SIGABRT and SIGFPE need to run
so we get backtraces. Otherwise the process just exits.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
(cherry picked from commit 13a6ac5b4ca8fc08b348f64de64a787982f24250)
|
|
Currently FRR does not handle v6 recurisive resolution properly
when the route being recursed through changes and the most
significant bits of the route are not changed.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 73ab6a46c51db91df297774221053ab8fc4d12ae)
|
