The only difference in daemons' interface node definition is the config
write function. No need to define the node in every daemon, just pass
the callback as an argument to a library function and define the node
there.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
RCA: When Type-7 LSA is updated, the LSDB is searched, if the
LSA is present in the LSDB then the LSA is updated with next
sequence number and if not then it is originated with the
INITIAL sequence number.
Here while originating Type-7 LSA Process Level LSDB is searched
for instead of area level LSDB.
Fix: Search in the area level LSDB and not in the process level.
Fixes#9099
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
* When the "cost" argument isn't present, the default cost should be
used instead of preserving the previously configured one (if any);
* When the "not-advertise" argument isn't present, the "not-advertise"
flag should be unset regardless if it was previously configured or
not.
Configuration commands should be deterministic and work in the same
way regardless of the current state.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
like the other automake variables, setting `xyz_LDFLAGS` causes
`AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind
that automake doesn't do this for LDFLAGS, but... it does. (Which is
consistent with `_CFLAGS` and co.)
So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which
includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and
`MODULE_LDFLAGS` to handle all of this correctly (and move these bits to
a central location.)
Fixes: #9034
Fixes: 0c4285d77e ("build: properly split CFLAGS from AC_CFLAGS")
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
This is a requirement for avoiding sending traffic somewhere it was not
supposed to go: install summary route to local RIB to send traffic to
Null0.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
This feature is required for creating summary routes that drop traffic
without more specific routes.
Authored-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Feature Implementation.
========================
This feature will help in advertising the External LSAs with aggregation.
The commands allow us to tune the advertisement with different parameters
as mentioned in the CLI List below.
It can also help in case we do not want to advertise any prefix with the
no-advertise option.
New CLIs added:
===============
summary-address X:X::X:X/M$prefix [tag (1-4294967295)] [{metric (0-16777215) | metric-type (1-2)}]
no summary-address X:X::X:X/M$prefix [tag (1-4294967295)] [{metric (0-16777215) | metric-type (1-2)}]
summary-address X:X::X:X/M$prefix no-advertise
no summary-address X:X::X:X/M$prefix no-advertise
aggregation timer (5-1800)
no aggregation timer (5-1800)
show ipv6 ospf6 summary-address [detail$detail] [json]
debug ospf6 lsa aggregation
CAT RUN:
========
QE to add test scripts
Signed-Off-by: Mobashshera Rasool <mrassol@vmware.com>
In RFC 2328 OSPF Version 2, Section 12.4.3.1 "Originating summary-LSAs
into stub areas" mentions that the stub areas should not import external
routes and instead should generate a 'default summary-LSA' set to
default destination.
> In a stub area, instead of importing external routes
> each area border router originates a "default summary-
> LSA" into the area. The Link State ID for the default
> summary-LSA is set to DefaultDestination, and the metric
> set to the (per-area) configurable parameter
> StubDefaultCost. Note that StubDefaultCost need not be
> configured identically in all of the stub area's area
> border routers.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
The OSPF6_INTERFACE_LOOPBACK interface state wasn't entered anywhere,
even if the interface was OSPF6_IFTYPE_LOOPBACK. Fix.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
When ospf6d comes up, it gets interface and address state before it
decides on its router ID. This results in a bunch of LSAs with
advertising router ID 0.0.0.0 in the LSDB. Not quite right.
There's a whole bunch of paths leading to this, so just drop the LSA in
ospf6_lsa_originate. The router-ID change causes everything to be
readvertised anyway (... but the delete doesn't catch the 0.0.0.0 stuff
because the router-ID is now different.)
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Prefix options are per-prefix, not per-path. As evident by the fact
that the field is never used on ECMP paths. Move it where it belongs.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Somehow the hello message debugging code slipped outside the debug
guard. Lets just remove it.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
There's a delay in FreeBSD between issuing a command to leave a
multicast group and an actual leave. If we execute "no router ospf6" and
"router ospf6" fast enough, we can end up in a situation when OS
performs the leave later than it performs the join and the interface
remains without a multicast group.
Instead of counting on a one second delay, we must wait until the
interface actually leaves the group.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
Move code to its own function and remove most of the code indentation
(e.g. test for failure and quit as soon as possible).
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Move `is_default_prefix` variations to `lib/prefix.h` and make the code
use the library version instead of implementing it again.
NOTE
----
The function was split into per family versions to cover all types.
Using `union prefixconstptr` is not possible due to static analyzer
warnings which cause CI to fail.
The specific cases that would cause this failure were:
- Caller used `struct prefix_ipv4` and called the generic function.
- `is_default_prefix` with signature using `const struct prefix *` or
`union prefixconstptr`.
The compiler would complain about reading bytes outside of the memory
bounds even though it did not take into account the `prefix->family`
part.
Signed-off-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
This code has been wrong ~ever (according to git history). There are 3
conditional blocks with the added assertion that both the LSA and the
vertex being checked can't both be network LSAs.
The third block is clearly assuming both LSA and vertex are router
LSAs b/c it is accessing the backlink and lsdesc as router lsdesc's also
making sure both are p2p links (which they would have to be to point at
each other).
The programming error here is that (A && B) == False does NOT imply !A,
but the code is written that way.
So we end up in the third block one of LSA or vertex being network LSAs
rather easily (whenever that is the case and the desc isn't the backlink
being sought).
This was caught by ASAN b/c the lsdesc and backlinks are being accessed
(> 4 byte field offsets) as if they were router lsdesc's in the third
block, when in fact one of them is a network lsdesc which is only 4
bytes long -- so ASAN flags the access beyond bounds.
Signed-off-by: Christian Hopps <chopps@labn.net>
Issue: Crash observed when LSAs are removed from LSDB after max age
when there is no area configured.
(gdb) bt
0 raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
1 0x00007fdb190548bc in core_handler (signo=6, siginfo=0x7ffdd2f5a470, context=<optimized out>) at lib/sigevent.c:262
2 <signal handler called>
3 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
4 0x00007fdb185ad921 in __GI_abort () at abort.c:79
5 0x00007fdb1907f199 in _zlog_assert_failed (xref=xref@entry=0x55f30902aa20 <_xref.21999>, extra=extra@entry=0x0) at lib/zlog.c:581
6 0x000055f308dc4f78 in ospf6_asbr_lsa_remove (lsa=0x55f30a7546d0, asbr_entry=0x0) at ospf6d/ospf6_asbr.c:696
7 0x000055f308dd8f0d in ospf6_lsdb_remove (lsa=0x55f30a7546d0, lsdb=lsdb@entry=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:166
8 0x000055f308dd9701 in ospf6_lsdb_maxage_remover (lsdb=0x55f30a73d300) at ospf6d/ospf6_lsdb.c:376
9 0x000055f308dee724 in ospf6_maxage_remover (thread=<optimized out>) at ospf6d/ospf6_top.c:603
10 0x00007fdb1906520d in thread_call (thread=thread@entry=0x7ffdd2f5ae90) at lib/thread.c:1919
11 0x00007fdb19023e48 in frr_run (master=0x55f30a569b70) at lib/libfrr.c:1155
12 0x000055f308dc09b6 in main (argc=6, argv=0x7ffdd2f5b198, envp=<optimized out>) at ospf6d/ospf6_main.c:235
(gdb)
Steps to reproduce the issue:
1. router ospf6
2. redistribute static
3. ipv6 route 1::1/128 Null0
4. no redistribute static
5. wait for Max aged LSA to flush
6. Check DB, crash occurs.
RCA:
Crash occurred while accessing listgetdata(listhead(ospf6->area_list))
When there is no area attached to any of the interface listhead(ospf6->area_list)
is NULL. Therefore it crashed due to NULL access.
Fix:
Check before accessing null pointer.
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
Harmonize the code of functions ospf6_asbr_redistribute_disable and
ospf6_asbr_redistribute_reset.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
The ospf6 router-id is provided by order of preference by:
ospf6d itself if the "ospf6 router-id X.X.X.X" command is set.
- zebra. If the "ip router-id X.X.X.X" zebra command is set, the
configured IP is provided as the ID or alternatively the highest
loopback IPv4 address or else the highest interface IPv4 address.
The running ospf6 router-id is stored in ospf6->router-id.
ospf6->router-id can change in the following conditions:
- A configuration change provides a new router-id value according to
the above rules. ospf6->router-id is updated to the new value if
there is no adjacency in FULL state. Otherwise, the ospf6d process
must be restarted to take the new router-id into account.
- On startup of both zebra and ospf6d, if ospf6d has not yet received a
valid router-id, ospf6d->router-id is set to 0 (i.e. 0.0.0.0). Then,
zebra notifies ospf6d that the router-id is available.
At ospf6->router-id, the current behavior of ospf6d is the following:
- The self generated LSAs that refer to the previous router-id as the
advertising router are kept.
- Self generated LSAs are created with router-id value.
- LSAs from the redistribution that refer to the previous router-id are
kept and no new redistribution LSAs are created.
As a consequence, the routers in the ospf6 areas will get incorrect
LSAs and might not be able to install prefixes of those LSAs into their
RIB.
This fix solves this issue by resetting the areas and the redistribution
when ospf6->router-id updated.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
ospf6_router_id_update function is used by ospf6_router_id_update_zebra
to update the running the ospf6 router-id.
This patches makes the functions to (un)configure ospf6 router-id use
the same function as ospf6_router_id_update_zebra.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
---
When a router-id change is notified by zebra to ospf6d, we only take
into account the change if no adjacencies are in Full state.
Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com>
Problem Statement:
==================
when route-map config is changed from permit to deny, it is not getting
applied to both connected and static and vice versa
RCA:
==================
When route-map changes from permit to deny or vice versa, a notification is
sent to ospf6 daemon via ospf6_asbr_routemap_update. In this function, a thread
is scheduled after 5 seconds to apply the route-map changes. In this thread
(ospf6_asbr_routemap_update_timer), only the first type is passed as argument
and only the first type i.e "connected" is passed and hence in callback only
on this type of route route-map gets applied.
Fix:
====
Need to loop through all the route-types in the call back and process
the route-map changes. Added a flag to mark which all route-types needs
to be processed.
Test Executed:
===============
1. Change route-map from permit to deny.
2. Change route-map from deny to permit.
3. Add new route and checked.
4. Verified summarised routes.
Risk:
============
Low
Signed-off-by: Mobashshera Rasool <mrasool@vmware.com>
