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>
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>
1) Do not explicitly set the thread pointer to NULL.
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.
2) Fix mixup of `struct eigrp_interface` and `struct eigrp`
usage of the same thread pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Do not explicitly set the thread pointer to NULL.
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: Donald Sharp <sharpd@nvidia.com>
1) Remove `struct thread *` pointers that are never used
2) Do not explicitly set the thread pointer to NULL.
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: Donald Sharp <sharpd@nvidia.com>
Description:
As per the RFC 3623 section 3.2,
OSPF nbr shouldn't be deleted even in unsuccessful helper exit.
1. Made the changes to keep neighbour even after exit.
2. Restart the dead timer after expiry in helper. Otherwise, Restarter
will be in FULL state in helper forever until it receives the 'hello'.
Signed-off-by: Rajesh Girada <rgirada@vmware.com>
When a regular access-list is updated, we should update references to
regular access-lists, not as-path access-lists.
Fixes#9707.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
