Type-7 LSAs and their corresponding Type-5 LSAs don't share the same
LS IDs (unlike in the case of OSPFv2). As such, do not attempt to find
a translated Type-5 LSA using the LS ID of a Type-7 LSA. Instead,
use the LS-ID stored in the OSPF routing table.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This commits consists of several changes that positively impact
code reability without introducing any logical change.
Summary of the changes:
* Return earlier in ospf6_abr_range_update() in order to reduce one
level of indentation;
* Remove ospf6_translated_nssa_originate() since it's nothing other
than a useless wrapper around ospf6_lsa_translated_nssa_new();
* Change ospf6_abr_translate_nssa() to return void;
* Change ospf6_abr_process_nssa_translates() checking for NSSA areas
before anything else;
* Remove ospf6_abr_remove_unapproved_translates_apply() since it's a
small function that is only called in one place;
* Change ospf6_abr_check_translate_nssa() to avoid an LSDB lookup when
the router isn't an ABR.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In addition to being unnecessary, this check is problematic for the
upcoming NSSA ranges feature since NSSA ranges aren't added to the
OSPF routing table. Remove this for simplicity.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
This code tries to summarize NSSA Type-7 LSAs using normal ranges
which are intended to summarize Type-3 LSAs only. This is not only
wrong, but the code is incomplete and lacking lots of things. Better
to remove it before implementing NSSA ranges correctly.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The iteration performed on ospf6_abr_unapprove_translates() was
wrong since AS-external LSAs are stored in the global LSDB and not
in the area LSDBs. As such, the "unapproved" flag wasn't being set
in any translated AS-external LSA, leading them to linger forever.
Fix the LSDB iteration and make the required changes to unset the
"unapproved" flag for AS-external LSAs that shouldn't be removed.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
The ABR task already takes care of refreshing translated Type-5
LSAs that correspond to self-originated Type-7 LSAs. There's no
need to do that in ospf_external_lsa_install() as well. The ospfd
NSSA code takes the same precaution.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Change ospf6_get_nssa_fwd_addr() to try finding a global address
on any interface of the area and not on the first one only.
Additionally, do a micro-optimization in
ospf6_interface_get_global_address() to return as soon as a global
address is found.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Every received or originated LSA is automatically scheduled to be
refreshed periodically, there's no need to do that manually here.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Document the `sleep` statement so people know that we are sleeping
because we are waiting for the BFD down notification. If we don't
sleep here it is possible that we get outdated `show` command results.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Call the `show` commands less often to reduce the CPU pressure.
Also increase the wait time from 60 to 80 seconds to have spare room
for failures (4 times more). This is the latest measure wait time:
> INFO: topolog: 'router_json_cmp' succeeded after 20.08 seconds
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Reduce timers so we send hello packets more often and reduce dead
interval to converge faster.
Previous test wait amount:
> INFO: topolog: 'router_json_cmp' succeeded after 47.20 seconds
New test wait amount:
> INFO: topolog: 'router_json_cmp' succeeded after 20.08 seconds
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Currently, it is possible to configure IPv6 protocols for IPv4
redistribution and vice versa in CLI. The YANG model doesn't allow this
so the user receives the following error:
```
nfware(config-router)# redistribute ipv4 ospf6 level-1
% Failed to edit configuration.
YANG error(s):
Invalid enumeration value "ospf6".
Invalid enumeration value "ospf6".
Invalid enumeration value "ospf6".
YANG path: Schema location /frr-isisd:isis/instance/redistribute/ipv4/protocol.
```
Let's make CLI more user-friendly and allow only supported protocols in
redistribution commands.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
`yang_dnode_get` will `assert` if no YANG node/model exist, so lets test for
its existence first before trying to access it.
This `assert` is only acceptable for internal FRR usage otherwise we
might miss typos or unmatching YANG models nodes/leaves. For gRPC usage
we should let users attempt to use non existing models without
`assert`ing.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Description:
When grace lsa received, DUT is adding
the copy of the lsas to all nbrs retransmission list as part of
flooding procedure and subsequently incrementing the rmt counter in
the original the LSA. This counter is supposed to be decremented
when ack is received by nbr and the lsa will be removed from retransmission list.
But in our current scenario,
Step-1:
When GR helper is disabled, if DUT receives the grace lsa
it adds the lsa copy to nbrs retransmission list but original
LSA will be discarded since GR helper disabled.
Step-2:
GR helper enabled and DUT receives the grace lsa, as part
of flooding process all nbrs have same copy of lsa in their
corresponding rmt list which was added in step -1 due to this
the corresponding rmt counter in the original lsa is not getting
incremented.
Step-3:
If the same copy of the grace lsa received by DUT, It considers
as implicit ack from nbr if the same copy of the lsa exits in its
rmt list and subsequently decrement the rmt counter.
Since counter is zero (because of step-1 and 2) , it is asserting while decrement.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
No functional difference, but `length "0"` is more comprehensible.
Suggested-by: Christian Hopps <chopps@labn.net>
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Extend the pathd documentation with more configuration examples, more
detailed and some graphics to help understand what pathd supports.
Signed-off-by: Javier Garcia <rampxxxx@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
FRR should only ever use the appropriate THREAD_ON/THREAD_OFF
semantics. This is espacially true for the functions we
end up calling the thread for.
Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
The lsa->expire thread is for keeping track of when we
are expecting to expire(remove/delete) a lsa. There
are situations where we just decide to straight up
delete the lsa, but we are not ensuring that the
lsa is not already setup for expiration.
In that case just stop the expiry thread and
do the deletion.
Additionally there was a case where ospf6d was
just dropping the fact that a thread was already
scheduled for expiration. In that case we
should just setup the timer again and it will
reset it appropriately.
Fixes: #9721
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
