mips64el does not have a 64-bit PC-relative relocation, which is needed
to emit the ELF note for xrefs. Disabling the ELF note means clippy
takes the fallback path using section headers, so everything does still
work (... unless you strip the section headers.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Most 32-bit architectures cannot do atomic loads and stores of data
wider than their pointer size, i.e. 32 bit. Funnily enough they
generally *can* do a CAS2, i.e., 64-bit compare-and-swap, but while a
CAS can emulate atomic add/bitops, loads and stores aren't available.
Replace with a mutex; since this is 99% used from the zserv thread, the
mutex should take the local-to-thread fast path anyway. And while one
atomic might be faster than a mutex lock/unlock, we're doing several
here, and at some point a mutex wins on speed anyway.
This fixes build on armel, mipsel, m68k, powerpc, and sh4.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Alpine upstream changed the name of the isl package to isl-dev. This
caused the build breakage. Since FRR doesn't use it, we chose to solve
this issue by removing it.
Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
When FRR receives a route from the kernel about the route
offload success/failure. The metric being reported is not
going to be correct since we may not know it appropriately
at this point in time. If we can set the metric to something
appropriate.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When we are notified about the kernel about a route being offloaded
or not correctly set the distance.
Ticket: CM-33097
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Added ipv4 and ipv6 option to existing "show bgp nexthop"
command to be able to query nexthops that belong to a
particular address-family.
Also fixed the warnings of MR 12171
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
When creating one interface "vxlan66" ( ip link add vxlan66 type vxlan ... ),
which initially maintains down status, saw one unexpected EC log:
```
zebra[37906]: [ZAG0W-VSNSD] interface vxlan66 vrf default(0) index 35 becomes active.
zebra[37906]: [HPWGA-Y527W] IFLA_VXLAN_LINK missing from VXLAN IF message
...
zebra[37906]: [W6BZR-YZPAB] RTM_NEWLINK update for vxlan66(35) sl_type 0 master 0 flags 0x1002
zebra[37906]: [MR3ZF-ATDBY] Intf vxlan66(35) has gone DOWN
zebra[37906]: [T44X9-FFNVB] Intf vxlan66(35) L2-VNI 66 is DOWN
zebra[37906]: [KEGYY-K8XVV] Send EVPN_DEL 66 to bgp
zebra[37906]: [HPWGA-Y527W] IFLA_VXLAN_LINK missing from VXLAN IF message
bgpd[37911]: [TV0XP-3WR0A] Rx VNI del VRF default VNI 66 tenant-vrf default SVI ifindex 0
bgpd[37911]: [MDW89-YAXJG][EC 33554497] 0: VNI hash entry for VNI 66 not found at DEL
```
Since commit `6f908ded80eeba40a850e8d1f6246fb3ed31e648` support interfaces
from down to down, and bgpd doesn't know "VNI 66" at all. So, remove this
EC log.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
New show command "show evpn mac vni xx detail [json]"
to display details of all the mac entries for the
requested VNI.
Output of show evpn mac vni xx detail json:
{
"numMacs":2,
"macs":{
"ca:be:63:7c:81:05":{
"type":"local",
"intf":"veth100",
"ifindex":8,
"uptime":"00:06:55",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false,
"syncNeighCount":0,
"neighbors":{
"active":[
"fe80::c8be:63ff:fe7c:8105"
],
"inactive":[
]
}
}
}
}
Also added remoteEs field in the JSON output of
"show evpn mac vni xx json".
Output of show evpn mac vni xx json:
"00:02:00:00:00:0d":{
"type":"remote",
"remoteEs":"03:44:38:39:ff:ff:02:00:00:02",
"localSequence":0,
"remoteSequence":0,
"detectionCount":0,
"isDuplicate":false
}
Signed-off-by: Pooja Jagadeesh Doijode <pdoijode@nvidia.com>
Previously, routes leaked from one VRF to another VRF were associated
with the original nexthop interface.
Commit 14aabc0156 replaced the nexthop
interface with the index of incoming VRF interface.
Due to this change, the `bgp_srv6l3vpn_route_leak` topotest always fails
because it still expects the nexthop interface.
This commit fixes the expected interface name in the
`bgp_srv6l3vpn_route_leak` topotest.
Signed-off-by: Carmine Scarpitta <carmine.scarpitta@uniroma2.it>
netlink_route_multipath_msg_encode checks whether the local kernel
supports NextHop Netlink message and doesn't send the message if the
local kernel doesn't have support. This is also applied to the FPM since
kernel dataplane and FPM shares the same code. However, for the FPM,
it's not necessary to have this limit.
This commit adds extra check if netlink_route_multipath_msg_encode is
called from the FPM and bypass kernel support check if it is from the
FPM.
Signed-off-by: Yutaro Hayakawa <yutaro.hayakawa@isovalent.com>
agentx can't be disabled once enabled, so we should ignore it for frr-reload.py.
```
$ /usr/lib/frr/frr-reload.py --reload /etc/frr/bgpd.conf --bindir /usr/local/bin
"no agentx" we failed to remove this command
SNMP AgentX support cannot be disabled once enabled
```
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
On shutdown, bgp calls an unlock for the bnc connected table,
via the bgp_connected_cleanup function. This function is
only ever called on shutdown, so we know that bgp is going
away. The refcount for the connected data can be more than
1. Let's not worry about the refcount on shutdown and
just delete the nodes instead of leaving them around.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Shutdown of bgp results in both the bgp_path_info,
bgp_dest and bgp_table's not being freed because
the bgp_path_info remains locked.
Effectively static routes are scheduled for deletion but bgp_process
skips the work because the work queue sees that the bgp router
is marked for deletion. Effectively not doing any work and leaving
data on the floor.
Modify the code when attempting to put into the work queue to
notice and not do so but just unlock the path info.
This is effectively the same as what goes on for normal peering
as that it checks for shutdown and just calls bgp_path_info_free
too.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
