domainname is a merge conflict: it is duplicated, so delete it.
bgp content is a compille warning and wrongly display, so fix it.
Signed-off-by: anlancs <anlan_cs@tom.com>
When OSPFv3 router is configured in both default and non-default VRFs,
every packet destined to a non-default VRF is read twice. This makes it
impossible to establish neighborship because every DbDesc packet is
treated as duplicated and we end up infinitely exchanging DbDescs.
We should drop packets received in the default VRF if an interface we
received it on is bound to another VRF.
Same thing was done for OSPFv2 in 555691e.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Adding a `\n' should now produce a warning. Controlled by `-Werror` so
if you're doing a dev build and it's warning about some `prefix2str`
that should be converted to `%pFX`, you can turn off `-Werror` to fix it
later like with all other warnings.
Signed-off-by: David Lamparter <equinox@diac24.net>
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>
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>
