This was causing some weird prefixes to pop up in my log files. One
alternate solution would be to call apply_mask() on the prefix, but
memcpy() is faster and just enough in this case.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* use %u instead of %d, we don't want to print negative labels;
* increase the size of label_buf to accommodate the worst case scenarios;
* use strlcat() instead of strcat() as a security best practice.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
MAC entries are internally created for purposes such as when a local
neighbor is learnt but the MAC itself is not yet learnt. Such MACs are
not "real", so ensure they are not counted for UI output.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Ticket: CM-17991
Reviewed By: None
Testing Done: Manual, evpn-smoke
Fix following flaws that resulted in EVPN with L3 multi-tenancy (i.e.,
EVPN dealing with VxLAN routing in the presence of tenant VRFs) not
working properly:
1. EVPN enable ("advertise-all-vni") is a global command, ensure it is
accordingly processed. The config is maintained against the default VRF.
2. There was an incorrect attempt to derive the L3 VRF for L2 interfaces
- the VRF only applies for L3 interfaces, though the code may initialize
to the default value in other cases.
3. Functions to map (port, VLAN) to SVI or vice versa were incorrect -
particularly, zvni_map_svi() since it was looking in the L3 VRF for
"matching" L2 interface which it would never find. Fix.
In addition, since the 'zebra_vrf *' parameter is not relevant in most
places, it has been removed.
Signed-off-by: Vivek Venkatraman <vivek@cumulusnetworks.com>
Reviewed-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Reviewed-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ticket: CM-17840
Reviewed By: CCR-6685
Testing Done: evpn-smoke, various manual tests
Problem reported when a table entry originated by rdnbrd was moved from one
interface to another on the same switch. Both would be deleted, leaving
no imported entry in the table. Modified zebra_add_import_table_entry to
used rib_add_multipath as well as correct the call to delete a duplicate
entry to include the nexthop associated with the route_entry.
Ticket: CM-18154
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed By: CCR-6731
Testing Done: Manual testing successful, deb given to submitter, bgp-smoke
had no new failures
list_free is occassionally being used to delete the
list and accidently not deleting all the nodes.
We keep running across this usage pattern. Let's
remove the temptation and only allow list_delete
to handle list deletion.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Convert the list_delete(struct list *) function to use
struct list **. This is to allow the list pointer to be nulled.
I keep running into uses of this list_delete function where we
forget to set the returned pointer to NULL and attempt to use
it and then experience a crash, usually after the developer
has long since left the building.
Let's make the api explicit in it setting the list pointer
to null.
Cynical Prediction: This code will expose a attempt
to use the NULL'ed list pointer in some obscure bit
of code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The zebra_ptm_finish() code was being called before the
client_list deletion. The client_list deletion is
attempting to call the ptm daemon and shut down the connection.
We should not be doing this *after* we shut down memory associated
with it as that we were writing into memory in random spots
in this case.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The adata pointer was not properly being set to
0 before being used. In addition notice malloc
failure and hard exit. If we have no memory on
startup something terrible has gone wrong and
we were going to crash shortly here anyways.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Current cleanup is for unset values or variables that are not used anymore.
Regarding ospfd/ospf_vty.c: argv_find()
we'll never get it NULL, so get coststr = argv[idx]->arg;
irdp is crashing because it assumes that people have
configured it in a certain way. Ensure that this
'way' is honored at least enough so that we don't
crash.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
This is a continuation of 915902cb82. Basically the netlink
read of messages up from the kernel is now noticing the proper
owner of the route. As such when rib_delete was being called
as part of the upcall from the kernel we were not noticing that
we were the originator and not diss-allowing the rib_delete
from happening. This restores this behavior that we were getting
pre-915902cb82cfd
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
While u_char is technically a uint8_t in size I would
like to treat and think about the admin distance
as an actual integer value from 0-255, instead
of a char.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For ZEBRA_ROUTE_KERNEL types:
The metric/priority of the route received from the kernel
is a 32 bit number. We are going to interpret the high
order byte as the Admin Distance and the low order 3 bytes
as the metric.
This will allow us to do two things:
1) Allow the creation of kernel routes that can be
overridden by zebra.
2) Allow the old behavior for 'most' kernel route types
if a user enters 'ip route ...' v4 routes get a metric
of 0 and v6 routes get a metric of 1024. Both of these
values will end up with a admin distance of 0, which
will cause them to win for the purposes of zebra.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
If we have already scheduled a node to be on the meta_queue, there is no
need to schedule it up again.
On startup we are calling rib_update() multiple times per connected route.
Due to the multiple ways we can get callbacks for adding a connected route
I decided it was best to just improve meta_queue performance as opposed
to trying to figure out all the different ways across all the platforms
that we can decide that a connected route has changed. This appears
to solve the issue with a very large # of interfaces coming up
at the same time on startup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Both function were very similar, and as we know code duplication is not
good. As an example, in the past couple of weeks some fixes were made
on rib_add() but not on rib_add_multipath(), causing known bugs to still
exist in a different form.
Instead of merging the two functions into one, let's make rib_add()
call rib_add_multipath() with the appropriate parameters. This way we
remove the code duplication but still keep the easy-to-use rib_add()
function for single-path routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Fixes the following bug:
% ip route add 50.0.0.0/8 nexthop via 10.0.1.2 nexthop via 10.0.2.2
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.3 nexthop via 10.0.2.3
% ip route replace 50.0.0.0/8 nexthop via 10.0.1.4 nexthop via 10.0.2.4
%
% vtysh -c "show ip route"
[snip]
K * 50.0.0.0/8 [0/0] via 10.0.1.4, rt1-eth1, 00:00:00
* via 10.0.2.4, rt1-eth2, 00:00:00
K * 50.0.0.0/8 [0/0] via 10.0.1.3, rt1-eth1, 00:00:10
* via 10.0.2.3, rt1-eth2, 00:00:10
K>* 50.0.0.0/8 [0/0] via 10.0.1.2, rt1-eth1, 00:00:24
* via 10.0.2.2, rt1-eth2, 00:00:24
Commit a3d18ce6 fixed a similar problem for single-path routes.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Commit f19435a8 fixed rib_add() but didn't fix rib_add_multipath().
While here, remove the unnecessary 'same->table == re->table' check as
it always evaluate to true.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
On shutdown we were deleting the linked list that
kept the zclient connections, but we were not
freeing the data pointed at by the link list.
This modification allows the normal cleanup of the
linked list to cleanup the zclient data structure.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Static routes were not keeping track of uptime appopriately and
as such we were not properly displaying uptime.
Fixes: #1196
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
