This might be faster if at some point in the future the Linux vDSO
supports CLOCK_THREAD_CPUTIME_ID without making a syscall. (Same
applies for other OSes.)
Signed-off-by: David Lamparter <equinox@diac24.net>
...really no reason to force this into a compile time decision. The
only point is avoiding the getrusage() syscall, which can easily be a
runtime decision.
[v2: also split cputime & walltime limits]
Signed-off-by: David Lamparter <equinox@diac24.net>
This option does literally nothing. Not sure since when, but the value
is not used anywhere at all.
Signed-off-by: David Lamparter <equinox@diac24.net>
Problem Statement:
==================
Max aged LSAs are not getting deleted from DB when there are multiple
neighbors in a LAN.
Root Cause Analysis:
====================
When the LSA is added to the neighbor's retransmit list, the LSA retrans count
is incremented but it is not checked if the LSA is already present in the
retransmit list leading to the count being incremented multiple times
untill the ack is not received and when the ack is received the count is
decremented once and hence the count never becomes 0 and
it remains in the DB forever.
Fix:
====================
Do not increment the retrans count multiple times if the LSA is already
present in the retransmit list of the neighbor. Also do not add the LSA
in the retransmit List if already present.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Based in RFC 5440 @4.2.2 ""...after a no-path , the pcc may decide" and RFC
8231 #5.8.3 "... pcc must not set PcReq after path is delegated"
So will not (try) to delegate the path with no-path neither must do
further retries.
Signed-off-by: Javier Garcia <javier.garcia@voltanet.io>
When using frr-reload.py to modify a bgp neighbors route-map
the code was doing this:
a) deleting the previous route-map: `no neighbor XX route-map YY (in|out)`
b) Adding the new route-map back in `neighbor XX route-may ZZ (in|out)`
Now imagine that we have an outgoing route-map that we are changing
and the reload is large because of a large number of lines in frr.conf
Item (a) will happen. BGP will immediately start sending all local
routes. At some point in time in the future (b) will be applied.
This of course causes a withdraw but for a short amount of time we
are leaking unintended routes. This is bad for several reasons
not 1) route churn upstream, 2) we might influence traffic to go the
wrong way. 3) if upstream has a maximum-prefix command the routes
being sent might trip its circuitry and shutdown the peer entirely
not even allowing you to get to (b).
Ticket: #2589685
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
There are two checks done when configuring ldp-sync on an interface:
- interface is not a loopback
- interface is in the default VRF
Both checks are incorrectly done using the operational data.
The second check can be done using only config data - do that.
The first check can't be done using only configurational data, but it's
not necessary. LDP sync code doesn't operate on loopback interfaces
already. There's no harm in allowing this to be configured.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Don't rely on operational data to validate that configuration is applied
to the default VRF. The VRF name is stored in the config - use it instead.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Don't rely on operational data to check for system ID consistency. This
is purely configurational data thing.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The SR node is hidden by a `--enable-pathd` configuration option.
But the recent commit of SRv6 uses this node as well. Let's expose
this node and let things work.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
=================
When show ipv6 ospf6 neighbor is executed each neighbor gets
displayed twice.
frr# show ipv6 ospf6 neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
1.1.1.1 1 00:00:39 Full/DR 00:00:10 ens192[BDR]
1.1.1.1 1 00:00:39 Full/DR 00:00:10 ens192[BDR]
RCA:
====
Since ospf6_interface gets added twice to if_list we see multiple
display output.
Fix:
====
add ospf6_interface to if_list only when newly area gets attached
to the interface. If its already added no need to add it again.
Risk:
=====
Low
Tests Executed:
===============
Have tested the defect scenario.
frr# show ipv6 ospf6 neighbor
Neighbor ID Pri DeadTime State/IfState Duration I/F[State]
1.1.1.1 1 00:00:35 Full/DR 00:36:04 ens192[BDR]
frr#
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
ospf6_asbr_redistribute_unset must not be called if the redistribution
is not yet configured, because it decrements redistribution counter and
makes it negative in this case.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
We are passing around the system id using the variable name
of `argv`. Let's name the variable correctly and pass it around
correctly named.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
in lsp_for_arg we have already checked for NULL and returned
if argv is null. We do not need to check for it again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The initial idea was to deny prepending and just use _self_.
This patch at least allows prepending aspath with route-maps, but drops
all non-self ASNs in the path.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
