In an EBGP multihop configuration with dynamic neighbors, the TTL configured is not being updated for the socket.
Issue:
Assume the following topology:
Host (Dynamic peer to spine - 192.168.1.100) - Leaf - Spine (192.168.1.1)
When the host establishes a BGP multihop session to the spine,
the connection uses the MAXTTL value instead of the configured TTL (in this case, 2).
This issue is only observed with dynamic peers.
Logs: look at the TTL is still MAXTTL, instead of “2” configured.
18:13:18.872395 48:b0:2d:0c:58:0b > 48:b0:2d:66:64:6b, ethertype IPv4 (0x0800), length 85: (tos 0xc0, ttl 255, id 32078, offset 0, flags [DF], proto TCP (6), length 71)
192.168.1.100.179 > 192.168.1.1.40967: Flags [P.], cksum 0xfe89 (correct), seq 28406:28425, ack 28424, win 255, options [nop,nop,TS val 4192664793 ecr 2814447051], length 19: BGP
Keepalive Message (4), length: 19
Fix:
Whenever a dynamic peer is created, the socket TTL should be updated with the configured TTL, in this case 2.
19:13:24.894890 48:b0:2d:0c:58:0b > 48:b0:2d:66:64:6b, ethertype IPv4 (0x0800), length 85: (tos 0xc0, ttl 2, id 1131, offset 0, flags [DF], proto TCP (6), length 71)
192.168.1.100.179 > 192.168.1.1.41937: Flags [P.], cksum 0x7a67 (correct), seq 2046150759:2046150778, ack 4286110599, win 255, options [nop,nop,TS val 4196270815 ecr 2818051226], length 19: BGP
Keepalive Message (4), length: 19
Testing: UT
UT logs:
2023-12-29T19:13:21.892205+00:00 host bgpd[1591425]: [WWPV7-YSZB5] Dynamic Neighbor 192.168.1.1/32 matches group test listen range 192.168.1.0/30
2023-12-29T19:13:21.892654+00:00 host bgpd[1591425]: [GBPAR-M31QF] 192.168.1.1 Dynamic Neighbor added, group test count 1
2023-12-29T19:13:21.892993+00:00 host bgpd[1591425]: [GPE2H-K9QRE] bgp_set_socket_ttl: set TxTTL on peer (rtrid 0.0.0.0) socket, err = 2, peer ttl 2
Conflicts:
bgpd/bgp_network.c
Ticket: #
Signed-off-by: Rajesh Varatharaj <rvaratharaj@nvidia.com>
Only include "debug rpki" in "show run" if it was requested from the
configure mode but not it was from the enabled mode.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
when a plugin is attached, some debugs may be attached to that plugin.
For that, add one hook that is interacting with vty: a boolean indicates
what the usage is for: either for impacting the 'show running-config',
or for impacting the 'show debugging' command.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
"show run" displays the default RPKI timers when at least one cache
server is configured.
Only display the RPKI timers that differs from the default values.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
remove double spaces when doing show running-config.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
RPKI configuration is not totally flushed when doing "no rpki". Timers
remains to default values.
> r2# sh run bgpd
> [...]
> rpki
> rpki retry_interval 5
> rpki cache 192.0.2.1 15432 preference 1
> exit
> [...]
> r2# conf t
> r2(config)# no rpki
> r2(config)# do sh run
> [...]
> rpki
> rpki retry_interval 5
> exit
Reset the timers after doing "no rpki"
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Fix RPKI module compilation when rtrlib is compiled without SSH support,
ie. with cmake option:
> -D RTRLIB_TRANSPORT_SSH=No
> bgpd/bgp_rpki.c: In function ‘config_write’:
> bgpd/bgp_rpki.c:1062:3: error: enumeration value ‘SSH’ not handled in switch [-Werror=switch-enum]
> 1062 | switch (cache->type) {
> | ^~~~~~
> bgpd/bgp_rpki.c: In function ‘show_rpki_cache_connection_magic’:
> bgpd/bgp_rpki.c:1598:3: error: enumeration value ‘SSH’ not handled in switch [-Werror=switch-enum]
> 1598 | switch (cache->type) {
> | ^~~~~~
> cc1: all warnings being treated as errors
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
"show rpki XX json" should not return a void output because json.loads()
considers it to be an incorrect JSON.
> >>> json.loads("")
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/usr/lib/python3.9/json/__init__.py", line 346, in loads
> return _default_decoder.decode(s)
> File "/usr/lib/python3.9/json/decoder.py", line 337, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File "/usr/lib/python3.9/json/decoder.py", line 355, in raw_decode
> raise JSONDecodeError("Expecting value", s, err.value) from None
> json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
> >>> json.loads("{}")
> {}
Return "{}" instead in such a case.
Link: https://github.com/FRRouting/frr/pull/15034
Fixes: dff41cc8a9 ("bgpd: Add JSON output for `show rpki prefix` and other show commands")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
https://datatracker.ietf.org/doc/html/draft-uttaro-idr-bgp-oad#section-3.13
Extended communities which are non-transitive across an AS boundary MAY be
advertised over an EBGP-OAD session if allowed by explicit policy configuration.
If allowed, all the members of the OAD SHOULD be configured to use the same
criteria.
For example, the Origin Validation State Extended Community, defined as
non-transitive in [RFC8097], can be advertised to peers in the same OAD.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
If at least one of the candidate routes was received via EBGP, remove from
consideration all routes that were received via EBGP-OAD and IBGP.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
I've kept the assignment in a comment because I am concerned
about new code being added later that the data pointer would
not be set correctly. Next coder can see the commented
out line and uncomment it.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
```
Direct leak of 40 byte(s) in 1 object(s) allocated from:
0 0x7fc4b81eed28 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded28)
1 0x7fc4b7bd60bb in qcalloc lib/memory.c:105
2 0x56221dc19207 in aspath_dup bgpd/bgp_aspath.c:689
3 0x56221daacd42 in route_set_aspath_prepend bgpd/bgp_routemap.c:2283
4 0x7fc4b7c3891a in route_map_apply_ext lib/routemap.c:2687
5 0x56221dace552 in subgroup_default_originate bgpd/bgp_updgrp_adv.c:906
6 0x56221dabf79c in update_group_default_originate_route_map_walkcb bgpd/bgp_updgrp.c:2105
7 0x56221dabde4e in update_group_walkcb bgpd/bgp_updgrp.c:1721
8 0x7fc4b7b9d398 in hash_walk lib/hash.c:270
9 0x56221dac94cb in update_group_af_walk bgpd/bgp_updgrp.c:2062
10 0x56221dac9b0f in update_group_walk bgpd/bgp_updgrp.c:2071
11 0x56221dac9fd5 in update_group_refresh_default_originate_route_map bgpd/bgp_updgrp.c:2118
12 0x7fc4b7c7fc54 in event_call lib/event.c:1974
13 0x7fc4b7bb9276 in frr_run lib/libfrr.c:1214
14 0x56221d9217fd in main bgpd/bgp_main.c:510
15 0x7fc4b6bf2c86 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21c86)
```
tmp_pi.attr should be flushed since it's already interned (new_attr) or the
origin value is used (attr).
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
When filtering with `debug bgp updates in x.x.x.x prefix-list plist`, we want
to filter out unnecessary messages like:
```
127.0.0.1(Unknown) rcvd UPDATE wlen 0 attrlen 20 alen 5
```
Such a line as above will be repeated for all the paths received and it's useless
without knowing the prefix (because NLRIs are not parsed yet).
But want to see only relevant ones:
```
127.0.0.1(Unknown) rcvd UPDATE w/ attr: nexthop 127.0.0.1, origin i, path 65002
127.0.0.1(Unknown) rcvd 10.255.255.1/32 IPv4 unicast
```
With `debug bgp updates detail` we can combine this to something like:
```
127.0.0.1(Unknown) rcvd UPDATE w/ attr: nexthop 127.0.0.1, origin i, path 65002
127.0.0.1(Unknown) rcvd UPDATE wlen 0 attrlen 20 alen 5
127.0.0.1(Unknown) rcvd 10.255.255.1/32 IPv4 unicast
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
There are several problems with the bgp_sync_label_manager
function:
a) It is possible that a request in the lp->requests
fifo will be unable to be filled at this point in time
and the lf will be leaked and not ever fullfilled.
b) The bgp_sync_label_manager runs one time a second
irrelevant if there is work to do or not.
To fix (a) just add the request back to the requests
fifo and set the timer to pop in the future.
To fix (b) just every time something is put into
the request pool start a timer to run in 1 second
and do not restart it if all the work is done.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This reverts commit 7bf3c2fb19.
Commit reverted as it introduces a memoery leak during the tests
Signed-off-by: Martin Winter <mwinter@opensourcerouting.org>
The rfapi code was not using the zlog_backtrace()
functionality. Let's just convert over to using
the proper functionality that we have built in now.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Fix the following heap-buffer-overflow:
> ==3901635==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6020003a5940 at pc 0x56260067bb48 bp 0x7ffe8a4f3840 sp 0x7ffe8a4f3838
> READ of size 4 at 0x6020003a5940 thread T0
> #0 0x56260067bb47 in ecommunity_fill_pbr_action bgpd/bgp_ecommunity.c:1587
> #1 0x5626007a246e in bgp_pbr_build_and_validate_entry bgpd/bgp_pbr.c:939
> #2 0x5626007b25e6 in bgp_pbr_update_entry bgpd/bgp_pbr.c:2933
> #3 0x562600909d18 in bgp_zebra_announce bgpd/bgp_zebra.c:1351
> #4 0x5626007d5efd in bgp_process_main_one bgpd/bgp_route.c:3528
> #5 0x5626007d6b43 in bgp_process_wq bgpd/bgp_route.c:3641
> #6 0x7f450f34c2cc in work_queue_run lib/workqueue.c:266
> #7 0x7f450f327a27 in event_call lib/event.c:1970
> #8 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #9 0x56260062fc04 in main bgpd/bgp_main.c:540
> #10 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
> #11 0x56260062ca29 in _start (/usr/lib/frr/bgpd+0x2e3a29)
>
> 0x6020003a5940 is located 0 bytes to the right of 16-byte region [0x6020003a5930,0x6020003a5940)
> allocated by thread T0 here:
> #0 0x7f450f6aa1f8 in __interceptor_realloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:164
> #1 0x7f450f244f8a in qrealloc lib/memory.c:112
> #2 0x562600673313 in ecommunity_add_val_internal bgpd/bgp_ecommunity.c:143
> #3 0x5626006735bc in ecommunity_uniq_sort_internal bgpd/bgp_ecommunity.c:193
> #4 0x5626006737e3 in ecommunity_parse_internal bgpd/bgp_ecommunity.c:228
> #5 0x562600673890 in ecommunity_parse bgpd/bgp_ecommunity.c:236
> #6 0x562600640469 in bgp_attr_ext_communities bgpd/bgp_attr.c:2674
> #7 0x562600646eb3 in bgp_attr_parse bgpd/bgp_attr.c:3893
> #8 0x562600791b7e in bgp_update_receive bgpd/bgp_packet.c:2141
> #9 0x56260079ba6b in bgp_process_packet bgpd/bgp_packet.c:3406
> #10 0x7f450f327a27 in event_call lib/event.c:1970
> #11 0x7f450f21a637 in frr_run lib/libfrr.c:1213
> #12 0x56260062fc04 in main bgpd/bgp_main.c:540
> #13 0x7f450ee2dd09 in __libc_start_main ../csu/libc-start.c:308
Fixes: dacf6ec120 ("bgpd: utility routine to convert flowspec actions into pbr actions")
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
When bgp update is received for EVPN prefix
where for an existing path's nexthop becomes unreachable,
the path is marked as not VALID but the routes
were not unimported from tenant vrfs, which lead to
stale unicast route(s) and nexthop(s).
In Multipath scenario only a specific path may have marked as
not VALID, then specific path info for the EVPN prefix required to be
unimported from tenant vrf.
Ticket: #3671288
Signed-off-by: Chirag Shah <chirag@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
