The existing iteration callback only allows for a daemon to return a
pointer to objects that must already exist and must continue to exists
indefinitely.
To allow the daemon to return allocated iterator objects and for locking
it's container structures we need a callback to tell the daemon when FRR
is done using the returned value, so the daemon can free it (or unlock
etc)
That's what list_entry_done() is for.
Signed-off-by: Christian Hopps <chopps@labn.net>
Clean up compiler warnings; convert a linklist macro
to an inline to resolve one; clean up a side-effect in isisd.
Signed-off-by: Mark Stapp <mjs@cisco.com>
The `_once` loop variable will result in a `-Wshadow` warning when that
is turned on. Use `__COUNTER__` to give these variables distinct names,
like is already done with `_mtx_`.
(and because I touched it, clang-format wants it reformatted... ohwell.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This command:
route-map FOOBAR permit 10
set ipv6 next-hop prefer-global
set community 5060:12345 additive
!
When you issue a `show route-map ...` command displays this:
route-map: FOOBAR Invoked: 0 (0 milliseconds total) Optimization: enabled Processed Change: false
permit, sequence 5 Invoked 0 (0 milliseconds total)
Match clauses:
Set clauses:
ipv6 next-hop prefer-global (null)
community 5060:12345 additive
Call clause:
Action:
Exit routemap
Modify the code so that it no longer displays the NULL when there
is nothing to display.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If we do e.g.:
ip prefix-list PL_LoopbackV4 permit 10.1.0.32/32
ip prefix-list PL_LoopbackV4 permit 10.1.0.32/32
ip prefix-list PL_LoopbackV4 permit 10.1.0.32/32
We end up, having duplicate records with a different sequence number only.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
This commit undo 8c9b007a0c
stream lib has been modified to expand the stream if needed
Now for zapi route encode, we use expandable stream
Signed-off-by: Soumya Roy <souroy@nvidia.com>
Issue:
Currently, during encode time, if required memory is
more than available space in stream buffer, stream buffer
can't be expanded. This fix introduces new apis to support
stream buffer expansion.
Testing:
Tested with zebra nexthop encoding with 512 nexthops, which triggers
this new code changes, it works fine. Without fix, for same trigger
it asserts.
Signed-off-by: Soumya Roy <souroy@nvidia.com>
When creating a control plane protocol through NB, create the vrf
if needed instead of only looking up and asserting if it doesn't
exist yet.
Fixes 18429.
Signed-off-by: Nathan Bahr <nbahr@atcorp.com>
At VRF disabling, keep the route entries that was associated to its
table ID but not to the VRF itself. Kernel flushes these entries so we
need to reinstall them.
To do so, add a flag to mean that a route entry is owned by a table ID
and not by a VRF. If the VRF associated to the table ID is deleted, the
route entry must not be deleted.
Update to tests with new flag. 2057 is in hexa 0x809, meaning that the
new flag has been to some prefix.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
This macro is unused and it leads to the compile error:
```
./ospfd/ospf_dump.h:78:60: error: pasting "OSPF_DEBUG_" and ""Global Graceful Restart - GR Mode\n"" does not give a valid preprocessing token
78 | #define TERM_DEBUG_ON(a, b) term_debug_ospf_ ## a |= (OSPF_DEBUG_ ## b)
```
Signed-off-by: anlan_cs <anlan_cs@126.com>
The --command-log-always was not being listed as a valid
option for when the operator issues a <daemon> --help
command line.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The exact-match and the any options are missing for the extended
communities. Add missing options that are present on the match
operations for communities and large-communities.
> route-map rmap permit 1
> match extcommunity 1
> exit
> !
> route-map rmap permit 2
> match extcommunity 2 any
> exit
> !
> route-map rmap permit 3
> match extcommunity 3 exact-match
> exit
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Add a mechanism in route-map to filter out route-map which have a list
of extended communities greater than the given number.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
required stream size is evaluated as a fix part and variable one.
the variable one depend on the number of nexthops.
Signed-off-by: Francois Dumontet <francois.dumontet@6wind.com>
ldpd has this crash:
(gdb) bt
0 __pthread_kill_implementation (no_tid=0, signo=11, threadid=140329211443648) at ./nptl/pthread_kill.c:44
1 __pthread_kill_internal (signo=11, threadid=140329211443648) at ./nptl/pthread_kill.c:78
2 __GI___pthread_kill (threadid=140329211443648, signo=signo@entry=11) at ./nptl/pthread_kill.c:89
3 0x00007fa0f0642476 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
4 0x00007fa0f0b51944 in core_handler (signo=11, siginfo=0x7fff562810b0, context=0x7fff56280f80) at lib/sigevent.c:268
5 <signal handler called>
6 0x00007fa0f0b9534d in lm_get_label_chunk (zclient=0x0, keep=0 '\000', base=0, chunk_size=64, start=0x7fff56281bdc, end=0x7fff56281be0) at lib/zclient.c:3667
7 0x0000564e0d1c011e in lde_get_label_chunk () at ldpd/lde.c:2211
8 0x0000564e0d1c05f8 in lde_get_next_label () at ldpd/lde.c:2318
9 0x0000564e0d1bcb29 in lde_update_label (fn=0x564e16653050) at ldpd/lde.c:783
10 0x0000564e0d1c1fbe in lde_kernel_update (fec=0x7fff56281cb0) at ldpd/lde_lib.c:422
11 0x0000564e0d1b96c0 in l2vpn_pw_init (pw=0x564e165d1fa0) at ldpd/l2vpn.c:242
12 0x0000564e0d1b2d32 in merge_l2vpn (xconf=0x564e166424f0, l2vpn=0x564e166160a0, xl=0x564e165eabb0) at ldpd/ldpd.c:1883
13 0x0000564e0d1b28ea in merge_l2vpns (conf=0x564e166424f0, xconf=0x564e16653650) at ldpd/ldpd.c:1813
14 0x0000564e0d1b1244 in merge_config (conf=0x564e166424f0, xconf=0x564e16653650) at ldpd/ldpd.c:1321
15 0x0000564e0d1bc485 in lde_dispatch_parent (thread=0x7fff56282060) at ldpd/lde.c:611
16 0x00007fa0f0b6cebc in event_call (thread=0x7fff56282060) at lib/event.c:2019
17 0x0000564e0d1baee7 in lde () at ldpd/lde.c:155
18 0x0000564e0d1ae4b8 in main (argc=0, argv=0x7fff56282298) at ldpd/ldpd.c:312
(gdb)
Since it is possible to be asking for label data before the zclient has
been connected, let's just return -1 in the case where zclient is not
initialized yet either, since this is effectively the same thing as
the sock being < 0.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This value in the yang tree was returning NULL for
when the state of the vrf was not active. It should
return a false.
Before:
eva# show mgmt get-data /frr-vrf:lib/vrf[name="vrf1"]
{
"frr-vrf:lib": {
"vrf": [
{
"name": "vrf1",
"state": {
"id": 4294967295
}
eva# show mgmt get-data /frr-vrf:lib/vrf[name="BLUE"]
{
"frr-vrf:lib": {
"vrf": [
{
"name": "BLUE",
"state": {
"id": 68,
"active": true
},
After:
eva# show mgmt get-data /frr-vrf:lib/vrf[name="vrf1"]
{
"frr-vrf:lib": {
"vrf": [
{
"name": "vrf1",
"state": {
"id": 4294967295,
"active": false
}
eva# show mgmt get-data /frr-vrf:lib/vrf[name="BLUE"]
{
"frr-vrf:lib": {
"vrf": [
{
"name": "BLUE",
"state": {
"id": 68,
"active": true
},
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The capacity of the xpath string was not guaranteed to be sufficient to hold all
the key predicates and so would truncate. Calculate the required space and
guarantee that it is available.
Signed-off-by: Christian Hopps <chopps@labn.net>
The uA behavior is associated with an interface and the IP address of
the nexthop. However, the current SID context data structure only
includes the IP address. It lacks the interface.
This commit extends the SID context data structure by adding the
ifindex. This extension allows daemons to allocate uA SIDs with
the required interface and IP address.
Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
Introduce ZEBRA_IF_DUMMY interface flag to identify Linux dummy interfaces [0].
These interfaces behave similarly to loopback interfaces and can be
specially handled by daemons.
[0]: https://github.com/torvalds/linux/blob/master/drivers/net/dummy.c
Signed-off-by: Gabriel Goller <g.goller@proxmox.com>
This also fixes a bug with specific (position specified) queries on keyless
lists. If the `get_next` callback is using the parent entry it will probably
crash as the code is passing the list_entry as both parent and child in the
specific lookup case.
There may currently be no code that uses the parent entry if the child entry is
non-NULL, though.
Signed-off-by: Christian Hopps <chopps@labn.net>
