Add a public reset api, so a context can be reset and reused;
add apis to init a context for a route or mac update.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
Instead of retuning always `0`, lets return the amount of used bytes for
the message. This will be used by the new FPM interface to know how many
bytes we must reserve for the output buffer.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
* Use `inet_ntop` instead of `inet_ntoa`
* Replace function name with `__func__`
* Inline functions
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Generalize the netlink route message building function so it can be used
in the future by the netlink Forwarding Plane Manager (FPM) interface.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
ospf_opaque_self_originated_lsa_received decrements refcount which can
result in a free, this is followed by a call to ospf_ls_ack_send which
accesses the freed LSA
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Something in there is wrong and causing test failures. Moving it back to
how it was; we'll stil assert if the message was wrong, just in a
different place now.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
I'd like to keep the explicit check here, but since underlying type of
enum is implementation defined, theres some inconsistency using -Wall
-Werror in older compilers here
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This fixes a theoretical bug that could occur when trying to change an
ifindex on an interface to that of an existing interface. We would
remove the interface from the ifindex tree, and change the ifindex, but
when we tried to reinsert the interface, the insert would fail. It was
impossible to know if this failed due to the insertion / deletion macros
capturing the result value of the underlying BSD tree macros. So we
would effectively delete the interface.
Instead of failing on insert, we just check if the prospective ifindex
already exists and return -1 if it does.
Macros have been changed to statement expressions so the result can be
checked, and bubbled up.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* Don't crash if we get a request to create an existing VRF
* Ensure interface & vrf names are null terminated...again
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
If Zebra sends us an interface add notification with a garbage VRF we
crash on an assert(vrf_get(vrf_id, NULL)); let's not
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
With the command using STR_SHARP, the sharp daemon is not allowed
to use it's own routes for label modification. Switching over
to STR_ZEBRA allows the sharp daemon to modify labels on any
route in the system, since there are no `ROUTE_ZEBRA` types.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Issue: no ip msdp mesh-group <word> source command
deleting the mesh group, which might be used by the member.
Solution: no ip msdp mesh-group <word> source command, deletes
the mesh-group source.
Add a new cli command "no ip msdp mesh-group <word>" to delete
the mesh group.
Signed-off-by: Sarita Patra <saritap@vmware.com>
In some places we log the interface but not the vfr the
interface is in. In others we only output the vrf id, which
can be difficult for human to read. This commit makes zebra
debugs more vrf aware.
Signed-off-by: Jakub Urbańczyk <xthaid@gmail.com>
Issue:
For consecutive messages such as
MAC1 -> VTEP1 add
MAC1 -> VTEP2 add
MAC1 -> VTEP1 add
Final state, i.e. (MAC1 -> VTEP1 add) should be sent via FPM.
But, with current code, FPM will send (MAC1 -> VTEP2 add)
RCA:
When FPM receives (MAC1, VTEP1), it stores it in the FPM processing queue and
hash table.
When FPM receives (MAC1, VTEP2), this entry is stored as another node as hash
table key is (mac, vtep and vni)
IF FPM again receives (MAC1, VTEP1), we fetch this node in the hash table
which is already enqueued.
When the FPM queue is processed, we will send FPM message for (MAC1, VTEP1)
first and then for (MAC1, VTEP2)
This sequencing issue happened because the key of the table is (MAC, VTEP, VNI)
Fix:
Change the key of the hash table to (MAC, VNI)
So, every time we receive a new update for (MAC1, VNI1), we will find a node in
the processing queue corresponding to MAC1 if present.
We will update this same node for every operation related to (MAC1, VNI1)
Thus, at the time when FPM processes this node, it will have latest MAC1 info.
Signed-off-by: Ameya Dharkar <adharkar@vmware.com>
According to the RFC 5880 the transmission time should be mandated by
the slowest system.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Lets avoid garbage data on packets by zeroing the packet before setting
the fields/flags.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
