RFC7611 introduces new extended community ACCEPT_OWN and is already
implemented for FRR in the previous PR. However, this PR broke
compatibility about importing VPN routes.
Let's consider the following situation. There are 2 routers and these
routers connects with iBGP session. These routers have two VRF, vrf10
and vrf20, and RD 0:10, 0:20 is configured as the route distinguisher
of vrf10 and vrf20 respectively.
+- R1 --------+ +- R2 --------+
| +---------+ | | +---------+ |
| | VRF10 | | | | VRF10 | |
| | RD 0:10 +--------+ RD 0:10 | |
| +---------+ | | +---------+ |
| +---------+ | | +---------+ |
| | VRF20 +--------+ VRF20 | |
| | RD 0:20 | | | | RD 0:20 | |
| +---------+ | | +---------+ |
+-------------+ +-------------+
In this situation, the VPN routes from R1's VRF10 should be imported to
R2's VRF10 and the VPN routes from R2's VRF10 should be imported to R2's
VRF20. However, the current implementation of ACCEPT_OWN will always
reject routes if the RD of VPN routes are matched with the RD of VRF.
Similar issues will happen in local VRF2VRF route leaks. In such cases,
the route reaked from VRF10 should be imported to VRF20. However, the
current implementation of ACCEPT_OWN will not permit them.
+- R1 ---------------------+
| +------------+ |
| +----v----+ +----v----+ |
| | VRF10 | | VRF20 | |
| | RD 0:10 | | RD 0:10 | |
| +---------+ +---------+ |
+--------------------------+
So, this commit add additional condition in RD match. If the route
doesn't have ACCEPT_OWN extended community, source VRF check will be
skipped.
[RFC7611]: https://datatracker.ietf.org/doc/html/rfc7611
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
After implementing ACCEPT_OWN extended community, bgpd can't import VPN
routes to the VRFs whose RD is matched with that of VPN routes. This
commit adds new test to check the effect of the next commit.
Signed-off-by: Ryoga Saito <ryoga.saito@linecorp.com>
Use "(null)" for empty IP address.
One example in `bgp_zebra_send_remote_macip()` to install mac:
Before:
```
2023/01/18 02:09:09 BGP: [SCHS5-AK960] Tx ADD MACIP, VNI 200 MAC 06:6b:7c:db:83:72 IP flags 0x0 seq 0 remote VTEP 88.88.88.88 esi -
```
After:
```
2023/01/18 20:19:57 BGP: [SCHS5-AK960] Tx ADD MACIP, VNI 200 MAC 06:6b:7c:db:83:72 IP (null) flags 0x0 seq 0 remote VTEP 88.88.88.88 esi -
```
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Don't attempt to encode the pointer address instead pass the pointer
directly so the real contents can be accessed.
(`ri->pref_src` type is `union g_addr *`)
Found by Coverity Scan (CID 1482162)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Do extra inotify data structure checks and copy the file name to a stack
buffer making sure it is null byte terminated.
Found by Coverity Scan (CID 1465494)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Changes:
- Convert `unsigned int` to `time_t` to satisfy time truncation warnings
even though at this point we had already used the modulus operator.
- Avoid trying to access outside the bounds of the array
`months` array has a size of 13 elements, but the code inside the loop
uses `i + 1` to peek on the next month.
Found by Coverity Scan (CID 1519752 and 1519769)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
MPLS VPN networks can either peer with iBGP or eBGP. When
calculating the distance to send to zebra, the imported prefix
is never sent with distance information, even if the vty
command is used under the ipv4 unicast address family:
router bgp 65505 vrf vrf1
address-family ipv4 unicast
distance bgp 26 27 28
[vpn config]
The observation is that the distance sent to zebra for an
imported prefix is still 20:
[..]
VRF vrf1:
B> 192.168.0.0/24 [20/0] via 2.2.2.2 (vrf default) (recursive), label 20, weight 1, 00:00:12
* via 10.125.0.6, ntfp3 (vrf default), label implicit-null/20, weight 1, 00:00:12
The expectation is that the incoming prefix has to follow the
distance that is configured, or the distance derived from the peer
relationship established by the parent prefix.
In the case, an iBGP relationship is done, and no distance
configuration is done, the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [200/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
In the case an iBGP relationship is done, and distance configuration
is performed as below:
[..]
distance bgp 21 201 41
[..]
Then the below show is expected:
[..]
VRF vrf1:
B*> 192.168.0.0/24 [201/0] via 192.168.0.2, r1-gre0 (vrf default), label 20, weight 1, 00:00:12
To get this behaviour, get the peer origin where the prefix is coming
from.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
After calling `rib_unlink` the variable `re` will point to `free()`d
memory, so don't attempt to use it after this point.
Found by Coverity Scan (Coverity ID 1519784)
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
[New LWP 2524]
[New LWP 2539]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/opt/avi/bin/bgpd -f /run/frr/avi_ns3_bgpd.config -i /opt/avi/etc/avi_ns3_bgpd.'.
Program terminated with signal SIGABRT, Aborted.
[Current thread is 1 (Thread 0x7f92ac8f1740 (LWP 2524))]
0 0x00007f92acb3800b in raise () from /lib/x86_64-linux-gnu/libc.so.6
[Current thread is 1 (Thread 0x7f92ac8f1740 (LWP 2524))]
0 0x00007f92acb3800b in raise () from /lib/x86_64-linux-gnu/libc.so.6
1 0x00007f92acb17859 in abort () from /lib/x86_64-linux-gnu/libc.so.6
2 0x00007f92acb17729 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
3 0x00007f92acb28fd6 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
4 0x00007f92accf2164 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
5 0x000055b46be1ef63 in bgp_keepalives_wake () at bgpd/bgp_keepalives.c:311
6 0x000055b46be1f111 in bgp_keepalives_stop (fpt=0x55b46cfacf20, result=<optimized out>) at bgpd/bgp_keepalives.c:323
7 0x00007f92acea9521 in frr_pthread_stop (fpt=0x55b46cfacf20, result=result@entry=0x0) at lib/frr_pthread.c:176
8 0x00007f92acea9586 in frr_pthread_stop_all () at lib/frr_pthread.c:188
9 0x000055b46bdde54a in bgp_pthreads_finish () at bgpd/bgpd.c:8150
10 0x000055b46bd696ca in bgp_exit (status=0) at bgpd/bgp_main.c:210
11 sigint () at bgpd/bgp_main.c:154
12 0x00007f92acecc1e9 in quagga_sigevent_process () at lib/sigevent.c:105
13 0x00007f92aced689a in thread_fetch (m=m@entry=0x55b46cf23540, fetch=fetch@entry=0x7fff95379238) at lib/thread.c:1487
14 0x00007f92aceb2681 in frr_run (master=0x55b46cf23540) at lib/libfrr.c:1010
15 0x000055b46bd676f4 in main (argc=11, argv=0x7fff953795a8) at bgpd/bgp_main.c:482
Root cause:
This is due to race condition between main thread & keepalive thread during clean-up.
This happens when the keepalive thread is processing a wake signal owning the mutex, when meanwhile the main thread tries to stop the keepalives thread.
In main thread, the keepalive thread’s running bit (fpt->running) is set to false, without taking the mutex & then it blocks on mutex.
Meanwhile, keepalive thread which owns the mutex sees that the running bit is false & executes bgp_keepalives_finish() which also frees up mutex.
Main thread that is waiting on mutex with pthread_mutex_lock() will cause core while trying to access mutex.
Fix:
Take the lock in main thread while setting the fpt->running to false.
Signed-off-by: Samanvitha B Bhargav <bsamanvitha@vmware.com>
Add a function to find the VRF or the loopback interface: the loopback
interface for the default VRF and the VRF master interface otherwise.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Before this patch we allowed importing routes between VRFs in the same node,
only for external routes, but not for local (e.g.: redistribute).
Relax here a bit, and allow importing local routes between VRFs when the RT
list is modified using route reflectors.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
I'm seeing test failures after in micronet runs in CI
after 7 seconds * 30 attempts at seeing if it succeeds.
Let's see if another 60 seconds of attempts allows
this to work properly.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Got `ERROR: Daemon babeld is not a valid option for 'show running-config'` when using `frr-reload.py --reload --daemon babeld`.
Adds `babeld` and `nhrpd` as valid daemons.
Signed-off-by: Yuxiang Zhu <vfreex@gmail.com>
Before this patch, we needed to explicitly define a neighbor to be SOLO
(= separate update-group). Let's ease this functionality for an operator to
avoid confusions.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The idea is to drop unwanted attributes from the BGP UPDATE messages and
continue by just ignoring them. This improves the security, flexiblity, etc.
This is the command that Cisco has also.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Single run of this test suite on my machine was 8 minutes.
Breaking this up into 3 test suites halves the run time.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This change alters the behavior of existing test code. The
default mode (before any call to luSetWaitType()) is now
"strict".
The historical behavior of luCommand(op="wait) is to ignore
failures to match the specified regexp in the specified time.
In those cases, no result was logged and no error was signaled.
This change introduces a new "strict" mode for luCommand(op="wait):
in "strict" wait mode, each invocation of luCommand(op="wait)
generates an explicit, logged failure result when it fails to match
the specified regexp in the specified time. These failures signal
an error for the test.
Calling luSetWaitType("nostrict") restores the historical behavior.
Calling luSetWaitType("strict") (re)enables the new strict behavior.
Individual calls to luCommand() may also specify op="wait-nostrict"
to override any default and use the historical behavior.
Individual calls to luCommand() may also specify op="wait-strict"
to override any default and use the new behavior.
Signed-off-by: G. Paul Ziemba <paulz@labn.net>
This command helps in troubleshooting static bfd feature.
Add traces upon bfd events.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
