Currently when the fpm_listener attempts to read say X
bytes it may only get Y( which is less than X ). In this
case we should assume that the dplane_fpm_nl code is just
being slow, as that we know it is possible for it to send
a partial fpm message. Let's just loosen the constraints
a bit and allow data to flow.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Even if we have unnumbered peering, let's respect `no neighbor X capability link-local`
and disable it per-neighbor on demand.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Make it consistent and call it `event` when formatting something to
display. Much less confusing for some user seeing it too, since threads
aren't involved.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
FRR's event loop prints a warning if a timer is executed more than some
given threshold late, default being 4s. Set a more appropriate
threshold for BFD TX timers (half TX interval).
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Refactor the "timer getting executed too late" warning:
- warning threshold is now adjustable
- check is performed when event actually executes, rather than when it's
thrown on ready list
- ignore_late_timer replaced with threshold = 0
- system load averages printed in log message
- warning ratelimited to once per 10s rather than once per poll()
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
The transmitted AS value in te tx open message of the peer up loc-rib
message is set to 0. Actually, it should reflect the AS value of the
current BGP instance.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
When forging BMP open message, the BGP router-id of tx open message of
the BMP LOC-RIB peer up message is always set to 0.0.0.0, whatever the
configured value of 'bgp router-id'.
Actually, when forging a peer up LOC-RIB message, the BGP router-id
value should be taken from the main BGP instance, and not from the peer
bgp identifier. Fix this by refreshing the router-id whenever a peer up
loc-rib message should be sent.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Remove the num_labels variable, the received bgp_update() and
bgp_withdraw() function will read the message as including one
label or vni value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
If we have LL Next Hop capability exchanged, we should send LL-only as 16-bytes
NH instead of a GUA (global unicast).
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
In bgp route leak, when import vrf x is executed,
it creates bgp instance as hidden with asn value as unspecified.
When router bgp x is configured ensure the correct as,
asnotation is applied otherwise running config shows asn value as 0.
This can lead to frr-reload failure when any FRR config change.
Fix:
Move asn and asnotiation, as_pretty value in common done section,
so when bgp_create gets existing instance but before returning
update asn and required fields in common section.
In bgp_create(): when returning for hidden at least update asn
and required when bgp instance created implicitly due to vrf leak.
if (hidden) {
bgp = bgp_old;
goto peer_init; <<<
}
Before fix:
show running:
router bgp 0 vrf purple
bgp router-id 10.10.3.11
!
address-family ipv4 unicast
redistribute static
import vrf blue
exit-address-family
!
address-family ipv6 unicast
import vrf blue
exit-address-family
!
address-family l2vpn evpn
advertise ipv4 unicast
advertise ipv6 unicast
exit-address-family
exit
Testing:
1) following snippet config:
router bgp 63420 vrf blue
import vrf purple
router bgp 63420 vrf purple
import vrf blue
2) restart frr leads to the running config with 0 asn value.
Signed-off-by: Chirag Shah <chirag@nvidia.com>
We should involve checking received (not only advertised) capability, because
otherwise we put both peers (one with LL capability, another without) into a
single update-group and send 16-bytes NH instead of 16-bytes and 32-bytes
separately.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Add new topology for testing IGMP/MLD group/source limiting and more features
in the future.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Document the newly added commands to limit the maximum amount of
groups/source to learn.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
For groups we can just look at the length of the list, for sources we
need to count them on a per-interface level.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
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>
When SRv6 is enabled and an SRv6 locator is specified in the BGP
configuration, BGP may attempt to request SRv6 locator information from
zebra before the connection is fully established. If this occurs, the
request fails with the following error:
```
2025/02/06 16:37:32 BGP: [HR66R-TWQYD][EC 100663302] srv6_manager_get_locator: invalid zclient socket
````
As a result, BGP is unable to obtain the locator information,
preventing SRv6 VPN from working.
This commit fixes the issue by ensuring BGP requests SRv6 locator
information once the connection with zebra is successfully established.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `static_srv6_sids` topotest verifies that staticd correctly
programs the SIDs in the zebra RIB. Currently, the topotest only
validates the programmed behavior and SID attributes.
This commit extends the topotest to also validate the SID structure.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The `show ipv6 route json` command displays the IPv6 routing table in
JSON format, including SRv6 SIDs. For each SRv6 SID, it provides
behavior and SID attributes. However, it does not include the SID
structure.
This commit adds the SID structure to the SRv6 SID JSON output.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
The SRv6 support in staticd (PR #16894) does not set the correct SID
parameters (block length, node length, function length).
This commit fixes the issue and computes the correct parameters.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Capability's length is 0 and this is not needed to check if it's multiplied by
X or there is a minimum length for that.
Fixes: db853cc97e ("bgpd: Implement Link-Local Next Hop capability")
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
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>
