-Werror=sign-compare is failing with signed/unsigned usage
in the conditional expression.
Fixes: #1593
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The multithreading code has a comment that reads:
"XXX: Heavy abuse of stream API. This needs a ring buffer."
This patch makes the relevant code use a ring buffer.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The bgpTimerUp value was incorrectly named, add
a correct name bgpTimerUpMsec and add some
code to allow for deprecation.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
For some reason bgp is calculating the peer uptime
in miliseconds incorrectly. Additionally we have
the peer_uptime function call that should be doing this!
But since we've choosen different names for the json output
we cannot fix it at this point.
uptime contains the number of seconds of uptime here. Just
multiply by 1k and display that( as peer_uptime does )
Fixes: #1585
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Problems reported with inconsistent use of parameters for bgp network
statements. Converted 12 DEFUNs to 2 DEFPY statements, making the
parameter use consistent with the exception of keeping the "backdoor"
keywork ipv4 only. Also verified that if a route-map or label-index
is specified in the "no" case it matches what had been previously
defined. Manual testing looks good and bgp-smoke will be performed
before pushing.
Ticket: CM-16860
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Reviewed-by: CCR-7056
The json code was freeing json_paths and then
turning around and free'ing it again. Newer
versions of json-c have started to assert
this bad behavior.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
- used @sharpd's slack patch as a starting point
- fixes compile time issue, but code path not tested
Signed-off-by: Raymond P. Burkholder <github@oneunified.net>
Was using 0 as a sentinel value, so user couldn't configure 0 as the
value of the coalesce timer.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
EVPN is only enabled when user configures advertise-all-vni.
All VNIs (L2 and L3) should be cleared upon removal of this config.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
When we receive an MP_UNREACH,
we try to uninstall routes from the VRF and the VNI.
The route-node in the VRF corresponds
to the ip prefix formed from EVPN prefix.
We should correctly form the prefix based on the EVPN route-type.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
for EVPN routes prefixlen filed in struct prefix
represents the sizeof of the struct rather than the actual prefix len.
This is later used in looking up route node in RIB.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
CLI config for enabling/disabling type-5 routes
router bgp <as> vrf <vrf>
address-family l2vpn evpn
[no] advertise <ipv4|ipv6|both>
loop through all the routes in VRF instance and advertise/withdraw
all ip routes as type-5 routes in default instance.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
For EVPN type-5 route the NH in the NLRI is set to the local tunnel ip.
This information has to be obtained from kernel notification.
We need to pass this info from zebra to bgp in l3vni call flow.
This patch doesn't handle the tunnel-ip change.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
1. VRF RD can be auto-derived (simillar to RD for a VNI)
2. VRF RD can be configured manually through a config
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
currently, we have a rd_id bitfield
to assign an unique index for auto RD.
This bitfield currently resides under struct bgp which seems wrong.
We need to shift this to a global space
as this ID space is really global per box.
One more reason to keep it at a global data structure is,
the ID space could be used by both VNIs and VRFs.
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
BGP VRF can be created/deleted either via config or via l3vni add/del.
We need to handle various sequences.
1. If user config is presented, an l3vni del should not delete the vrf instance
2. do not write bgp config in show running for auto created vrf
2. If l3vni present, disallow the cli for deleting bgp vrf instance
3. If l3vni is added and vrf config is present set the flags properly
4. if bgp vrf is configured unset the AUTO flag
Ticket: CM-18630
Review: CCR-6906
Testing: Manual
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Currently, kernel doesn't support ipv6 routes with ipv4 nexthops.
To avoid the crash,
we will only attach l3-vni related
RTs/ecommunities only to ipv4 host routes.
Ticket: CM-18743
Review: ccr-6912
Testing: Manaul
Signed-off-by: Mitesh Kanjariya <mitesh@cumulusnetworks.com>
Handle the return value of argv_find_and_parse_afi() to avoid passing
along bad values.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This is a possible buffer overflow.
We should always use the buffer size (whenever possible) to tell
functions what the size of the buffer is, instead of a hardcoded value.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
When bgp has a metric butt-load of routes w/ ecmp, this command
can take an inordinate amount of time to run and complete via
vtysh.
Converting the bgp route output in this case back to not
using the json pretty-print drops ~2 minutes of runtime
off.
It is assumed that if users would like pretty output they
can run it through an appropriate tool via a pipe command.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The prefix_rd2str uses a buffer size of RD_ADDRSTRLEN.
Modify the code to consistently use this for all of BGP.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Make prefix_rd2str return an "Unknown" string when something
goes wrong. This will allow for simplification of the
code that uses prefix_rd2str.
Additionally ensure that size is big enough with an assert.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Ignoring the return from argv_find_and_parse_afi
makes the SA system assume that you could pass a AFI_MAX
value to bgp_show_route. Which in turn would cause
an array out of bounds read.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
PREFIX_STRLEN is the correct length for buffers needed to output
a prefix2str. Additionally cleanup some setting of the last
value to a `\0` this is handled by prefix2str.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Since coalesce time is now heuristically adjusted based on peer count,
we need to separate out specific configuration by the user from the
current value. Behavior established is to not adjust if the user has a
value set.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
If we ever turn off assertion for production builds
this code as written will cause a crash in that
the assignment will not happen.
Modify the code such that this erroneous assumption
cannot happen.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Some of the deprecated stream.h macros see such little use that we may
as well just remove them and use the non-deprecated macros.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
With the way things are set up, this bit of code would never actually
cause a deadlock, but would be highly likely in the future.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
If we are in OpenSent or OpenConfirm peer state and we receive a new
address-family activation, we would end up ignoring the new activation
and not tell our peer about it. You could notice this by seeing
the fact that a 'show bgp neighbor' command returns a 'Not in
any update group' for a particular family.
This modifies the code such that we now notice that we are in
either OpenSent or OpenConfirm state and reset the peer to
allow us to send them the new capability.
Ticket: CM-19021
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
After a batch of generated UPDATEs, call bgp_writes_on() once instead of
after generating each packet.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
The subgroup coalesce timer controls how long updates to a particular
subgroup are delayed in order to allow additional peers to join the
subgroup. Presently the timer value is 200 ms. Increase it to 1 second
and adjust up as peers are configured, with an upper cap at 10s.
This cuts convergence time by a factor of 3 at large scale (300+ peers,
1000+ prefixes per peer).
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
This is necessary because otherwise between the time we wipe the output
buffer and the time we push the NOTIFY onto it, the KA generation thread
could have pushed a KEEPALIVE in the middle.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
In the same vein as the round-robin input commit, this re-adds logic for
limiting the amount of time spent generating UPDATEs per generation
cycle. Missed this when shifting around wpkt_quanta; prior to MT it
limited both calls to write() as well as UPDATE generation.
Unfortunately, batching input processing severely impacts BGP initial
convergence times. As a consequence of the way update-groups were
implemented, advancing the state of the routing table based on prefixes
learned from one peer prior to all (or at least most) peers establishing
connections will cause us to start generating outbound UPDATEs, which is
a very expensive operation at present. This intensive processing starves
out bgp_accept(), delaying connection of additional peers. When
additional peers do connect the problem gets worse and worse, yielding
approximately exponential growth in convergence time dependent on both
peering and prefix counts. This behavior is present pre-multithreading
as well, but batched input exacerbates it.
Round-robin input processing marginally harms convergence times for
small topologies but should allow much larger topologies to function
within reasonable performance thresholds.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Different places scheduling the same thread should use the same
semantics and thread type. Additionally providing the back reference
here makes sure we only schedule the job once and avoids flooding the
event queue with jobs to process an empty buffer.
Apparently I didn't fully understand how subgroup packets make their way
out to individual peers. Turns out (on the base branch) we just busy
poll while waiting for packets to make their way onto subgroup queues.
While this needs to be fixed in the future, for now readding this logic
fixes performance issues with convergence.
Instead of checking whether the post-write number of updates sent was
greater than the pre-write number of updates sent, it was comparing post
to zero. In effect this meant every time we wrote a packet it was
counted as an update for route advertisement timer purposes.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
During initial session establishment, bgpd performs a "connection
transfer" to a new peer struct if the connection was initiated passively
(i.e. by the remote peer). With the addition of buffered input and a
reorganized packet processor, the following race condition manifests:
1. Remote peer initiates a connection. After exchanging OPEN messages,
we send them a KEEPALIVE. They send us a KEEPALIVE followed by
10,000 UPDATE messages. The I/O thread pushes these onto our local
peer's input buffer and schedules a packet processing job on the
main thread.
2. The packet job runs and processes the KEEPALIVE, which completes the
handshake on our end. As part of transferring to ESTABLISHED we
transfer all peer state to a new struct, as mentioned. Upon returning
from the KEEPALIVE processing routing, the peer context we had has
now been destroyed. We notice this and stop processing. Meanwhile
10k UPDATE messages are sitting on the input buffer.
3. N seconds later, the remote peer sends us a KEEPALIVE. The I/O thread
schedules another process job, which finds 10k UPDATEs waiting for
it. Convergence is achieved, but has been delayed by the value of the
KEEPALIVE timer.
The racey part is that if the remote peer takes a little bit of time to
send UPDATEs after KEEPALIVEs -- somewhere on the order of a few hundred
milliseconds -- we complete the transfer successfully and the packet
processing job is scheduled on the new peer upon arrival of the UPDATE
messages. Yuck.
The solution is to schedule a packet processing job on the new peer
struct after transferring state.
Lengthy commit message in case someone has to debug similar problems in
the future...
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
During initial session establishment, bgpd performs a "connection
transfer" to a new peer struct if the connection was initiated passively
(i.e. by the remote peer). With the addition of buffered input, I forgot
to transfer the raw input buffer to the new peer. This resulted in
infrequent failures during session handshaking whereby half of a packet
would be thrown away in the middle of a read causing us to send a NOTIFY
for an unsynchronized header. Usually the transfer coincided with a
clean input buffer, hence why it only showed up once in a while.
At some point when rearranging FSM code, bgpd lost the ability to
perform active opens because it was only paying attention to POLLIN and
not POLLOUT, when the latter is used to signify a successful connection
in the active case.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
Use best-performing memory orders where appropriate.
Also update some style and add missing comments.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
