convert:
frr_with_mutex(..)
to:
frr_with_mutex (..)
To make all our code agree with what clang-format is going to produce
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The creation of the rtadv socket can fail but there
is very very little data associated with this event
to let the operator know something has gone terribly
wrong.
Please note if this socket fails to create or fails
the setsockopt's rtadv is basically just really really
messed up. I am not sure what can be done here.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
==1595641== 280 (80 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 30 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EC880: mpls_lsp_install (zebra_mpls.c:3192)
==1595641== by 0x1C51BB: zread_vrf_label (zapi_msg.c:3197)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
==1595641==
==1595641== 1,400 (400 direct, 1,000 indirect) bytes in 5 blocks are definitely lost in loss record 35 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EBD7C: mpls_zapi_labels_process (zebra_mpls.c:2915)
==1595641== by 0x1C35D9: zread_mpls_labels_add (zapi_msg.c:2513)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
Since the `mac->flags` with `ZEBRA_MAC_ES_PEER_ACTIVE` is about ES Peer,
it should be displayed as `PEER Active`.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
Just adding two more attributes to decode and show nicely in netlink
msgdump debug output.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The IPv6 version needs rtm_src_len and rtm_dst_len filled in due to
strict validation. IPv4 also has this requirement, but zebra is running
in non-strict mode there so the kernel accepts it...
Also the table ID hack is IPv4 only.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The multicast routing RTM_GETROUTE command does not use IIF/OIF
attributes, and the IPv6 version will refuse them with an error due to
being new netlink API and thus using strict validation.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
These two structs happen to be the same size and have the family field
in the same spot, but the correct one to use here is rtmsg not ndmsg.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
zebra does not care about _notifications_ from the kernel regarding
multicast routing; we only use the MR netlink API to request stats from
the kernel by actively sending a RTM_GETROUTE.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
New output example:
2022-07-03 09:40:29.310 [DEBG] zebra: [JF0K0-DVHWH] rib_meta_queue_add: (0:254):4.5.6.8/32: queued rn 0x55937f586ee0 into sub-queue Kernel Routes
2022-07-03 09:40:29.321 [DEBG] zebra: [HH6N2-PDCJS] default(0:254):4.5.6.8/32 rn 0x55937f586ee0 dequeued from sub-queue Kernel Routes
Let's make it a bit more human readable.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a slightly modified version of Hiroki Sato's version:
9ca79c941f
Handle the `ENOBUFS` on a OS basis since it could have been implemented
differently (OpenBSD for an example uses `RTM_DESYNC`).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Just some missing ones. Make zebra stop complaining, was getting
some messages from proto2zebra when doing testing, let's clean
that up from happening.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Instead of having global allow_delete move it to
where it belongs in the zrouter data structure.
Additionally show this data in `show zebra`
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When reading a multipath route and we detect an encoding
error from the kernel( yeah I don't think so either ),
let's tell the operator what happened to that route.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There exists a possibility that an end operator has choosen
to compile FRR on an extremely old KERNEL that does not support
the SOL_NETLINK sockopt call. If so let's note it for them
instead of stuff silently not working.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The usage of SOL_NETLINK for adding memberships of interest is
1 group per call. The netink_socket function implied that
the call could be a bitfield of values. This is not correct
at all. This will trip someone else up in the future when
a new value is needed. Let's get it right `now` before
it becomes a problem.
Let's also add a bit of extra code to give operator a better
understanding of what went wrong when a kernel does not
support the option.
Finally as a point of future reference should FRR just switch
over to a loop to add the required loops instead of having
this bastardized approach of some going in one way and some
going in another way?
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The rib_process_dplane_results function was having each
sub function handler process the results and then
free the ctx. Lot's of functionality that needs to remember
to free the context. Let's just free it in the main loop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Add the ability for the netconf dplane code to handle
the global NETCONFA_IFINDEX_DEFAULT and NETCONF_IFINDEX_ALL
values. Then store our interested values when we get
them from the kernel as well as being able to display
them to the end operator.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When Zebra receives the netconf update an afi is passed
let's seperate that out and track the v4/v6 specific data
to save and store appropriately.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The mc_forwarding status for an interface was being sent but not
properly retrieved on the zebra master side of the dplane.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
-> Moved new capabilities needed to under HAVE_DPDK
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
PBR rules are installed as match, action rules in most dataplanes. This
requires the action to be resolved via a GW. And the GW to be subsequently
resolved to {SMAC, DMAC}.
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
Currently specific local neighbors (attached to SVIs) are maintatined
in an EVPN specific database. There is a need to maintain L3 neighbors
for other purposes including MAC resolution for PBR nexthops.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Cleanup compile and fix crash
Signed-off-by: Anuradha Karuppiah <anuradhak@nvidia.com>
'bridge vni add vni <id> dev <vxlan device>'
generates new RTM_NEWTUNNEL and RTM_DELTUNNEL
to add or remove vni to l3vxlan device.
Register new RTNLGRP_TUNNEL group to receive
new netlink notification.
Callback for the new RTM_xxxTUNNEL.
kernel patches:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?h=v5.18-rc7&id=7b8135f4df98b155b23754b6065c157861e268f1
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/
linux.git/commit/?h=v5.18-rc7&id=f9c4bb0b245cee35ef66f75bf409c9573d934cf9
Ticket:#3073812
Testing Done:
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Signed-off-by: Chirag Shah <chirag@nvidia.com>
When a interface is configured with this:
int eva
ipv6 nd ra-interval 5
no ipv6 nd suppress-ra
!
And then subsuquently the interface is created and brought up, FRR
would both error on joining the RA multicast address and never
properly work in this state.
Delay the startup of the join and start of the Router Advertisements
until after the ifindex has actually been found.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
