This fix will delete an OSPFv3 area when all the interfaces and
configuration (ranges, NSSA ranges, stub area, NSSA area, filter-list,
import-list and export-list) have been removed. The changes provides
a general solution to https://github.com/FRRouting/frr/issues/18324.
Signed-off-by: Acee Lindem <acee@lindem.com>
In preperation for Extended LSA types and their TLVs, factor out the TLV
handling from the Gracefull Restart functionality.
Signed-off-by: Andrew Cooks <acooks.at.bda@gmail.com>
interface_up also handles changes to the interface type, i.e. broadcast
to ptp to ptmp. Connected routes for these are different and must be
readvertised, which is done in ospf6_interface_recalculate_cost() - but
only if the cost changed. Use the force variant here.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
The code emitting connected routes was checking against the interface
state (which can also be lo/ptp/ptmp) rather than the interface type.
This was causing wrong IA prefixes for connected routes getting put up
out if the interface was down intermittently.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
clang-format doesn't understand `DEFUN` and formats it rather ugly.
Standard approach was to skip these in clang-format, which hasn't
happened here sadly.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Replace `struct list *` with `DLIST(if_connected, ...)`.
NB: while converting this, I found multiple places using connected
prefixes assuming they were IPv4 without checking:
- vrrpd/vrrp.c: vrrp_socket()
- zebra/irdp_interface.c: irdp_get_prefix(), irdp_if_start(),
irdp_advert_off()
(these fixes are really hard to split off into separate commits as that
would require going back and reapplying the change but with the old list
handling)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
...so that multiple functions can be subscribed.
The create/destroy hooks are renamed to real/unreal because that's what
they *actually* signal.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
https://www.rfc-editor.org/rfc/rfc5340.html#page-37 states:
If the interface type is point-
to-multipoint or the interface is in the state Loopback, the
global scope IPv6 addresses associated with the interface (if any)
are copied into the intra-area-prefix-LSA with the PrefixOptions
LA-bit set, the PrefixLength set to 128, and the metric set to 0.
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
To announce connected prefixes, or not to announce connected prefixes,
that is the question...
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds the PtMP interface type, which is effectively identical to PtP
except that all the database flooding & updates are unicast.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Some lower layers still don't handle multicast correctly (or
efficiently.) Add option to send unicast hellos on explicitly
configured neighbors for PtP/PtMP.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
With the configured neighbor list, unicast hellos can be sent. Allow
disabling multicast hellos for that scenario.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This adds a knob to refuse forming adjacencies with neighbors not listed
in the config. Only works on PtP/PtMP of course, otherwise the DR/BDR
machinery gets broken.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Both for virtual links and correct PtMP operation, advertising local
addresses as Intra-Prefix with LA set is a prerequisite. Add the
appropriate entries.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Include an event ptr-to-ptr in the event_execute() api
call, like the various schedule api calls. This allows the
execute() api to cancel an existing scheduled task if that
task is being executed inline.
Signed-off-by: Mark Stapp <mjs@labn.net>
Commit 76249532fa ("ospf6d: Handle Premature Aging of LSAs") added a
duplicate call to OSPF6_INTRA_PREFIX_LSA_EXECUTE_TRANSIT(), when the
interface state changes to "Down".
Fixes: #1738
Signed-off-by: David Ward <david.ward@ll.mit.edu>
This command makes unplanned GR more reliable by manipulating the
sending of Grace-LSAs and Hello packets for a certain amount of time,
increasing the chance that the neighboring routers are aware of
the ongoing graceful restart before resuming normal OSPF operation.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
In practical terms, unplanned GR refers to the act of recovering
from a software crash without affecting the forwarding plane.
Unplanned GR and Planned GR work virtually the same, except for the
following difference: on planned GR, the router sends the Grace-LSAs
*before* restarting, whereas in unplanned GR the router sends the
Grace-LSAs immediately *after* restarting.
For unplanned GR to work, ospf6d was modified to send a
ZEBRA_CLIENT_GR_CAPABILITIES message to zebra as soon as GR is
enabled. This causes zebra to freeze the OSPF routes in the RIB as
soon as the ospf6d daemon dies, for as long as the configured grace
period (the defaults is 120 seconds). Similarly, ospf6d now stores in
non-volatile memory that GR is enabled as soon as GR is configured.
Those two things are no longer done during the GR preparation phase,
which only happens for planned GRs.
Unplanned GR will only take effect when the daemon is killed
abruptly (e.g. SIGSEGV, SIGKILL), otherwise all OSPF routes will be
uninstalled while ospf6d is exiting. Once ospf6d starts, it will
check whether GR is enabled and enter in the GR mode if necessary,
sending Grace-LSAs out all operational interfaces.
One disadvantage of unplanned GR is that the neighboring routers
might time out their corresponding adjacencies if ospf6d takes too
long to come back up. This is especially the case when short dead
intervals are used (or BFD). For this and other reasons, planned
GR should be preferred whenever possible.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Effectively a massive search and replace of
`struct thread` to `struct event`. Using the
term `thread` gives people the thought that
this event system is a pthread when it is not
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
This is a first in a series of commits, whose goal is to rename
the thread system in FRR to an event system. There is a continual
problem where people are confusing `struct thread` with a true
pthread. In reality, our entire thread.c is an event system.
In this commit rename the thread.[ch] files to event.[ch].
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Consider the case where a DR router is performing a graceful restart,
and all neighbors attached to the DR network have their priorities
set to zero.
According to RFC 3623, the router should reclaim its DR status while
coming back up once it receives a Hello packet from a neighbor
listing the router as the DR, and the associated interface is in
Waiting state.
The problem arises when the DR election starts. Since the router
is already elected the DR, and no BDR will be elected (since all
neighbors have their priorities set to zero), the AdjOk event won't
be triggered at the end of the DR election as it would normally
happen. That causes all neighbors reachable over the broadcast
interface to get stuck in the 2-Way state.
Fix this corner case by always triggering the AdjOk event at the
end of the DR election process when a GR is in progress. Triggering
the AdjOk event when not necessary should never be a problem as
the neighbor FSM is already prepared to deal with that.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
When using auth keys in ospfv3, there are some memory
leaks when you change the key or remove the interface
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
donatas-pc# sh ipv6 ospf6 interface enp3s0
enp3s0 is up, type BROADCAST
Interface ID: 2
Internet Address:
inet : 192.168.10.17/24
inet6: fe80::ca5d:fd0d:cd8:1bb7/64
Instance ID 0, Interface MTU 1500 (autodetect: 1500)
MTU mismatch detection: enabled
Area ID 0.0.0.0, Cost 1000
State Waiting, Transmit Delay 1 sec, Priority 1
Timer intervals configured:
Hello 10(8.149), Dead 40, Retransmit 5
DR: 0.0.0.0 BDR: 0.0.0.0
Number of I/F scoped LSAs is 1
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication Trailer is disabled
donatas-pc# con
donatas-pc(config)# int enp3s0
donatas-pc(config-if)# ipv6 ospf6 passive
donatas-pc(config-if)# do sh ipv6 ospf6 interface enp3s0
enp3s0 is up, type BROADCAST
Interface ID: 2
Internet Address:
inet : 192.168.10.17/24
inet6: fe80::ca5d:fd0d:cd8:1bb7/64
Instance ID 0, Interface MTU 1500 (autodetect: 1500)
MTU mismatch detection: enabled
Area ID 0.0.0.0, Cost 1000
State Waiting, Transmit Delay 1 sec, Priority 1
Timer intervals configured:
No Hellos (Passive interface)
DR: 0.0.0.0 BDR: 0.0.0.0
Number of I/F scoped LSAs is 1
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication Trailer is disabled
donatas-pc(config-if)#
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
After all needed interfaces ( for example: interface "a1", vrf "vrf1", and
"a1" is binded to "vrf1" ) are ready/created, then restart/start frr. zebra
at startup will call `netlink_interface()` to process all interfaces and notify
all clients, but its calling `get_iflink_speed()` maybe fails for unexpected
order of the coming interfaces: when processing "a1", "vrf1" maybe is unknown
at that time. `if_zebra_speed_update()` timer is introduced to deal with this
order problem.
Currently only ospfd and ospf6d deal with this speed change to recalculated
route cost. ospfd can deal with this change, but ospf6d will wrongly missed it.
Since both `ipv6 ospf6 cost COST` and `auto-cost reference-bandwidth COST` are
not set, cost of this ospf6 interface should be calculated with interface
speed, but it is wrongly kept to `10`, which is based on interface speed being
`0` for it missed speed change. Further, ECMP function becomes invalid after
restart frr, beacuse some ospf6 interfaces of one ECMP are wrongly with cost
`10`.
To avoid missing, recalculate cost for ospf6 interfaces based on potentially
changed speed.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
topology: C1--R1---R2---R3--C2
client C1 connected to router node R1
client C2 connected to router node R3
router nodes R1,R2 and R3 are back to back connected
area 0 configured between R1 and R2
R1: all routes of area 0 are learnt successfully
R2: all routes of area 0 are learnt successfully
area 1 configured between R2 and R3
R2: all routes are learnt from R3
R3: routes learnt from C1 on ABR router R2 does not get forward to R3
root cause: on interface start, ABR schedule task is missing.
fix: handle ABR schedule during interface start event
Signed-off-by: Punith Kumar S <punith.shivakumar@sophos.com>
a) Remove setting of thread pointer to NULL after
thread invocation, this is already done.
b) Use thread_is_scheduled()
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
If a end users does something like this:
int enp39s0
ipv6 ospf6 hello-interval 65535
And then the timer pops and we send the hello and immediately
if the end user does this:
ipv6 ospf6 hello-interval 5
The timer is not being reset and FRR waits the full 65k seconds
before sending the hello again, which then immediately sets
the next hello to go out in 5 seconds.
When FRR receives the new timer value, look at how much time
is left on the timer in seconds. If this value is greater
than the new hello timer, stop the timer and set it too that
value.
This should fix a CI system test failure found, where the
system is testing setting timer from things like 12 seconds
to 65k seconds then back down to 12 and that the ospf6 neighbor
relationship stays up.
The code was also changed from thread_add_event to thread_add_timer
in all cases. I am not sure what would happen if a show command
comes in for a thread timer remaining with an event instead of a timer
just make it consistent.
This was chased down because the support bundle showed this:
r0# show ipv6 ospf6 vrf all interface
r0-r1-eth0 is up, type BROADCAST
Interface ID: 6
Internet Address:
inet6: fe80::a4ea:d3ff:fe35:cef1/64
inet6: fd00::1/64
Instance ID 0, Interface MTU 1500 (autodetect: 1500)
MTU mismatch detection: enabled
Area ID 0.0.0.0, Cost 10
State DR, Transmit Delay 1 sec, Priority 1
Timer intervals configured:
Hello 12(65480.960), Dead 48, Retransmit 5
And looking at the test code is doing stuff like this:
2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config)# interface r1-r0-eth0
2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 65535
2022/05/16 17:08:15 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# no ipv6 ospf6 hello-interval
2022/05/16 17:08:16 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 1
2022/05/16 17:08:16 OSPF6: [M7Q4P-46WDR] vty[5]@(config-if)# ipv6 ospf6 hello-interval 12
If the old timer value pops, the hello interval is set to 65k and never reset again.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When running `show ipv6 ospf6 interface` the hello timer period
is shown, but there is no indication on how much time is left
on the timer. Add a clue:
sharpd@eva ~/frr5 (master)> vtysh -c "show ipv6 ospf6 int"
enp39s0 is up, type BROADCAST
Interface ID: 2
Internet Address:
inet : 192.168.119.224/24
inet6: 2603:6080:602:509e:9a14:998:b154:9e9/64
Instance ID 0, Interface MTU 1500 (autodetect: 1500)
MTU mismatch detection: enabled
Area ID 0.0.0.0, Cost 1000
State DR, Transmit Delay 1 sec, Priority 1
Timer intervals configured:
Hello 10(2.652), Dead 40, Retransmit 5
DR: 192.168.122.1 BDR: 0.0.0.0
Number of I/F scoped LSAs is 1
0 Pending LSAs for LSUpdate in Time 00:00:00 [thread off]
0 Pending LSAs for LSAck in Time 00:00:00 [thread off]
Authentication Trailer is disabled
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Problem Statement:
==================
RFC 7166 support for OSPF6 in FRR code.
RCA:
====
This feature is newly supported in FRR
Fix:
====
Core functionality implemented in previous commit is
stitched with rest of ospf6 code as part of this commit.
Risk:
=====
Low risk
Tests Executed:
===============
Have executed the combination of commands.
Signed-off-by: Abhinay Ramesh <rabhinay@vmware.com>
