Donald Sharp [Thu, 23 Feb 2023 18:29:32 +0000 (13:29 -0500)]
bgpd: Flowspec overflow issue
According to the flowspec RFC 8955 a flowspec nlri is <length, <nlri data>>
Specifying 0 as a length makes BGP get all warm on the inside. Which
in this case is not a good thing at all. Prevent warmth, stay cold
on the inside.
Reported-by: Iggy Frankovic <iggyfran@amazon.com> Signed-off-by: Donald Sharp <sharpd@nvidia.com>
(cherry picked from commit 0b999c886e241c52bd1f7ef0066700e4b618ebb3)
Donald Sharp [Wed, 12 Oct 2022 18:53:21 +0000 (14:53 -0400)]
bgpd: Allow `network XXX` to work with bgp suppress-fib-pending
When bgp is using `bgp suppress-fib-pending` and the end
operator is using network statements, bgp was not sending
the network'ed prefix'es to it's peers. Fix this.
Also update the test cases for bgp_suppress_fib to test
this new corner case( I am sure that there are going to
be others that will need to be added ).
Donald Sharp [Wed, 20 Jul 2022 20:43:17 +0000 (16:43 -0400)]
ospfclient: Ensure ospf_apiclient_lsa_originate cannot accidently write into stack
Even though OSPF_MAX_LSA_SIZE is quite large and holds the upper bound
on what can be written into a lsa, let's add a small check to ensure
it is not possible to do a bad thing.
This wins one of the long standing bug awards. 2003!
Fixes: #11602 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Donald Sharp [Fri, 30 Sep 2022 12:57:43 +0000 (08:57 -0400)]
bgpd: Ensure FRR has enough data to read 2 bytes in bgp_open_option_parse
In bgp_open_option_parse the code is checking that the
stream has at least 2 bytes to read ( the opt_type and
the opt_length). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formateed. Ensure that
FRR has the appropriate data length to read the data.
Donald Sharp [Fri, 30 Sep 2022 12:51:45 +0000 (08:51 -0400)]
bgpd: Ensure FRR has enough data to read 2 bytes in peek_for_as4_capability
In peek_for_as4_capability the code is checking that the
stream has at least 2 bytes to read ( the opt_type and the
opt_length ). However if BGP_OPEN_EXT_OPT_PARAMS_CAPABLE(peer)
is configured then FRR is reading 3 bytes. Which is not good
since the packet could be badly formated. Ensure that
FRR has the appropriate data length to read the data.
==395247== 8,268 (32 direct, 8,236 indirect) bytes in 1 blocks are definitely lost in loss record 199 of 205
==395247== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==395247== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1FBF63: community_intern (in /usr/lib/frr/bgpd)
==395247== by 0x1FC0C5: community_parse (in /usr/lib/frr/bgpd)
==395247== by 0x1F0B66: bgp_attr_community (in /usr/lib/frr/bgpd)
==395247== by 0x1F4185: bgp_attr_parse (in /usr/lib/frr/bgpd)
==395247== by 0x26BC29: bgp_update_receive (in /usr/lib/frr/bgpd)
==395247== by 0x26E887: bgp_process_packet (in /usr/lib/frr/bgpd)
==395247== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==395247== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 94 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD3CC: bgp_ca_alias_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8E5: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
==361630==
==361630== 24,780 (96 direct, 24,684 indirect) bytes in 3 blocks are definitely lost in loss record 95 of 97
==361630== at 0x483DD99: calloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==361630== by 0x492EB8E: qcalloc (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x490BB12: hash_get (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1FD39C: bgp_ca_community_insert (in /usr/lib/frr/bgpd)
==361630== by 0x2CF8F4: bgp_community_alias_magic (in /usr/lib/frr/bgpd)
==361630== by 0x2C980B: bgp_community_alias (in /usr/lib/frr/bgpd)
==361630== by 0x48E3556: cmd_execute_command_real (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E384B: cmd_execute_command_strict (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3D41: command_config_read_one_line (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x48E3EBA: config_from_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x499065C: vty_read_file (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4990FF4: vty_read_config (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491CB95: frr_config_read_in (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x4985380: thread_call (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x491D521: frr_run (in /usr/local/lib/libfrr.so.0.0.0)
==361630== by 0x1EBEE8: main (in /usr/lib/frr/bgpd)
Rafael Zalamena [Tue, 11 Jan 2022 18:39:11 +0000 (15:39 -0300)]
lib: rotate log file supplied by command line
Call `zlog_file_rotate` for command file lines as well otherwise on
`SIGUSR1` the old descriptor will still be used and no new log file will
be created for the rotation.
Donald Sharp [Thu, 24 Mar 2022 16:57:01 +0000 (12:57 -0400)]
zebra: Don't send uninited data to kernel on FreeBSD
When running zebra w/ valgrind, it was noticed that there
was a bunch of passing uninitialized data to the kernel:
==38194== Syscall param ioctl(generic) points to uninitialised byte(s)
==38194== at 0x4CDF88A: ioctl (in /lib/libc.so.7)
==38194== by 0x49A4031: vrf_ioctl (vrf.c:860)
==38194== by 0x2AFE29: vrf_if_ioctl (ioctl.c:91)
==38194== by 0x2AFF39: if_get_mtu (ioctl.c:161)
==38194== by 0x2B12C3: ifm_read (kernel_socket.c:653)
==38194== by 0x2A7F76: interface_list (if_sysctl.c:129)
==38194== by 0x2E9958: zebra_ns_enable (zebra_ns.c:127)
==38194== by 0x2E9958: zebra_ns_init (zebra_ns.c:214)
==38194== by 0x2B3F82: main (main.c:401)
==38194== Address 0x7fc000967 is on thread 1's stack
==38194== in frame #3, created by if_get_mtu (ioctl.c:155)
==38194==
==38194== Syscall param ioctl(generic) points to uninitialised byte(s)
==38194== at 0x4CDF88A: ioctl (in /lib/libc.so.7)
==38194== by 0x49A4031: vrf_ioctl (vrf.c:860)
==38194== by 0x2AFE29: vrf_if_ioctl (ioctl.c:91)
==38194== by 0x2AFED9: if_get_metric (ioctl.c:143)
==38194== by 0x2B12CB: ifm_read (kernel_socket.c:655)
==38194== by 0x2A7F76: interface_list (if_sysctl.c:129)
==38194== by 0x2E9958: zebra_ns_enable (zebra_ns.c:127)
==38194== by 0x2E9958: zebra_ns_init (zebra_ns.c:214)
==38194== by 0x2B3F82: main (main.c:401)
==38194== Address 0x7fc000967 is on thread 1's stack
==38194== in frame #3, created by if_get_metric (ioctl.c:137)
==38194==
==38194== Syscall param ioctl(generic) points to uninitialised byte(s)
==38194== at 0x4CDF88A: ioctl (in /lib/libc.so.7)
==38194== by 0x49A4031: vrf_ioctl (vrf.c:860)
==38194== by 0x2AFE29: vrf_if_ioctl (ioctl.c:91)
==38194== by 0x2B052D: if_get_flags (ioctl.c:419)
==38194== by 0x2B1CF1: ifam_read (kernel_socket.c:930)
==38194== by 0x2A7F57: interface_list (if_sysctl.c:132)
==38194== by 0x2E9958: zebra_ns_enable (zebra_ns.c:127)
==38194== by 0x2E9958: zebra_ns_init (zebra_ns.c:214)
==38194== by 0x2B3F82: main (main.c:401)
==38194== Address 0x7fc000707 is on thread 1's stack
==38194== in frame #3, created by if_get_flags (ioctl.c:411)
Bijan [Tue, 1 Feb 2022 07:33:00 +0000 (11:03 +0330)]
zebra: Keep the interface flags safe on multiple ioctl calls
Trying to call multiple ioctl calls on ifreq will result in
overwriting ifreq with garbage data. On if_get_flags call,
try to keep the flags field safe from another possible ioctl
call before applying the flags field.
Modified code as per Code Review, done by Donald Sharp.
Donald Sharp [Tue, 28 Jun 2022 14:26:52 +0000 (10:26 -0400)]
lib: Allow downgrade of all caps when none are specified
Staticd when run tells privs.c that it does not need any
priviledges. The lib/privs.c code was not downgrading
any and all permissions it may have been given at startup.
Since we don't need any let's actually tell the system that
FRR does not need the capabilities anymore in the case
where a daemon does not ask for any cap's.
Christian Hopps [Fri, 17 Jun 2022 06:04:51 +0000 (02:04 -0400)]
lib: cleanup red-herring memleaks in parent of daemonizing fork
- The parent of the daemonizing fork reports memleaks for the early
northbound allocations (libyang). If these were real memleaks these
would show up in the child as well; however, ignoring all memleaks in
the parent of the fork is too hard a sale. Instead, spend some CPU
cycles cleaning up the allocations in the parent after the fork and
immeidatley prior to exiting the parent after the daemonizing fork.
bgpd: Withdraw implicitly old paths from VRFs when import/export list changes
If we overwrite import/export RT list via route-maps or even flush by using
`set extcommunity none`, then we must withdraw old paths from VRFs to avoid
stale paths.
Donald Sharp [Thu, 9 Jun 2022 14:29:04 +0000 (10:29 -0400)]
pimd: Show interface traffic even if interface is currently `down`
the `show ip pim interface [x] traffic` command was deciding
to skip display of interfaces if they happened to be down at
that moment. This of course does not make a bunch of sense
to limit the output for a interface that may have sent data
in the past.
This fixes this test crash:
rnode = <lib.topogen.TopoRouter object at 0x7fc755be3880>, dut = 'c1', input_dict = {'c1': {'c1-l1-eth2': ['helloTx', 'helloRx']}}, output_dict = {'c1': {}}
bgpd: Fix memory leak when setting [l]community at egress
```
==2209758== 7,791,480 (399,840 direct, 7,391,640 indirect) bytes in 9,996 blocks are definitely lost in loss record 102 of 103
==2209758== at 0x4C33B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2209758== by 0x4EE264F: qcalloc (memory.c:116)
==2209758== by 0x22E62A: lcommunity_new (bgp_lcommunity.c:42)
==2209758== by 0x22E62A: lcommunity_dup (bgp_lcommunity.c:155)
==2209758== by 0x26F28F: route_set_lcommunity (bgp_routemap.c:2382)
==2209758== by 0x4EFF7EF: route_map_apply_ext (routemap.c:2663)
==2209758== by 0x250B3D: subgroup_announce_check (bgp_route.c:2202)
==2209758== by 0x27A195: subgroup_announce_table (bgp_updgrp_adv.c:690)
==2209758== by 0x27A509: subgroup_coalesce_timer (bgp_updgrp_adv.c:332)
==2209758== by 0x4F1C3FC: thread_call (thread.c:2002)
==2209758== by 0x4ED6D67: frr_run (libfrr.c:1196)
==2209758== by 0x1E921B: main (bgp_main.c:519)
```
To reproduce it's enough to have something like applied at egress:
On the other side doing:
```
spine1-debian-11# sharp install routes 100.100.100.1 nexthop 192.168.10.65 30
spine1-debian-11# sharp remove routes 100.100.100.1 30
spine1-debian-11# sharp install routes 100.100.100.1 nexthop 192.168.10.65 30
```
Before:
```
Large Community : 66 40 2816 66 2816
Large Community value : 66 variable 29728 66 29728
Large Community : 96 40 4096 96 4096
Large Community value : 96 variable 52048 96 52048
```
After:
```
Large Community : 28 40 1152 29 1192
Large Community value : 28 variable 1456 29 2200
Large Community : 28 40 1152 29 1192
Large Community value : 28 variable 1456 29 2200
```
Donald Sharp [Tue, 24 May 2022 17:33:35 +0000 (13:33 -0400)]
pimd: Allow the LPM match work properly with prefix lists and normal rp's
All rp_info's are being saved in the pim->rp_list and the non prefix-list
rp's are supposed to be saved in table pim->rp_table. What was happening,
though, is that all the plists were being stored at the 224.0.0.0/4 node
of the tree(irrelevant to the fact that we should not be looking up the
non-prefix list rp's in the table) and since we can have multiple prefix lists
and only one rp_info stored at the 224.0.0.0/4 node of the tree, there can be situations
where the 224.0.0.0/4 node can be overwritten due to the order entered.
As such there exists situations where command enter ordering will cause
what we match to, change in pim_rp_find_match_group.
Fixes:
a) Do not store prefix list based rp_info's in the pim->rp_table
b) In pim_rp_find_match_group, ensure that the node lookup does
not correspond to a prefix list based node.
c) When in the situation there are both:
ip pim rp 4.5.6.7 224.0.0.0/16
ip pim rp 5.6.67.8 prefix-list FOO
ip prefix-list FOO permit 224.0.1.0/24
and we receive a group for 224.0.1.5, we were comparing the
224.0.0.0/16 to the 224.0.0.0/4 of the 5.6.67.8 group, when
FRR should have been comparing to entry that matched in the prefix-list
Donatas Abraitis [Thu, 26 May 2022 11:03:02 +0000 (14:03 +0300)]
bgpd: Fix memory leak for BGP community alias in CLI
Before:
```
root@spine1-debian-11:~/frr# vtysh -c 'show memory bgpd | include Large Community'
Large Community : 100 40 4000 100 4000
Large Community value : 100 12 2400 100 2400
root@spine1-debian-11:~/frr# for x in $(seq 1 100); do vtysh -c 'conf' -c 'bgp community alias 123:123:123 testas' > /dev/null; done
root@spine1-debian-11:~/frr# vtysh -c 'show memory bgpd | include Large Community'
Large Community : 200 40 8000 200 8000
Large Community value : 200 12 4800 200 4800
root@spine1-debian-11:~/frr# for x in $(seq 1 100); do vtysh -c 'conf' -c 'bgp community alias 123:123:123 testas' > /dev/null; done
root@spine1-debian-11:~/frr# vtysh -c 'show memory bgpd | include Large Community'
Large Community : 300 40 12000 300 12000
Large Community value : 300 12 7200 300 7200
root@spine1-debian-11:~/frr#
```
After:
```
root@spine1-debian-11:~/frr# vtysh -c 'show memory bgpd | include Large Community'
Large Community : 0 40 0 1 56
Large Community display string: 0 8192 0 1 8200
Large Community value : 0 12 0 1 24
root@spine1-debian-11:~/frr# for x in $(seq 1 100); do vtysh -c 'conf' -c 'bgp community alias 123:123:123 testas' > /dev/null; done
root@spine1-debian-11:~/frr# vtysh -c 'show memory bgpd | include Large Community'
Large Community : 0 40 0 1 56
Large Community display string: 0 8192 0 1 8200
Large Community value : 0 12 0 1 24
root@spine1-debian-11:~/frr#
```
After we call [l]community_str2com(), we should free the memory.
Donald Sharp [Thu, 12 May 2022 13:39:27 +0000 (09:39 -0400)]
bgpd: Prevent crash when issuing various forms of `bgp no-rib`
The `bgp no-rib` command cycles through all the bgp rib tables
and removes them from zebra. Modify the code so that FRR notices
that it is attempting to cycle through the safi's that are two level
tables. In addition these safi's cannot just blindly remove the routes
from the rib as that there are none explicitly.
This code just prevents the crash in bgpd. It does not properly cycle
through and remove the zebra changes made that are explicit to these afi's.
This should be handled as appropriate by the developers on these safi's when
it becomes important to them.
Fixes: #11178 Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If duplicate value is entered, the whole plist/alist just dropped.
Before:
```
$ grep prefix-list /etc/frr/frr.conf
ip prefix-list test seq 5 permit 1.1.1.1/32
ip prefix-list test seq 10 permit 1.1.1.1/32
$ systemctl restart frr
$ vtysh -c 'show run | include prefix-list'
$
```
After:
```
$ grep prefix-list /etc/frr/frr.conf
ip prefix-list test seq 5 permit 1.1.1.1/32
ip prefix-list test seq 10 permit 1.1.1.1/32
$ systemctl restart frr
$ vtysh -c 'show run | include prefix-list'
ip prefix-list test seq 5 permit 1.1.1.1/32
```
Donald Sharp [Wed, 27 Apr 2022 12:16:50 +0000 (08:16 -0400)]
tests: Correctly align variable type in tests
New compilers are noticing that the tests are compiling with
a pointer for the bgpd_privs variable while the bgp library
that is being linked against is not a pointer. Since
these tests had the declaration just to make the compiler
happy, let's actually align the variable type to make the
compiler even happier.
Donald Sharp [Wed, 27 Apr 2022 11:57:41 +0000 (07:57 -0400)]
bgpd: Ensure pkt_afi and pkt_safi are not used uninited in some cases
The compiler is, rightly, pointing out that in some cases it is
possible that the pkt_afi and pkt_safi values are not properly
set and could result in a use before initialized. I do not
actually belive that this is possible, but let's make the compiler
happy.
Carl Baldwin [Wed, 29 Dec 2021 21:32:33 +0000 (14:32 -0700)]
bgpd: ensure that the node gets unlocked in all cases
The logic to unlock dest if iteration completed without iterating the
entire node was flawed. Specifically, if iteration terminated due to
`gr_deferred == 0` then the node would not get unlocked.
This change takes into account the fact that dest will be NULL only in
the case when the entire table was iterated and all nodes were already
unlocked. In any other case, it needs to be unlocked.
David Lamparter [Mon, 25 Apr 2022 12:07:41 +0000 (14:07 +0200)]
build: fix new gcc 11.2 warnings
Some recent improvement in GCC triggers 2 new warnings, and they're
actual bugs (reading beyond end of prefix_ipv6 by accessing it as
prefix, which is larger.) Luckily it's only in sharpd.
Modified BGP to pay more attention the prefix returned from
zebra to ensure that a LPM wasn't accidently causing BGP
import checks to think it had a match when it did not.
This unfortunately removed the check to handle the route
removal.
This sequence of config and events would leave BGP in a bad state:
ip route 100.100.100.0/24 Null0
router bgp 32932
bgp network import-check
address-family ipv4 uni
network 100.100.100.0/24
Then if you removed the static route the import check would
still think the route existed:
donatas-pc(config)# ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via static
is directly connected, Null0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)# no ip route 100.100.100.0/24 Null0
donatas-pc(config)# do sh ip nht
100.100.100.0
resolved via kernel
via 192.168.10.1, enp3s0
Client list: bgp(fd 17)
donatas-pc(config)# do sh ip bgp import-check-table
Current BGP import check cache:
100.100.100.0 valid [IGP metric 0], #paths 1
blackhole
Last update: Sat Apr 23 22:51:34 2022
donatas-pc(config)# do sh ip bgp neighbors 192.168.10.123 advertised-routes | include 100.100.100.0
*> 100.100.100.0/24 0.0.0.0 0 32768 i
donatas-pc(config)#
Fix this by moving the code to handle the prefix check to the
evaluation function and mark the bnc as not matching and actually
evaluate the bnc.
Donald Sharp [Thu, 21 Apr 2022 18:13:01 +0000 (14:13 -0400)]
lib: Ensure an empty string does not get printed for host/domain
End operator is showing:
!
frr version 8.0.1
frr defaults traditional
hostname test.example.com
domainname
domainname should not be printed in this case at all. I do not
see any mechanism in current code that this could happen, but
what do I know? Put some extra stupid insurance in place
to prevent bad config from being generated.
zebra: set ZEBRA_IFC_DOWN on connected routes for inactive interfaces
If you are in a situation where you have multiple addresses on an
interface, zebra creates one connected route for them.
The issue is that the rib entry is not created if addresses were
added before the interface was running.
We add the address to a running interface in a typical flow.
Therefore, we handle the route & rib creation within a single ADD event.
In the opposite case, we create the route entries without activating them.
These are considered to be active since ZEBRA_IFC_DOWN is not set.
On the following interface UP, we ignore the same ADDR_ADD as it overlaps
with the existing prefixes -> rib is never created.
The minimal reproducible setup:
-----------------------------------------
ip link add name dummy0 type dummy
ip addr flush dev dummy0
ip link set dummy0 down
ip addr add 192.168.1.7/24 dev dummy0
ip addr add 192.168.1.8/24 dev dummy0
ip link set dummy0 up
vtysh -c 'show ip route' | grep dummy0
Donald Sharp [Sat, 9 Apr 2022 17:12:28 +0000 (13:12 -0400)]
zebra: Allow system routes to recurse through themselves
Currently if a end user has something like this:
Routing entry for 192.168.212.1/32
Known via "kernel", distance 0, metric 100, best
Last update 00:07:50 ago
* directly connected, ens5
Codes: K - kernel route, C - connected, 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,
> - selected route, * - FIB route, q - queued, r - rejected, b - backup
t - trapped, o - offload failure
K>* 0.0.0.0/0 [0/100] via 192.168.212.1, ens5, src 192.168.212.19, 00:00:15
C>* 192.168.212.0/27 is directly connected, ens5, 00:07:50
K>* 192.168.212.1/32 [0/100] is directly connected, ens5, 00:07:50
And FRR does a link flap, it refigures the route and rejects the default
route:
2022/04/09 16:38:20 ZEBRA: [NZNZ4-7P54Y] default(0:254):0.0.0.0/0: Processing rn 0x56224dbb5b00
2022/04/09 16:38:20 ZEBRA: [ZJVZ4-XEGPF] default(0:254):0.0.0.0/0: Examine re 0x56224dbddc20 (kernel) status: Changed Installed flags: Selected dist 0 metric 100
2022/04/09 16:38:20 ZEBRA: [GG8QH-195KE] nexthop_active_update: re 0x56224dbddc20 nhe 0x56224dbdd950 (7), curr_nhe 0x56224dedb550
2022/04/09 16:38:20 ZEBRA: [T9JWA-N8HM5] nexthop_active_check: re 0x56224dbddc20, nexthop 192.168.212.1, via ens5
2022/04/09 16:38:20 ZEBRA: [M7EN1-55BTH] nexthop_active: Route Type kernel has not turned on recursion
2022/04/09 16:38:20 ZEBRA: [HJ48M-MB610] nexthop_active_check: Unable to find active nexthop
2022/04/09 16:38:20 ZEBRA: [JPJF4-TGCY5] default(0:254):0.0.0.0/0: After processing: old_selected 0x56224dbddc20 new_selected 0x0 old_fib 0x56224dbddc20 new_fib 0x0
So the 192.168.212.1 route is matched for the nexthop but it is not connected and
zebra treats it as a problem. Modify the code such that if a system route
matches through another system route, then it should work imo.
Optional recognized and unrecognized BGP attributes,
whether transitive or non-transitive, SHOULD NOT be updated by the
route server (unless enforced by local IXP operator configuration)
and SHOULD be passed on to other route server clients.
By default LB ext-community works with iBGP peers. When we receive a route
from eBGP peer, we can send LB ext-community to iBGP peers.
With this patch, allow sending LB ext-community to iBGP/eBGP peers if they
are set as RS clients.
FRR does not send non-transitive ext-communities to eBGP peers, but for
example GoBGP sends and if it's set as RS client, we should pass those attributes
towards another RS client.
bgpd: Do not forget to update conditional advertisements rmaps for peer-groups
When the peer is configured for the first time:
```
neighbor P1 peer-group
neighbor P1 remote-as external
neighbor P1 advertise-map ADV exist-map EXIST
neighbor 10.10.10.1 peer-group P1
```
Conditional advertisements route-maps are not updated and cond. advertisements
do not work until FRR restarted. BGP sessions clear does not help.
Or even changing peer-group for a peer, causes this bug to kick in.
```
no neighbor 10.10.10.1
neighbor 10.10.10.1 peer-group P2
```
With this fix, cond. advertisements start working immediatelly.
bgpd: Allow setting BGP [large]community in route-maps
Before:
```
spine1-debian-11(config-route-map)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
% Malformed communities attribute
```
After:
```
spine1-debian-11(config)# bgp community alias 65001:65001 test1
spine1-debian-11(config)# route-map rm permit 10
spine1-debian-11(config-route-map)# set community 65001:65001
spine1-debian-11(config-route-map)#
```
projects / mirror / frr.git / log