Valgrind reports:
2437395-==2437395== Invalid read of size 8
2437395:==2437395== at 0x40B610: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:327)
2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395== Address 0x5c668a8 is 24 bytes inside a block of size 256 free'd
2437395:==2437395== at 0x48399AB: free (vg_replace_malloc.c:538)
2437395-==2437395== by 0x429027: ospf6_route_delete (ospf6_route.c:419)
2437395-==2437395== by 0x429027: ospf6_route_unlock (ospf6_route.c:460)
2437395-==2437395== by 0x429027: ospf6_route_remove (ospf6_route.c:887)
2437395-==2437395== by 0x40B343: ospf6_asbr_update_route_ecmp_path (ospf6_asbr.c:318)
2437395-==2437395== by 0x40BC7C: ospf6_asbr_lsa_add (ospf6_asbr.c:544)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
2437395-==2437395== Block was alloc'd at
2437395:==2437395== at 0x483AB65: calloc (vg_replace_malloc.c:760)
2437395-==2437395== by 0x48D2A32: qcalloc (memory.c:115)
2437395-==2437395== by 0x427CE4: ospf6_route_create (ospf6_route.c:402)
2437395-==2437395== by 0x40BA8A: ospf6_asbr_lsa_add (ospf6_asbr.c:490)
2437395-==2437395== by 0x40C5DF: ospf6_asbr_lsentry_add (ospf6_asbr.c:829)
2437395-==2437395== by 0x42D88D: ospf6_top_brouter_hook_add (ospf6_top.c:185)
2437395-==2437395== by 0x4188E3: ospf6_intra_brouter_calculation (ospf6_intra.c:2320)
2437395-==2437395== by 0x42C624: ospf6_spf_calculation_thread (ospf6_spf.c:638)
2437395-==2437395== by 0x4904B7E: thread_call (thread.c:1681)
2437395-==2437395== by 0x48CAA27: frr_run (libfrr.c:1126)
2437395-==2437395== by 0x40AF43: main (ospf6_main.c:232)
ospfv3 loops through the ecmp routes to decide what to clean up. In some
situations the code free's up an existing route at the head of the list.
Cleaning the pointers in the list but never touching the original pointer.
In that case notice and update the old pointer.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When redistributing multiple route types into ospfv3
the code must create a new array per route type into
the the json code.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
1. Created new ospf6_redist structure.
2. Moved the 'route_map' structure from structure 'ospf6' to
structure 'ospf6_redist'.
3. Added new message type OSPF6_REDISTRIBUTE.
4. Added the placeholder for metric option in structure ospf6_redist
for redistribute.
5. Added few API's for route redistribute lookup, add & del.
Signed-off-by: Kaushik <kaushik@niralnetworks.com>
Modify code to add JSON format output in show command
"show ipv6 ospf6 redistribute" with proper formating
Signed-off-by: Yash Ranjan <ranjany@vmware.com>
The route_map_object_t was being used to track what protocol we were
being called against. But each protocol was only ever calling itself.
So we had a variable that was only ever being passed in from route_map_apply
that had to be carried against and everyone was testing if that variable
was for their own stack.
Clean up this route_map_object_t from the entire system. We should
speed some stuff up. Yes I know not a bunch but this will add up.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
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 code pattern:
for (ALL_LSDB(lsdb, lsa)) {
remove_lsa(lsa)
}
has a use after free in ALL_LSDB, since we ask for the next pointer,
after it has been freed.
Modify the code such that we grab the next pointer before we can
possibly free it.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
1. Removed the VRF_DEFAULT dependency from ospf6d.
2. The dependency on show command still exist
will be fixed when the ospf6 master is available.
Co-authored-by: Harios <hari@niralnetworks.com>
Signed-off-by: Kaushik <kaushik@niralnetworks.com>
Problem reported that when an a previously advertised redistributed
route should be withdrawn based on a prefix-list change or route-map
deletion, the external LSAs would remain in the database and not be
withdrawn from peers. This fix does the withdraw when the prefix-list
is changed or route-map is deleted.
Ticket: CM-28944
Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
We are seeing this crash:
New LWP 7673]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/frr/ospf6d -d -F datacenter -M snmp -A ::1'.
Program terminated with signal SIGABRT, Aborted.
(gdb) bt
vtysh=vtysh@entry=0) at lib/command.c:1288
(gdb)
The command entered is `debug ospf6 lsa inter-router examin`. Code
inspection leads us to the fact that FRR is declaring the data as
const but we are attempting to modify it, causing the crash.
Remvoe the const of this set/get and let things work.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
User pass the string match large-community 1 exact-match from CLI.
Now route map lib has got the string as "1 exact-match". It passes the string
to call back for compilation. BGP will parse this string and came to know
that for "1" it has to do exact match. Routemap lib has to save "1" in it’s
dependency table. Here routemap is saving this as a “1 exact-match”
which is wrong. The solution is used the compiled data.
Signed-off-by: vishaldhingra <vdhingra@vmware.com>
Conver these functions:
route_map_add_match
route_map_delete_match
route_map_add_set
route_map_delete_set
To return the `enum rmap_compile_rets` and ensure all functions
that use this code handle all the enumerated possible returns.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
State1:
If match cmd returns RMAP_MATCH then, keep existing behaviour.
If routemap type is PERMIT, execute set cmds or call cmds if applicable,
otherwise PERMIT!
Else If routemap type is DENY, we DENYMATCH right away
State2:
If match cmd returns RMAP_NOMATCH, continue on to next route-map. If there
are no other rules or if all the rules return RMAP_NOMATCH, return DENYMATCH
We require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Also, this rule should be applicable for routes with VNI label only, and
not for routes without labels. For example, type 3 and type 4 EVPN routes
do not have labels, so, this match cmd should let them through.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
As a result we have a 3rd state:
State3:
If match cmd returned RMAP_NOOP
Then, proceed to other route-map, otherwise if there are no more
rules or if all the rules return RMAP_NOOP, then, return RMAP_PERMITMATCH.
Signed-off-by: Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
the vrf_id parameter is replaced by struct vrf * parameter.
this impacts most of the daemons that look for an interface based on the
name and the vrf identifier.
Also, it fixes 2 lookup calls in zebra and sharpd, where the vrf_id was
ignored until now.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Introducing a 3rd state for route_map_apply library function: RMAP_NOOP
Traditionally route map MATCH rule apis were designed to return
a binary response, consisting of either RMAP_MATCH or RMAP_NOMATCH.
(Route-map SET rule apis return RMAP_OKAY or RMAP_ERROR).
Depending on this response, the following statemachine decided the
course of action:
Action: Apply route-map match and return the result (RMAP_MATCH/RMAP_NOMATCH)
State1: Receveived RMAP_MATCH
THEN: If Routemap type is PERMIT, execute other rules if applicable,
otherwise we PERMIT!
Else: If Routemap type is DENY, we DENYMATCH right away
State2: Received RMAP_NOMATCH, continue on to next route-map, otherwise,
return DENYMATCH by default if nothing matched.
With reference to PR 4078 (https://github.com/FRRouting/frr/pull/4078),
we require a 3rd state because of the following situation:
The issue - what if, the rule api needs to abort or ignore a rule?:
"match evpn vni xx" route-map filter can be applied to incoming routes
regardless of whether the tunnel type is vxlan or mpls.
This rule should be N/A for mpls based evpn route, but applicable to only
vxlan based evpn route.
Today, the filter produces either a match or nomatch response regardless of
whether it is mpls/vxlan, resulting in either permitting or denying the
route.. So an mpls evpn route may get filtered out incorrectly.
Eg: "route-map RM1 permit 10 ; match evpn vni 20" or
"route-map RM2 deny 20 ; match vni 20"
With the introduction of the 3rd state, we can abort this rule check safely.
How? The rules api can now return RMAP_NOOP (or another enum) to indicate
that it encountered an invalid check, and needs to abort just that rule,
but continue with other rules.
Question: Do we repurpose an existing enum RMAP_OKAY or RMAP_ERROR
as the 3rd state (or create a new enum like RMAP_NOOP)?
RMAP_OKAY and RMAP_ERROR are used to return the result of set cmd.
We chose to go with RMAP_NOOP (but open to ideas),
as a way to bypass the rmap filter
As a result we have a 3rd state:
State3: Received RMAP_NOOP
Then, proceed to other route-map, otherwise return RMAP_PERMITMATCH by default.
Signed-off-by:Lakshman Krishnamoorthy <lkrishnamoor@vmware.com>
The route_map_event_hook callback was passing the `route_map_event_t`
to each individual interested party. No-one is ever using this data
so let's cut to the chase a bit and remove the pass through of data.
This is considered ok in that the routemap.c code came this way
originally and after 15+ years no-one is using this functionality.
Nor do I see any `easy` way to do anything useful with this data.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Made changes and updated the routemap applied
counter in the following flows.
1.Increment the routemap applied counter when route map
attached to a redistribution list.
The counter will be updated if the routemap exists.
2.Decrement when route map removed / modified from a
redistribution list.
3.Increment/decrement when route map create/delete
callback triggered.
Signed-off-by: RajeshGirada <rgirada@vmware.com>
When calling route_map_finish, every place that we do we must
first set the deletion event to NULL, or we will create an infinite
loop, if we are using the delayed route-map application code.
As such we might as well just make the route_map_finish code
do this work, as that there is really no viable alternative here
and route_map_finish should only be called on shutdown.
This fixes an infinite loop in zebra on shutdown when there
are route-maps.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Inter Area Prefix LSA ECMP is not working properly.
Two ABRs advertising IAP routes to backbone, not installed
with correct cost or if ABR restarted the route is removed
from backbone.
The current implementation ABR was not suppressing IAP update
for prefix cost is not better or route is not installed.
The better cost or path route was overwritten with non optimal
cost. This caused a loop with nexthops pointing each other
at backbone and non-backbone routers.
Consider to only send BEST/installed route's IAP notification
at ABRs.
When receiving IAP update from multiple ABRs, preserve multiple
advertising routers under the prefix route node.
Upon LSA maxage only remove the advertising route's which is
impacted and update route's nexthops and update FIB.
Testing Done:
Top to Bottom is part of area 0 on the Right, and
from Left side in area 1.
Top and Bottom act as ABRs.
H1 route is sent as Inter-Area Prefix to Right.
Trigger multiple triggers for ABR routes.
1) Shutting down link between, top to right to eliminate nhs
2) Restart frr at Top.
3) Restart frr at Right.
+-----------+
. |
,'| Top |`.
/ . | \
,' ,'+.----------+`. `.
/ / ` `. \ ',
,' ,' ,' \ `. .
- / ` `. ', `,
,` ,` ,' \ \ \
' - ` `. `, `,
+--------+ +--`--`--`--+ +---'---'--'+ +--------+
| | | | | | | |
| H1 ------ Left | | Right ------ H2 |
| | | | | | | |
+--------+ +-----------+ +----.--,-,-+ +--------+
`. ` \ - / /
\ `. ` ,' .` `
' . \ / / '
`. \ `. ` / ,'
\ ` . ,` / /
`. `. . / / /
\ . \ ,' ' /
' '--'--------+,'.`
`.| - /
' mid1 |/
| -
+-----------+
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Use brouter table to fetch nexthops for
asbr prefix (external) routes.
Change adv. router of the router's path once
the DB/FIB is updated with effective nexthops.
Cleanup of nexthop update when route's adv
router changes cost.
Ticket:CM-16139
Testing Done:
Tested ASBR external routes in CLOS topology with
multiple paths asbr originator at tor to spine.
Validated external route's nexthop within
area and inter area.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Durig ospf6 instance cleanup all border routers
are removed from the db then external LSAs removal
from DB is triggered. During the time, external route
path would not be valid as brouters along with its
rechability have vanished.
For a given external route removal check if no more
paths available simple remove the route from route db.
Ticket:CM-20669
Testing Done:
Bring up ASBR configuration with ECMP paths to a route.
Bring down the ospf6 instance and validate route is removed
from the DB.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.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>
We create route_to_del and then on the error path
we are not properly freeing it up. Let's clean it
up for the goodness of mankind.
Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
The route being added check its origin matches,
with any of the existing path (list of paths).
Remove the existing path, add if its cost is
eqaual or less than any of the existing path.
For a given route and of existing path cost is lower
(better) than one being added, discard new route update.
The existing path cost is higher (lower) than one being
added, ospf6_route_add replaces existing with new route
info.
Compare cost between delete request and with existing
route.
Ticket:CM-16139
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
RFC 2328 (14.1) Premature aging of LSAs from
routing domain :
When ospf6d is going away (router going down),
send MAXAGEd self originated LSAs to all
neighbors in routing domain to trigger
Premature aging to remove from resepective LSDBs.
Neighbor Router Reboot:
Upon receiving Self-originate MAXAGEd LSA, simply
discard, Current copy could be non maxaged latest.
For neighbor advertised LSA's (current copy in LSDB)
is set to MAXAGE but received new LSA with Non-MAXAGE
(with current age), discard the current MAXAGE LSA,
Send latest copy of LSA to neighbors and update the
LSDB with new LSA.
When a neighbor transition to FULL, trigger AS-External
LSAs update from external LSDB to new neighbor.
Testing:
R1 ---- DUT --- R5
| \
R2 R3
|
R4
Area 1: R5 and DUT
Area 0: DUT, R1, R2, R3
Area 2: R2 R4
Add IPv6 static routes at R5
Redistribute kernel routes at R5,
Validate routes at R4, redistributed via backbone
to area 2.
Stop n start frr.service at R5 and validated
MAXAGE LSAs then recent age LSAs in Database at DUT-R4.
Validated external routes installed DUT to R4.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Add hook for route-map update event.
Add a delay one shot timer to accomodate route-map
update and reset redist with zebra to process
all redistribute routes with route-map info.
Cleanup route-map, prefix cached date during ospf6 exit.
Ticket:CM-13800
Testing Done:
configure redistribute connected with route-map to define
type-2 routes. Restart frr.service and validated
route-map add,update event, thread is scheduled,
once timer is done redist reset with zebra.
Upon redist add notification, all route map info is cached
in ospf6 and processed as type-2 route and send ASE E2 LSA.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
Handle RFC 2328 16.4 Calculating AS external routes with ECMP
For ASBR route, if it is learnt via new LSA and contains
different nexthop list. First lookup route in ospf6 route table
if it exists, merge nexthop list to existing and call the callback
to install into FIB (zebra). Delete created new route as it is
identical to existing entry in route table.
Ticket:CM-16139
Testing Done:
Run two ASBR with 2 ECMP paths from each
DUT neighbor receievs 4 ECMP path to a external route.
ospf6 installs all 4 ECMP path to FIB/RIB
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
When ospf6 configure with redistribute connected/protocol
with route-map. Upon restart of frr.service, ospf6 receives
redistribute update then route-map update.
During redistribute route update, since route-map info is not
filled, route is suppressed from injected as external route.
Fix: reset redistribute when route-map update received
matches with redistribution (type) and route-map name.
Ticket:CM-13800
Testing Done:
Configure ospf6 redistribute with route-map to inject
Type-2 external routes into database. Trigger frr restart
redistribute with route-map happens.
Signed-off-by: Chirag Shah <chirag@cumulusnetworks.com>
