Configuration:
```
vtysh <<EOF
configure
vrf vrf100
vni 10100
exit-vrf
router bgp 50
address-family l2vpn evpn
advertise-all-vni
exit-address-family
exit
router bgp 100 vrf vrf100
exit
EOF
```
TL;DR; When we configure `advertise-all-vni` (in this case), a new BGP instance
is created with the name vrf100, and ASN 50. Next, when we create
`router bgp 100 vrf vrf100`, we look for the BGP instance with the same name
and we found it, but ASNs are different 50 vs. 100.
Every such a new auto created instance is flagged with BGP_VRF_AUTO.
After the fix:
```
router bgp 50
!
address-family l2vpn evpn
advertise-all-vni
exit-address-family
exit
!
router bgp 100 vrf vrf100
exit
!
end
donatas.net(config)# router bgp 51
BGP is already running; AS is 50
donatas.net(config)# router bgp 50
donatas.net(config-router)# router bgp 101 vrf vrf100
BGP is already running; AS is 100
donatas.net(config)# router bgp 100 vrf vrf100
donatas.net(config-router)#
```
Fixes: https://github.com/FRRouting/frr/issues/16152
Fixes: https://github.com/FRRouting/frr/issues/9537
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Fixes:
zebra/zebra_netns_notify.c: In function 'zebra_ns_ready_read':
zebra/zebra_netns_notify.c:266:40: error: implicit declaration of function 'basename' [-Wimplicit-function-declaration]
266 | if (strmatch(VRF_DEFAULT_NAME, basename(netnspath))) {
| ^~~~~~~~
Fixed by including libgen.h, then since basename may modify its
parameter, allocate a copy on the stack, using strdupa, and pass the
temporary string to basename.
According to the man page for basename:
With glibc, one gets the POSIX version of basename() when
<libgen.h> is included, and the GNU version otherwise.
The POSIX version of basename may modify the contents of path,
so we should to pass a copy when calling this function.
[1] https://man7.org/linux/man-pages/man3/basename.3.html
Signed-off-by: Georgi Valkov <gvalkov@gmail.com>
This change will stop this action from running on forked repos.
Previously whenever one pushed a change to one's development branch the
action would "run but skip" which still generated an email notifications
and thus was very annoying. :)
Signed-off-by: Christian Hopps <chopps@labn.net>
The default DSCP used for BGP connections is CS6. The DSCP value is
not part of the TCP header.
When setting the IP_TOS or IPV6_TCLASS socket options, the argument
is not the 6-bit DSCP value, but an 8-bit value for the former IPv4
Type of Service field or IPv6 Traffic Class field, respectively.
Fixes: 425bd64be8 ("bgpd: Allow bgp to control the DSCP session TOS value")
Signed-off-by: David Ward <david.ward@ll.mit.edu>
When the kernel is not compiled with mroute vrf's enabled it will
fail the call to initialize the vrf. As such let's recognize this
specific error code and output a specific warning to the operator
to help them figure this problem out.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Before we checked for received Graceful Restart capability, but that was also
incorrect, because we SHOULD HAVE checked it per AFI/SAFI instead.
https://datatracker.ietf.org/doc/html/rfc4724 says:
Although the End-of-RIB marker is specified for the purpose of BGP
graceful restart, it is noted that the generation of such a marker
upon completion of the initial update would be useful for routing
convergence in general, and thus the practice is recommended.
Thus, it might be reasonable to send EoR regardless of whether the Graceful Restart
capability is received or not from the peer.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
lib/typesafe.h was supposed to be outside the _TYPESAFE_EXPAND_MACROS
guard, so that including lib/atomlist.h grabs all the typesafe container
macros.
(No effect on normal build, as _TYPESAFE_EXPAND_MACROS is never defined
there.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Only output requested information to stdout so it can be
filtered and captured in shell variables etc...
Signed-off-by: Christian Hopps <chopps@labn.net>
There is no reason to call `igmp_anysource_forward_stop()` inside a call to
`igmp_get_source_by_addr()`; not only it is not expected for a "get" function
to perform such an action, but also the decision to start/stop forwarding is
already handled correctly by pim outside `igmp_get_source_by_addr()`.
That call was left there from the days pim was initially imported into the sources.
The problem/crash was happening because `igmp_find_source_by_addr()` would fail to
find the group/source combo when mixing `(*, G)` and `(S, G)`. When having an existing
flow `(*, G)`, and a new `(S, G)` igmp is received, a new entry is correctly created.
`igmp_anysource_forward_stop(group)` always stops and eventually frees `(*, G)`, even
when the new igmp is `(S, G)`, leaving a bad state. I.e, the new entry for `(S, G)`
causes `(*, G)` to be deleted.
Tested the fix with multiple receivers on the same interface with several ssm and
any source senders and receivers with various combination of start/stop orders and
they all worked correctly.
Fixes: #15630
Signed-off-by: Jafar Al-Gharaibeh <jafar@atcorp.com>
Contains 2 testcases. The first does a basic configuration/connectivity.
The second testcase initiates a shortcut through the primary NHS,
verifies shortcut routes are installed. Primary NHS interface brought
down and verify that the shortcut is not impacted. Finally verify that
after the shortcut expires, it is able to be re-established via a backup
NHS.
Signed-off-by: dleroy <dleroy@labn.net>
When nhrpd is shutdown via nhrp_request_stop() the shutdown
sequence was not handling the case where there are active
shortcut routes installed. The zebra client and shortcut rib
were being cleaned up before vrf_terminate() had an opportunity
to delete the active routes.
Signed-off-by: dleroy <dleroy@labn.net>
When parsing a osf6 grace lsa field and we receive an
unknown tlv type, ospf6d was not incrementing the pointer
to get beyond the tlv. Leaving a situation where ospf6d
would parse the packet incorrectly.
Signed-off-by: Iggy Frankovic <iggy07@gmail.com>
Locally this test would occassionally fail for me
because the connected route the sharp route being
installed has not fully come up yet due to heavy
load and start up slowness. Add a bit of code
to look for the problem and make sure it doesn't
happen.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Using absolute xpath is not optimal for finding the target node. As the
route map configuration grows, the yang validation will take more time
to complete. Relative paths are much faster.
Tested with a config file that contains ~3k route map config lines.
- before:
time cat conf | vtysh
configure
log syslog errors
router bgp 65000
!
route-map RM:BGP:VPNV4:PEER:VRR9:IN10001 permit 101
match community CL:HCC:PATH_PRIO1_EAST1
set local-preference 15200
!
...
route-map RM:BGP:VPNV4:PEER:VRR9:IN10001 permit 1182
match community CL:HCC:PATH_PRIO1_EAST1082
set local-preference 16281
!
real 13m51.500s
user 0m0.522s
sys 0m4.854s
- after:
time cat conf | vtysh
...
real 0m48.390s
user 0m0.384s
sys 0m1.245s
Signed-off-by: Loïc Sang <loic.sang@6wind.com>
When a router route already exists in the area border routers table
as an ABR and it solely changes its ABR or ASBR status, the change
was missed and border route is not updated. This fixes the comparison
for the router_bits in the ospf6_path structure.
This fixes issue https://github.com/FRRouting/frr/issues/16053 although
the actual problem is not the computing router (r2) and not the OSPFv3
redistribution (r3).
Signed-off-by: Acee <aceelindem@gmail.com>
