| Commit message (Collapse) | Author | Files | Lines |
|
Add a header to cleanup no declaration and properly
wrapper some variables to appropriate #ifdef.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
The `top` variable could possibly be used without
any initialization, remove the possibility.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
isis_handle_pdu is called but not declared for usage
by not including the appropriate header.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
We were ignoring mpls labels encapped with static routes.
Added support for single and multipath labels.
Signed-off-by: Stephen Worley <sworley@cumulusnetworks.com>
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
watchfrr needs to handle a SIGCHLD also when it calls a global restart
command. Before this patch, it would lead to the following behavior:
15:44:28: zebra state -> down : unexpected read error: Connection reset by peer
15:44:33: Forked background command [pid 6392]: /usr/sbin/frr.init watchrestart all
15:44:53: Warning: restart all child process 6392 still running after 20 seconds, sending signal 15
15:44:53: waitpid returned status for an unknown child process 6392
15:44:53: background (unknown) process 6392 terminated due to signal 15
15:45:13: Warning: restart all child process 6392 still running after 40 seconds, sending signal 9
15:45:33: Warning: restart all child process 6392 still running after 60 seconds, sending signal 9
15:45:53: Warning: restart all child process 6392 still running after 80 seconds, sending signal 9
15:46:13: Warning: restart all child process 6392 still running after 100 seconds, sending signal 9
15:46:33: Warning: restart all child process 6392 still running after 120 seconds, sending signal 9
15:46:53: Warning: restart all child process 6392 still running after 140 seconds, sending signal 9
This is obviously incorrect and can be fixed by comparing the pid to
the global restart object as well.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
|
|
When we add / remove a nexthop that we need to track,
keep track of the number of times we have done this
for each nexthop. Consequently keep track of the
number of available nexthops, so that we can
just install new routes when we get one
that uses a pre-existing nexthop. Deletion of
nexthops is done on refcount going to 0.
Removal of routes is handled elsewhere for removal.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
The code prior to this change, was allowing clients to register
for nexthop tracking. Then zebra would look up the rnh and
send to that particular client any known data. Additionally
zebra was blindly re-evaluating the rnh for every registration.
This leads to interesting behavior in that all people registered
for that nexthop will get callbacks even if nothing changes.
Modify the code to know if we have evaluated the rnh or not
and if so limit the re-evaluation to when absolutely necessary
This is of particular importance to do because of nht callbacks
for protocols cause those protocols to do not insignificant
work and as more protocols are registering for nht callbacks
we will cause more work than is necessary.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Linux 2.6.0 was released in December of 2003... I'm pretty sure we don't
need this Linux 2.4 support anymore.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
These MIB OIDs were only used to identify clients on the SMUX protocol.
And even for that, they were essentially pointless.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
A nicely-formatted colorful table of all our daemons and target OS'.
Based off & intended to replace / extend
https://github.com/FRRouting/frr/wiki/Features-and-Kernel-Support
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
The problem is seen where speed mismatch caused ECMP route
not being reflected with correct number paths (NHs).
During cold boot, some interface speed updated by zebra as
part of one shot timer and triggers interface add to clients.
In this case, ospf already have created interface (bond interface),
but speed was not updated, trigger to do interface speed change
as part of interface add, which will trigger all Router LSA to
use updated speed into cost calculation.
Ticket:CM-22170
Testing Done:
Bring up CLOS config with Spine and leafs. Leaf have CLAG pair,
with same VRR ip address.
At spine one of the bond connecting to leaf node was having
higher speed than the paired device, With this fix, at spine (DUT)
bond interface speed is equal from all peer nodes.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
Coded as part of #2684 and most code written while participating at
BornHack@2018.
bgp_route.c: Changes regarding adding explanations for the IANA
well-known communities added in #2684
Signed-off-by: Christoffer <netravnen@gmail.com>
|
|
Coded as part of #2684 and most code written while participating at
BornHack@2018.
bgp.rst: Explain what the communities does and a summarized edition of
the communities purpose.
Signed-off-by: Christoffer <netravnen@gmail.com>
|
|
While perusing CONFDATE I noticed that we had a couple
CONFDATE 201805, which we were not picking up( for other
reasons and fixed in a different PR ). But upon investigation
of these I noticed that the commits where in 201805, so these
CONFDATES should be in 2019
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
The ZEBRA_IPV4_ROUTE_[ADD|DELETE] and ZEBRA_IPV6_ROUTE_[ADD|DELETE] functionality
has been deprecated for a year now, let's remove this code from the system.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
The zebra/client_main.c code is not being maintained or used.
Remove from system. Especially since the encode/decode
zapi functionality it `purports` to be testing is deprecated
and now being removed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Memory sizes of the vrf bit-map was insane for a system
with a moderate number of data on it:
Zebra:
VRF bit-map : 601 65536 39391944
Having a full 32bit integer bit space is problematically large,
switch over to a hash to store bit data. We do not need to waste
so much space.
VRF bit-map : 13 8 312
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
|
|
If a command returns a nonzero exit status and VTYSH has a corresponding
command, VTYSH will skip executing its own version. If this happens in a
command that changes CLI nodes we get node desynchronization.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
The master->unused list was unbounded during normal operation.
A full BGP feed on my machine left 11k threads on the unused
list, taking up over 2mb of data. This seemed a bit excessive,
reduce to a limit of 10.
Also fix a crash that this exposed where we assumed that a thread
structure was not deleted.
Future committers can make this configurable? or modify
the value to something better for their system. I am
dubious of the value of this.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
This debug should be moved to an error situation since it's a
developmental escape that needs to be fixed.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
We are using a enum to drive a switch statement and we have
a default case statement that can never be entered because
we know all the enum states have been covered. Remove it
from the code as that it cannot happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
zlog_warn was being used to inform user of impossible situations
or for normal operations. Remove these from the code.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
The smux.c code has not been able to compile for 2+ years
and no-one has noticed. Additionally net-snmp has marked
smux integration as deprecated for quite some time as well.
Since no-one has noticed and it's been broken and smux integration
is deprecated let's just remove this from the code base.
From looking at the code, it sure looks like SNMP could use
a decent cleanup.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Several zlog_warns were being used to tell the end
user that bgp had detected a bug. These all look like information
added during development that can be noted as debugs or logged
as an error situation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
A warn with a backtrace does not need another warn
to file an issue with Quagga, so just remove it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
We were storing Poll data for the read and write
memory information in MTYPE_THREAD, so a show run
would not be able to show actual amount of memory
associated with the `struct thread`.
Remove unnecessary NULL checks on malloc.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Handle Remote Neigh entry state change from Router to Host.
Remote MAC-IP update may not continue EVPN NA Extended community,
Zebra need to accomodate if router_flag change for existing neigh
and install with or without Router Flag (R-bit).
Testing:
Have locally run MAC/IP (neigh entry) with R-bit set,
Checke on remote VTEP 'show bgp evpn route ...mac ip' and
'show evpn arp-cache ...' contians router flag.
Change host to remove R-bit, which locally learnt entry removes
Router flag. This results in remote vtep to remove R-bit from
neigh entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
Neigh update can have router_flag change, from unset to set and
viceversa. This is the case where MAC, IP and VLAN are same but
entry's flag moved from R to not R bit and reverse case.
Router flag change needs to trigger bgpd to inform all evpn peers
to remove from the evpn route.
Testing Done:
Send GARP with and without R bit from host and validate neigh entry
and evpn neigh and mac-ip route entry in zebra and bgpd.
Check Peer VTEP evpn route entry where router flag is (un)set.
With R-bit
Route [2]:[0]:[0]:[48]:[00:1f:2f:db:45:a6]:[128]:[2006:33:33:2::10]
VNI 1001
Imported from
27.0.0.16:5:[2]:[0]:[0]:[48]:[00:1f:2f:db:45:a6]:[128]:[2006:33:33:2::10]
4435 5551
27.0.0.16 from MSP1(uplink-1) (27.0.0.9)
Origin IGP, valid, external, bestpath-from-AS 4435, best
Extended Community: RT:5551:1001 ET:8 ND:Router
Flag
AddPath ID: RX 0, TX 1261
Last update: Wed Aug 15 20:52:14 2018
Without R-bit
Route [2]:[0]:[0]:[48]:[00:1f:2f:db:45:a6]:[128]:[2006:33:33:2::10]
VNI 1001
Imported from
27.0.0.16:5:[2]:[0]:[0]:[48]:[00:1f:2f:db:45:a6]:[128]:[2006:33:33:2::10]
4435 5551
27.0.0.16 from MSP2(uplink-2) (27.0.0.10)
Origin IGP, valid, external, bestpath-from-AS 4435, best
Extended Community: RT:5551:1001 ET:8
AddPath ID: RX 0, TX 1263
Last update: Wed Aug 15 20:53:10 2018
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
The neigh update can come prior to mac add update.
In this case, the mac will be auto created for the vni.
set router flag to local neigh update for mac with auto flag.
The neigh update will be informed to bgpd once local mac is learnt.
Unset router flag if the neigh update comes without the router flag
for an existing neigh entry.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
Scan all bgp vrf instances and respective L3VNI against the VNI which is being configured.
Ticket:CM-21859
Testing Done:
Configure l3vni,
try to configure same vni as l2vni under router bgp, address-family
l2vpn evpn.
The configuration is rejected.
show evpn vni
VNI Type VxLAN IF # MACs # ARPs # Remote VTEPs Tenant VRF
4001 L3 vx-4001 0 0 n/a vrf1
TOR(config)# router bgp 5546
TOR(config-router)# address-family l2vpn evpn
TOR(config-router-af)# vni 4001
% Failed to create VNI
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
|
|
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
|
Root Cause: In the function bgp_show_table(), we are creating a
json object and a json array with the same name as “json_paths”.
First it will create a json object variable "json_paths" pointing
to the memory allocated for the json object. Then it will create
a json array for each bap node rn (if rn->info is available) with
the same name as json_paths. Because of this, json_paths which was
pointing to the memory allocated for the json object earlier, now
will be overwritten with the memory allocated for the json array.
As per the existing code, at the end of each iteration loop of bgp
node, it will deallocate the memory used by the json array and
assigned NULL to the variable json_paths. Since we don’t have the
pointer pointing to the memory allocated for json object, will be
not able to de-allocate the memory, which is a memory leak here.
Fix: Removing this json object since it is never getting used in
this function.
Testing: Reproduced the memory leak with valgrind.
With the fix, memory leak gets resolved and checked with valgrind.
Signed-off-by: Sarita Patra saritap@vmware.com
|
|
This roughly outlines when to use which logging function. It's
certainly something to have to point people to, so they get things nice
and right - and so we get at least somewhat consistent behaviour for the
user.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
|
|
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
|
|
In some situations rtrlib does not release the locks for its internal
data structures before calling a callback. This can lead to deadlocks
when a lot of routes must be revalidated because the sync socket buffer
will fill up and block the rtrlib thread. The bgpd main thread then
waits for rtrlibs internal locks to be released indefinitely.
This is fixed by using nonblocking sockets instead of blocking ones and
setting a flag to revalidate everything, if it would block.
Signed-off-by: Marcel Röthke <marcel.roethke@haw-hamburg.de>
|
|
* Added parameter in bgp_redistribute_set() to indicate change
in redistribute option
* If there is change, call bgp_redistribute_unreg() to withdraw routes
Signed-off-by: kssoman <somanks@vmware.com>
|
|
Modify stream.c to have stream_new call one malloc call
instead of two. Also change stream_resize_orig to
use stream_resize_inplace and to send an error
to the developer to switch over.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Switch code and tests to use new stream_resize_inplace functionality.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Start setup for handling of stream_resize into old
and new functions.
Create a stream_resize_inplace function that takes
a double pointer to allow for a realloc operation
to return the possibly moved pointer.
Add a CONFDATE for removal as well.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
|
|
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
Table identifier is not read if table id marker is not set.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
this function had to be used only inside zebra ( this was written in the
header vrf.h). To keep the functionality, a more generic API is used.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
The function handles not a vrf pointer instead of a vrf_id value.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
|
|
When pimd is getting terminated, pim_upstream_del() gets called as
part of cleaning process. pim_upstream_del() deletes the route and
assigns NULL to the up->channel_oil. It also deletes each if_channel
by calling the function pim_ifchannel_delete().
pim_ifchannel_delete() internally calls the caller function pim_upstream_del(),
if it is the last ifchannel for that upstream. So pim_upstream_del
is getting called twice, which will access the up->channel_oil which
was already set to NULL before. This results in crash.
Fix:
pim_ifchannel_delete() should call pim_upstream_del (caller function)
only if the up->ref_count > 0. Added an assert(up->ref_count > 0) in
the function pim_upstream_del().
Signed-off-by: Sarita Patra <saritap@vmware.com>
|
|
Make the wart slightly less bad... also there is still a possible write
after free here. This needs to be fixed again, properly, by some
structure changes.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
e.g.
pimd/pim_oil.c: In function ‘pim_channel_oil_dump’:
pimd/pim_oil.c:51:19: error: ‘%d’ directive writing between 1 and 11 bytes into a region of size 10 [-Werror=format-overflow=]
Build on gcc-8.2.0 is warning-free after this patch.
Signed-off-by: David Lamparter <equinox@diac24.net>
|
|
This generates a warning on gcc versions before 7.0.
Signed-off-by: David Lamparter <equinox@diac24.net>
|