Rather than running selected source files through the preprocessor and a
bunch of perl regex'ing to get the list of all DEFUNs, use the data
collected in frr.xref.
This not only eliminates issues we've been having with preprocessor
failures due to nonexistent header files, but is also much faster.
Where extract.pl would take 5s, this now finishes in 0.2s. And since
this is a non-parallelizable build step towards the end of the build
(dependent on a lot of other things being done already), the speedup is
actually noticeable.
Also files containing CLI no longer need to be listed in `vtysh_scan`
since the .xref data covers everything. `#ifndef VTYSH_EXTRACT_PL`
checks are equally obsolete.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Problem:
Multiple memory leaks in ospf6.
260 ==6637== 32 bytes in 1 blocks are definitely lost in loss record 5 of 24
261 ==6637== at 0x4C31FAC: calloc (vg_replace_malloc.c:762)
262 ==6637== by 0x4E8A1BF: qcalloc (memory.c:111)
263 ==6637== by 0x11EE27: ospf6_summary_add_aggr_route_and_blackhole (ospf6_asbr.c:2779)
264 ==6637== by 0x11EEBA: ospf6_originate_new_aggr_lsa (ospf6_asbr.c:2811)
265 ==6637== by 0x4E7C6A7: hash_clean (hash.c:325)
266 ==6637== by 0x11FA93: ospf6_handle_external_aggr_update (ospf6_asbr.c:3164)
267 ==6637== by 0x11FA93: ospf6_asbr_summary_process (ospf6_asbr.c:3386)
268 ==6637== by 0x4EB739B: thread_call (thread.c:1692)
269 ==6637== by 0x4E85B17: frr_run (libfrr.c:1068)
270 ==6637== by 0x119535: main (ospf6_main.c:228)
356 ==6637== 240 bytes in 12 blocks are indirectly lost in loss record 13 of 24
357 ==6637== at 0x4C2FE96: malloc (vg_replace_malloc.c:309)
358 ==6637== by 0x4E8A0DA: qmalloc (memory.c:106)
359 ==6637== by 0x13545C: ospf6_lsa_alloc (ospf6_lsa.c:724)
360 ==6637== by 0x1354E3: ospf6_lsa_create_headeronly (ospf6_lsa.c:756)
361 ==6637== by 0x1355F2: ospf6_lsa_copy (ospf6_lsa.c:790)
362 ==6637== by 0x13B58B: ospf6_dbdesc_recv_slave (ospf6_message.c:976)
363 ==6637== by 0x13B58B: ospf6_dbdesc_recv (ospf6_message.c:1038)
364 ==6637== by 0x13B58B: ospf6_read_helper (ospf6_message.c:1838)
365 ==6637== by 0x13B58B: ospf6_receive (ospf6_message.c:1875)
366 ==6637== by 0x4EB739B: thread_call (thread.c:1692)
367 ==6637== by 0x4E85B17: frr_run (libfrr.c:1068)
368 ==6637== by 0x119535: main (ospf6_main.c:228)
RCA:
1. when the ospf6 area is being deleted, the neighbor related information
was not being cleaned up.
2. when aggr route gets deleted from rt_aggr_tbl the corrsponding summary
route attched to the aggr route was not being deleted.
Fix:
Added the ospf6_neighbor_delete in ospf6_area_delete to free the
neighbor related information and added ospf6_route_delete while
freeing external aggr route to free the summary route.
Signed-off-by: Manoj Naragund <mnaragund@vmware.com>
This PR will include if the area is NSSA in the output of "show ipv6 ospf"
r2# show ipv6 ospf
...
Area 0.0.0.0
Number of Area scoped LSAs is 8
Interface attached to this area: r2-eth1
SPF last executed 20.46717s ago
Area 0.0.0.1[Stub]
Number of Area scoped LSAs is 9
Interface attached to this area: r2-eth0
SPF last executed 20.46911s ago
Area 0.0.0.2[NSSA]
Number of Area scoped LSAs is 14
Interface attached to this area: r2-eth2
SPF last executed 20.46801s ago
Signed-off-by: ckishimo <carles.kishimoto@gmail.com>
Currently the ospf6d's commands with non-exist vrfs can't give the error
informations to users.
This commit adds a macro "OSPF6_CMD_CHECK_VRF" to give error information
if with non-exist vrfs. As usual, skip the checking process in the case
of json.
So one command can call this macro to do the checking process in its
end. At that time it need know json style or not, so add "json" parameter for
several related functions.
BTW, suppress the build warning of the macro `OSPF6_FIND_VRF_ARGS`:
"Macros starting with if should be enclosed by a do - while loop to avoid
possible if/else logic defects."
Signed-off-by: anlan_cs <anlan_cs@tom.com>
Implement NSSA address ranges as specified by RFC 3101:
NSSA border routers may be configured with Type-7 address ranges.
Each Type-7 address range is defined as an [address,mask] pair. Many
separate Type-7 networks may fall into a single Type-7 address range,
just as a subnetted network is composed of many separate subnets.
NSSA border routers may aggregate Type-7 routes by advertising a
single Type-5 LSA for each Type-7 address range. The Type-5 LSA
resulting from a Type-7 address range match will be distributed to
all Type-5 capable areas.
Syntax:
area A.B.C.D nssa range X:X::X:X/M [<not-advertise|cost (0-16777215)>]
Example:
router ospf6
ospf6 router-id 1.1.1.1
area 1 nssa
area 1 nssa range 2001:db8:1000::/64
area 1 nssa range 2001:db8:2000::/64
!
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add the "default-information-originate" option to the "area X nssa"
command. That option allows the origination of Type-7 default routes
on NSSA ABRs and ASBRs.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Issue #9535 describes how the export-list/import-list commands work
differently on ospfd and ospf6d.
In short:
* On ospfd, "area A.B.C.D export-list" filters which internal
routes an ABR exports to other areas. On ospf6d, instead, that
command filters which inter-area routes an ABR exports to the
configured area (which is quite counter-intuitive). In other words,
both commands do the same but in opposite directions.
* On ospfd, "area A.B.C.D import-list" filters which inter-area
routes an ABR imports into the configured area. On ospf6d, that
command filters which inter-area routes an interior router accepts.
* On both daemons, "area A.B.C.D filter-list prefix NAME <in|out>"
works exactly the same as import/export lists, but using prefix-lists
instead of ACLs.
The inconsistency on how those commands work is undesirable. This
PR proposes to adapt the ospf6d commands to behave like they do
in ospfd.
These changes are obviously backward incompatible and this PR doesn't
propose any mitigation strategy other than warning users about the
changes in the next release notes. Since these ospf6d commands are
undocumented and work in such a peculiar way, it's unlikely many
users will be affected (if any at all).
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
Add a knob to turn a NSSA area into a totally stub area. In this
configuration a Type-3 default summary route is generated by default.
Syntax: `area A.B.C.D nssa no-summary`.
Signed-off-by: Renato Westphal <renato@opensourcerouting.org>
* 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>
The ospf6_is_router_abr is checking to see if ospfv3 is an abr router
and also setting values. Let's rename it too `ospf6_check_and_set_router_abr`
to more accurately reflect what it is doing.
Additionally fix coverity #1505176 where we were not checking the return
value of ospf6_is_router_abr like we did every other time. In this
case we don't care about the return value so indicate that we do not.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently the interface area is configured from the router node using
"interface IFNAME area ID" command. There are multiple problems with
this command:
- it is not in line with all other interface-related commands - other
parameters are configured from the interface node using "ipv6 ospf6"
prefix
- it is not in line with OSPFv2 - area is configured from the interface
node using "ip ospf area" command
- most importantly, it doesn't work correctly when the interface is in
a different VRF - instead of configuring the interface, it creates a
new fake interface and configuring it instead
To fix all the problems, this commit adds a new command to the interface
configuration node - "ipv6 ospf6 area ID". The purpose of the command is
completely the same, but it works correctly in a multi-VRF environment.
The old command is preserved for the backward compatibility, but the
warning is added that it is deprecated because it doesn't work correctly
with VRFs.
Signed-off-by: Igor Ryzhov <iryzhov@nfware.com>
The following is implemented.
1. Configuring area as NSSA.
2. Generating Type 7 LSA.
3. Conversion of Type 7 to Type 5 ( Default Behavior).
4. NSSA ABR selection.
Reviewed-by: Rafael Zalamena <rzalamena@opensourcerouting.org>
Co-authored-by: Kaushik <kaushiknath.null@gmail.com>
Co-authored-by: Soman K.S <somanks@gmail.com>
Signed-off-by: Kaushik <kaushiknath.null@gmail.com>
When an "export-filter" or "filter-list out" was configured on an area the
filter was not applied to existing database. The user would either have
to restart the neighboring router in the other area or issue a "clear ipv6
ospf6 interface" to cause the neighbor router to resend it's LSAs. The
new filter would then be applied to these LSAs and permit or deny summary
LSAs from being added/removed from the database. The code now applies the
filters to the existing database without user needing to take any action
to clear ospfv3 adjacencies.
The second part of the problem was if a rule changed the updated filter was
not applied. The code has been modifed to now process the rule update and
reapply the filter.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
Same as other commits -- convert most DEFINE_MTYPE into the _STATIC
variant, and move the remaining non-static ones to appropriate places.
Signed-off-by: David Lamparter <equinox@diac24.net>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
If area is a normal area and has adjacencies up and then the user changes
the area to a stub area, the code was leaving existing AS-External LSAs in
the database and was sending AS-External LSAs into the stub area causing
the adjacency to stay in Ex-Start. With this change we now cleanup the
AS-External LSAs that existed when area was not a stub and do not advertise
AS-External LSAs into the stub area.
Signed-off-by: Lynne Morrison <lynne@voltanet.io>
1. All the changes are related to handle ospf6 with different vrf.
2. The dependancy of global ospf6 is removed.
Co-authored-by: Kaushik <kaushik@niralnetworks.com>
Signed-off-by: harios_niral <hari@niralnetworks.com>
The ospf6 "interface <blah> area <x>" command only allows the area to
be specified in the ipv4 address format, whereas the show run command
always shows it in the format in which the area was created. This causes
the frr-reload script to be unable to remove ospfv3 interfaces when the
area was created in decimal format. The solution is to allow both formats
to be configured as they can be for other area commands.
Signed-off-by: Duncan Eastoe <duncan.eastoe@att.com>
there are some events where the list of interfaces per area should be
reviewed due to an interface is being removed. This fix avoids having
some memory leak.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
it was not possible to configure per area identifier under decimal
format some ospf6 area options. this is the case of filter list, or
export-list.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Issue: # https://github.com/FRRouting/frr/issues/1836
Issue 1: if the router ospf current configuration is "area 0.0.0.2
range 1.0.0.0/24 cost 23" and user try to configure "area 0.0.0.2
range 1.0.0.0/24 not-advertise", the existing o/p is "area 0.0.0.2
range 1.0.0.0/24 cost 23 not-advertise". The keywords "not-advertise"
& "cost" are multually exclusive, so they should not come together.
The vice versa way configuration is working fine.
Fix: When ospf area range "not-advertise", the cost should be initialized
to OSPF_AREA_RANGE_COST_UNSPEC.
Issue 2: if the router ospf current configuration "area 0.0.0.2 range
1.0.0.0/24 substitute 2.0.0.0/24" and user try to configure "area 0.0.0.2
range 1.0.0.0/24 not-advertise" the existing o/p is "area 0.0.0.2 range
1.0.0.0/24 not-advertise substitute 2.0.0.0/24". The keywords
"not-advertise" & "substiture" are multually exclusive, so they should
not come together. The vice versa way configuration is working fine.
Fix: When ospf area range "not-advertise" is configured,
ospf_area_range_substitute_unset() should be get called.
Issue 3: if the router ospf6 current configuration is "area 0.0.0.2
range 2001::/64 cost 23" and user try to configure "area 0.0.0.2 range
2001::/64 advertise", the existing o/p is area 0.0.0.2 range 2001::/64.
The keyword "cost 23" disappears.
Fix: When ospf area range "advertise" is configured and the range is not
NULL, the cost should not be modified.
Signed-off-by: Sarita Patra <saritap@vmware.com>
The following types are nonstandard:
- u_char
- u_short
- u_int
- u_long
- u_int8_t
- u_int16_t
- u_int32_t
Replace them with the C99 standard types:
- uint8_t
- unsigned short
- unsigned int
- unsigned long
- uint8_t
- uint16_t
- uint32_t
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
